User's mailing list? And multiple cherry pick

User's mailing list? And multiple cherry pick

[David]

Hi list.

I've tried Googling for these, and checked the FAQ.

1) Is there a separate Git Users mailing list or FAQ?

So that git noobs like myself don't bother the developers directly :-)
Also so that non-git-developer users who want to help other users
don't get a lot of mails with patches & git internal development
discussions.

2) Is it possible to cherry pick multiple patches?

Sometimes git rebase isn't appropriate, and it's a pain to do multiple
'git-cherry-pick' commands. Here is my current recipe:

for C in $(git log --reverse <commit1>..<commit2> --pretty=format:%H);
do git-cherry-pick $C; done

Is there an easier syntax for doing this?

David.

Re: User's mailing list? And multiple cherry pick

[Junio C Hamano]

David <wizzardx@gmail.com> writes:

> Hi list.
>
> I've tried Googling for these, and checked the FAQ.
>
> 1) Is there a separate Git Users mailing list or FAQ?
>
> So that git noobs like myself don't bother the developers directly :-)
> Also so that non-git-developer users who want to help other users
> don't get a lot of mails with patches & git internal development
> discussions.
>
> 2) Is it possible to cherry pick multiple patches?
>
> Sometimes git rebase isn't appropriate, and it's a pain to do multiple
> 'git-cherry-pick' commands. Here is my current recipe:
>
> for C in $(git log --reverse <commit1>..<commit2> --pretty=format:%H);
> do git-cherry-pick $C; done
>
> Is there an easier syntax for doing this?

rebase --onto?

Re: User's mailing list? And multiple cherry pick

[David]

>>
>> for C in $(git log --reverse <commit1>..<commit2> --pretty=format:%H);
>> do git-cherry-pick $C; done
>>
>> Is there an easier syntax for doing this?
>
> rebase --onto?
>

Thanks, I checked the manuals further, and it looks like this will
(mostly) do what I need.

What's still missing is multiple cherry pick ;-)

In other words, is there a simple way to *copy* a large number of
commits from one branch to another, without rebasing?

David.

Re: User's mailing list? And multiple cherry pick

[Jakub Narebski]

David <wizzardx@gmail.com> writes:

> I've tried Googling for these, and checked the FAQ.
> 
> 1) Is there a separate Git Users mailing list or FAQ?
> 
> So that git noobs like myself don't bother the developers directly :-)
> Also so that non-git-developer users who want to help other users
> don't get a lot of mails with patches & git internal development
> discussions.

There is Git User's mailing list ("Git for human beings", heh)
  git-users@googlegroups.com
  http://groups.google.com/group/git-users
  nntp://news.gmane.org/gmane.comp.version-control.git.user
 
There is GitFaq at Git Wiki:
  http://git.or.cz/gitwiki/GitFaq

> 2) Is it possible to cherry pick multiple patches?
> 
> Sometimes git rebase isn't appropriate, and it's a pain to do multiple
> 'git-cherry-pick' commands. Here is my current recipe:
> 
> for C in $(git log --reverse <commit1>..<commit2> --pretty=format:%H);
> do git-cherry-pick $C; done
> 
> Is there an easier syntax for doing this?

 $ git rebase --onto
 $ git rebase --onto --interactive

(if you want to copy, just create new branch using "git branch", or
something).

Why can't you simply use merge, BTW?
-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: User's mailing list? And multiple cherry pick

[Stephan Beyer]

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

> for C in $(git log --reverse <commit1>..<commit2> --pretty=format:%H);
> do git-cherry-pick $C; done
> 
> Is there an easier syntax for doing this?

Put this into a script and you've got an easier syntax ;-)
But note that <commit1> does not get cherry-picked then.
Use <commit1>^..<commit2> (or $1^..$2).

Except if there's a conflict.

Well, though it is far from finished, you could fetch git-sequencer.sh[1]
 1. http://tinyurl.com/6xtdvl

chmod +x it and do

for C in $(git log --reverse <commit1>..<commit2> --pretty=format:%H);
do echo pick $C ; done >temporaryfile
/where/you/put/it/git-sequencer.sh temporaryfile

Hope I could help.

Regards,
  Stephan

-- 
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F

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

Re: User's mailing list? And multiple cherry pick

[Jakub Narebski]

David <wizzardx@gmail.com> writes:

[Please don't remove quote attributions]

>>> for C in $(git log --reverse <commit1>..<commit2> --pretty=format:%H);
>>> do git-cherry-pick $C; done
>>>
>>> Is there an easier syntax for doing this?
>>
>> rebase --onto?
>>
> 
> Thanks, I checked the manuals further, and it looks like this will
> (mostly) do what I need.
> 
> What's still missing is multiple cherry pick ;-)
> 
> In other words, is there a simple way to *copy* a large number of
> commits from one branch to another, without rebasing?

 # make temporary branch to not move to-be-copied during rebase
  $ git checkout -b tmp-rebase to-be-copied
 # copy commits; results are in just created temporary branch
  $ git rebase --onto branch copy-from tmp-rebase
 # check if everything is all right and rename temporary branch
 # to final name
  $ git branch -M tmp-rebase branch

That said, cherry-picking multiple commits is often requested feature.
I guess that git-sequencer GSoC 2008 project would help in having it
finally implemented.  BTW. why can't you use topic branches and
merging?

-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: User's mailing list? And multiple cherry pick

[David]

> There is Git User's mailing list ("Git for human beings", heh)
>  git-users@googlegroups.com
>  http://groups.google.com/group/git-users
>  nntp://news.gmane.org/gmane.comp.version-control.git.user
>
> There is GitFaq at Git Wiki:
>  http://git.or.cz/gitwiki/GitFaq
>

Thanks for the links.

>> Is there an easier syntax for doing this?
>
>  $ git rebase --onto
>  $ git rebase --onto --interactive
>
> (if you want to copy, just create new branch using "git branch", or
> something).

Thanks, but this doesn't quite solve the problem. I'm on the verge of
figuring it out, and would appreciate any further tips :-)

Here is an example:

o--o--O master
       \
        o--o--X--X--X--X--o--o topic

I want to copy the "X" patches from the topic branch over to master.
The other patches aren't appropriate for master for whatever reason.
eg, temporary debugging hacks, but I fixed a few problems in master in
the X patches and now want to apply them on top of master, and keep
working on "topic"

I want to end up with a tree like this:


o--o--O--X'--X'--X'--X' master
       \
        o--o--X--X--X--X--o--o topic

After getting the branches like this, I would then (try to) rebase
topic like this:

o--o--O--X'--X'--X'--X' master
                      \
                       o'--o'--o'--o' topic

I say try to, because rebase sometimes gets a lot of dumb (to me,
maybe I'm not using git correctly) conflicts in cases like this, so I
end up manually rebasing, by making a new topic branch off master,
cherry picking into it off the old topic branch, and then removing the
old branch. Another case where multiple cherry picks would be nice :-)

>
> Why can't you simply use merge, BTW?

Because the topic branch has some 'dirty' commits that I don't want in master.

David.

Re: User's mailing list? And multiple cherry pick

[Johan Herland]

On Wednesday 04 June 2008, David wrote:
> > rebase --onto?
> 
> Thanks, I checked the manuals further, and it looks like this will
> (mostly) do what I need.
> 
> What's still missing is multiple cherry pick ;-)
> 
> In other words, is there a simple way to *copy* a large number of
> commits from one branch to another, without rebasing?

Depends on you definition of "simple". Here are 5 commands that gets the job done in a (IMHO) conceptually simple way.

Use

	git checkout -b [tmpBranch] [fromBranch]

to create (and checkout) a _new_ branch pointing to the same commit as the "from"-branch. Then use

	git rebase --onto [toBranch] [fromBranchStart] [tmpBranch]

to rebase all commits between [fromBranchStart] and [fromBranch] on top of [toBranch]. Since this was done with HEAD == [tmpBranch], the original [fromBranch] is not moved, and therefore *still* points to the old commits. [tmpBranch], however, have been moved to point at the rebased commits. This in effect *copies* the commits from [fromBranch] to [tmpBranch]. Now, all that remains is to reconcile [tmpBranch] and [toBranch], and finally remove [tmpBranch]:

	git checkout [toBranch]
	git merge [tmpBranch]
	git branch -d [tmpBranch]

The merge should be a simple fast-forward without any conflicts.

Here is an illustrated version of what's going on:

Initial layout:

	          G---H---I  <---- [fromBranch]
	         /
	A---B---C---D---E---F  <-- [toBranch]
	        ^----------------- [fromBranchStart]

git checkout -b [tmpBranch] [fromBranch]

	          G---H---I  <---- [fromBranch]
	         /        ^------- [tmpBranch]      
	A---B---C---D---E---F  <-- [toBranch]
	        ^----------------- [fromBranchStart]

git rebase --onto [toBranch] [fromBranchStart] [tmpBranch]

	          G---H---I  <------------------- [fromBranch]
	         /              
	A---B---C---D---E---F---G'---H'---I'  <-- [tmpBranch]
	        ^           ^-------------------- [toBranch]
	        --------------------------------- [fromBranchStart]

git checkout [toBranch]
git merge [tmpBranch]
git branch -d [tmpBranch]

	          G---H---I  <------------------- [fromBranch]
	         /              
	A---B---C---D---E---F---G'---H'---I'  <-- [toBranch]
	        ^-------------------------------- [fromBranchStart]


This should also work even if your commit graphs are considerably more complicated.

If you need to drop/edit/squash any commits between [fromBranchStart] and [fromBranch], simply add a "--interactive" to the rebase command.


Have fun!

...Johan

-- 
Johan Herland, <johan@herland.net>
www.herland.net

Re: User's mailing list? And multiple cherry pick

[David]

>> Is there an easier syntax for doing this?
>
> Put this into a script and you've got an easier syntax ;-)
> But note that <commit1> does not get cherry-picked then.
> Use <commit1>^..<commit2> (or $1^..$2).

Thanks for the ^ tip. I prefer to use git built-ins where possible,
instead of re-inventing the wheel badly by using my own scripts ;-)

> for C in $(git log --reverse <commit1>..<commit2> --pretty=format:%H);
> do echo pick $C ; done >temporaryfile
> /where/you/put/it/git-sequencer.sh temporaryfile
>

Thanks for the script, but I want to use git built-ins only if
possible :-) eg, so that I can easily help other people do the same
thing without telling them to download separate scripts.

Also, that syntax is almost as long & complicated-looking as my own ;-)

Re: User's mailing list? And multiple cherry pick

[Johan Herland]

On Wednesday 04 June 2008, Jakub Narebski wrote:
> That said, cherry-picking multiple commits is often requested feature.
> I guess that git-sequencer GSoC 2008 project would help in having it
> finally implemented.  BTW. why can't you use topic branches and
> merging?

What about adding a "-b" option to git-rebase that simply performs a "git
checkout -b" before starting the rest of the rebase process?


...Johan

-- 
Johan Herland, <johan@herland.net>
www.herland.net

Re: User's mailing list? And multiple cherry pick

[David]

On Wed, Jun 4, 2008 at 10:05 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> David <wizzardx@gmail.com> writes:
>
> [Please don't remove quote attributions]
>

Thanks for the netiquette tip, I didn't know this was a bad thing. Are
<snip>s also a good thing, or is it ok to just cut out the parts that
don't need re-quoting?


>
>  # make temporary branch to not move to-be-copied during rebase
>  $ git checkout -b tmp-rebase to-be-copied
>  # copy commits; results are in just created temporary branch
>  $ git rebase --onto branch copy-from tmp-rebase
>  # check if everything is all right and rename temporary branch
>  # to final name
>  $ git branch -M tmp-rebase branch
>

Thanks :-) This still isn't what I had in mind (see my earlier post
with examples), but I realise now, thanks to your post, that I can
probably do it like this:

1) Make a temporary branch off the topic

2) Rebase the temporary branch onto master interactively (maybe or
maybe not with --onto), and in interactive mode take out, reorder,
etc.

3) Check & test the temporary branch

4) Merge the temporary branch into master, and drop the temporary branch.

5) Rebase the original topic branch onto the new master.

Thanks to all the posters for their tips.

David.

Re: User's mailing list? And multiple cherry pick

[Jakub Narebski]

On Wed, 4 June 2008, David wrote:
> 
> Thanks, but this doesn't quite solve the problem. I'm on the verge of
> figuring it out, and would appreciate any further tips :-)
> 
> Here is an example:
> 
> o--o--O master
>        \
>         o--o--X--X--X--X--o--o topic
> 
> I want to copy the "X" patches from the topic branch over to master.
> The other patches aren't appropriate for master for whatever reason.
> eg, temporary debugging hacks, but I fixed a few problems in master in
> the X patches and now want to apply them on top of master, and keep
> working on "topic"
> 
> I want to end up with a tree like this:
> 
> 
> o--o--O--X'--X'--X'--X' master
>        \
>         o--o--X--X--X--X--o--o topic

I think the simplest solution would be to mark old master, change it
to topic (merge or branch -f), and use interactive rebase.

  $ git checkout master
  $ git branch TMP
         
  o--o--O *master, TMP
         \
          o--o--X--X--X--X--o--o topic

where '*master' means that 'master' is current branch.

Then to rewind 'master' to 'topic' you can use either
  $ git merge topic 
which should fast-forward to 'topic', or use git-reset
  $ git reset --hard topic

  o--o--O TMP
         \
          o--o--X--X--X--X--o--o topic, *master

Then there is simply a matter of rebasing master interactively, picking 
commits marked X.

  $ git rebase --interactive TMP
  # pick commits marked X in above diagram, backup (save) both original
  # list of commits, and final list of commits.

It is now safe to delete 'TMP' branch

  $ git branch -d TMP

  o--o--O--X'--X'--X'--X' *master
         \
          o--o--X--X--X--X--o--o topic

Now, if all goes well it would be simply a matter of rebasing 'topic' on 
top of 'master'; git-rebase would skip commits that are already there.

If it is not the case, use interactive rebase again, this time picking 
commits marked 'o' (if you saved original series, and list of commits 
rebased, this should be fairly easy to find/do).
 
> After getting the branches like this, I would then (try to) rebase
> topic like this:
> 
> o--o--O--X'--X'--X'--X' master
>                       \
>                        o'--o'--o'--o' topic

And here you are.

HTH
-- 
Jakub Narebski
Poland

Re: User's mailing list? And multiple cherry pick

[David]

On Wed, Jun 4, 2008 at 10:50 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> On Wed, 4 June 2008, David wrote:
>>
>> Thanks, but this doesn't quite solve the problem. I'm on the verge of
>> figuring it out, and would appreciate any further tips :-)
>>

[snip]

> I think the simplest solution would be to mark old master, change it
> to topic (merge or branch -f), and use interactive rebase.
>

Thanks for the idea, but doesn't this make your 'master' branch very volatile?

My understanding is that it's better to keep master as stable & "main
line" as possible, and only merge into it when the bits being merged
are relatively safe.

In your example, you still have a TMP "rollback" point if you need to
rewind master in the event that the merge into master goes badly.

Maybe jumping master around like that works better when you're more
experienced with git and can fix problems with master quickly.

In my case I make rsync backups of my git repos before I do anything
that looks remotely dangerous ;-)

David.

Re: User's mailing list? And multiple cherry pick

[Wincent Colaiuta]

El 4/6/2008, a las 10:30, David escribió:

> Thanks :-) This still isn't what I had in mind (see my earlier post
> with examples), but I realise now, thanks to your post, that I can
> probably do it like this:
>
> 1) Make a temporary branch off the topic
>
> 2) Rebase the temporary branch onto master interactively (maybe or
> maybe not with --onto), and in interactive mode take out, reorder,
> etc.
>
> 3) Check & test the temporary branch
>
> 4) Merge the temporary branch into master, and drop the temporary  
> branch.
>
> 5) Rebase the original topic branch onto the new master.
>
> Thanks to all the posters for their tips.

Sounds like it would definitely work but it also sounds like a lot of  
repetitive "busy work"[1] which could be avoided by using finer- 
grained topic branches in the first place.

In the basic case Git makes it incredibly easy to split off topic  
branches and merge them back in, and when you do this you're working  
in synergy with the tool. But while what you're wanting to do is  
certainly possible you can also see that it has a lot of fiddly, error- 
prone overhead in which you're juggling temporary branches and commits  
back and forth in a complicated way. Not working in synergy with the  
tool.

I know that I'd soon get tied of this "busy work" if I had to do it;  
maybe with time you'll be able to transition to a style in which you  
make more, smaller topic branches,  which can really be treated as  
logically-grouped topics and merged in as a whole rather than sifted  
out into separate sub-topics.

Having said that, the ability to pass multiple commits or ranges of  
commits to "git cherry-pick" is a logical enough enhancement, if  
someone is interested enough in this feature to actually do the work.

Wincent

[1] http://en.wikipedia.org/wiki/Busy_work

Re: User's mailing list? And multiple cherry pick

[Jakub Narebski]

David wrote:

[...]
> In your example, you still have a TMP "rollback" point if you need to
> rewind master in the event that the merge into master goes badly.

And you have ORIG_HEAD and reflog (master@{1}, master@{2} etc.) as 
safety net.  Reflog is now enabled by default.

Besides unless you run prune in the meantime, even without reflogs you 
would be able to recover using lost-found / git-fsck output.
-- 
Jakub Narebski
Poland

Re: User's mailing list? And multiple cherry pick

[David]

On Wed, Jun 4, 2008 at 11:39 AM, Wincent Colaiuta <win@wincent.com> wrote:
> El 4/6/2008, a las 10:30, David escribió:
>
>> Thanks :-) This still isn't what I had in mind (see my earlier post
>> with examples), but I realise now, thanks to your post, that I can
>> probably do it like this:

[snip]

>
> Sounds like it would definitely work but it also sounds like a lot of
> repetitive "busy work"[1] which could be avoided by using finer-grained
> topic branches in the first place.
>

I see where you're coming from, and I am learning to work more in this
way. Using git has made a big difference to how I develop. Not just as
a SCM, but also for improved work-flow. eg trying out things in code,
and storing failed attempts for later reference/retries/etc if it
doesn't work out.

My problem with your post is, even if you take this to the extreme
(topic branches for every fix that you want to make), there will still
be cases where while working on one fix (maybe disruptive to the main
branch), you uncover problems with master and start fixing it in your
topic branch.

It isn't always easy to fix the problems in master (that you're seeing
in topic) by changing back to master and making another topic. Maybe
you can only (easily) find & detect the problems in master because of
other changes in topic (eg: WIP unit tests) that you aren't ready to
merge yet.

So you would probably have to jump back and forth between your topic,
and your new 'fix problems in master' branch a lot to track down the
issues and get the fixes into master. This sounds like a lot more
'busy work' than simply cherry-picking (multiple) those fixes out of
your topic branch into master, and then rebasing your topic branch :-)

David.

Re: User's mailing list? And multiple cherry pick

[Karl Hasselström]

On 2008-06-04 00:39:07 -0700, Jakub Narebski wrote:

> There is Git User's mailing list ("Git for human beings", heh)
>   git-users@googlegroups.com
>   http://groups.google.com/group/git-users
>   nntp://news.gmane.org/gmane.comp.version-control.git.user

Is there a way to subscribe to a Google list such as this one and have
the list mails delivered to a non-gmail address? I'd like to be able
to follow this list and the msysgit list, but not if I have to use
gmail to do it.

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle

Re: User's mailing list? And multiple cherry pick

[Wincent Colaiuta]

El 4/6/2008, a las 12:02, David escribió:

> On Wed, Jun 4, 2008 at 11:39 AM, Wincent Colaiuta <win@wincent.com>  
> wrote:
>> El 4/6/2008, a las 10:30, David escribió:
>>
>>> Thanks :-) This still isn't what I had in mind (see my earlier post
>>> with examples), but I realise now, thanks to your post, that I can
>>> probably do it like this:
>
> [snip]
>
>>
>> Sounds like it would definitely work but it also sounds like a lot of
>> repetitive "busy work"[1] which could be avoided by using finer- 
>> grained
>> topic branches in the first place.
>>
>
> I see where you're coming from, and I am learning to work more in this
> way. Using git has made a big difference to how I develop. Not just as
> a SCM, but also for improved work-flow. eg trying out things in code,
> and storing failed attempts for later reference/retries/etc if it
> doesn't work out.
>
> My problem with your post is, even if you take this to the extreme
> (topic branches for every fix that you want to make), there will still
> be cases where while working on one fix (maybe disruptive to the main
> branch), you uncover problems with master and start fixing it in your
> topic branch.
>
> It isn't always easy to fix the problems in master (that you're seeing
> in topic) by changing back to master and making another topic. Maybe
> you can only (easily) find & detect the problems in master because of
> other changes in topic (eg: WIP unit tests) that you aren't ready to
> merge yet.
>
> So you would probably have to jump back and forth between your topic,
> and your new 'fix problems in master' branch a lot to track down the
> issues and get the fixes into master. This sounds like a lot more
> 'busy work' than simply cherry-picking (multiple) those fixes out of
> your topic branch into master, and then rebasing your topic branch :-)

I guess it depends on how long-lived your topic branches are, and how  
urgently you want to get independent fixes back into "master".

If the topic branch isn't very long-lived, and the fix isn't  
incredibly urgent, you could just keep it in the topic until the  
entire topic branch is ready to be merged back in.

If the fix depends on changes in the topic branch then getting it into  
master may not be so urgent anyway. How often does this really happen?  
I know that all code bases are different, but in my experience if I  
discover a problem (in master) while working on a topic, the fix is  
usually independent of the topic, in which case I have two options:  
either fix it on master (and then optionally rebase the topic), or  
just fix it on the topic and let the fix propagate back to the master  
when I merge in the topic.

Don't forget that you also have "git stash" for those moments when you  
are working on a topic and see a completely unrelated fix or change  
that you want to do.

But obviously, this is all highly context-dependent and what works for  
me won't always work for everyone.

Wincent

Re: User's mailing list? And multiple cherry pick

[Jakub Narebski]

David <wizzardx@gmail.com> writes:

> On Wed, Jun 4, 2008 at 11:39 AM, Wincent Colaiuta <win@wincent.com> wrote:
> >
> > Sounds like it would definitely work but it also sounds like a lot of
> > repetitive "busy work"[1] which could be avoided by using finer-grained
> > topic branches in the first place.
> >
> 
> I see where you're coming from, and I am learning to work more in this
> way. Using git has made a big difference to how I develop. Not just as
> a SCM, but also for improved work-flow. eg trying out things in code,
> and storing failed attempts for later reference/retries/etc if it
> doesn't work out.
> 
> My problem with your post is, even if you take this to the extreme
> (topic branches for every fix that you want to make), there will still
> be cases where while working on one fix (maybe disruptive to the main
> branch), you uncover problems with master and start fixing it in your
> topic branch.
> 
> It isn't always easy to fix the problems in master (that you're seeing
> in topic) by changing back to master and making another topic. Maybe
> you can only (easily) find & detect the problems in master because of
> other changes in topic (eg: WIP unit tests) that you aren't ready to
> merge yet.
> 
> So you would probably have to jump back and forth between your topic,
> and your new 'fix problems in master' branch a lot to track down the
> issues and get the fixes into master. This sounds like a lot more
> 'busy work' than simply cherry-picking (multiple) those fixes out of
> your topic branch into master, and then rebasing your topic branch :-)

For this I think it would be best to use some kind of patch management
interface on top of Git, be it StGIT or Guilt (interface of the latter
is based on Mercurial Queues, hence former name Git Queues (gq)), see
http://git.or.cz/gitwiki/InterfacesFrontendsAndTools (there was also
Patchy Git (pg) tool, but it is no longer maintained).  I personally
use StGIT, therefore all examples will use this tool.

Then you would be able to go back and forth between patches (commits),
correct them, with some difficulty even split or join them.

Now the workflow depends if you are third-party contributor, sending
patches upstream via email, or if you are project maintainer, and
others pull from you.

If you are third-party contributor, sending patches upstream via
email,using "stg mail" or "git format-patch" plus either "git
send-email", or your favorite mail program, you would do the
following, on your topic branch:
  1. edit, going back and forth between patches
  2. "stg mail" patches to maintainer
  3. incorporate feedback, going to 1. if necessary
  4. fetch from upstream (I use "git fetch"/"git remote update")
  5. rebase your patches ("stg rebase <upstream>")
  6. remove applied patches (which should be empty) from stack,
     using "stg clean -a"; remove patches by hand if necessary
     ("stg remove <patchname>").

If you are maintainer / main contributor your workflow would be a bit
different.  Instead of emailing patches you would probably "stg
commit" them, turning them into ordinary commits (removing from patch
queue) when you finish working on them, then probably merge (parts of)
feature branch into one of stable branches ('maint', 'master',
'next',...).

HTH.
-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: User's mailing list? And multiple cherry pick

[Miklos Vajna]

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

On Wed, Jun 04, 2008 at 12:38:48PM +0200, Karl Hasselström <kha@treskal.com> wrote:
> On 2008-06-04 00:39:07 -0700, Jakub Narebski wrote:
> 
> > There is Git User's mailing list ("Git for human beings", heh)
> >   git-users@googlegroups.com
> >   http://groups.google.com/group/git-users
> >   nntp://news.gmane.org/gmane.comp.version-control.git.user
> 
> Is there a way to subscribe to a Google list such as this one and have
> the list mails delivered to a non-gmail address? I'd like to be able
> to follow this list and the msysgit list, but not if I have to use
> gmail to do it.

Yes. You need a google account for your non-gmail address, though.

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

Re: User's mailing list? And multiple cherry pick

[Theodore Tso]

On Wed, Jun 04, 2008 at 10:11:33AM +0200, David wrote:
> Here is an example:
> 
> o--o--O master
>        \
>         o--o--X--X--X--X--o--o topic
> 
> I want to copy the "X" patches from the topic branch over to master.
> The other patches aren't appropriate for master for whatever reason.
> eg, temporary debugging hacks, but I fixed a few problems in master in
> the X patches and now want to apply them on top of master, and keep
> working on "topic"
> 
> I want to end up with a tree like this:
> 
> 
> o--o--O--X'--X'--X'--X' master
>        \
>         o--o--X--X--X--X--o--o topic
>
> After getting the branches like this, I would then (try to) rebase
> topic like this:
> 
> o--o--O--X'--X'--X'--X' master
>                       \
>                        o'--o'--o'--o' topic
> 


OK, so assume the tree looks like this:

 o--o--O master
        \
         1--2--3--4--5--6--7--8 topic

First do a "git checkout topic; git rebase --interactive master", and
reorder the topic branch so it looks like this:

 o--o--O master
        \
         3--4--5--6--1--2--7--8 topic

Now find the commit ID for commit #6 above, and assuming that it's
f1dead2f, run the command "git checkout master; git merge f1dead2f".
Now the graph looks like this:

 o--o--O--3--4--5--6 master
                    \
                     1--2--7--8 topic

You could also use the command:

	"git update-ref refs/heads/master f1dead2f"

which keeps HEAD pointing at the topic branch, but the reason why I
suggested the "git checkout master; git merge f1dead2f" is that the
commands are generally more familiar to git newcomers, and I usually
want to do a test build and run the regression tests on master to make
sure things are clean.


> I say try to, because rebase sometimes gets a lot of dumb (to me,
> maybe I'm not using git correctly) conflicts in cases like this, so I
> end up manually rebasing, by making a new topic branch off master,
> cherry picking into it off the old topic branch, and then removing the
> old branch. Another case where multiple cherry picks would be nice :-)

Note that in the above set of commands, summarized as:

1) "git checkout topic; git rebase --interactive master"
   1a)  "make; make check" to build and run regression tests on the 
   	reordered topic branch.
2) "git checkout master; git merge f1dead2f" (this should be a fast forward)
   2a)  "make; make check" to build and run regression tests on the 
   	updated master branch.

There may be indeed conflicts at the first "git rebase --interactive",
but that's just git being conservative.  Usually it really isnt that
hard to resolve the conflicts, git add the files which required
fixups, and then doing a "git rebase --continue".  And you will have
to do the manual fixup regardless of whether you use "git rebase" or
"git cherry-pick"; the git rebase is just a more automated way of
doing things.

Regards,

						- Ted

Re: User's mailing list? And multiple cherry pick

[Björn Steinbrink]

On 2008.06.04 12:02:13 +0200, David wrote:
> On Wed, Jun 4, 2008 at 11:39 AM, Wincent Colaiuta <win@wincent.com> wrote:
> > El 4/6/2008, a las 10:30, David escribió:
> >
> >> Thanks :-) This still isn't what I had in mind (see my earlier post
> >> with examples), but I realise now, thanks to your post, that I can
> >> probably do it like this:
> 
> [snip]
> 
> >
> > Sounds like it would definitely work but it also sounds like a lot of
> > repetitive "busy work"[1] which could be avoided by using finer-grained
> > topic branches in the first place.
> >
> 
> It isn't always easy to fix the problems in master (that you're seeing
> in topic) by changing back to master and making another topic. Maybe
> you can only (easily) find & detect the problems in master because of
> other changes in topic (eg: WIP unit tests) that you aren't ready to
> merge yet.
> 
> So you would probably have to jump back and forth between your topic,
> and your new 'fix problems in master' branch a lot to track down the
> issues and get the fixes into master. This sounds like a lot more
> 'busy work' than simply cherry-picking (multiple) those fixes out of
> your topic branch into master, and then rebasing your topic branch :-)

The unit tests example is a pretty good use-case for rebase --onto.
Simply start your new topic on top of the WIP topic, you don't always
have to branch from master. Then you have the all the code around. Fix
the bug, and finally rebase your new topic onto master.

git checkout -b bug_fix_branch wip_branch
# work work work, commit commit commit
git rebase --onto master wip_branch bug_fix_branch

Eventually, you'll have to add stuff to your wip_branch while doing the
bug_fix, but that's relatively straight forward.

git checkout wip_branch
# work work work, commit commit commit
git rebase wip_branch bug_fix_branch

And then you can continue to work on the bug fix branch and at some
point end up at the rebase --onto from above.

Of course for stronger dependencies between wip_branch and
bug_fix_branch, that's not possible, but then you most likely wouldn't
want to cherry-pick the bug fix stuff into master anyway.

Björn