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
signature.asc
Description: PGP signature
