Fw: [RFD] Rewriting safety - warn before/when rewriting published history

Oops, forget 'reply all' to the list.
Philip

----- Original Message ----- 
From: "Philip Oakley" <redacted>
To: "Jakub Narebski" <redacted>
Sent: Sunday, February 05, 2012 2:31 PM
Subject: Re: [RFD] Rewriting safety - warn before/when rewriting published 
history

From: "Jakub Narebski" <redacted>
Sent: Saturday, February 04, 2012 7:45 PM

quoted

Git includes protection against rewriting published history on the
receive side with fast-forward check by default (which can be
overridden) and various receive.deny* configuration variables,
including receive.denyNonFastForwards.

Nevertheless git users requested (among others in Git User's Survey)
more help on creation side, namely preventing rewriting parts of
history which was already made public (or at least warning that one is
about to rewrite published history).  The "warn before/when rewriting
published history" answer in "17. Which of the following features would
you like to see implemented in git?" multiple-choice question in latest
Git User's Survey 2011[1] got 24% (1525) responses.

[1]: https://www.survs.com/results/Q5CA9SKQ/P7DE07F0PL

So people would like for git to warn them about rewriting history before
they attempt a push and it turns out to not fast-forward.

Another area that is implicitly related is that of (lack of) publication 
of sub-module updates. A mechanisms that, in the super project, knows the 
status of the (local) submodules, such as where they would be sourced 
from, i.e. what was last pushed & where, could help in such instances.

quoted

What prompted this email is the fact that Mercurial includes support for
tracking which revisions (changesets) are safe to modify in its 2.1
latest version:

 http://lwn.net/Articles/478795/
 http://mercurial.selenic.com/wiki/WhatsNew

It does that by tracking so called "phase" of a changeset (revision).

 http://mercurial.selenic.com/wiki/Phases
 http://mercurial.selenic.com/wiki/PhasesDevel

 http://www.logilab.org/blogentry/88203
 http://www.logilab.org/blogentry/88219
 http://www.logilab.org/blogentry/88259


While we don't have to play catch-up with Mercurial features, I think
something similar to what Mercurial has to warn about rewriting
published history (amend, rebase, perhaps even filter-branch) would
be nice to have.  Perhaps even follow UI used by Mercurial, and/or
translating its implementation into git terms.

In Mercurial 2.1 there are three available phases: 'public' for
published commits, 'draft' for local un-published commits and
'secret' for local un-published commits which are not meant to
be published.

The phase of a changeset is always equal to or higher than the phase
of it's descendants, according to the following order:

     public < draft < secret

Commits start life as 'draft', and move to 'public' on push.

Recording where they wer pushed to would be useful for synchronising 
sub-modules and their super projects. That is, giving remote users a clue 
as to where they might find mising sub-modules.

quoted

Mercurial documentation talks about phase of a commit, which might
be a good UI, ut also about commits in 'public' phase being "immutable".
As commits in Git are immutable, and rewriting history is in fact
re-doing commits, this description should probably be changed.

While default "push matching" behavior makes it possible to have
"secret" commits, being able to explicitly mark commits as not for
publishing might be a good idea also for Git.

Being able to mark temporary, out of sequence or other hacks as Secret 
could be useful, as would recording where Public commits had been sent.

quoted

What do you think about this?
-- 
Jakub Narebski
Poland
--

Philip Oakley