Re: Lost association between TAGS and COMMITs when rebased a git(1) repository

From: Philip Oakley <philipoakley@iee.org>
Date: Sep 4, 2011, 17:20 UTC
Message-ID: <1B5C619E91F7437EA844D1D3DD3E6798@PhilipOakley>
In-Reply-To: <3c10d6593152436c9dd3a5b5773e3c79-mfwitten@gmail.com>

From: "Michael Witten" <mfwitten@gmail.com>

Show 22 quoted lines

> On Sat, 3 Sep 2011 21:32:03 -0400, John S. Urban wrote:
>> Also, I have some commits with multiple tags pointing to them. It has 
>> come
>> to my attention that might not be an intentional feature. I could find
>> nothing in the documentation explicitly stating multiple tags were 
>> allowed
>> to point to a commit; but the tags seem to be unique "objects" so I
>> see no reason this should not be an expected feature?
>
> Well, everybody, it sounds like John's confusion is a good example for
> why `tag' is another TERRIBLE choice of terminology.
>
> See here:
>
>  http://article.gmane.org/gmane.comp.version-control.git/179609
>  Message-ID: 
> <CAMOZ1Btmk86vmp1gRuCfG7yRuc6fD3_oYBvtq2VKK9Ywu8ay0A@mail.gmail.com>
>
>  http://article.gmane.org/gmane.comp.version-control.git/179942
>  Message-ID: 
> <CAMOZ1Bti3ZtAEOtLiUYSkWE+rO_VQd09NAn58Cn4hZBu8f-aFQ@mail.gmail.com>
> --

In terms of things understood and misunderstood, I found that Branches and Tags were reasonable terms for use within Git at the time I read about them (I'm still getting to grips with git in a hostile Windows environment).

There were other areas of confusing (to me) terminology, such as heads, tips, and refs, which are 'the same' within particular contexts. In the same way the Index/Staging area can be confusing without a good visualisation.

The fact that Git has both Trees, and Branches but relating to different parts of the architecture can be a bit confusing, but wasn't too much of a hassle.

The fact that git does merging with relative ease is one reason that brings on the 'branch' problem. If merging is a major activity that is kept independent of the SCM, as it often is, then branches take on a bigger meaning as being proper sub-projects with all the attention that comes from there. If they are simple, lightweight, easy to use, and 'discard' then the concerns should reduce, unless that is, local customs keep worrying the issue. Most SCM systems are built on archaic principles that pre-date computers, so a new methodology has an uphill battle.

In terms of Figure 0 in Sourceforge, It doesn't fully represent the information that Git would have, because the order of parentage would be available, though Git doesn't mandate that branch names are remembered (but is normally within merge commit messages). This means that some folks would feel unhappy about the bundle of diverge/merge links in the DAG that don't have Names, which is a very human concern.

Overall, I'm not too unhappy with the terminology, and yes I would like filter-branch to be able to copy across tags when creating a publishable history - it probably just need me to understnd the right --tag-name-filter <command>.

Philip