git newbie errors

git newbie errors

[Lars Magne Ingebrigtsen]

I did...  something...  just now that probably removed Sven, Glenn, and
Katsumi's last three patches.  I'm not quite sure what.

But I've tried reapplying them, but have a look...

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: git newbie errors

[Steinar Bang]

I learnt something about git today.  We've been running it in a CVS like
fashion, and that is (apparently) not the way.

What we did was to have one branch in the hub index that our group was
working on, and then we all each had a local branch tracking it, and we
were all working directly on our local tracking branches.

When we then did "git pull" we got some odd merges done into our local
branches.  It was hard to see what had happened and hard to undo.  

I ended up with a fresh git clone, replace the index in the working
directory, and doing a "git reset --hard" today, after a misbegotten
clean up attempt.

So... what we'll do come tomorrow, is:
 - each create a local branch tracking the shared branch on origin
 - branch off from this local tracking branch to do work, and commit all
   of our work to this branch
 - when finished working, switch to the local tracking branch
 - pull ff changes from the shared origin branch
 - merge in the local work branch into the tracking branch
 - handle conflicts
 - push
 - if the push fails (because someone else have pushed since your pull),
   reset --hard your tracking branch, do a new ff pull from origin, do a
   merge from the temp branch and try pushing again (repeat as needed)
 - when push has completed the work branch can be deleted (git branch -d
   will only delete remerged branches)

This is the recommended CVS-like pattern of git (or so I'm told).

Re: git newbie errors

[Julien Danjou]

On Tue, Nov 09 2010, Steinar Bang wrote:

> When we then did "git pull" we got some odd merges done into our local
> branches.  It was hard to see what had happened and hard to undo.  

What I do on my side is:

git pull --rebase

So I never merge, I just fix conflict of my local patches one by one if
needed (which is rare, except for changelog).
The history is then linear and not diamond-like, which is simpler when
you only work on small patches.

-- 
Julien Danjou
// ᐰ <julien@danjou.info>   http://julien.danjou.info

Re: git newbie errors

[Lars Magne Ingebrigtsen]

Julien Danjou <julien@danjou.info> writes:

> What I do on my side is:
>
> git pull --rebase
>
> So I never merge, I just fix conflict of my local patches one by one if
> needed (which is rare, except for changelog).
> The history is then linear and not diamond-like, which is simpler when
> you only work on small patches.

Every time I've tried to say "git pull --rebase", it hasn't worked...
or did I say "git rebase"?  Uhm.  Yes, probably.  :-)

I'll try to say "git pull --rebase" in the future, and see what
happens... 

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: git newbie errors

[Francis Moreau]

Steinar Bang <sb@dod.no> writes:

> I learnt something about git today.  We've been running it in a CVS like
> fashion, and that is (apparently) not the way.
>
> What we did was to have one branch in the hub index that our group was
> working on, and then we all each had a local branch tracking it, and we
> were all working directly on our local tracking branches.
>
> When we then did "git pull" we got some odd merges done into our local
> branches.  It was hard to see what had happened and hard to undo.  
>
> I ended up with a fresh git clone, replace the index in the working
> directory, and doing a "git reset --hard" today, after a misbegotten
> clean up attempt.
>
> So... what we'll do come tomorrow, is:
>  - each create a local branch tracking the shared branch on origin
>  - branch off from this local tracking branch to do work, and commit all
>    of our work to this branch
>  - when finished working, switch to the local tracking branch
>  - pull ff changes from the shared origin branch
>  - merge in the local work branch into the tracking branch
>  - handle conflicts
>  - push
>  - if the push fails (because someone else have pushed since your pull),
>    reset --hard your tracking branch, do a new ff pull from origin, do a
>    merge from the temp branch and try pushing again (repeat as needed)
>  - when push has completed the work branch can be deleted (git branch -d
>    will only delete remerged branches)
>
> This is the recommended CVS-like pattern of git (or so I'm told).

But why still using CVS-like pattern with git ?

IOW, why not using git as it should be ?

-- 
Francis

Re: git newbie errors

[Steinar Bang]

>>>>> Francis Moreau <francis.moro@gmail.com>:

> IOW, why not using git as it should be ?

How should we use git then?

Re: git newbie errors

[Andreas Schwab]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> I'll try to say "git pull --rebase" in the future, and see what
> happens... 

If you have a recent git you can set branch.$branch.rebase to make that
implicit.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: git newbie errors

[Katsumi Yamaoka]

Lars Magne Ingebrigtsen wrote:
> I did...  something...  just now that probably removed Sven, Glenn, and
> Katsumi's last three patches.  I'm not quite sure what.

> But I've tried reapplying them, but have a look...

Er, I don't know what happened in your side.  I did:

When I was about to apply Sven's patch, I found nnbabyl.el has
been changed by Glenn in the Emacs trunk.  So, I put Glenn's
change and Sven's patch into the local copy of Gnus git, and
updated the ChangeLog locally.  And then:

git commit --author='Glenn...' -m '...' lisp/nnbabyl.el
git push
git commit --author='Sven...' -m '...' lisp/message.el
git push
git commit -m Update. lisp/ChangeLog
git push

(Maybe a better way was to push Glenn's change and its log, and
then to put Sven's change and its log.)

Before them I noticed "(was Re: ...)" in subject was not removed
even though message-subject-trailing-was-query is t (to which Lars
has changed it in 2010-10-31).  Try replying to the article:

<b4msjzc1jwt.fsf_-_@jpl.org>

Therefore I changed message-subject-trailing-was-regexp slightly.
See: <E1PFdVw-0007jE-00@quimby.gnus.org>

Now "(was Re: ...)" got not being deleted again. :<

BTW, I wondered why there are two regexps
message-subject-trailing-was-ask-regexp and
message-subject-trailing-was-regexp.  Is there any reason unable
to integrate them into one?

Re: git newbie errors

[Francis Moreau]

Steinar Bang <sb@dod.no> writes:

>>>>>> Francis Moreau <francis.moro@gmail.com>:
>
>> IOW, why not using git as it should be ?
>
> How should we use git then?
>

You can take a look at gitworkflows(7).

It sum up how *distributed* workflows works.

-- 
Francis

Re: git newbie errors

[Steinar Bang]

>>>>> Francis Moreau <francis.moro@gmail.com>:

> It sum up how *distributed* workflows works.

I'm in a maze of "distributed" commits, all alike.

I believe it is important that different people's changes are run
together as soon as possible.

I like continous integration building (from changes contributed by
different developers).

I don't like the need for a person that is the designated integrator.

(I didn't look at the man page.  Give me a URL or give me death!)

Re: git newbie errors

[Andreas Schwab]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> git commit --author='Glenn...' -m '...' lisp/nnbabyl.el
> git push
> git commit --author='Sven...' -m '...' lisp/message.el
> git push
> git commit -m Update. lisp/ChangeLog
> git push

There is no need to push every commit separately.

> (Maybe a better way was to push Glenn's change and its log, and
> then to put Sven's change and its log.)

Keeping related changes together is always good.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: git newbie errors

[Lars Magne Ingebrigtsen]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> BTW, I wondered why there are two regexps
> message-subject-trailing-was-ask-regexp and
> message-subject-trailing-was-regexp.  Is there any reason unable
> to integrate them into one?

I think the point is that the former is more sloppy, since the user is
queried, which the latter is a precise match on (basically) just
"(Was: ...)".  But I don't know whether that really warrants to
variables.  I'd vote for just using one variable.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: git newbie errors

[Greg Troxel]

[-- Attachment #1: Type: text/plain, Size: 753 bytes --]


Steinar Bang <sb@dod.no> writes:

>>>>>> Francis Moreau <francis.moro@gmail.com>:
>
>> It sum up how *distributed* workflows works.
>
> I'm in a maze of "distributed" commits, all alike.
>
> I believe it is important that different people's changes are run
> together as soon as possible.
>
> I like continous integration building (from changes contributed by
> different developers).
>
> I don't like the need for a person that is the designated integrator.

It's entirely possible and reasonable to use git where the group lets
any commiter push changes to official master, and people push commits as
soon as they're comfortable, roughly equivalent to when they would cvs
commit.   git doesn't argue against this - it just makes other ways possible.

[-- Attachment #2: Type: application/pgp-signature, Size: 194 bytes --]