See inlined responses below. On Feb 4, 2012, at 11:45 AM, Jakub Narebski wrote: > 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. > I like this idea and I encounter this issue with my co-workers new to git. It scares them thinking they broke the repository. > 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 Let's not limit ourselves to just three levels. They are a great start but I propose the following. published - The commits that are on a public repository that if are rewritten will invoke uprisings. general rule here would be to revert or patch, no rewrites. based - The commits that the core developers have work based upon. (not just the commits in their repo.) general rule is notify your fellow developers before a rewrite. shared - The commits that are known to your fellow core developers. These commits are known, but have not had work based off of them. Minimal risk to rewrite. local - The commits that are local only, no one else has a copy. Commits your willing to share, but have not been yet shared, either from actions of you, or a fetch from others. restricted or private - The commits that you do not want shared. Manually added, think of a branch tip marked as restricted automatically promotes commits to the branch as restricted. Maybe make these like nice levels, but as two components, publicity 0-100 and rewritability 0-100 Published is publicity 100 and rewritability 0 Restricted is publicity 0 and rewritability 100 Based publicity 75 and rewritability 25 Shared publicity 50 and rewritability 50 Local publicity 25 and rewritability 75 Restricted publicity 0 and rewritability 100 Other option are flags stating if the commit is published, based, shared, or restricted. You could have a published and based commit that is more opposed to rewrite than a public commit. Call security on a published restricted commit ;-) Commits are by default local. Commits are published when they are pushed or fetched and merged to a publishing branch of a repository. On fetch/merge a post merge hook should send back a note to the remote repository that the commits were published. Restricted commits/branches/tags should not be made public, error out and require clearing of the attribute or a --force-restricted option that automatically removes the restricted attribute. They are at least promoted to shared, if not published. Based is only used in situations where you have developers sharing amongst their repositories, and you want a rule that is less restrictive than no rewrites. Shared is what we have now when a commit is in a remote repository without the no rewrite options. e.g. receive.denyNonFastForwards. As it stands now we can infer local and shared, we need metadata to know when a commit is made based, published, or restricted. Using the nomenclature from Mercurial > public < draft < secret public -> publicity 100, rewritability 0 draft -> publicity ?, rewritability 50 secret -> publicity 0, rewritability 100 Steve-- 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