[Vm-dev] a couple of git issues

Ben Coman btc at openinworld.com
Fri Apr 28 17:17:55 UTC 2017


On Fri, Apr 28, 2017 at 3:46 PM, Tobias Pape <Das.Linux at gmx.de> wrote:

>
>
> > On 28.04.2017, at 04:41, Eliot Miranda <eliot.miranda at gmail.com> 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
> .
> =-=-=-=-=-=
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20170429/be9e0e3c/attachment.html>


More information about the Vm-dev mailing list