On Fri, 4 Aug 2023, James Browning via devel wrote:
On 08/04/2023 6:35 PM PDT Fred Wright via devel <devel@ntpsec.org> wrote:
:::snip:::
I notice that the two commits for that don't seem to be in any branch.
Having commits only "owned" by a tag and not a branch seems fragile.
I do not think it is particularly fragile; I mean the garbage
collector is that aggressive, is it?
It's not just about the garbage collector. Git's general philosophy is
that non-transient commits are exepected to exist on at least one branch,
and some of the tools for moving commits around are branch-oriented. It
happens that "git fetch" manages to pick up this commit via the tag, but
in general, expecting branchless commits to be handled fully correctly is
pushing one's luck.
In the process of investigating this, I noticed that only the master
branch is visible in the WebGUI, even though there are actually 25
branches in the repo.
I also only see the branch master. Then again I am not expecting to
see 26 branches because we have 25 tags and master. BTW master at one
point or another contained all of those tags.
This is about branches, not tags. The number was 25 including master, but
24 of those were leftovers in my local repo, due to not having done a
prune. So master-only is actually correct at the moment.
Having a separate branch for each patch release could get somewhat
cluttered, but it's straightfoward to use a single branch for all patch
releases, as long as folks aren't allergic to merge commits.
If it bothers you, I could add a merge request to add a 1.2.2 branch.
As I mentioned, a branch for each patch release doesn't scale well, though
it's probably better than nothing. Using a release branch in general
would have additional benefits besides handling the patch release case
reasonably.
On Mon, 7 Aug 2023, Richard Laager via devel wrote:
On 2023-08-04 20:35, Fred Wright via devel wrote:
I notice that the two commits for that don't seem to be in any branch.
Having commits only "owned" by a tag and not a branch seems fragile.
I think it's fine for a backport fix release like this.
See above.
That said, I did advocate for merging it back in to master (as a no-op). But
I don't feel particularly strongly about that.
Attempting to merge it into master now would just result in a conflict
that would have to be resolved by turning it into an empty commit (and
giving git explicit permission to do that).
The real problem at that level is that the patch wasn't originally created
via "git cherry-pick", which is because the original master commit
combined multiple changes into one commit. This is one example of why
that should be avoided.
Fred Wright
_______________________________________________
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo/devel
