Messages in this thread | | | Date | Sat, 23 Apr 2005 22:45:52 -0700 | From | Greg KH <> | Subject | Re: Linux 2.6.12-rc3 |
| |
On Sun, Apr 24, 2005 at 01:00:23AM +0200, Pavel Machek wrote: > Hi! > > > > Could we add some kind off "This-changeset-obsoletes: <sha1>" header? > > > That would allow me to send patches by hand and still make the SCM do the > > > right thing during merge. > > > > That doesn't really scale, plus I don't want to rely on that kind of hack > > since it's simply not reliable (the patch may have gotten edited on the > > way, so maybe the stuff I apply is 90% from your patch, but 10% > > different). > > (Well, at that point I probably want to drop that 10% anyway :-). > > > Also, it doesn't actually handle the generic case, which is that the other > > end used something else than git to maintain his patches (which in the end > > has the exact same issues). > > Actually this one should not be a problem. "This-changeset-obsoletes:" > would probably be in changelog part, and remote end would just > propagate it. > > > > Alternatively I should just get public rsync-able space somewhere... > > > Would kernel.org be willing to add people/pavel? > > > > Now, that's actually something people are working on ("git.kernel.org"), > > so I don't think that would be a problem. People _are_ trying to set up > > things like a bkbits.net at least for the kernel. I know OSDL and OSL > > (http://osuosl.org/) are interested, and I think the current kernel.org > > works too. > > > > A word of warning: in many ways it's easier to work with patches. In > > particular, if you want to have me merge from your tree, I require a > > certain amount of cleanliness in the trees I'm pulling from. All of the > > people who used to use BK to sync are already used to that, but for people > > who didn't historically use BK this is going to be a learning experience. > > > > The reason patches are easier is that you can start out from a messy tree, > > and then whittle down the patch to just the part you want to send me, so > > it doesn't actually matter how messy your original tree is, you can always > > make the end result look nice. > > I created three trees here (with git fork): one ("clean-git") to track > your changes, second ("linux-git") to do my development on and third > ("linux-good") for good, nice, cleaned-up changes, for you to merge. > > ...unfortunately pasky's git just symlinked object/ directories... > > ...that means that if you pull from me using rsync, you'll get all my > "development" files, too. Not accessible in any normal way, but still > there. > > That means that git fork can't be used for "good tree for > Linus"... not until we have something better than rsync :-(.
I'm not really using the git-pasky part of git yet for development (except for 'git log -c') You can just "clone" the tree yourself with a stupid little script like I do below. It still uses hard-links so common git objects are only in one place on the disk.
Feel free to make it better, I have never claimed to be a bash programmer :)
thanks,
greg k-h
--------------
#!/bin/bash
DIR=$1
mkdir $DIR cd $DIR mkdir .git cp ~/linux/kernel.org/people/torvalds/linux-2.6.git/HEAD .git/ cp -rl ~/linux/kernel.org/people/torvalds/linux-2.6.git/objects/ .git/objects/
HEAD=`cat .git/HEAD` echo "HEAD=$HEAD" echo ""
cat-file commit $HEAD TREE_HEAD=`cat-file commit $HEAD | head -n 1 | cut -f 2 -d " "` echo "TREE_HEAD=$TREE_HEAD"
echo "read-tree $TREE_HEAD" read-tree $TREE_HEAD
echo "checkout-cache -a" checkout-cache -a
echo "update-cache --refresh" update-cache --refresh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |