Re: Actual tag-commit points...

I think this sounds like a good, and lossless, cleanup.

Dustin

On Thu, May 2, 2019 at 3:45 PM Chris Hassell <[email protected]>
wrote:

> NEW GIT-STYLE TAGS FOR BRANCH-POINTS
>
> So I've put the tags up as I mentioned a while ago... these
> last-shared-commits marked with these tags.   (i.e. last same-commit-used
> between master and many branches).
>
> These now mark all the points on the trunk/master line of commits.   As
> complicated as this revision history is, this does help anyone navigate the
> line of commits to see how compatible any change is versus any others in
> the master-branch line.   There aren't that many and they're named
> unambiguously at least.
>
>    - tag-2.5.2
>    - tag-2.5.2.beta1
>    - tag-2.5.x-perl
>    - tag-2.6.0
>    - tag-2.6.0.beta2
>    - tag-2.6.1
>    - tag-3.1.x
>    - tag-3.2.0.beta1
>    - tag-3.2.x
>    - tag-3.3.x
>    - tag-3.4.x
>    - tag-3.5.x
>
> Beyond these, out in each branch for each version, there are many many
> more ... and they're named with "subtag" to clarify that they didn't get
> contributed to the master (not directly).   Here's the ones based on the
> zmanda and community release-tags explicitly.   Any named with "-stub"
> signifies that nothing more exists downstream of this tag by itself.  Any
> with .rel after the name implies it exists as the patch-level-0 among other
> tags with patch-levels or QA-levels.
>
>    - subtag-community-3.3.1
>    - subtag-community-3.3.2
>    - subtag-community-3.3.4
>    - subtag-community-3.3.6
>    - subtag-community-3.3.7
>    - subtag-community-3.3.7.qa02-stub
>    - subtag-community-3.3.7.qa03-stub
>    - subtag-community-3.3.7.rel-p1
>    - subtag-community-3.3.8
>    - subtag-community-3.3.9
>    - subtag-community-3.4.1
>    - subtag-community-3.4.2
>    - subtag-community-3.4.3
>    - subtag-community-3.4.4
>    - subtag-community-3.4.5
>    - subtag-community-3.4.rel
>    - subtag-community-3.5
>    - subtag-community-3.5.1
>    - subtag-community-3_4.rel
>    - subtag-zmanda-3.3.0.rel
>    - subtag-zmanda-3.3.1.qa01
>    - subtag-zmanda-3.3.1.qa02-stub
>    - subtag-zmanda-3.3.1.rel
>    - subtag-zmanda-3.3.2.rel
>    - subtag-zmanda-3.3.3
>    - subtag-zmanda-3.3.4
>    - subtag-zmanda-3.3.5
>    - subtag-zmanda-3.3.6.rel
>    - subtag-zmanda-3.3.7.qa01-stub
>    - subtag-zmanda-3.3.7.qa02-stub
>    - subtag-zmanda-3.3.7.qa03-stub
>    - subtag-zmanda-3.3.7.rel
>    - subtag-zmanda-3.4
>    - subtag-zmanda-3.5.rel
>    - subtag-zmanda-3_3_2.rel
>    - subtag-zmanda-3_5.rel
>
> REQUEST TO CHANGE TO GIT-STYLE TAGS ONLY
>
> As a request to everyone, I'd like to remove a set of stub-branches that
> are named "tag/N_N_N" and contain no commits.  In their place we'd have the
> git-style tags (named with "subtag-*").   Note that this is not all of the
> tags/* branches!
>
> Why choose a subset of them?  Each of those branches listed in my
> attachment has exactly *1* commit and no changed files at all.  They are
> just leftovers from Subversion and can be discarded with no loss except the
> log message (I guess?) as they changed no files.  Most of these
> non-branch-branches don't even represent a real release of Amanda that ever
> happened.
>
> Erasing branches is rather serious, but in this case we lose precisely
> nothing, I believe.  The git-style tags references can be used instead and
> are much clearer.  [I'd prefer to rename "tag-*" for off-master and
> "subtag-*" for off-release-branch but only with a consensus.]
>
>     -- CH
>
>
>
> On 4/10/19 8:50 AM, Chris Hassell wrote:
>
> -----Original Message-----
> From: Chapman Flack <[email protected]> <[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
>
>