-
Notifications
You must be signed in to change notification settings - Fork 2.5k
Shallow roots #3853
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
Shallow roots #3853
Conversation
I think, with a helpful nudge, I might be able to have revwalk not error out on missing parents (as per a Slack discussion, and my goal atm), but I'm still not clear on the merge-base case... |
Will fix the leaking cache on update first ;-). FIXED |
@@ -746,6 +747,15 @@ GIT_EXTERN(const char *) git_repository_get_namespace(git_repository *repo); | |||
GIT_EXTERN(int) git_repository_is_shallow(git_repository *repo); | |||
|
|||
/** | |||
* Determine the shallow roots of the repository | |||
* | |||
* @param out An array of shallow oids. Can be NULL. |
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.
Why can it be NULL
? Why would you call this function if you did not want the answer?
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.
Since I did the extraction in two pass, it behaved like git_repository_is_shallow()
(which used it internally). But it doesn't make sense anymore. I'll make it mandatory.
We run valgrind on the Linux builds for each PR, and the Windows builds are instrumented with leak detection as well. |
@ethomson I was wondering about having a way to run leaks just before |
Ugh. I don't know why leaks doesn't have the ability to run the process for you and catch its leaks. Anyway. I guess you could add some functionality to clar that would exec a process at the end of the run. Then you could, I guess, do something like If it were me, I would just run |
} | ||
start = end + 1; | ||
} | ||
end++; |
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.
It seems like there's not a lot of error checking here... It looks like it would handle a very malformed line if it was 80 characters of things that looked like hex characters...? Also, walking every character yourself seems a bit unnecessary and I think that you could solve both problems with some minor refactoring.
I would rather see you use some existing standard library function (git__strtok
may be a good choice) to find the terminating newline, validate that it's GIT_OID_HEXSZ
away from your start, and then try to parse it...
Does git
handle blank linkes? Comments? Windows style newlines? I assume not, but I wanted to ask.
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.
The documentation about the shallow file format is pretty terse (what I know of it is what's in Documentation/technical/shallow.txt
), and I wanted to know if it's acceptable to look at the source (since licensing).
I rebased and pushed a version that uses git__strsep
, which really feels cleaner. I do have a point to make : our implementation is "non-conforming" (for some definition of it 😉). Here's the relevant tidbit from my OS X man pages (which I was referring to when I wrote it) :
The location of the next character after the delimiter character (or NULL, if the end of the string was reached) is stored in *stringp. The original value of *stringp is returned.
Ours just leave *stringp
as it is and returns NULL
in that case, which can complicate parsing files where newlines-at-EOF are not guaranteed.
If that's expected, allow me to either 1) fix it or 2) add a comment on top of that function so you don't blindly trust your manpages (as I did).
For the record, the relevant changes are :
while ((line = git_strsep(&buffer, "\n")) != NULL) {
/* stuff with line */
}
if (*buffer) {
/* missing EOL */
}
to
while ((line = git_strsep(&buffer, "\n")) != NULL) {
if (buffer == NULL)
/*missing EOL */;
/* stuff with line */
}
Is the AppVeyor failure relevant or not ? |
This adds a helper function to grab the shallow OIDs, as right now there's only a yes/no check available.
I figured a way to get that info (even though our behavior might not be optimal) is a first step toward support.