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

Re: How to handle Debian patches



On Fri, 16 May 2008 14:39:56 -0700, Russ Allbery <rra@debian.org> said: 

> Adam Majer <adamm@zombino.com> writes:
>> Clear patches are not because of VCS, but because of clear and
>> concisely described changesets. If you have patches with bad
>> descriptions or a giant blob in VCS, then that is useless not because
>> of the failure of VCS, but the failure of the developer.

> And by changeset in this context, referring to Git, you mean a branch?

> The description part is exactly the part that I don't know how to
> solve easily using Git unless the solution is to rebase everything and
> amend commits, which is a really annoying and substandard workflow.
> If I'm going to do that, I'd rather just use quilt, since then the
> workflow is the same as quilt and quilt is better at it.  The useful
> part of Git is the merging and branching support; if I'm not going to
> merge branches, there doesn't seem to be a lot of point.  But merges
> mean that there are no longer simple commits in the Git repository
> that one can point to.

> How does upstream easily get the complete description of a change that
> I have in a Git repository for packaging their software?  What should
> I be doing to help with that?

        Create a submission branch. There are two audiences for your
 work; one is downstream (which includes the integration branch for
 Debian), the other is upstream, one audience does not like rebases, the
 other thrives on it. See
  http://www.golden-gryphon.com/software/misc/packaging.html#sec-5.4
 for details on this scheme.

        manoj
-- 
The difference between dogs and cats is that dogs come when they're
called.  Cats take a message and get back to you.
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


Reply to: