From: "Michael Witten" <mfwitten@xxxxxxxxx>
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@xxxxxxxxxxxxxx>
http://article.gmane.org/gmane.comp.version-control.git/179942
Message-ID:
<CAMOZ1Bti3ZtAEOtLiUYSkWE+rO_VQd09NAn58Cn4hZBu8f-aFQ@xxxxxxxxxxxxxx>
--
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
--
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