a couple of git issues

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

a couple of git issues

Eliot Miranda-2
 
Hi All,

    first, is there a way we can modify the checkin script (scripts/gitci) to check for incoming changes so that by default the check-in fails?  Some people may check automatically but I always forget and its annoying to have to merge later on.

    second, to eliminate this error message:

remote: Resolving deltas: 100% (17/17), completed with 8 local objects.
remote: This repository moved. Please use the new location:

should I simply edit .git/configure to change

[remote "origin"]

to

?  Or something else?

_,,,^..^,,,_
best, Eliot
Reply | Threaded
Open this post in threaded view
|

Re: a couple of git issues

alistairgrant
 
Hi Eliot,

On Thu, Apr 27, 2017 at 07:41:46PM -0700, Eliot Miranda wrote:

>  
> Hi All,
>
>     first, is there a way we can modify the checkin script (scripts/gitci) to
> check for incoming changes so that by default the check-in fails?  Some people
> may check automatically but I always forget and its annoying to have to merge
> later on.
>
>     second, to eliminate this error message:
>
> remote: Resolving deltas: 100% (17/17), completed with 8 local objects.
> remote: This repository moved. Please use the new location:
> remote:   https://github.com/OpenSmalltalk/opensmalltalk-vm.git
> To http://github.com/OpenSmalltalk/vm
>
> should I simply edit .git/configure to change
>
> [remote "origin"]
> url = http://github.com/OpenSmalltalk/vm
>
> to
>
> [remote "origin"]
> url = https://github.com/OpenSmalltalk/opensmalltalk-vm.git
>
> ?  Or something else?


You can view the repository URL(s) with:

  git remote -v

and change them with:

  git remote set-url origin https://github.com/OpenSmalltalk/opensmalltalk-vm.git

and of course:

  git remote --help

for more information.

Cheers,
Alistair
Reply | Threaded
Open this post in threaded view
|

Re: a couple of git issues

Tobias Pape
In reply to this post by Eliot Miranda-2
 

> On 28.04.2017, at 04:41, Eliot Miranda <[hidden email]> wrote:
>
> Hi All,
>
>    first, is there a way we can modify the checkin script (scripts/gitci) to check for incoming changes so that by default the check-in fails?  Some people may check automatically but I always forget and its annoying to have to merge later on.

Well, frequent merges is kind-of part of git's philosophy.
Also, just getting incoming changes before checking won't buy you anything, because
a merge will surely happen, and it's actually safer to have a commit _before_ merging
with incoming changes. One could surely use rebasing [1], but this can get hairy in cases
of incompatible diffs.

Looking at the script itself, sure, you could add a `git pull` or `git pull --rebase`
somewhere before the add or commit, but then, when you have incompatible diffs,
it just wouldn't go through with the pull and say that you should commit or stash
away your changes before continuing the 'pull'.

I would think that'll make things only more annoying.

Best regards
        -Tobias


>
>    second, to eliminate this error message:
>
> remote: Resolving deltas: 100% (17/17), completed with 8 local objects.
> remote: This repository moved. Please use the new location:
> remote:   https://github.com/OpenSmalltalk/opensmalltalk-vm.git
> To http://github.com/OpenSmalltalk/vm
>
> should I simply edit .git/configure to change
>
> [remote "origin"]
> url = http://github.com/OpenSmalltalk/vm
>
> to
>
> [remote "origin"]
> url = https://github.com/OpenSmalltalk/opensmalltalk-vm.git
>
> ?  Or something else?
>
> _,,,^..^,,,_
> best, Eliot

[1]:  from git's manpage or (https://git-scm.com/docs/git-rebase):
=-=-=-=-=
Assume the following history exists and the current branch is "topic":

         A---B---C topic
        /
   D---E---F---G master

From this point, the result of either of the following commands:

git rebase master
git rebase master topic

would be:

                 A'--B'--C' topic
                /
   D---E---F---G master

=-=-=-=-=-=

and this can be made easier with a 'git pull --rebase'
(from git-pull(1):
More precisely, git pull runs git fetch with the given parameters and calls git merge to merge the retrieved branch heads into the current branch. With --rebase, it runs git rebase instead of git merge.
).

So by default `git pull` is
        git fetch
        git merge
but `git pull --rebase` would be
        git fetch
        git rebase
.
=-=-=-=-=-=




Reply | Threaded
Open this post in threaded view
|

Re: a couple of git issues

Ben Coman
 


On Fri, Apr 28, 2017 at 3:46 PM, Tobias Pape <[hidden email]> wrote:


> On 28.04.2017, at 04:41, Eliot Miranda <[hidden email]> wrote:
>
> Hi All,
>
>    first, is there a way we can modify the checkin script (scripts/gitci) to check for incoming changes so that by default the check-in fails?  Some people may check automatically but I always forget and its annoying to have to merge later on.


That seems horrible, to be forced to merge in someone else's changes into mine before doing a commit to draw a line between my changes and theirs.  

Eliot, I'm never sure how much you've adapted to git thinking or still think in terms of subversion.  IIUC a svn commit goes directly to the server and so has immediate public visibility(??) - so merging before a svn-commit may be good policy.  But git-commits are local until pushed.  So would this be a reasonable alternative workflow...
1. local-commit your own work  
2. get notified that the remote server has moved forward
3. if required, merge remote server on top of your local-commit
4. push the result to the server

cheers -ben

Well, frequent merges is kind-of part of git's philosophy.
Also, just getting incoming changes before checking won't buy you anything, because
a merge will surely happen, and it's actually safer to have a commit _before_ merging
with incoming changes. One could surely use rebasing [1], but this can get hairy in cases
of incompatible diffs.

Looking at the script itself, sure, you could add a `git pull` or `git pull --rebase`
somewhere before the add or commit, but then, when you have incompatible diffs,
it just wouldn't go through with the pull and say that you should commit or stash
away your changes before continuing the 'pull'.

I would think that'll make things only more annoying.

Best regards
        -Tobias


>
>    second, to eliminate this error message:
>
> remote: Resolving deltas: 100% (17/17), completed with 8 local objects.
> remote: This repository moved. Please use the new location:
> remote:   https://github.com/OpenSmalltalk/opensmalltalk-vm.git
> To http://github.com/OpenSmalltalk/vm
>
> should I simply edit .git/configure to change
>
> [remote "origin"]
>       url = http://github.com/OpenSmalltalk/vm
>
> to
>
> [remote "origin"]
>       url = https://github.com/OpenSmalltalk/opensmalltalk-vm.git
>
> ?  Or something else?
>
> _,,,^..^,,,_
> best, Eliot

[1]:  from git's manpage or (https://git-scm.com/docs/git-rebase):
=-=-=-=-=
Assume the following history exists and the current branch is "topic":

         A---B---C topic
        /
   D---E---F---G master

From this point, the result of either of the following commands:

git rebase master
git rebase master topic

would be:

                 A'--B'--C' topic
                /
   D---E---F---G master

=-=-=-=-=-=

and this can be made easier with a 'git pull --rebase'
(from git-pull(1):
More precisely, git pull runs git fetch with the given parameters and calls git merge to merge the retrieved branch heads into the current branch. With --rebase, it runs git rebase instead of git merge.
).

So by default `git pull` is
        git fetch
        git merge
but `git pull --rebase` would be
        git fetch
        git rebase
.
=-=-=-=-=-=





Reply | Threaded
Open this post in threaded view
|

Re: a couple of git issues

Nicolas Cellier
 


2017-04-28 19:17 GMT+02:00 Ben Coman <[hidden email]>:
 


On Fri, Apr 28, 2017 at 3:46 PM, Tobias Pape <[hidden email]> wrote:


> On 28.04.2017, at 04:41, Eliot Miranda <[hidden email]> wrote:
>
> Hi All,
>
>    first, is there a way we can modify the checkin script (scripts/gitci) to check for incoming changes so that by default the check-in fails?  Some people may check automatically but I always forget and its annoying to have to merge later on.


That seems horrible, to be forced to merge in someone else's changes into mine before doing a commit to draw a line between my changes and theirs.  


But it's exactly like in Monticello: you can allways commit without merging into a separate branch.
The main difference is that branch has to be explicit in git while they are implicit in MC.
 
Eliot, I'm never sure how much you've adapted to git thinking or still think in terms of subversion.  IIUC a svn commit goes directly to the server and so has immediate public visibility(??) - so merging before a svn-commit may be good policy.  But git-commits are local until pushed.  So would this be a reasonable alternative workflow...
1. local-commit your own work  
2. get notified that the remote server has moved forward
3. if required, merge remote server on top of your local-commit
4. push the result to the server

cheers -ben

Well, frequent merges is kind-of part of git's philosophy.
Also, just getting incoming changes before checking won't buy you anything, because
a merge will surely happen, and it's actually safer to have a commit _before_ merging
with incoming changes. One could surely use rebasing [1], but this can get hairy in cases
of incompatible diffs.

Looking at the script itself, sure, you could add a `git pull` or `git pull --rebase`
somewhere before the add or commit, but then, when you have incompatible diffs,
it just wouldn't go through with the pull and say that you should commit or stash
away your changes before continuing the 'pull'.

I would think that'll make things only more annoying.

Best regards
        -Tobias


>
>    second, to eliminate this error message:
>
> remote: Resolving deltas: 100% (17/17), completed with 8 local objects.
> remote: This repository moved. Please use the new location:
> remote:   https://github.com/OpenSmalltalk/opensmalltalk-vm.git
> To http://github.com/OpenSmalltalk/vm
>
> should I simply edit .git/configure to change
>
> [remote "origin"]
>       url = http://github.com/OpenSmalltalk/vm
>
> to
>
> [remote "origin"]
>       url = https://github.com/OpenSmalltalk/opensmalltalk-vm.git
>
> ?  Or something else?
>
> _,,,^..^,,,_
> best, Eliot

[1]:  from git's manpage or (https://git-scm.com/docs/git-rebase):
=-=-=-=-=
Assume the following history exists and the current branch is "topic":

         A---B---C topic
        /
   D---E---F---G master

From this point, the result of either of the following commands:

git rebase master
git rebase master topic

would be:

                 A'--B'--C' topic
                /
   D---E---F---G master

=-=-=-=-=-=

and this can be made easier with a 'git pull --rebase'
(from git-pull(1):
More precisely, git pull runs git fetch with the given parameters and calls git merge to merge the retrieved branch heads into the current branch. With --rebase, it runs git rebase instead of git merge.
).

So by default `git pull` is
        git fetch
        git merge
but `git pull --rebase` would be
        git fetch
        git rebase
.
=-=-=-=-=-=







Reply | Threaded
Open this post in threaded view
|

Re: a couple of git issues

Ben Coman
 


On Sat, Apr 29, 2017 at 3:13 AM, Nicolas Cellier <[hidden email]> wrote:
 


2017-04-28 19:17 GMT+02:00 Ben Coman <[hidden email]>:
 


On Fri, Apr 28, 2017 at 3:46 PM, Tobias Pape <[hidden email]> wrote:


> On 28.04.2017, at 04:41, Eliot Miranda <[hidden email]> wrote:
>
> Hi All,
>
>    first, is there a way we can modify the checkin script (scripts/gitci) to check for incoming changes so that by default the check-in fails?  Some people may check automatically but I always forget and its annoying to have to merge later on.


That seems horrible, to be forced to merge in someone else's changes into mine before doing a commit to draw a line between my changes and theirs.  


But it's exactly like in Monticello: you can always commit without merging into a separate branch.

The main difference is that branch has to be explicit in git while they are implicit in MC.

They way I understood the original request, the analogy would be... being forced to merge-in another persons mcz before being able to first commit your own changes to a separate mcz.  But now I see I misread it, and its just the default being considered, presumably with a "force" option.   So sorry for my angst.  Anyway, this still might be a good workflow... 
  
1. local-commit your own work  
2. get notified that the remote server has moved forward
3. if required, merge remote server on top of your local-commit
4. push the result to the server

cheers -ben

Well, frequent merges is kind-of part of git's philosophy.
Also, just getting incoming changes before checking won't buy you anything, because
a merge will surely happen, and it's actually safer to have a commit _before_ merging
with incoming changes. One could surely use rebasing [1], but this can get hairy in cases
of incompatible diffs.

Looking at the script itself, sure, you could add a `git pull` or `git pull --rebase`
somewhere before the add or commit, but then, when you have incompatible diffs,
it just wouldn't go through with the pull and say that you should commit or stash
away your changes before continuing the 'pull'.

I would think that'll make things only more annoying.

Best regards
        -Tobias


>
>    second, to eliminate this error message:
>
> remote: Resolving deltas: 100% (17/17), completed with 8 local objects.
> remote: This repository moved. Please use the new location:
> remote:   https://github.com/OpenSmalltalk/opensmalltalk-vm.git
> To http://github.com/OpenSmalltalk/vm
>
> should I simply edit .git/configure to change
>
> [remote "origin"]
>       url = http://github.com/OpenSmalltalk/vm
>
> to
>
> [remote "origin"]
>       url = https://github.com/OpenSmalltalk/opensmalltalk-vm.git
>
> ?  Or something else?
>
> _,,,^..^,,,_
> best, Eliot

[1]:  from git's manpage or (https://git-scm.com/docs/git-rebase):
=-=-=-=-=
Assume the following history exists and the current branch is "topic":

         A---B---C topic
        /
   D---E---F---G master

From this point, the result of either of the following commands:

git rebase master
git rebase master topic

would be:

                 A'--B'--C' topic
                /
   D---E---F---G master

=-=-=-=-=-=

and this can be made easier with a 'git pull --rebase'
(from git-pull(1):
More precisely, git pull runs git fetch with the given parameters and calls git merge to merge the retrieved branch heads into the current branch. With --rebase, it runs git rebase instead of git merge.
).

So by default `git pull` is
        git fetch
        git merge
but `git pull --rebase` would be
        git fetch
        git rebase
.
=-=-=-=-=-=