the safest thing would probably be to just get rid of gitflags. while it’s a nice feature overall i think supporting it fully as was said is not ideal. just saying a feature that should work doesn’t and live with it is a cop-out. On Wed, May 1, 2024, at 9:27 AM, Allan McRae wrote:

Hi all,

Posting here as I want some opinions.

With pacman 6.1, we introduced the GITFLAGS variable that controls how makepkg clones a git repo. To quote Douglas Adams:

"This has made a lot of people very angry and been widely regarded as a bad move"

Maybe that is just my opinion!

Essentially all git source features (i.e. build refs) supported by makepkg do not work using popular things like GITFLAGS="--mirror --filter=tree:0" or GITFLAGS="--depth=1". So no building from branches, or specific commits, or.... This has resulted in bug reports and increasingly complicated suggestions for "fixes".

We can get around a few issues using a worktree instead of a clone for making the copy of the repo in $srcdir. This actually worth doing anyway, as it will also help with LFS retrieval.

However, properly supporting all options that could be passed to GITFLAGS appears to be a never-ending / impossible task. It also means we can not assume our checkout is bare, which has already had implications for other fixes we are working on.

I am proposing two possible solutions:

1) Document that any use of GITFLAGS that breaks makepkg features is not our problem.

2) Remove GITFLAGS.

Note that people wanting specific GITFLAGS can readily overwrite the relevant function in libmakepkg, so #2 is really not the end of the world...

I'm seeking options on which option to take. Or is there a third option? Option #2 would bring me joy, but I'd accept #1 if that is the prevailing opinion.

Cheers, Allan