Some git repositories are really really large, and forcing a full copy on the initial download might not be ideal. Git (don't know about the other VCSs) supports passing a --depth option to only download the last couple of commits rather than everything. Thoughts on including this functionality somehow in the PKGBUILD VCS support?

Some git repositories are really really large, and forcing a full copy on the initial download might not be ideal. Git (don't know about the other VCSs) supports passing a --depth option to only download the last couple of commits rather than everything. Thoughts on including this functionality somehow in the PKGBUILD VCS support?

+

:Does this work with a bare clone? Check the pacman-devel mailing list, I seem to remember this being discussed and rejected. This talk page really isn't the place to discuss changes to pacman, anyway.

The download example can still be found in /usr/share/pacman/. The next version of the ABS package should update it a bit so the download happens in the prepare function where it belongs. As for pkgver, I think the generic example using date covers that, as there's not a way to get a version number from a CVS repo. Maybe a note to that effect?

That makes the most sense, but it might also be a good idea to rename the "Fallback" section to something like "Fallback / CVS" to make it more obvious even when you're just checking out the table of contents.

But as for ABS, as far as I can tell the last commit was over 8 months ago.

Hmm, there were a number of patches submitted last month for cleaning up the prototypes, looks like none have been committed yet. I do remember a discussion (IRC maybe?) questioning the proper place for the prototypes, so maybe that's why? Looking at the patches, I was mistaken anyway; they didn't update the darcs or cvs prototypes. Simple enough, I'll send in a patch myself.

Checking out branches/tags needs clarification

The #fragment part of the VCS source URL has a different meaning for each type of VCS.
This can be confusing for people, especially when they are trying to checkout a specific branch or tag.
Examples would reduce the chance for confusion a lot.

fictional examples for git and svn (don't have experience with bzr or HG)

More on git pkgver()'s

so they are more friendly to vercmp.
Current behaviour using git-git as an example:

current ver: 1.8.2.210.g123abc-1
next ver: 1.8.2.1.50.g123abc-1

vercmp 1.8.2.210.g123abc 1.8.2.1.50.g123abc
1 # the first is greater than the second

Right now, the current version is actually greater than the new version, causing a downgrade. If r is appended to the patch level (the numbers just before the g<hex> bit), then vercmp would order the versions correctly.

current ver: 1.8.2.r210.g123abc-1
next ver: 1.8.2.1.r50.g123abc-1

vercmp 1.8.2.r210.g123abc 1.8.2.1.r50.g123abc
-1 # the first is less than the second

I have the same issue with tup--git package that bumped its version from 0.6 to 0.6.5. previously generated version was 0.6.350.gfoobar now it became 0.6.5 that is smaller than previous. Generated version should split upstream version from 'git describe' version. My vote is goes to '~' delimiter proposed above. Or maybe we can use '-' as delimiter?

Clarifying the first Git function

Instead of just sed 's|-|.|g' it'd probably be better to give some example with cut (which you're probably gonna end up using anyway) and tr (which is simpler than sed). Then you could either explain it like this or just mention the man pages: "cut -d "-" -f2- cuts from the first hyphen (-) to the end, tr - . converts hyphens to dots (.) and tr -d - removes the hyphens".

Did you test this before posting? It doesn't do anything like you think it does. Scimmia (talk) 22:29, 4 May 2013 (UTC)

Well, my friend, that's what makes it an example. The reason I'm using cut is to remove the actual project names that are often included in their tags. All the sed example does is change the hyphens (-) to dots (.), which is simpler to do with tr - . anyway.

What _makes_ it so hard is that there isn't a single solution that somehow magicly worked on all scenarios. Even if you decided to be clever and started cutting the output up until the first number (with something like $ sed 's/\([^0-9]*\)\(.*\)/\2/g'), you'd still end up with the wrong result whenever the "version" starts with a letter or the project name ends with a number.

Ah, I see now, you were addressing a special case. You're right, there isn't a single solution. You're also right that tr is simpler and should probably be used in the example if that's all the example is going to show. It seems to be fairly common, though, to include a "v" at the beginning of the version number, in which case you'd already be using sed anyway so you can just do sed 's/^v//;s/-/./g' So many ways of doing the same job. Scimmia (talk) 02:15, 8 May 2013 (UTC)

That only works when they do. It doesn't remove the names from the tags, which are included in things like Wine and the entire X stack.

git describe --always | sed 's/\([^0-9]*\)\(.*\)/\2/g; s/-/./g' is the most universal approach I can think of. But it's totally unreadable and a damn lot harder to edit than some cut/tr example.

Yeah, my example was a special case as well. I'm really thinking that this is a situation where it's best just to include a very simple example and let the maintainer customize it as needed instead of trying to find a convoluted solution that works everywhere.

In that sense the current one is pretty fitting, but it sort of gives the impression that it works "right away", which it doesn't. So at least a note for probably having to do something yourself would be good.

Use --long insead of --always in git describe

--always is for returning something even when it can't find a tag. It just returns the short hash of the commit, which is kind of useless in this example.
On the other hand --long is needed to get the output we want if HEAD has a tag. By default, git describe would just return the name of the tag, --long forces it to return the full output we want, ie "2.0-0-g123abcd" instead of just "2.0".
--Scimmia (talk) 09:40, 22 May 2013 (UTC)

pkgver function for hg based on tags

I recent came across a way with hg to show the most recent tag, as well as the number of commits from this tag (similar to the output of `git describe`.)

Support for shallow copies

Some git repositories are really really large, and forcing a full copy on the initial download might not be ideal. Git (don't know about the other VCSs) supports passing a --depth option to only download the last couple of commits rather than everything. Thoughts on including this functionality somehow in the PKGBUILD VCS support?

Does this work with a bare clone? Check the pacman-devel mailing list, I seem to remember this being discussed and rejected. This talk page really isn't the place to discuss changes to pacman, anyway.