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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
