On Tue, 24 May 2005, Jeff Garzik wrote:
> Please pull the 'for-linus' branch from
>
> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
Is this really what you meant to do? There's seven merges there, none of
which have _any_ information about _what_ you merged, because you've mixed
everything up in one tree, so that there's absolutely no record of the
fact that you actually had seven different repositories that you pulled..
That sucks, Jeff.
I don't understand why you don't use different trees, like you did with
BK. You can share the object directory with the different trees, but the
way you work now, it all looks like mush.
Even if you don't get confused youself, you sure are confusing everybody
else with it..
Anyway, if you really want to work this way, with one big mushed-together
thing that has different heads that you keep track of, can you _please_ at
least make the commit message tell what you're doing. It's not a complex
script, and you're definitely mis-using it as things stand now by
switching heads around inside one repository, and not telling other people
about it.
--- side note ---
Also, the way you work, I think you actually may want to do a multi-parent
merge. That is, you may want to merge multiple parents in _one_ commit,
rather than having seven commits for it.
The way to do that is to just do "git-read-tree -m" (and the subsequent
merge) several times. You do not have to commit in between each step, you
just need to remember the parents, and then you do the final commit with
git-commit-tree $result_tree -p $head -p $p1 -p $p2 -p $p3 ...
ie you build up a commit command line that grows one more "-p xxxx" for
each parent you have merged. That requires a bit more work, but as it is,
your merges just look like crap.
--- end side note ----
Please?
Linus
----
commit fd3fac6ffe20bc6ca75b3ad38be0a8be6666b5d3
tree 49b4cfa6c95094612438b1ddeb0c9511a19125fe
parent c97f5a778ed33aef8f62496d7b82ba3cb896a587
parent b3dd65f958354226275522b5a64157834bdc5415
author <[email protected]> Tue, 24 May 2005 00:47:58 -0400
committer Jeff Garzik <[email protected]> Tue, 24 May 2005 00:47:58 -0400
Automatic merge of /spare/repo/netdev-2.6/.git
commit c97f5a778ed33aef8f62496d7b82ba3cb896a587
tree c72dbed812b0ffa83700a1896895714248407daf
parent 09fc75b6757852798969e7585456499784a982e1
parent 1bcd315362e215a72b56d1330bbf32f1c74eefb5
author <[email protected]> Tue, 24 May 2005 00:47:43 -0400
committer Jeff Garzik <[email protected]> Tue, 24 May 2005 00:47:43 -0400
Automatic merge of /spare/repo/netdev-2.6/.git
commit 09fc75b6757852798969e7585456499784a982e1
tree 60a2d2893cb757307edf0a0c450689610644cac2
parent b5545f2a2d915f5b6d86fb57e6ccc96b3010259e
parent ac79c82e793bc2440c4765e5eb1b834d2c18edf2
author <[email protected]> Tue, 24 May 2005 00:47:28 -0400
committer Jeff Garzik <[email protected]> Tue, 24 May 2005 00:47:28 -0400
Automatic merge of /spare/repo/netdev-2.6/.git
commit b5545f2a2d915f5b6d86fb57e6ccc96b3010259e
tree 0ece2dd139d1fa4a6b0c5f61fc2be75692d0ea47
parent f180e742711ce512e62161436d166eb4df92b34d
parent 2648345fcbadfae8e7113112ff9402e465a184dc
author <[email protected]> Tue, 24 May 2005 00:47:20 -0400
committer Jeff Garzik <[email protected]> Tue, 24 May 2005 00:47:20 -0400
Automatic merge of /spare/repo/netdev-2.6/.git
commit f180e742711ce512e62161436d166eb4df92b34d
tree 21fcfc0ca4a47776bc1182898d9b394529aa1daf
parent 7b5c2db59567052805771e1de2ad4e089b88c847
parent 042e2fb70006f135469d546726451b7d14768980
author <[email protected]> Tue, 24 May 2005 00:47:12 -0400
committer Jeff Garzik <[email protected]> Tue, 24 May 2005 00:47:12 -0400
Automatic merge of /spare/repo/netdev-2.6/.git
commit 7b5c2db59567052805771e1de2ad4e089b88c847
tree d18dc44dcfd34a99ac11a83e6d324730784b7d81
parent 02dd6b49b3f75dacfa7eddf7f2faa8b810906e47
parent 9092f46b5aed4515d9a427d5dab3be1584851f07
author <[email protected]> Tue, 24 May 2005 00:45:05 -0400
committer Jeff Garzik <[email protected]> Tue, 24 May 2005 00:45:05 -0400
Merge of /spare/repo/netdev-2.6/.git
commit 02dd6b49b3f75dacfa7eddf7f2faa8b810906e47
tree 240cfa2396a6ed006ee28f3848b4cceebfc35b11
parent 187a1a94d629621d1471b42308e63573b1150773
parent dfa1b73ffb414b64dc0452260132a090eb25bf52
author <[email protected]> Tue, 24 May 2005 00:44:49 -0400
committer Jeff Garzik <[email protected]> Tue, 24 May 2005 00:44:49 -0400
Automatic merge of /spare/repo/netdev-2.6/.git
Linus Torvalds wrote:
>
> On Tue, 24 May 2005, Jeff Garzik wrote:
>
>
>>Please pull the 'for-linus' branch from
>>
>>rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
>
>
> Is this really what you meant to do? There's seven merges there, none of
> which have _any_ information about _what_ you merged, because you've mixed
> everything up in one tree, so that there's absolutely no record of the
> fact that you actually had seven different repositories that you pulled..
>
> That sucks, Jeff.
>
> I don't understand why you don't use different trees, like you did with
> BK. You can share the object directory with the different trees, but the
> way you work now, it all looks like mush.
>
> Even if you don't get confused youself, you sure are confusing everybody
> else with it..
You are getting precisely the same thing you got under BitKeeper: pull
from X, you get my tree, which was composed from $N repositories. The
tree you pull was created by my running 'bk pull' locally $N times.
Ultimately, you appear to be complaining about:
* your own git-pull-script, which doesn't record the $2 (branch)
argument in the commit message.
* the fact that my changelog includes the merge csets that were
present-but-invisible by my BitKeeper submissions. i.e. I lack a
shortlog that filters out merge csets.
> Anyway, if you really want to work this way, with one big mushed-together
> thing that has different heads that you keep track of, can you _please_ at
> least make the commit message tell what you're doing. It's not a complex
Hey, I didn't write git-pull-script, I just use it :)
> script, and you're definitely mis-using it as things stand now by
> switching heads around inside one repository, and not telling other people
> about it.
Switching heads around? It sounds like you did not pull from the branch
I mentioned. This is how git-pull-script pulls from a branch:
git-pull-script \
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git\
refs/heads/for-linus
Jeff
Linus Torvalds wrote:
> I don't understand why you don't use different trees, like you did with
> BK. You can share the object directory with the different trees, but the
You really can't beat
cp .git/refs/heads/master .git/refs/heads/new-branch
as the fastest way to create a new branch off the tip.
Jeff
On Tue, 24 May 2005, Jeff Garzik wrote:
>
> You are getting precisely the same thing you got under BitKeeper: pull
> from X, you get my tree, which was composed from $N repositories. The
> tree you pull was created by my running 'bk pull' locally $N times.
No. Under BK, you had DIFFERENT TREES.
What does that mean? They had DIFFERENT NAMES.
Which meant that the commit message was MEANINGFUL.
> Ultimately, you appear to be complaining about:
>
> * your own git-pull-script, which doesn't record the $2 (branch)
> argument in the commit message.
Yes, because _my_ pull script is meant to work with the way _I_ have told
people (including you) they should work.
The fact that you mush everything up in one tree _despite_ me having told
you that isn't a good thing to do is the problem.
Git can technically do it, but then you shouldn't use my scripts, which
aren't written for that behaviour.
> Hey, I didn't write git-pull-script, I just use it :)
You don't use it, you MIS-use it. Which is what I'm complaining about.
> Switching heads around? It sounds like you did not pull from the branch
> I mentioned.
No, I pulled exactly from the head you mentioned.
In fact, go look at YOUR OWN changelog. And then compare that changelog to
the changelog you had when you used BK, and realize that IT IS NOT AT ALL
EQUIVALENT. You used to have valid changelogs, even for the merge heads.
You don't any more:
Automatic merge of /spare/repo/netdev-2.6/.git
Automatic merge of /spare/repo/netdev-2.6/.git
Automatic merge of /spare/repo/netdev-2.6/.git
Automatic merge of /spare/repo/netdev-2.6/.git
Merge of /spare/repo/netdev-2.6/.git
See a pattern?
Your BK usage was equivalent to having multiple GIT repositories.
Linus
On Tue, 24 May 2005, Jeff Garzik wrote:
>
> You really can't beat
>
> cp .git/refs/heads/master .git/refs/heads/new-branch
>
> as the fastest way to create a new branch off the tip.
So? It's the fastest, but it's also BROKEN. Exactly because the way you do
things, the merge messages are meaningless.
So fix your merge messages.
Linus
Linus Torvalds wrote:
>
> On Tue, 24 May 2005, Jeff Garzik wrote:
>
>>You are getting precisely the same thing you got under BitKeeper: pull
>>from X, you get my tree, which was composed from $N repositories. The
>>tree you pull was created by my running 'bk pull' locally $N times.
>
>
> No. Under BK, you had DIFFERENT TREES.
>
> What does that mean? They had DIFFERENT NAMES.
>
> Which meant that the commit message was MEANINGFUL.
Ok, I'll fix the commit message.
As for different trees, I'm afraid you've written something that is _too
useful_ to be used in that manner.
Git has brought with it a _major_ increase in my productivity because I
can now easily share ~50 branches with 50 different kernel hackers,
without spending all day running rsync. Suddenly my kernel development
is a whole lot more _open_ to the world, with a single "./push". And
it's awesome.
That wasn't possible before with BitKeeper, just due to sheer network
overhead of 50 trees. With BitKeeper, the _only_ thing that kernel
hackers and users could get from me is a mush tree with everything
merged into a big 'ALL' repository.
So I'll continue to be the oddball, because more people can work in
parallel with me that way. I'll just have to make sure the commit
messages look right to you.
Jeff
On Tue, 24 May 2005, Jeff Garzik wrote:
>
> Ok, I'll fix the commit message.
>
> As for different trees, I'm afraid you've written something that is _too
> useful_ to be used in that manner.
I really think you'll eventually confuse yourself terminally, but as long
as the commit messages end up being meaningful, your "mush everything
together" clearly is the thing that is going to perform best.
> Git has brought with it a _major_ increase in my productivity because I
> can now easily share ~50 branches with 50 different kernel hackers,
> without spending all day running rsync.
Hey, I'm happy it works for you, but are you sure those 50 other kernel
hackers aren't confused?
IOW, your work model is pretty extreme, and I'm much more worried about
mixing up trees by mistake than about the technical side of git per se.
That's also why I think it's important that the commit logs are
meaningful: they do end up containing the SHA1 key, so clearly "all the
information" is there, but if something gets mixed up, I'd like some human
to be able to eventualyl say "Aaahhh.. _that's_ where it got mixed up".
Linus
On Tue, 24 May 2005, Jeff Garzik wrote:
> Linus Torvalds wrote:
>>
>> On Tue, 24 May 2005, Jeff Garzik wrote:
>>
>>> You are getting precisely the same thing you got under BitKeeper: pull
>>> from X, you get my tree, which was composed from $N repositories. The
>>> tree you pull was created by my running 'bk pull' locally $N times.
>>
>>
>> No. Under BK, you had DIFFERENT TREES.
>>
>> What does that mean? They had DIFFERENT NAMES.
>>
>> Which meant that the commit message was MEANINGFUL.
>
> Ok, I'll fix the commit message.
>
> As for different trees, I'm afraid you've written something that is _too
> useful_ to be used in that manner.
>
> Git has brought with it a _major_ increase in my productivity because I can
> now easily share ~50 branches with 50 different kernel hackers, without
> spending all day running rsync. Suddenly my kernel development is a whole
> lot more _open_ to the world, with a single "./push". And it's awesome.
>
> That wasn't possible before with BitKeeper, just due to sheer network
> overhead of 50 trees. With BitKeeper, the _only_ thing that kernel hackers
> and users could get from me is a mush tree with everything merged into a big
> 'ALL' repository.
couldn't you just have your multiple 'trees' use the same object
repository directory (still a single group of files to push), but still
have your trees with different names? it would be just a little more then
the copy of the HEAD object (you'd have to change the name in it), but it
should be easily scriptable)
or is there a limit in git that I'm overlooking that would prohibit this?
David Lang