[Top][All Lists]

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

Re: [GNU-linux-libre] The "Free" Kernel In Debian Squeeze

From: Alexandre Oliva
Subject: Re: [GNU-linux-libre] The "Free" Kernel In Debian Squeeze
Date: Mon, 03 Jan 2011 17:59:20 -0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)

On Jan  3, 2011, Richard Stallman <address@hidden> wrote:

>     It's so clean and general that it's already implemented in git.  It's
>     called  git filter-branch , in the way you stated,

> Maybe it is.  What does filter-branch do?

It lets one programmatically remap commits, file contents, tags, commit
messages, committers, tags, and more, from a given branch or set of
commits onto a rewritten branch.

> Where does it store the correspondence table?

In git refs/original, unless overridden.

>      or  git rebase , for
>     a more manual implementation (maybe good to create an initial mapping).

> Based on your definition of rebase, it can't be the same operation,
> because rebase and my transformation produce different kinds of graphs.

> So I wonder if there is a miscommunication occurring.

I guess there is.  AFAIK git rebase is supposed to create an isomorphic
subgraph, unless it detects that equivalent commits are already present
in the target graph.  I.e., given

branch1: c1 <- c2 <- c3 <- c4
branch2: c1 <- c2 <- da

rebasing branch1 onto branch2 would yield:

branch2: c1 <- c2 <- c3 <- c4 <- da'

whereas rebasing branch2 onto branch1 would yield:

branch1: c1 <- c2 <- da <- c3' <- c4'

I'm not entirely sure rebasing preserves arbitrarily complex graph
structures, like filter-branch does, or if it flattens the graphs, but
I'm not sure how important this is, given that filter-branch does
preserve arbitrary graphs (unless told not to).

>     What git misses is means to restore compatibility between the original
>     and the rewritten branch.

> My proposal does that automatically.  If filter-branch doesn't do that,
> I think that implies filter-branch is not the same thing.

Compatibility as in “git pull/merge” recognizing automatically the
saved-away commit equivalences?  I don't see that your solution does
that.  If it does, then the problem is solved indeed, but I didn't see
any suggestion of yours that changed the way git pull or git merge
operate.  Can you please clarify?

Alexandre Oliva, freedom fighter
You must be the change you wish to see in the world. -- Gandhi
Be Free! --   FSF Latin America board member
Free Software Evangelist      Red Hat Brazil Compiler Engineer

reply via email to

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