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

["Philip Oakley" <philipoakley@iee.org>]

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

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


> From: "Jakub Narebski" <jnareb@gmail.com>
> Sent: Saturday, February 04, 2012 7:45 PM
>> 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.
>
>>
>> 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.
>
>>
>> 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.
>
>>
>> What do you think about this?
>> -- 
>> Jakub Narebski
>> Poland
>> --
>
> Philip Oakley
>