On Sat, 2014-08-02 at 15:55 +0200, Sébastien Wilmet wrote:
On Sat, 2014-08-02 at 15:21 +0200, drago01 wrote:Well you could just create a branch do your release there so that you don't have to care about what happens on master (branches are free in git) and merge it back to master afterwards.
You shouldn't need to create a branch for this. What we're talking about here is an utterly normal and everyday part of the git workflow — not specific to releases and translations. Any time you've done some work locally and it's time to push it upstream, you may find that someone else has pushed something before you. The correct thing to do when that happens is to pull, resulting in a merge commit in your tree, and then push that upstream. There's nothing to see here; this whole thread doesn't exist. There is no problem.
In GNOME we generally prefer to have a linear git history, but creating a branch is indeed another solution.
Right. You have correctly identified the root cause of the problem. We shouldn't be advising people as a matter of course *not* to use the version control system correctly in the manner in which it was designed. This mentality of rebasing for no better reason than because we like straight lines isn't just an issue in the specific case discussed here. It also causes the loss of accurate history in other cases, which can cause problems. It's relatively rare, but it does happen that two concurrent patches can conflict with each other. I could do some work in my local tree which is entirely correct and functional, but by the time I've finished testing and I go to push it upstream, someone else has pushed something which subtly breaks my work. If I rebase, it is just human nature that I'm not going to retest every intermediate commit of the rebased version as carefully as I retested the original, and it's quite possible that I'll end up pushing a commit which in some circumstances *never* worked. If I use git correctly and push the *merge*, however, then my original work is preserved. Someone later trying to work out what happened has actually got a correct version of history to refer back to, and the problem can be correctly tracked down to the *merge* of the concurrent changes. Whereas if I rebase and rewrite history to make it look like I just committed something that *never* worked, sorting that out later is *much* harder. We really ought to abandon this idea that we "prefer to have a linear git history". It might be simpler that way, but it's wrong, and in the cases that *matter* it actually makes things harder. And the cases that don't matter... don't matter. Unless you have some kind of OCD about straight lines. -- dwmw2
Attachment:
smime.p7s
Description: S/MIME cryptographic signature