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