Matthieu Moy <Matthieu.Moy@xxxxxxx> wrote: > Petr Baudis <pasky@xxxxxxx> writes: > > > The origin branch is considered readonly (though Git does > > not enforce it) and only mirrors the branch in the remote repository. > > By curiosity, what happens if you accidentally commit to it? It will quietly accept the commit. Later when you attempt to run `git fetch` to download any changes from the remote repository to your local origin branch the fetch command will fail as it won't be a strict fast-forward due to there being changes in origin which aren't in the remote repository being downloaded. The user can force those changes to be thrown away with `git fetch --force`, though they probably would want to first examine the branch with `git log origin` to see what commits (if any) should be saved, and either extract them to patches for reapplication or create a holder branch via `git branch holder origin` to allow them to later merge the holder branch (or parts thereof) after the fetch has forced origin to match the remote repository. So in short by default Git stops and tells the user something fishy is going on, but the error message isn't obvious about what that is and how they can resolve it easily. There has been discussion about marking these branches that we know the user fetches into as read-only, to prevent `git commit` from actually committing to such a branch (we also have the same case with the special bisect branch), but I don't think anyone has stepped forward with the complete implementation of that yet. Like anything I think people get used to the idea that those branches are strictly for fetching and shouldn't be used for anything else. There's really no reason to checkout a fetched into branch anyway; temporary branches are less than 1 second away with `git checkout -b tmp origin` (for example). -- Shawn. - 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