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: Keith Marshall
Subject: Re: Git, where zombie branches shamble again
Date: Sun, 24 Oct 2021 20:35:44 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.2.1

On 24/10/2021 03:16, G. Branden Robinson wrote:
> [Here's another long email; Ralph may want to skip it.]
> At 2021-10-23T22:07:27+0100, Keith Marshall via Groff-commit wrote:
>> Well, I pulled, and updated my local tree, to capture Brandon's most
>> recent commits, then applied _one_ trivial ms patch, (which _should_
>> have affected only tmac/s.tmac, and ChangeLog); how this push has
>> regurgitated around 50 of Branden's old commits is beyond me.
> 
> It looks like you had a local, remote-tracking branch for
> dev-gropdf-boxes (which Bertrand created back in April or so).

I guess so; what's more, it will not go away, (see below).

> [...snip...]
> 
> You probably "git --pull --rebase"d, and implicitly pulled all
> branches.  You did your work and pushed...implicitly, _all_
> branches.

Nope.  I don't use git ... its user interface — or rather its *complete
lack* of any coherently designed UI — is just too repulsive (for me) to
even contemplate!  I actually did:

  $ hg qpop -a
  $ hg pull -u

to shelve all of my locally pending changes, and capture your latest
round of public changes, (and you are correct in assuming that my local
working copy incorporates *all* git branches, because that's just the
way mercurial clones of git repositories work), then:

  $ hg qpush
  $ hg qchlog --rewrite ChangeLog
  $ hg qrefresh
  $ hg qfinish -a
  $ hg push

to push the first change in my local patch queue ... and incidentally,
(and unexpectedly), restore the public repository history, which you had
(IMO inadvisedly) rewritten.

> [...snip...]
> 
> Today, after your mail, I have done this:
> 
> $ git push --delete origin dev-gropdf-boxes
> To git.sv.gnu.org:/srv/git/groff.git
>  - [deleted]             dev-gropdf-boxes

That seems like *really* antisocial behaviour!  We had a similar
discussion on MinGW, several years ago, when Earnie Boyd *proposed*
rewriting history on a public repository server; Chuck Wilson and I
persuaded him not to do so, because it really screws up collaborative
effort ... even git's commit documentation *strongly* discourages it!

> It _seems_ to be truly dead:

On the server, yes, but in my local *mercurial* clone, it is still
present!  There is (apparently) nothing I can pull:

  $ hg pull
  pulling from
  git+ssh://keithmarshall@git.savannah.gnu.org/srv/git/groff.git
  no changes found

but ... the 54 commits, which managed to have themselves regurgitated
yesterday, have done so again, today:

  $ hg outgoing | grep -c '^changeset:'
  54

(inspection of the actual "hg outgoing" output, without the grep
filtering, shows that these *do* correspond to your rewritten history):

  $ hg outgoing -B
  comparing with
  git+ssh://keithmarshall@git.savannah.gnu.org/srv/git/groff.git
  searching for changed bookmarks
     dev-gropdf-boxes          a1f569c9318c

I can delete the dev-gropdf-boxes bookmark, locally, but that *doesn't*
remove the associated commits; they remain in my local working copy of
the public repository, as orphans:

  $ hg bookmarks --delete dev-gropdf-boxes
  $ hg outgoing -B
  comparing with
  git+ssh://keithmarshall@git.savannah.gnu.org/srv/git/groff.git
  searching for changed bookmarks
  no changed bookmarks found
  $ hg outgoing | grep -c '^changeset:'
  54

> But the problem was mainly (1); that is, me.  Sorry about that.

What you describe may be a manifest *effect* of the problem; the *real*
problem is that, contrary to established wisdom, you've abused git's
ability to rewrite history, within a public repository — that should be
an absolute taboo.  The only way *I* (and I guess, other collaborators)
can recover from the adverse consequences of such history rewriting is
to abandon my current working copy of the repository, clone a fresh
copy, and forward port my outstanding patch queue to the newly cloned
working copy.

I have now cloned a fresh working copy of the public repository, so it
is unlikely that *I* will be pushing a resurrection of this particular
unwanted branch, but unless everyone else does likewise, perhaps we
shouldn't be too surprised if it reappears again.

-- 
Regards,
Keith.



reply via email to

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