On Tue, Oct 27, 2009 at 03:33:16PM -0700, Junio C Hamano wrote: > > $ git fetch ;# presumably gets origin/branch > > $ git push origin/branch:renamed-branch > > > > which is much nicer than exposing clueless users to > > ":refs/heads/renamed-branch". > > You would need to expose ":refs/heads/branch" to make this a rename, not a > copy, wouldn't you? Yeah, you're right. This was based on an actual user request, and I didn't think too closely about the other steps. But since the deletion is of an existing branch, you should be able to do that without refs/heads. So: $ git push origin origin/branch:renamed-branch $ git push origin :branch Which of course you could do in one command if you wanted to live (more) dangerously. > > Am I missing some part of your argument? > > I do not see much point (other than your "rename" example) in pushing what > you got from the other end without changing anything yourself back to the > same remote. I don't either; my hope was that we can make that case a little bit easier without creating undue hardship for anybody else. > There was a thread in which people argued that the primary thing that is > dangerous in this sequence > > $ git checkout origin/next; work-commit; work-commit; ... > > is when you leave the detached HEAD state without saving it to a local > branch. I think what is more dangerous is that it will not give the user > a solid understanding that these commits do _not_ change origin/next in > any way. After doing the above, it is understandable that a novice would > mistakenly think: "I started from origin/next and built some, let's push > the result". I suppose it's possible. I don't have any evidence that users actually think that way. > With such a misconception, you will see the likely mistake here, too: > > $ git push origin origin/next:refs/heads/next > > If "rename" is the _only_ valid reason you might want to push what you got > from there back to the same remote, _and_ if "rename" is something very > often needed, I think we would prefer to have a way to support that > operation directly, instead of more general DWIM that would risk passing > mistakes like the above unwarned. OK, I can buy that. It would be much nicer even to support explicit renaming (in fact, the user request started with that, and I just didn't want to give them an answer that involved refs/heads/, which I think is unnecessarily scary to users). > IOW, it's between "prevent push with dubious $src from happening in the > first place" vs "give them rope". Historically I always sided with the > latter camp, but I am trying to play a devil's advocate for a change ;-). Heh. Thanks for explaining your thinking. Let's scrap this for now, then. Remote rename doesn't actually come up very often, and I agree that it would be nice to have an actual atomic movement, which is what people really want. -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