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 >
