On Feb 22, 2012, at 2:09 AM, Jeff King <peff@xxxxxxxx> wrote: > 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. Fair points. Honestly, I was thinking more about a developer pulling changes between locations within his or her control, say a laptop and a desktop, or simply between multiple clones on the same machine. In this scenario, it would be useful to warn the developer that: "[some of] the commits you are about to rewrite, while not in the upstream repository, have been replicated into other repositories within your control. These other repositories will not be rewritten. Are you sure you want to continue?" davez -- 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