-
-
Notifications
You must be signed in to change notification settings - Fork 329
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix discovery #1620
fix discovery #1620
Changes from all commits
85e18d2
208cf5a
f8952e4
c18ebbe
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -14,8 +14,10 @@ pub enum Path { | |
/// The currently checked out or nascent work tree of a git repository | ||
WorkTree(PathBuf), | ||
/// The git repository itself, typically bare and without known worktree. | ||
/// It could also be non-bare with a worktree configured using git configuration, or no worktree at all despite | ||
/// not being bare (due to mis-configuration for example). | ||
/// | ||
/// Note that it might still have linked work-trees which can be accessed later, weather bare or not, or it might be a | ||
/// Note that it might still have linked work-trees which can be accessed later, bare or not, or it might be a | ||
/// submodule git directory in the `.git/modules/**/<name>` directory of the parent repository. | ||
Repository(PathBuf), | ||
} | ||
|
@@ -112,8 +114,11 @@ pub enum Kind { | |
/// Note that this is merely a guess at this point as we didn't read the configuration yet. | ||
/// | ||
/// Also note that due to optimizing for performance and *just* making an educated *guess in some situations*, | ||
/// we may consider a non-bare repository bare if it it doesn't have an index yet due to be freshly initialized. | ||
/// The caller is has to handle this, typically by reading the configuration. | ||
/// we may consider a non-bare repository bare if it doesn't have an index yet due to be freshly initialized. | ||
/// The caller has to handle this, typically by reading the configuration. | ||
/// | ||
/// It could also be a directory which is non-bare by configuration, but is *not* named `.git`. | ||
/// Unusual, but it's possible that a worktree is configured via `core.worktree`. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is there also the possibility that the worktree path is established by the presence of a There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. In There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Thanks--I've commented #1585 (comment) with a note about including or otherwise revisiting this when I open the other environment-related compatibility issues per the plan in #1585 (comment). There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Maybe as an additional note, despite claiming it's 'most definitely' not conforming, what I tried to say is that I didn't really try to make it conforming in the first place. To me it felt like environment variables are only needed in certain contexts, for instance, when creating a Git hook with That's pretty nice in practice as |
||
PossiblyBare, | ||
/// A `git` repository along with checked out files in a work tree. | ||
WorkTree { | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this, and the related
conformed_git_dir
variable, about something conforming to a standard or expectation? Or are they typos, where "confirming" andconfirmed_git_dir
should be written instead?If "conform" is the intended word, then I suggest rephrasing this message for clarity and probably also renaming the
conformed_git_dir
variable toconforming_git_dir
. If "confirm" is intended--i.e. if the intended meaning is that we are verifying that something is a git dir--then I recommend changing this to "confirming" and renaming the variable toconfirmed_git_dir
.I'm not sure which meaning is intended--they both seem plausible in context--so I haven't proposed a specific edit at this time. Also, I couldn't propose it in a review comment easily, because at least as applied to the variable name, this is a preexisting ambiguity, and some occurrences of the variable name are in places this PR does not modify. If it is known that one of these two changes is desired, though, then I'd be pleased to open a PR for them
afternow that this PR is merged.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the hint - the affected variable name is definitely leaking here and I improved the message to be much more specific in this PR.