On Thu, 26 Oct 2006, Jerome Lovy wrote: > > Could someone please point me to / give me the rationale for the "Never commit > to the right side of a Pull line" rule ? It's not a technical rule per se. It's just a way to avoid what will almost inevitably otherwise be a horribly horribly confusing situation. I say "almost inevitably", because if you really have worked with git enough, and understand how it works on a very fundamental level, there are actually no problems at all with doing so, and maybe you could have perfectly fine reasons to break the rule, and commit to a branch that is officially "maintained in another repository" and then push it out. But it's a good rule in general, just because it makes a certain common workflow explicit. In fact, we really probably should start to always use the "refs/remote/origin/HEAD" kind of syntax by default, where you can't even _switch_ to the branch maintained in the remote repository, because it's not a real branch locally. So normally you should consider the "origin" branch to be a pointer to WHAT YOU FETCHED LAST - and that implies that you shouldn't commit to it, because then it loses that meaning (now it's "what you fetched last and then committed your own work on top of", which is something totally different). Linus - 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