[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