a couple of git issues

> 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
.
=-=-=-=-=-=

 

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
.
=-=-=-=-=-=

 

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.

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
.
=-=-=-=-=-=