gnu-linux-libre
[Top][All Lists]
Advanced

[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    http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   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]