Re: Actual tag-commit points...

This seems like a fine thing and we can always change tag names later as
necessary.  In the interest of accelerating the move to Git, I say let's do
it without further worry about the details..

Dustin

On Wed, Apr 10, 2019 at 11:56 AM Chris Hassell <[email protected]>
wrote:

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