Petr Baudis wrote:
> On Thu, May 03, 2007 at 01:48:26AM CEST, Jakub Narebski wrote:
>> 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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html