[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20080212.172051.58554658.davem@davemloft.net>
Date: Tue, 12 Feb 2008 17:20:51 -0800 (PST)
From: David Miller <davem@...emloft.net>
To: torvalds@...ux-foundation.org
Cc: jeff@...zik.org, arjan@...radead.org, greg@...ah.com,
sfr@...b.auug.org.au, linux-kernel@...r.kernel.org,
linux-next@...r.kernel.org, linux-arch@...r.kernel.org,
akpm@...ux-foundation.org
Subject: Re: Announce: Linux-next (Or Andrew's dream :-))
From: Linus Torvalds <torvalds@...ux-foundation.org>
Date: Tue, 12 Feb 2008 16:44:47 -0800 (PST)
> gitk --merge
...
> This is something where I actually think git could and should do better:
> git has the capability to act as more of a "quilt replacement", but
> because it wasn't part of the original design, we never actualy exposed
> the simple queue management commands to do this (stgit does things like
> that, though).
>
> So if you haven't pushed out, right now you'd have to do this stupid
> thing:
Thanks for all the useful info.
But as soon as I've applied any patches to my tree I've "pushed out".
So this scheme doesn't work for me. The first thing I do when I have
changes to apply is clone a tree locally and on master.kernel.org,
then I apply that first patch locally and push it out to master.
What would be really cool is if you could do the rebase thing, push
that to a remote tree you were already pushing into and others could
pull from that and all the right things happen.
A rebase is just a series of events, and those could propagate to
people who are pulling from the tree. I'm pretty sure GIT could
support this.
--
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/
Powered by blists - more mailing lists