On 10/24/06, Linus Torvalds <torvalds@xxxxxxxx> wrote:
On Tue, 24 Oct 2006, Erik Bågfors wrote:
>
> I don't see any problem doing a "gitk --all" equivalent in bzr.
The problem? How do you show a commit that is _common_ to two branches,
but has different revision names in them?
Eric,
coming from an Arch background, I understand the whole per-branch
commitids approach. After using GIT for a while, you start realising
that it tries to pin down things in the wrong place.
This is specially visible if you run `gitk --all` before and after a
merge. Or on a project with many merges (if you can, get a checkout of
git itself, and browse its history with gitk).
Before the merge, you see
--o--o--o--o
\
\--o--o
and after
--o--o--o--o
\ \
\--o--o--o
Now, after it's merged somewhere, both commits are part of its
history, regardless of where they come from. And it is very clear if
two branches have been merging and remerging.
Where a commit originated does not matter. And fancy
repo-and-branch-centric names get in the way. A lot. And they re
mostly meaningless as soon as you put what matters in the commit
message. Which means that that bit of metadata that you are hoping
that the revno keeps "indirectly" isn't lost on cherry picking.
I guess that's where I used to find revnos useful as they contained
some basic metadata. With bzr it seems to be author-repo-branch where
branch is hopefully "line of work" but all of that can be (and should
be) in the commit message.
You can see similar info in the first part of the commit message for
most git-hosted projects. It'll say something like
cvsserver: fix the frobnicator to be sequential
which means that at that point, you could be working in a branch
called fix-this-fscking-thing-attempt524" and no-one would know ;-)
And in a few years (even months) time, that bit of metadata you were
hoping to keep is totally irrelevant. What you have in the commit
message remains relevant and useful.
cheers,
martin
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html