On 7/6/07, Josef Sipek <[EMAIL PROTECTED]> 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
_______________________________________________
unionfs mailing list: http://unionfs.filesystems.org/
[email protected]
http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs
