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.

--

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=3Dformat:%H);

do echo pick $C ; done >temporaryfile

/where/you/put/it/git-sequencer.sh temporaryfile
Hope I could help.
Regards,

  Stephan
--=20

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

Thanks for the ^ tip. I prefer to use git built-ins where possible,
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 ;-)

--

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:
 $ 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

--

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

--

On Wed, Jun 04, 2008 at 12:38:48PM +0200, Karl Hasselstr=F6m <kha@treskal.c=
Yes. You need a google account for your non-gmail address, though.

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
Because the topic branch has some 'dirty' commits that I don't want in master.
David.

--

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
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

--

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 
And here you are.
HTH

--

Jakub Narebski

Poland

--

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.

--

David wrote:
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

--

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.

--

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...
[ message continues ]

David <wizzardx@gmail.com> writes:
 # 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

--

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
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.

--

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
--

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.

--

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

--

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

--

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
--

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

--