[Top][All Lists]

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

Re: Bad translation merge

From: David Kastrup
Subject: Re: Bad translation merge
Date: Wed, 07 Mar 2012 19:29:41 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux)

Graham Percival <address@hidden> writes:

> On Wed, Mar 07, 2012 at 05:27:08PM -0000, Phil Holmes wrote:
>> As an improvement to patchy, wouldn't it be better for patchy to
>> test for a "stop-patchy" branch and abort if it finds one?  Then all
>> that would be necessary to suspend the cron job would be to create a
>> branch with that name.
> No; if there's an emergency, deleting staging is no more effort
> than creating a new branch.

Wrong.  I _did_ delete staging.  But at that time, patchy had already
started its testing work.  If it checked for a stop-patchy or similar
before it pushed the tested results, things would have been fine.

But we don't need a separate branch for something like this.  Patchy can
just try doing a non-ff merge of origin/staging (on a detached HEAD?)
before pushing the tested results (not the results of the non-ff merge
which were not tested).  If the non-ff merge of origin/staging _fails_,
it means that whatever had been in origin/staging at the time the test
started had been removed.  I'll do something like that.

> Now, it could well be worth writing some test into patchy wherein if
> there's something suspicious in the git history for staging, it
> refuses to test it.  Patches appreciated.

What is suspicious?  The suspicious part was that the merge of the
translation branch changed a number of files outside of translation.

The lesson I can see for Francisco is that he _never_ should need to
resolve merge conflicts manually outside of the Documentation subtree.
If something outside of Documentation calls for attention, he should not
proceed but holler.

And do the old

git diff origin

check, or at least

git diff --stat origin

check before pushing upstream and see that no non-Documentation files
are tampered with.

And if they are, complain.  It is a really ungrateful job to work as
translator and deal with a tool like git that is hard to really
understand even for programmers.  I know it's easy to say something like
"if there is something fishy" when smelling the fishiness requires a
trained nose.  I still have no idea how this _started_ going wrong.

Anyway, I am still working on finding a solution that does not require
large sequences of cherry-picks to get the right state back out.

David Kastrup

reply via email to

[Prev in Thread] Current Thread [Next in Thread]