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@chiark.greenend.org.uk> 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.
Reply to: