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

Re: Please don't stop using uscan (Re: Include git commit id and git tree id in *.changes files when uploading?)





Le mar. 13 janv. 2026 à 09:19, Otto Kekäläinen <otto@debian.org> a écrit :
> > I recommend as the best way to see what is happening, is to do a mock
> > import on the Debian packaging repository as suggested in
> > https://optimizedbyotto.com/post/debian-packaging-from-git/#import-new-upstream-versions-in-the-future
> > -> https://optimizedbyotto.com/post/debian-source-package-git/#try-it-yourself-example-repository-galera-4-demo
> >
> > cd $(mktemp -d)
> > gbp clone --add-upstream-vcs https://salsa.debian.org/otto/galera-4-demo.git
> > cd galera-4-demo/
> > gitk --all &
> >
> > (gitk here is important so you see the state of the git repo and all
> > the branches before the import)
> >
> > gbp import-orig --uscan --verbose
> > (--verbose will show all the git commands that ran)
> >
> > After the import hit F5 in the gitk window to see the state after the
> > import, and to easily inspect all branches, commits and read tag
> > contents.
>
> Right, but that project doesn't use debian/watch mode=git?  So I'm not
> sure this is comparable.  Here is another example.

No but it does not matter, it will still pull the upstream git. Just
try to example and have `gitk --all &` open and see before and after.

> jas@frallan:~/dpkg$ git clone git@salsa.debian.org:go-team/packages/golang-github-protocolbuffers-txtpbfmt.git
..
> However this still creates a merge commit in the upstream branch:
>
> commit 57d77483f79cb82e667e3d9a1fc45c5cc470d3cc (tag: upstream/0.0_git20251124.fcb97cc, upstream)
> Merge: fba763a fcb97cc
> Author: Simon Josefsson <simon@josefsson.org>
> Date:   Tue Jan 13 08:29:48 2026 +0100
>
>     New upstream version 0.0~git20251124.fcb97cc
>
> Sigh, so it seems I was wrong, and now I know of no way to teach 'gbp
> import-orig' to behave like Ian/Sean would prefer it to do.
>
> To be honest, I find these GBP synthesized merge commits just noice.
> What value do this add?  Why can't the 'upstream' branch be the upstream
> branch without any GBP modifications?  Couldn't GBP support that?  For
> some packages, I've created such a solution manually, and GBP seems to
> cope well with that once it is in place.

Having the merge commit is intentional and mandatory. The branch
`upstream/latest` is not supposed to have the upstream git commit, but
the result of the _import_ to Debian. See
https://dep-team.pages.debian.net/deps/dep14/

> Perhaps 'gbp import-ref' is the answer here.

I think it is better to maintain that debian/watch is correct and
uscan can fetch the package than to manually do direct pulls.

If debian/metadata:upstream-vcs was mandatory and uscan could read it
instead of debian/watch and there was a command like `gbp import` that
always did the right thing based on what is codified in debian/*
things would be easier, but that does not exist now and there are a
lot of corner cases to handle, and the benefit of current
uscan+debian/watch is that they do handle them all.

uscan is smart and uses d/upstream/metadata
~/Software/debian/gpaste/salsa:debian/latest$ uscan --verbose
uscan info: Found debian/upstream/metadata instead of debian/watch, trying to read it


Reply to: