Please don't remove git mailing list from Cc... Oh, I see that you forgot to send to list, but resend your email there. On Sun, 5 Feb 2012, Philip Oakley wrote: > 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. "Better support for submodules" had almost the same number of requests in the latest Git User's Survey 2011 (25% which means 1582 responses). Remembering when to do recursive push and where would be a very nice thing. [...] > Recording where they were 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. Is it a matter of correctly writing configuration with current git? I don't use submodules myself, so I cannot say. > > 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. Marking as 'secret' must I think be explicit, but I think 'public' phase should be inferred from remote-tracking branches. The idea of phases is to allow UI to ask about status of commits: can we amend / rebase it or not, can we push it or not. -- Jakub Narebski Poland -- 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