[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: why do people introduce stup^Wstrange changes to quilt 3.0 format

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 <kilobyte@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

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

Reply to: