On 10/24/06, Martin Langhoff <martin.langhoff@xxxxxxxxx> wrote:
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,
It's Erik :)
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.
Let's make one thing clear. Revnos are NOT stored with the revision,
they are not "names" of the revision. They are basically just
shortcuts to specific revisions, that only makes sence in the context
of a branch.
As human beings this is something we are very used to in everyday
life. I don't always call my friends with firstname and surname, I
just use first name or even "mate". As long as it's clear who I'm
talking about in that contect. If there are multiple people with the
same first name, then we might have to use the surname as well.
Same with bzr. In the context of a branch, revnos works as shortcuts
to the revision id. In the context of multiple branches, they don't.
I think they do serve a good purpose but I don't really think that we
absolutely need them either.
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.
I'm not even going to try to understand the argument here as they are
about a totally different thing and doesn't make any sense to me.
I think this disussion is getting out of hand.
There are a few things that are being discussed
1. Revnos are bad/good
2. treating "leftmost" parrent special is bad/good
3. plugins are useless/useful
4. And now, storing branch information should be done manually (if
wanted) and not automatically.
1. I don't really care, I haven't seen any confusion based on it, but
I don't have a very strong opinion about it either.
2. This is something I do care about. For me, this is the only
logical way of doing it. It might be because I am used to it now, but
when I started to look at bzr/hg/git/darcs/etc, I just got a so much
more clear view of the history when running a standard log command,
that it was one of the first things that attracted me to bzr. This is
just a user talking.
There might be technical reasons why it's better to not do it, but for
me it works the way I expect, therefore I'm happy
3. This is just silly
4. No comment.
/Erik
-
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