[Top][All Lists]

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

Git: to merge or not to merge.

From: Francisco Vila
Subject: Git: to merge or not to merge.
Date: Sun, 26 Oct 2008 23:32:57 +0100

I'm sure you have noticed that I do a merge of master into
lilypond/translation every few days. I am sorry if this is considered
a pollution of the history or some kind of inconvenient for any
reason. If so, please tell me.

The fact is: in the past I have suffered of an inconvenient
"continuous out-of-date" status of translations, because if I update a
translated file and write down a commitish in it which is on the other
branch, when the merge happens the file seems to be (falsely) out of
date again.

In that case I'd have to commit again only changes to committishes,
which seems more nonsense to me.

So, the only way I can find to write down --into my updated files-- a
committish that links to an existing commit in the same branch at the
moment of updating, is to previously merge master into

I'd thank if anybody could point me towards a better method of
preserve the uptodate status of a freshly updated file after a recent
change in the original.

A deeper reason for this all is the lack of a Doc freezing policy for
2.12 "Rune", which is not necessary except that it leads to an
impossible completeness of translations. I can live with that, anyway.
Francisco Vila. Badajoz (Spain)

reply via email to

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