I’m really liking this.
So I set up some Git feature branches to help get Redmine patches from their BTS into their SVN trunk faster. (I don’t know why, but it seems to take a *very* long time for that to happen.)
Each BTS patch gets a Git feature branch. My Git repo for this project has about 21 branches in it.
So, I pull upstream into a branch called, well, upstream.
Each feature branch is created off upstream.
Then, the master branch merges all the feature branches in. I wrote a simple git-merge-fb shell script that just runs git-merge for each feature branch. Very simple. I expect to have a git-pull-fb script of some sort that merges upstream into each feature branch when I update against upstream. It could also run a diff at the end to see if there is any difference remaining, and if not, delete the branch.
It’s trivial to give an updated diff to upstream for any given patch: git diff feature-blah..upstream will do it.
I only wish gitweb had a way to do that so I could just hand out a URL that always corresponds to the latest diff against upstream for a given feature. Now that would rock.
gitweb has that ;-) You can throw almost(?) anything into the h/hp parameters. So for example if you wanted a static URL that shows the diff from master to next for git.git, you’d use:
http://git.kernel.org/?p=git/git.git;a=blobdiff;h=next;hp=master
Oops. Just verified that the displayed changes were correct, but missed that the filenames are bogus/missing in the output.
If you can live with a somewhat bogus header, this works:
http://git.kernel.org/?p=git/git.git;a=commitdiff;h=next;hp=master
But yeah, gitweb seems to be actually missing a way to display “correct” diffs between arbitrary trees.
Thanks, Bjorn. I’m wondering where I might have gone to learn about this? I didn’t see it in any docs.
Probably nowhere. I’m just curious when it comes to URL parameters and usually throw “interesting” things in there to see what happens (or usually: how to make the script behave badly ;-)). Passing refs was the natural thing to try when I saw the hashes in the URLs.
Obviously, for blobdiff and commitdiff, that’s not what you’re actually supposed to do. blobdiff doesn’t handle multi-file diffs at all, and commit diff has the commit message header, which is pretty bogus when you’re not diffing against the real parent(s).
I guess you could add a treediff pretty easily, as it seems to boil down to a commitdiff without the commit message header.
You can configure Git to merge multiple branches when you “git pull”, doing an octopus merge. See the git-config manpage for documentation about branch..merge.
I don’t think this is quite what I’m after. It could merge a bunch of stuff into master, but what I want is to merge the same stuff into each topic branch, then merge all those into master.
John, might I suggest you get your blog added to the [url=http://planet.revisioncontrol.net] Revision Control planet[/url]? I think it’s run by James Blackwell, a Bzr guy.
They might have to create a new category for users like you and zooko who take on the task of learning about various version control systems and telling us about it. (for which, thanks!)
Hi Eric,
I didn’t know about that Planet — nice site, and I’ve added it to my Bloglines feeds.
But I can’t find any contact information to ask to be added. Do you know whom I talk to?
Hi, I think you can contact James
[url=”http://jblack.linuxguru.net/contact_me”]here[/url].
Are you raving about feature branches in general, or git feature branches in particular? Does git support this model better than mercurial, for example? If so, how?
(Um, raving as in “rave reviews,” not as in “raving lunatic.”)
Git in particular.
With Mercurial, I would have had to have a separate repo for every single feature branch. It would be possible, but would be more difficult and take more careful scripting, disk space, and thought.
Mercurial’s in-tree branches aren’t really the same thing as Git’s, and I don’t think they’d be quite right for this.
Something new in Mercurial (AFAIK) is ‘local branches’.
http://www.selenic.com/mercurial/wiki/index.cgi/LocalbranchExtension
As far as I can tell these are pretty much like Git’s branches. Unfortunately they don’t seem to be a part of the standard Mercurial distribution yet.