On Tue, Jan 07, 2025 at 12:46:46PM +0100, Julien Plissonneau Duquène wrote: > > > This change basically adds the recommendation to use "upstreamvcs" > > > as the > > > name of the "git remote" to access the upstream repository and it also > > Like many others, this looks like a gratuitous change for change's sake. > > Countless packages have been using "upstream" for years, but apparently > > it is not perfect enough and somebody had to invent a new name. > > Let's say upstream name their release tags like "1.2.3". That's valid and > that happens. > > In your Debian packaging repository, after importing that release you now > have a tag named "upstream/1.2.3" if you follow the proposed convention or > use some existing tooling with its default configuration. > > Let's now assume that your upstream remote is named "upstream", as is common > practice (I do that too). > > git checkout upstream/1.2.3 > > --> the tag from upstream or the tag from your import? Nominally that should > be the same content, excepted that there are many projects that repack > sources, and the tooling will always generate a different commit anyway. The > different name is to resolve this ambiguity.
Tags in git are not prefixed with the remote name or anything else. A tag named upstream/1.2.3 is never from the upstream. A tag named 1.2.3 should always be from the upstream. Branches, on the other hand, indeed clash between "upstream/foo branch from the maintainer" and "foo branch from the upstream". -- WBR, wRAR
signature.asc
Description: PGP signature
