[Vm-dev] a couple of git issues

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Fri Apr 28 19:13:11 UTC 2017


2017-04-28 19:17 GMT+02:00 Ben Coman <btc at openinworld.com>:

>
>
>
> 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.
>
>
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
>> .
>> =-=-=-=-=-=
>>
>>
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20170428/816e9d32/attachment.html>


More information about the Vm-dev mailing list