Skip to content

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

Closed
wants to merge 11 commits into from
Closed

Shallow roots #3853

wants to merge 11 commits into from

Conversation

tiennou
Copy link
Contributor

@tiennou tiennou commented Jul 7, 2016

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.

@tiennou
Copy link
Contributor Author

tiennou commented Jul 7, 2016

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...

@tiennou
Copy link
Contributor Author

tiennou commented Jul 7, 2016

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.
Copy link
Member

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?

Copy link
Contributor Author

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.

@ethomson
Copy link
Member

Grr 😆. Any chance I could graft leaks on clar's exit, so I get a nice reminder when that happens ?

We run valgrind on the Linux builds for each PR, and the Windows builds are instrumented with leak detection as well.

@tiennou
Copy link
Contributor Author

tiennou commented Jul 18, 2016

@ethomson I was wondering about having a way to run leaks just before clar exists, so that I can catch those locally. Right now I just busy-loop in main, run leaks, and kill clar manually afterward, but it's hacky, and I was wondering if there was a better way...

@ethomson
Copy link
Member

ethomson commented Aug 4, 2016

@ethomson I was wondering about having a way to run leaks just before clar exists, so that I can catch those locally. Right now I just busy-loop in main, run leaks, and kill clar manually afterward, but it's hacky, and I was wondering if there was a better way...

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 ./libgit2_clar -smytest -e"leaks libgit2_clar". I guess you could also hardcode leaks detection, but that sort of bums me out.

If it were me, I would just run valgrind in a VM. (Unless it's stable on Mac again, then I wouldn't even bother with the VM.)

}
start = end + 1;
}
end++;
Copy link
Member

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.

Copy link
Contributor Author

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 */
}

@tiennou
Copy link
Contributor Author

tiennou commented Sep 22, 2016

Is the AppVeyor failure relevant or not ?

@tiennou tiennou mentioned this pull request Aug 22, 2017
@tiennou tiennou closed this Aug 22, 2017
@tiennou tiennou deleted the shallow-roots branch June 24, 2018 22:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants