Re: How to handle Debian patches
On Fri, 16 May 2008 14:39:56 -0700, Russ Allbery <email@example.com> said:
> Adam Majer <firstname.lastname@example.org> 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
for details on this scheme.
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 <email@example.com> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C