Oops, forget 'reply all' to the list.
Philip
----- Original Message -----
From: "Philip Oakley" <philipoakley@xxxxxxx>
To: "Jakub Narebski" <jnareb@xxxxxxxxx>
Sent: Sunday, February 05, 2012 2:31 PM
Subject: Re: [RFD] Rewriting safety - warn before/when rewriting published
history
From: "Jakub Narebski" <jnareb@xxxxxxxxx>
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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html