lilypond-devel
[Top][All Lists]
Advanced

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

Re: Please stop pushing to the translation branch until further notice


From: David Kastrup
Subject: Re: Please stop pushing to the translation branch until further notice
Date: Thu, 08 Mar 2012 08:07:02 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux)

Werner LEMBERG <address@hidden> writes:

>> Once you have checked that the recent fixes have not caused any of
>> your work to get lost and the criss-cross merge has been done, you
>> can continue committing to the translation branch.
>> 
>> I apologize for the inconvenience.
>
> Thanks a lot for fixing this.  Do you recommend a modification of the
> current workflow to avoid this problem in the future?  It probably
> doesn't affect me since I don't do branch merges, but just to be
> sure...
>
> Usually I follow your advice sent some time ago to the list:
>
>   git fetch (to be sure you have the current version of staging)
>   git checkout origin/staging
>   ... commit your simple change ...
>   git push origin HEAD:staging

It's totally fine.  The problem was caused by _not_ adhering to
procedures and then digging one self further in instead of resetting and
restarting or asking for advice.  One problem was rebasing instead of
merging between the translation and master branches.  That caused some
nuisances by ruining the history (changes appearing on more than one
branch, consequently at least one revert that I did, "\layout-from", had
to be redone manually several times).  The real problem was that ominous
merge (probably with a merge strategy of "theirs" or "ours") that did
not actually merge but copy.  And the damage that this caused was rather
large because it has been a really long time since the translation
branch had been merged into staging last before that merge, and since it
was a really long time afterwards that the merge into the main line
happened.  So a lot of history needed fixing.

A systematic problem was to check for correctness of the merge by making
test and building docs: those won't notice if you accidentally rewind
the state of master a few weeks, because we make it a point to have
every commit on master pass regression tests and doc builds.  If you
want to make sure there is not something fishy with a merge, you need to
look at the diffs in relation to the parents, at least the diffstat
showing which files changed how much.

I think the main thing is "don't be clever around git".  Which I do not
heed entirely myself, obviously.  But I do hard resets to the state of
"15 minutes ago" when something does not look good.  Restarting from
scratch in your local repository is easy with git.  Being clever has no
place on long-running public branches.

-- 
David Kastrup



reply via email to

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