search

gittuf / gittuf

A security layer for Git repositories
https://gittuf.dev
Apache License 2.0
439 stars 28 forks source link

git-options flag #417

Closed flandweber closed 4 weeks ago

flandweber commented 4 weeks ago

Add a description

For advanced/scripting uses a way to pass flags/options to git is needed.

The example I've stumbled across is that I'm trying to clone a repository from another local user: 

time=2024-05-28T15:08:41.518Z level=DEBUG msg="Cloning from '/nix/store/7igpy1c43jpqcwhhcvjj3jba2bphipq8-repo'..."
time=2024-05-28T15:08:41.518Z level=DEBUG msg="Checking if local directory exists for repository..."
time=2024-05-28T15:08:41.518Z level=DEBUG msg="Cloning repository..."
Error: unable to clone repository
unknown error: fatal: detected dubious ownership in repository at '/nix/store/7igpy1c43jpqcwhhcvjj3jba2bphipq8-repo/.git'

$ ls -dl /nix/store/7igpy1c43jpqcwhhcvjj3jba2bphipq8-repo/.git
dr-xr-xr-x 8 root root 4096  1. Jan 1970  /nix/store/7igpy1c43jpqcwhhcvjj3jba2bphipq8-repo/.git

This error is expected in git and can be fixed with setting an option: -c safe.directory='*'

Would a global flag --git-arg make sense that effects every call of git?

Relevant log output if the discussion pertains to existing gittuf functionality

No response

Code of Conduct

neilnaveen commented 4 weeks ago

This should be fixed, in a way, with https://github.com/gittuf/gittuf/pull/411, which means we could clone directly with git, allowing all git functionality to exist and include gittuf functionalities.

patzielinski commented 4 weeks ago

The transport mechanism @neilnaveen mentioned will alleviate the need for interacting with gittuf directly to clone/pull/push to a repository, so one can then pass options to git as needed. There is also #220 which is an effort to have command compatibility with git for when gittuf is invoked instead (i.e. if gittuf would be needed to be invoked manually), but the transport mechanism enabling the use of git should suffice.

adityasaky commented 4 weeks ago

Thanks for opening this! As things stand, --git-arg wouldn't get us far enough; gittuf clone uses go-git and we'd have to separately map flags to the options exposed by the library. With gitinterface switching over to the Git binary, this would make sense, but then we arrive at the question of how the user is using gittuf (raised by @patzielinski). To unblock you in the short term, is it an option to set this as part of git config --global, maybe without the *?

As for the longer term:

If they're primarily using the gittuf transport, there may not be a need to pass on any flags at all as they'll be using git directly. I suspect gittuf's use of git under the hood shouldn't be changeable by users 99% of the time.

If it's via command compatibility, where gittuf implements a git front end, we would want to make it so that any git flag the user wants to pass gets sent to git, without requiring some thing like --git-arg. gittuf clone today is actually more akin to a command compatibility feature; in fact it's the only one.

flandweber commented 4 weeks ago

That all makes sense, thanks a lot for your quick explanations!

To unblock you in the short term, is it an option to set this as part of git config --global, maybe without the *?

Yes, thank you. I didn't realize the library respects the config files.

adityasaky commented 4 weeks ago

Great! Happy to help.