Re: Git training wheels for the pimple faced maintainer

From: Kyle Moffett
Date: Fri Oct 20 2006 - 03:31:02 EST


On Oct 20, 2006, at 02:34:54, Pierre Ossman wrote:
Linus Torvalds wrote:
That all sounds fine. Please just check the format for the "[GIT PULL]" message: Andrew pulls peoples trees on his own and largely automatically, so he doesn't much care _what_ is in the tree, but I care deeply. So I want the diffstat and shortlog listings, and preferably a few sentences at the top of the email describing what's going on and why things are happening.

I'm still learning the more fancy parts of git, but I think that would be:

git diff master..for-linus | diffstat
git log master..for-list | git shortlog

Not quite. diffstat doesn't understand renames and such, you want to use something more like this:

git diff -M --stat --summary master..for-linus
git log --pretty=short master..for-linus | git shortlog

As an example, if you rename foo/bar/baz.c to foo/bar/quux.c and change a few lines, you'll get something like this:

foo/bar/{baz.c => quux.c} | 8 +--

It similarly makes renames between directories look nice.

So there's simply no point in merging from me, unless you know that there are clashes due to other development, and you actually want to fix them up. You will just cause unnecessary criss-cross merges if you pull from my tree after you've started development, and the history gets really really messy.

And in order to test for conflicts, I assume I should have a "test tree" that I merge all my local stuff in, together with your current HEAD?

Yes

If you actually want your development tree to "track" my tree, I'd suggest you have your "for-linus" branch that you put the work you want to track into, and then a plain "linus" branch which tracks _my_ tree. Then you can just fetch my tree (to keep your "linus" branch up-to-date), and if you want your development branch to track those changes, you can just do a "git rebase linus" in your "for-linus" branch.

If I've understood git correctly, a rebase is a big no-no once I've published those changes as it reverts some history. Right?

Well, sorta. If it's a pseudo-published development and you actually _don't_ _care_ what the old history was (because it was broken or incorrect or one of the patches got corrupted during import) then go ahead and wipe it out. On the other hand if you have random people pulling from your published tree then you can't safely git-rebase or cg-admin-rewrite-hist or similar. Luckily GIT will just complain about a discontinuous history as opposed to losing data.

Cheers,
Kyle Moffett


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/