Re: Translation commits pushed when rolling a tarball

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

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.


Attachment: smime.p7s
Description: S/MIME cryptographic signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]