groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Git, where zombie branches shamble again


From: G. Branden Robinson
Subject: Re: Git, where zombie branches shamble again
Date: Tue, 2 Nov 2021 11:29:17 +1100
User-agent: NeoMutt/20180716

At 2021-11-01T22:30:28+0000, Keith Marshall via Groff-commit wrote:
> On 01/11/2021 14:01, G. Branden Robinson wrote:
> > At 2021-10-24T18:53:52-0700, Larry McVoy wrote:
> >> On Mon, Oct 25, 2021 at 11:58:55AM +1100, G. Branden Robinson
> >> wrote:
> >>> Since I am now accused four times over of rewriting history, and
> >>> moreover of violating an "absolute taboo", I must insist upon the
> >>> presentation of particulars.
> >>
> >> Hi, I'm the BitKeeper guy, nobody knows who I am but BitKeeper was
> >> the first distributed source management system, hg, git, etc are
> >> copies, I'm the guy that figured this model out.
> > 
> > Fear not!  I've known your name and (some of) your work for many
> > years.
> > 
> >> If you did not rewrite history, which means you changed things so
> >> that a pull won't work or will create a massive merge mess, then
> >> you are fine.
> > 
> > As far as _I_ can tell, neither of these has taken place.
> 
> Seriously?  You absolutely _did_ rewrite history ... not just once,
> but twice!  You deleted an _entire branch_ of published development
> history, then after my subsequent push had reinstated it, you deleted
> it once again!  If that isn't rewriting history, then I'd like to know
> what you would call it.

Larry's operational definition seems fine to me.  You've asserted
neither that (1) a pull won't work [depending on what, precisely, that
means--there are plenty of ways a pull won't work, like having a dirty
working tree or accessing the wrong remote] nor that (2) I've created a
massive merge mess.

I've told you earlier in the thread, what I call it: "marking a
development branch closed, abandoned, or otherwise defunct"[1].  I've
acknowledged, also more than once, that I may well have used an
incorrect approach to doing so, and I apologized for my error.  Yet you
remain unsatisfied.

> Now, I'm sure you made this mistake in ignorance, rather than with any
> malicious intent,

Thank you for acknowledging that.  I would ask that you let this
knowledge influence the tenor of your communications in a collaborative
working environment.

> but it was a history rewriting mistake nonetheless.

I remain unconvinced that it was; I'm not aware of any rule that says
dev branches must be immortal.  Once all of their work has been
merged/rebased/cherry-picked onto a living branch--as is the case here--
why do they need to stick around?

Here are some branches on Savannah right now.
  origin/gropdfmultiglyph
  origin/unique-version

They do not appear in the Web interface
<https://git.savannah.gnu.org/cgit/groff.git>.  Getting Savannah to
similarly "unlist" dev-gropdf-boxes was all I really wanted, but when I
found it was gone I didn't regard it as an emergency, since that was
consistent with branch management practices I've been exposed to
elsewhere (see below).  For the benefit of groff developers in general,
would you explain how to put a branch into the state where the Savannah
Web UI doesn't list it?

> Two things which you should never do, after anything has been pushed
> to a public repository: you should not rebase any of it; neither
> should you delete any of it.

Neither of these prohibitions is a universal practice applied to topic
branches.  I've seen force-pushes and deletion of branches like this
done commonly and encouraged as a matter of policy at workplaces.  With
dozens of developers, each of whom created topic branches at a frenzied
pace (often one per JIRA ticket), it was the only way to keep "git
branch --list --remote" (as excerpted above) output sane.  Similarly,
forced pushes (again, to topic branches, never to master) was a common
activity for uncluttering a series of commits before merging or rebasing
it onto the master branch.

The motivation for forced pushes on topic branches is simple: in a
peer-reviewed environment, development seldom proceeds in a straight
line: blind alleys are pursued, mistaken assumptions get written into
code and commit messages.  (Most often, in my experience, a person
initially simply isn't clear about what the root cause of a problem is;
they tend to feel pressure, often self-imposed, to get a "fix" pushed
without a detailed analysis, so that they can report progress to
supervisors.  A peer reviewer subsequently talks through the issue with
them, both of them understand it better, and the description and
sometimes the nature of the change are altered, reflecting this improved
knowledge.)

Eventually (ideally) full understanding and a code or documentation
change of impact proportional to the problem is arrived at.  Having the
false starts, blind alleys, and mistaken assertions in the master
branch's commit history is confusing to a project's own developers and
to the general public.  For a rigorously-engineered, high-profile, and
(in part) externally-funded project, such digressions are unwelcome.

groff is not the same sort of project, thankfully.  It's more casual and
doesn't draw the attention of suits or uniforms.  If groff's Git repo
has, or should have, a different policy, that's fine by me.  Let's get
it written down and teach people about it instead of having you blow in
every once in a while with derision and insults coupled with a refusal
to coach people in Git usage because you despise the tool in favor of
Mercurial[2].

> Yet you ignored what you suggest you have learned; you _did_ change
> some of that (published) history, by deleting an entire branch of it.

I reiterate: it's accepted practice in some places to dispose of a topic
branch once there is consensus that its usefulness is ended.  I inferred
consensus from Deri's activities and my own, since we were the only
people who worked on the branch.  I had not realized you considered
yourself a stakeholder in the branch.

> Frankly, I thought you might have been smart enough to work it out for
> yourself.

Please, don't budge from your inference that I'm stupid--it will save me
much time in dealing with you in the future.

> > Without an accurate description of damage done (if any) to the
> > repository, there is no way anyone can repair it.  And if there is
> > none, then charges of rewriting history are overblown, unwarranted,
> > and unfriendly.
> 
> Claims that you have not done what you so clearly have, are frankly
> disingenuous.
[repeated from earlier]
> Now, I'm sure you made this mistake in ignorance, rather than with any
> malicious intent,

What is given with one hand is taken away with the other.  If you can't
sustain a collegial attitude for even one email it's best not to try,
lest you come across as, shall one say, disingenuous.

> The damage done may not be critical, insofar as we may be able to live
> without that deleted branch,

Again I will stipulate to ungraceful procedure on my part, but, really,
what value remains in the branch?  You have a copy.  Tell us.
contrib/sboxes is on master, has Deri's own improvements (which were
never on the branch as far as I know, like the removal of "BX=1"
debugging output or some such thing) and my own further changes.
I checked a sample of your 54 commits (#01, #11, #22, #33, #44, #54) and
all of their hashes are present in my clone.

> but a possibility remains, that it could find its own way back at some
> future date;

How would that be a bad thing?  Wouldn't it constitute the restoration
of history so unwholesomely effaced by me?

> indeed, I still have a local clone, in which that history remains ...
> 54 commits, per attached deleted-history.log, (produced by 'hg
> outgoing' from that ...  now outdated ... clone).

As I said before[3], these ~50 commits you pushed that were not authored
by you were due to a "git --rebase master" on the "dev-gropdf-boxes"
branch.  They are therefore replays of history of the master branch.
(I make this claim based on the sampling above and the observation that,
as I understand it--and speaking loosely--a rebase operation moves a
branch's divergence point from its parent, increasing the amount of
shared history; or effectively moving a pointer from one node to another
in a directed acyclic graph.  I could be mistaken, however--let's not
understate my lack of smarts.)

What will fix this?  What do you want?  Who do you want do it?  You keep
complaining about the same thing without proposing a clear remedy.

I pledge to not alter any groff.git branches (meaning: not master) on
Savannah without checking with the list first, or until we can devise
some contributor-facing documentation that tells us all what is expected
and how to perform routine tasks like branch creation, management
(without blitzing the -commit list), and deletion.  If such a document
is created, I further pledge to follow it.

I'd like you to show the grace to accept the concessions I've made,
of mistaken practice and of my own stupidity, and let the topic drop.

If you won't do that, then I propose that you state your criteria for
satisfaction to a neutral arbiter--I nominate Larry McVoy, since he's
offered assistance.

If that, too, is unacceptable to you, then, again, I reckon we need to
escalate the issue.

Regards,
Branden

[1] https://lists.gnu.org/archive/html/groff-commit/2021-10/msg00194.html
[2] https://lists.gnu.org/archive/html/groff/2021-10/msg00056.html
[3] https://lists.gnu.org/archive/html/groff-commit/2021-10/msg00187.html

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]