On Fri, 18 May 2012, Adam Borowski wrote: > On Fri, May 18, 2012 at 12:16:40PM +0200, Andrew Shadura wrote: > > On Fri, 18 May 2012 11:37:08 +0200 > > Adam Borowski <kilob...@angband.pl> wrote: > > > Quilt is a kind of really primitive VCS. It does not make sense to > > > use both it and a modern one, and when someone tries, > > > > I'm sorry to disappoint you, but quilt isn't a VCS at all. It's a patch > > queue management system, and it does its job well. And, by the way, git > > can't do it better at the moment as guilt seems to be dead, and stgit > > is buggy (mq in mercurial is better than quilt, but we speak of git > > atm). > > What would you need guilt or stgit for? Various invocations of git-rebase > can already do all of that. -i in particular can do most of that in an > user-friendly way.
You rebase, that branch is crap that cannot possibly be used by others in any way that is not (1) error-prone; (2) annoying; (3) at least as troublesome as quilt (IMHO it is much worse than quilt). Have you ever been downstream from someone that publishes branches that are rebased all the time? But yes, git is *MUCH* better at merging than patch, which would be the reason why I work on development of patch-based deliverables (anything for the Linux kernel, and anything that is supposed to make its way upstream) using the latest development shapshot of stgit instead of quilt. When it is time to release/upload, the branch gets git format-patch'd, and makes its way to debian/patches for 3.0(quilt) to handle. That branch is never published. git-pq can automate this stuff in an even better way that is rebase-less if you want, but I don't bother. > I'm sorry but I fail to see any core differences between quilt and a series > of patches rebased on top of the latest upstream tag. Except that git's 3.0(quilt) doesn't need a full git repository to actually be manipulated. Since we cannot use 3.0(git) with the full git repository in Debian, IMO that makes 3.0(git) useless if you're going to use it like that. You're free to propose that we change the way 3.0(git) is supposed to be used, and maybe that will require a 3.1(git), or maybe not. That's probably where we'll get some value out of this necrotic thread. Damn, I hate the stink of dead horse corpses... It would certainly be possible to define that all that can go in the git repository is the snapshots uploaded to Debian/Ubuntu. That DOES mean you CANNOT use git directly with the upstream repository, you'll need to transport changes using git format-patch and git-am, or maybe git cherry-pick from a remote. I think this will actually be worse for people to understand than 3.0(quilt), but it does have the advantage that you will be using git instead of quilt to manipulate the changes. We'd need a procedure to deal with uploads fixing "cannot be distributed, but it was" problems, and THAT will require rewriting history to get rid of the offending data. Which is rather nasty, but doable. > A rebased series is just one way to work with git, but it alone can do > everything quilt can. Indeed. But shallow clones are not the way (we've debated this already on a huge technical thread, at least twice). -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120518140907.ge...@khazad-dum.debian.net
