linux-kernel - Re: Git training wheels for the pimple faced maintainer

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <64E321FD-FD09-4962-9BF3-86104B92A74A@mac.com>
Date:	Fri, 20 Oct 2006 00:28:20 -0400
From:	Kyle Moffett <mrmacman_g4@....com>
To:	Linus Torvalds <torvalds@...l.org>
Cc:	Pierre Ossman <drzeus-list@...eus.cx>,
	Andrew Morton <akpm@...l.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: Git training wheels for the pimple faced maintainer

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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/