Re: Actual tag-commit points...
Chapman Flack <[email protected]> Wed, 10 Apr 2019 11:03:03 -0400
| Newsgroups | gmane.comp.archivers.amanda.devel,gmane.comp.archivers.amanda.user |
|---|---|
| Message-ID | <[email protected]> |
On 4/10/19 10:35 AM, Chris Hassell wrote:
> As we move from SVN to Git I'm hoping to add real git "Tags"
> (symbolic names for commits) so that we can get descriptive names
> (using "git describe") for every possible point in the repository.
Hi,
Are you planning to tag just the commits that correspond to numbered
releases? That's a very common approach and definitely useful. (For
example, github will automagically populate its "Releases" page from
commits that have tags, or at least maybe tags of a certain form.)
For exactly that reason, it might be confusing to add a lot of tags
for, hm, interesting moments in development that weren't actual
releases.
For the day-to-day details of what was going on in the many
individual commits between one release and the next, one hopes
the commit messages themselves will give that information.
It's also possible to create a branch at any time, starting at
any historical point. If you add no new commits to the new 'branch',
it can also function as a new descriptive name for the point in
history that it points to ... and github won't automatically confuse
it with a release.
gitk --all
will give you a nice display of the history showing
what branches point where, what was merged when, and so on.
On 4/5/19 8:20 PM, Chris Hassell wrote:
> If you merge with it in your own repo ("
> git checkout origin/tags/community_3_5_1;
> git merge mergeable-trunk_buildfix_base;
>" ... it should put in some improvements that may help.
If I were doing that in my own repo, I would add a middle step where
I create a branch with a new name (initially pointing to the same
point in history as community_3_5_1), and then do the merge there.
That way, I don't end up with a branch in my repo called
community_3_5_1 that has extra stuff on it, and can no longer
be sync'd with the upstream.
That situation can always be sorted after the fact (as can most
things in git) with the right number of resets and rebases, but
in my early stages with git, I found that to be a bit daunting.
Easier to just make up a new branch name and experiment there
(and even just delete the whole branch if things go wobbly).
Regards,
-Chap