[Unionfs] problem with unionfs git tree

[Simon Sasburg]

On 7/6/07, Josef Sipek <jsipek at fsl.cs.sunysb.edu> wrote:
>
> Sorry for the delay with the response...and the length of my reply :)
>
> I'm no git expert I only pretend to be one :)
>
> In a way, there are several reasons for why we do rebase.
>
> 1) kernel.org git tree:
>
>         Right from the time I created the git tree, I used guilt[1] (a
>         quilt work-alike) to manage the individual patches. When a new
>         kernel version comes out, I pop all the patches, pull linus's
>         changes, and push all of the patches back. Right now, guilt has a
>         semi-broken rebase command which I am in the process of fixing
>         (it'll drop applied patches, etc.). I prefer using guilt for this
>         repo because it allows me to easily fix up a patch based on feedback
>         received on the mailing lists.
>
> 2) non-kernel.org git trees:
>
>         We have several other git trees internally, for example the patches
>         you can obtain from our ftp, come from a repo which contains all of
>         the code from the kernel.org repo as well as some additional code.
>         In a way, I think of it as the testing ground for code.
>
>         Currently, we maintain this repo using regular git commands, and
>         because of that it has a number of nasty commits (don't you hate
>         when you find a typo in something you already committed?).  We use
>         git-rebase on this tree, but we were thinking about switching
>         development to guilt to avoid the nasty looking "oops, a typo"
>         commits.
>
> 3) rewriting history:
>
>         Yes, I _hate_ rewriting history. Back in 2005, I tried both git and
>         Mercurial[2] and concluded that I liked mercurial more, and in many
>         ways, I still do. All my respositories use mercurial, _except_
>         kernel trees, and guilt itself. I tried mercurial and mq for unionfs
>         for about a month, but it got really painful because I had to do
>         more things manually than I should - because git was made to be used
>         by the linux kernel developer community, it does everything the
>         "right way".
>
>         I agree that rewriting history is evil, and creates all sort of
>         problems. Rest assured it took me about a week to figure out how to
>         maintain Unionfs git tree semi-sanely. I must admit that although
>         this makes it the easiest for me, it makes it harder for you.
>
>         The #1 problem with using merge instead of rebase, is that after you
>         merge, rebase will no longer work properly. That's why I always
>         tried to avoid using it. Also, it is a whole lot easier if I can
>         change any one commit I made (using guilt). This gets really hard
>         once you introduce branching - as a matter of fact, I'm pretty sure
>         guilt would just die, and I'm not even sure how a quilt-like tool
>         would handle branching in history.
>
> The whole thing gets more and more messy as more commits are made
> (kernel.org repo has 119 Unionfs-related commits). If you can think of a way
> to make things easier for you but at the same time keep things about as easy
> for us, let us know!
>
> I have a small script that allows me to turn any extra commits in an
> arbitrary tree into one megadiff:
>
> git-clone -n git://git.kernel.org/pub/scm/.../torvalds/linux-2.6 linux-tmp
> cd linux-tmp/
> git-fetch git://git.kernel.org/pub/scm/.../jsipek/unionfs.git
> git-log master..FETCH_HEAD           # list of commits in $URL not found in
>                                      # linus's tree
> git-diff master...FETCH_HEAD > $FILE # a mega diff of the changes, note the
>                                      # 3 periods
>
> Really, think of the kernel.org unionfs git tree as something that gets
> deleted and recreated whenever a new kernel release is made. Which reminds
> me, I should probably fix up the git page on unionfs's website.
>
> Thanks for pointing out the merge vs. rebase idea, it forced me to write all
> this down :)
>
> Josef "Jeff" Sipek.
>
> [1] http://www.kernel.org/pub/linux/kernel/people/jsipek/guilt/man/
> [2] http://www.selenic.com/mercurial/
>
> --
> UNIX is user-friendly ... it's just selective about who it's friends are
>

Very interesting, unfortunately i have no idea what
quilt/guilt/mercurial do or how they work...

However, i *think* its possible to use something like the following to
update your local old git tree to a new unionfs git tree.
$ git-fetch
$ git-rebase --onto FETCH_HEAD master
This would take all commits in the current branch that are not in
master (the old unionfs tree), and try to apply those to FETCH_HEAD
(the new unionfs tree).
Note i haven't tried this yet, and i'm not sure FETCH_HEAD is valid
for --onto ...

Also this to work properly i think the master may not have been
committed to locally, so local development would have to be done in
branches.
And you need to rebase these branches before you rebase master.

This could be made easier of you organize the unionfs git tree to keep
the branches against old kernel releases.

If you instead of rebasing the master branch for each kernel release,
give each kernel version its own branch, those branches can be more
easily used in the rebase command.

This shouldn't be too hard, instead of rebasing an existing branch,
you create a new branch and rebase that one. This way you also aren't
rewriting any history so git-pull shouldn't fail so badly. Though it
also won' t update through new kernel releases, for that rebase would
be needed.

The rebase command for me should then look something like:
$ rebase --onto unionfs-2.6.22-rc6 unionfs-2.6.22-rc5

For you all this would take is creating an extra branch before
rebasing to a new kernel-release.

You could also tag the u1/u2 thingies in these branches, making all
older releases also easily accessible through the git tree.

I hope i'm making any sense here, let me know what you think :-)

Simon