{"thread":{"id":"29553","subject":"Fw: [RFD] Rewriting safety - warn before/when rewriting published history","startedAt":"2012-02-05T15:05:27Z","lastAt":"2012-02-05T15:05:27Z","messageCount":1,"participants":["Philip Oakley"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"183899","messageId":"1A0FD0F1D0AF429D941C20774162118F@PhilipOakley","threadId":"29553","inReplyTo":null,"subject":"Fw: [RFD] Rewriting safety - warn before/when rewriting published history","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":null,"receivedAt":"2012-02-05T15:05:27Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"Oops, forget 'reply all' to the list.\nPhilip\n\n----- Original Message ----- \nFrom: \"Philip Oakley\" <philipoakley@iee.org>\nTo: \"Jakub Narebski\" <jnareb@gmail.com>\nSent: Sunday, February 05, 2012 2:31 PM\nSubject: Re: [RFD] Rewriting safety - warn before/when rewriting published \nhistory\n\n\n> From: \"Jakub Narebski\" <jnareb@gmail.com>\n> Sent: Saturday, February 04, 2012 7:45 PM\n>> Git includes protection against rewriting published history on the\n>> receive side with fast-forward check by default (which can be\n>> overridden) and various receive.deny* configuration variables,\n>> including receive.denyNonFastForwards.\n>>\n>> Nevertheless git users requested (among others in Git User's Survey)\n>> more help on creation side, namely preventing rewriting parts of\n>> history which was already made public (or at least warning that one is\n>> about to rewrite published history).  The \"warn before/when rewriting\n>> published history\" answer in \"17. Which of the following features would\n>> you like to see implemented in git?\" multiple-choice question in latest\n>> Git User's Survey 2011[1] got 24% (1525) responses.\n>>\n>> [1]: https://www.survs.com/results/Q5CA9SKQ/P7DE07F0PL\n>>\n>> So people would like for git to warn them about rewriting history before\n>> they attempt a push and it turns out to not fast-forward.\n>>\n>\n> Another area that is implicitly related is that of (lack of) publication \n> of sub-module updates. A mechanisms that, in the super project, knows the \n> status of the (local) submodules, such as where they would be sourced \n> from, i.e. what was last pushed & where, could help in such instances.\n>\n>>\n>> What prompted this email is the fact that Mercurial includes support for\n>> tracking which revisions (changesets) are safe to modify in its 2.1\n>> latest version:\n>>\n>>  http://lwn.net/Articles/478795/\n>>  http://mercurial.selenic.com/wiki/WhatsNew\n>>\n>> It does that by tracking so called \"phase\" of a changeset (revision).\n>>\n>>  http://mercurial.selenic.com/wiki/Phases\n>>  http://mercurial.selenic.com/wiki/PhasesDevel\n>>\n>>  http://www.logilab.org/blogentry/88203\n>>  http://www.logilab.org/blogentry/88219\n>>  http://www.logilab.org/blogentry/88259\n>>\n>>\n>> While we don't have to play catch-up with Mercurial features, I think\n>> something similar to what Mercurial has to warn about rewriting\n>> published history (amend, rebase, perhaps even filter-branch) would\n>> be nice to have.  Perhaps even follow UI used by Mercurial, and/or\n>> translating its implementation into git terms.\n>>\n>> In Mercurial 2.1 there are three available phases: 'public' for\n>> published commits, 'draft' for local un-published commits and\n>> 'secret' for local un-published commits which are not meant to\n>> be published.\n>>\n>> The phase of a changeset is always equal to or higher than the phase\n>> of it's descendants, according to the following order:\n>>\n>>      public < draft < secret\n>>\n>> Commits start life as 'draft', and move to 'public' on push.\n>\n> Recording where they wer pushed to would be useful for synchronising \n> sub-modules and their super projects. That is, giving remote users a clue \n> as to where they might find mising sub-modules.\n>\n>>\n>> Mercurial documentation talks about phase of a commit, which might\n>> be a good UI, ut also about commits in 'public' phase being \"immutable\".\n>> As commits in Git are immutable, and rewriting history is in fact\n>> re-doing commits, this description should probably be changed.\n>>\n>> While default \"push matching\" behavior makes it possible to have\n>> \"secret\" commits, being able to explicitly mark commits as not for\n>> publishing might be a good idea also for Git.\n>>\n>\n> Being able to mark temporary, out of sequence or other hacks as Secret \n> could be useful, as would recording where Public commits had been sent.\n>\n>>\n>> What do you think about this?\n>> -- \n>> Jakub Narebski\n>> Poland\n>> --\n>\n> Philip Oakley\n> \n"}]}