RE: Actual tag-commit points...

> -----Original Message-----
> From: Chapman Flack <[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.

[Chris Hassell] 
Agreed.  In this case the situation is more complex.

The ties to SVN make it so that there are not merely *zero* tags present anywhere, but that every 'branch-head' which SVN used as a tag has a fork-point (a commit parent of two child commits) that is wholly unnamed.  Many of these 'tag-forks' are simply the last-modification-before-a-release and the release itself is a branch where the "tag" was applied and the ChangeLog file was altered to show this.

My intention is to simply name that fork-point for *only* the tags that we have present from SVN.  No need to clutter with thousands of others.   As well these fork-points are ambiguous with the tag-branches we have now so they must be named differently anyway.   I hope to name them something clear-enough like "tag-3.1-trunk" or somesuch.   I don't want to clutter the namespace but we do need exact names to keep track, for history and for the future.
 
> 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.

[Chris Hassell] Having just one (recent) point that shows up in git, labelling a branch in its history, would be all we need.  No need for extra, I agree.

> 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.

[Chris Hassell] Yes certainly.  I have made several and, as well, don't want to make them ambiguous or confusing against real releases.

>   gitk --all
> 
> will give you a nice display of the history showing what branches point
> where, what was merged when, and so on.

[Chris Hassell] I love that view.  I go big and do "gitk --branches --tags --all" ... because those are passed on to "git log".

> 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.

[Chris Hassell] This was, I should note, merely put in until we may consider the pull-requests.  I'm trying to get to those.  Being one of the main CM-and-old-old-C-debugging guys at BETSOL has kept me in demand!  

> 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.

I was thinking I may add a tool in for that.  Ideally a build-with-merge-mixin-options is a bit of a silly option for the long term... but it does work for now.   If we have other configuration-changes we may do that.   In theory any build should be identified by its peak commit and this merge should make a distinct but repeatable commit name.  Maybe that can be the basis of naming a new branch with a "merge mixin".

> 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.

[Chris Hassell] Resets and merges are ... always possible but we've seen that Git doesn't like them as much as a smooth fast-forward line of commits.

> Easier to just make up a new branch name and experiment there (and even
> just delete the whole branch if things go wobbly).

[Chris Hassell] As they do.  :->

> Regards,
> -Chap