On Tue, Feb 21, 2012 at 06:59:38PM -0500, Dave Zarzycki wrote: > > I think that question should be "warn before pushing out a commit that the > > user may later regret to have pushed out" ;-) > > Why limit this proposal to just the commits that are reachable from > upstream? What if somebody pulls from your repo? > > In other words, wouldn't it be better to have a git track "unshared" > commits and only let those be rewritten? The theory being that if the > given commits haven't been pushed or pulled anywhere, then they are > safe to rewrite. You don't necessarily know who has read from you. Depending on your setup, the user running git code may not have write access to the repository (e.g., Alice runs "git pull ~bob/project.git"). Where would Alice write the list of commits she pulled so that when Bob later runs git, he knows that she has pulled them? There is also the issue of "dumb" transports in which no git code is running on the remote repo at all (e.g., Alice fetches from Bob via dumb http; Bob's server doesn't even have git at all). There may be clever or complex ideas to tackle those problems, but I suspect that handling push would cover most practical cases (e.g., in the dumb http case, Bob's commits probably ended up on the server via push). So perhaps it is a good place to start. -Peff -- 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