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://keithmarsh...@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://keithmarsh...@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://keithmarsh...@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.
