Re: FFmpeg considering GIT

From: Jakub Narebski <jnareb@gmail.com>
Date: May 4, 2007, 00:42 UTC
Message-ID: <200705040242.46156.jnareb@gmail.com>
In-Reply-To: <20070503010312.GF4489@pasky.or.cz>

Petr Baudis wrote:

> On Thu, May 03, 2007 at 01:48:26AM CEST, Jakub Narebski wrote:

Show 10 quoted lines

>> About removing a commit: assume that you have the following history
>> The problem exists _only_ if somebody based his/her work on commit
>> C or its descendant, i.e. original D, E commits. He/she would have
>> to rebase his/her work on top of _changed_ (moved) commits D' and E'.
> 
> "_Only_"?
> 
> I think it's just totally unsustainable to do this history rewriting in
> an "upstream" git repository. You will get horridly confused, then
> frustrated and then just move from software development to beekeeping.

Perhaps I should have said: "There always would be problems if somebody based his/her work on commit C or its descendant..."

But there are some times when you can rewrite history without bad consequences.

You can without any problems rewrite _unpublished_ commits; if one for example pushes to public repo once per day, or few times a week, there is time to remove a commit, or amend a commit, or change commit deeper in a history. Or even use StGIT to manage patches, and change their sequence, add patch in the midle of patch series, split or join patches, all that working on creating 'a perfect patch [series]'.

You can rewrite a branch which never would be published, like feature branches in git.git repository (which are visible only via 'pu' -- proposed updates branch, which is meant to have history rewritten). Or you can announce that given branch might be rewritten, and not to base any work on it (well, you can, but you always should rebase before sending).

Because there always are, and always will be problems if somebody would base work on series including now removed commit, even if SCM need not to rewrite history to remove a commit [*1*]. And with history rewriting even more so, for example accidental inclusion of removed commit.

Besides I think it would be better to teach blame to ignore reversion commits (for example based on first line of commit message) than to mess with the history. Note also that git has more tools for forensic analysis than git-blame; blame / annotate was added later because people are used to it (and it is I think better than any other, because it can detect moving and copying code blocks). The primary examining tools are history browsing limited to specified pathspec, and pickaxe i.e. searching for commits which changed given line.

Footnotes:
----------
 [1] Git began as content adressed filesystem, where each object is named
     by its contents (or rather cryptographics hash function of contents).
     This results in hash (object id) of commit identifying whole lineage
     of it, and makes signing specified commit (using signed tag)
     identifying / signing whole history.

-- 
Jakub Narebski
ShadeHawk on #git
Poland