Thanks to all for the replies. Perhaps the tutorials should mention notes
more often. I used several introductory
manuals; all of which mentioned tags and none of which mentioned notes. The
tags seem (in retrospect) useful when
I want additional sign-off capabilities. If the tags are seen only as a
sign-off mechanism I understand why they do not
retain their associations when you "rewrite history"; but I really would
like to see a --tags option on the rebase option
that lets tags keep their associations when they are not signed, as one
reply suggested.
Notes are definitely more appropriate for my purpose than tags, however. I
haven't tried them yet but will shortly.
I hope to see that
they show up in gitk(1) as nicely as the tags do. I've been using the line
mode but the reviewers are very happy with
gitk(1) as an efficient way to review and sign changes (especially simple
ones).
Now that I've used the basics enough to find git(1) useful I guess it's time
to read the complete manual before I shoot
myself in the foot again (yeehh, like that will happen!).
Much appreciated!
----- Original Message -----
From: "knittl" <knittl89@xxxxxxxxxxxxxx>
To: "John S. Urban" <urbanjost@xxxxxxxxxxx>
Sent: Sunday, September 04, 2011 3:55 AM
Subject: Re: Lost association between TAGS and COMMITs when rebased a git(1)
repository
On Sun, Sep 4, 2011 at 3:32 AM, John S. Urban <urbanjost@xxxxxxxxxxx> wrote:
With my first use of git(1) I created a small project with about 200
"commits". When this was complete, I needed to label each commit with
information pointing it to a section of a document. I used tags for this.
Use git notes[1] to attach additional info to existing commits. Git
notes will by default be copied when using git rebase or git commit
--amend (cf. notes.rewrite.<command> config)
So far, everything was fine. I was then asked to merge two commits
into one. I then did a "rebase" (for the first time). I then appear to
have
lost all association between the tags and the effected commits; as all
commits after
the ones I modified no longer see "their" tags. Was there a way to have
kept
the tags associated with the original commits as they were "rebased"?
"Rebase" takes commits and creates new commits from those. The new
commits are not the same as the old, although they might have
associated the same tree or changeset.
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?
Tags can point to any git object (commits, trees, blobs, notes, even
to other annotated tags). There's nothing wrong with that.
[1]: http://www.kernel.org/pub/software/scm/git/docs/git-notes.html
--
typed with http://neo-layout.org
myFtPhp -- visit http://myftphp.sf.net -- v. 0.4.7 released!
--
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