Web lists-archives.com

Re: Preferred git branch structure when upstream moves from tarballs to git [and 1 more messages]




Holger Levsen writes ("Re: Preferred git branch structure when upstream moves from tarballs to git"):
> could you be so kind and provide a pointer, this thread is rather long
> already? (Maybe this is also worth an FAQ entry somewhere..)

Jonathan Carter writes ("Re: Preferred git branch structure when upstream moves from tarballs to git"):
> I'd like to second that request, I mean to go through this thread again
> when I have some free moments, but a FAQ would help a lot to assimilate
> all this information.

A FAQ is a really good idea.  Thank you for the suggestion.

In the meantime,

> > [Ian Jackson:]
> > > You should use dgit for the benefit of users.  See my other mail which
> > > answers why Vcs-Git and debcheckout is not enough.
> > 
> > could you be so kind and provide a pointer, this thread is rather long
> > already? (Maybe this is also worth an FAQ entry somewhere..)

I meant this message:
  https://lists.debian.org/debian-devel/2019/05/msg00065.html

> (I'm in a similar boat to Holger with my experience to gbp, I tried
> going through the documentation on the wiki a few times and just got
> frustrated. I just use packaging and Vcs-fields and tags and nothing
> fancier than that, which works for the few dozen packages I have and I
> think the workflow is trivial enough so that downstream consumers
> wouldn't have any problem whatsoever figuring out how to make use of it,
> but I suppose as that list grows it will become important to have
> worflows that scale up a bit more.)

I confess I always find these kind of comments (which I hope you won't
mind me parodying as "I don't use anything") a bit confusing because
they don't explain how you perform the key task that tools like gbp pq
are intended to help with.

I think what is going on here is this: to you, what you do for that is
so completely obvious it doesn't occur to you that I don't know what
it is.  There is such a gulf here between different people's workflows
that we are having trouble communicating.

If you are maintaining a package in "3.0 (quilt)", you are maintaining
a series of patches to the upstream part of the package.  The question
is: what tool(s) do you use to change what changes a patch makes to
the upstream source, edit a patch's accompanying message (if you give
them messages), add a new patch, drop a patch, rebase the patches onto
a new upstream version, and so on.

The answer clearly isn't "nothing" since you're not fiddling with the
individual bits in your computer's RAM by your electrotelekinetic
superpowers :-).  At least if you are then awesome but maybe you are
beyond need for version control software.

I guess the answer probably isn't even "I edit the diffs in the
patches, in my text editor".  At least I hope not since editing diffs
in a text editor is still horrific even with a really good text
editor.  I think that probably many people who say "I don't use
anything fancy" are using quilt, or maybe raw diff and patch ?  Maybe
you are editing debian/series with your text editor and occasionally
using rm and mv on patch files ?  Or git-mv and git-rm ?

I realise the above might sound facetious.  That's not my intent.

Ian.

-- 
Ian Jackson <ijackson@xxxxxxxxxxxxxxxxxxxxxx>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.