On Oct 19, 2006, at 19:44:41, Linus Torvalds wrote:
- If you actually want your development tree to "track" my tree,
I'd suggest you have your "for-linus" branch that you put the work
you want to track into, and then a plain "linus" branch which
tracks _my_ tree. Then you can just fetch my tree (to keep your
"linus" branch up-to-date), and if you want your development branch
to track those changes, you can just do a "git rebase linus" in
your "for-linus" branch.
I'm no official maintainer, but I have several random local GIT trees
I use for local development and patches which don't make a lot of
sense outside my personal systems. Because of this it's important
for me to be able to migrate my changes over to newer versions
easily, but I don't care all that much about maintaining old history,
I just want my separate patches to work on latest Linus.
It also matters a lot to me to be able to wipe out a devel tree with
a quick rm and create it from scratch.
As a result, I have an "upstream" tree with various "linus", "libata-
dev", etc upstream branches that I pull from for various reasons. I
then have a "linux-template" tree which has no objects of its own but
references the "upstream" tree's object directory and "pulls" from
some branch in the upstream tree. To create a new devel tree I just
copy the "upsteram" tree which is the size of a single checkout, and
start patching. To update all my patchsets to latest linus:
### This gets the upstream tree to the latest state
$ cd ~/git/linux/upstream
$ cg-fetch linus
$ cg-fetch libata-dev
$ cg-fetch $OTHER_UPSTREAM_SRC
## Optionally repack the single copy of the upstream objects for
better speed
$ git-repack -a -d -l -f
### Now fast-forward the patches in $MY_TREE to be based on the
latest version of the random upstream tree
$ cd ~/git/linux/$MY_TREE
$ cg-fetch upstream
$ git-rebase upstream
### Now I resolve rebase-conflicts
When I want to export a GIT tree for somebody else to look at I just
pull into the HTTP-accessible GIT directories from my various
development trees, optionally merging if necessary.
This isn't "The Best Solution(TM)" for everyone, but it works really
well for me and has the advantage of only storing one easily-repacked
copy of the upstream sources; the rest of my dev trees have only the
overhead of my local changesets and a single copy of the kernel
sources. In the event I have to wipe out a dev tree it's a very fast
"rm -rf $OLD_TREE", and creating one is also a fast "cp -a linux-
template $NEW_TREE"
Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
