Skip to content
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

Merge analysis support for bare repos #5022

Merged
merged 6 commits into from
Jun 13, 2019

Conversation

rcoup
Copy link
Contributor

@rcoup rcoup commented Mar 19, 2019

Fix for #5017

For testing, I copied tests/merge/workdir/analysis.c into tests/merge/trees/, and (manually) converted tests/resources/merge-resolve/ repo into a bare tests/resources/merge-resolve.git/ repo.

For testing, I refactored tests/merge/workdir/analysis.c into two matching test suites with a common implementation, one for working dirs and one for bare trees.

  • 8/9 new tests fail without the change. The remaining one checks for unborn, which happens before the bare-repo check.
  • 9/9 new tests pass with the change
  • no change to existing merge tests

Copy link
Contributor

@tiennou tiennou left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hello @rcoup, thanks for the PR ! Your fix is fine with me, but I'm not fond of the duplicate tests, hence some remarks :

  • A "this has been duplicated as" comment at the top of both files would be a 👍, just so changes can be propagated.
  • It might be possible to bare-clone from the other repo when initializing the testcase, but I'm not sure about runtime speed.
  • Test case duplication : this has been bothering me as well (surprisingly, on the topic of bare repositories), but I don't think it can be done cleanly without changes to clar (something like RSpec's behaves). The only alternative I can think of is preprocessor tomfoolery (having a "shared" analysis.template, and include this from both .c files, switching the prefixes from the template, but meh).

I'm OK with merging it as is, I just want to fly those clar questions through maintainers 😉.

@rcoup
Copy link
Contributor Author

rcoup commented Mar 19, 2019

I'm not fond of the duplicate tests, hence some remarks :

Yeah, I wasn't too excited about it either.

A "this has been duplicated as" comment at the top of both files would be a 👍, just so changes can be propagated.

Can do this easily.

It might be possible to bare-clone from the other repo when initializing the testcase, but I'm not sure about runtime speed.

Any examples in the test suite for doing this? I guess it's just git_clone(..., {bare=1}) but I'll need some pointers to figure out the path/tempdir handling in the tests.

Test case duplication ... I don't think it can be done cleanly without changes to clar

backs away slowly 🐉🐍

Alternatively as a simple starting point before clar supports parameterisation I could probably move all the analysis test bodies into merge/analysis.c and call them from the workdir/analysis.c & trees/analysis.c versions with the right setup?

@tiennou
Copy link
Contributor

tiennou commented Mar 20, 2019

Any examples in the test suite for doing this? I guess it's just git_clone(..., {bare=1}) but I'll need some pointers to figure out the path/tempdir handling in the tests.

  • initialize
#define ANALYZED_REPO "merge-analysis-bare.git"

/* cl_sandbox setup, pretty standard, using the non-bare version */

git_clone_options opts = GIT_CLONE_OPTIONS_INIT;
opts.bare = 1;

git_clone(ANALYZED_REPO, &opts);
  • cleanup
git_futils_rmdir_r(ANALYZED_REPO);

Code mildly brain-compiled. Helpful "low-level" utilities can be found in futils.c/h, path.c/h, good-ol' buffer.c/h, as well as the clar headers.

Alternatively as a simple starting point before clar supports parameterisation […]

Yeah, I'd much prefer having a clean implementation if that's something we ever want. For now, a documentation comment is sufficient in my eyes. Again, thanks for doing this !

@pks-t
Copy link
Member

pks-t commented Mar 29, 2019

You could just use git_repository_open_ext(&repo, "/path/to/sandbox/.git", GIT_REPOSITORY_OPEN_BARE, NULL); instead of doing a copy.

@rcoup
Copy link
Contributor Author

rcoup commented Jun 6, 2019

@tiennou sorry, been distracted by some other work. I've refactored the analysis test implementation into one file and removed the duplicate test data (I went with @pks-t's suggestion).

Copy link
Member

@pks-t pks-t left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some nits with regards to style, but otherwise I'm fine with this PR. Thanks for amending!

tests/merge/analysis.c Outdated Show resolved Hide resolved
tests/merge/analysis.c Outdated Show resolved Hide resolved
tests/merge/workdir/analysis.c Outdated Show resolved Hide resolved
tests/merge/analysis.h Show resolved Hide resolved
@rcoup
Copy link
Contributor Author

rcoup commented Jun 7, 2019

I addressed all those.

I can't quite spot my error which is triggering valgrind though. Any obvious insight?

git_merge_analysis_t merge_analysis;
git_merge_preference_t merge_pref;

git_repository_config(&config, repo);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're not freeing this...

@ethomson
Copy link
Member

ethomson commented Jun 7, 2019

I can't quite spot my error which is triggering valgrind though. Any obvious insight?

Not sure offhand. But something is probably incrementing the refcount on the repository, so your call to repository_free isn't actually disposing it (just reducing the refcount).

My guess is that it's that git_repository_config but I'm not 100%.

Copy link
Member

@pks-t pks-t left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can't quite spot my error which is triggering valgrind though. Any obvious insight?

Not sure offhand. But something is probably incrementing the refcount on the repository, so your call to repository_free isn't actually disposing it (just reducing the refcount).
My guess is that it's that git_repository_config but I'm not 100%.

It is. All leaks point to the repository configuration snapshots, which are leaked in merge::analysis::no_fastforward_with_config_ffonly and merge::analysis::fastforward_with_config_noff. Sorry for not spotting these in my previous review.

tests/merge/analysis.c Outdated Show resolved Hide resolved
tests/merge/analysis.c Outdated Show resolved Hide resolved
@rcoup
Copy link
Contributor Author

rcoup commented Jun 10, 2019

Aha, it had passed CI before my test refactoring which had confused me, I assumed it was related to the init/reorg. <looking in the wrong place> Thanks 😄

OT: Valgrind on OSX (3.14.0/Homebrew) reports a pile of leaks, even when using tests/valgrind-supp-mac.txt & libgit2_clar.supp, looks like mostly from dyld/ImageLoader. And doesn't report these test leaks, with or without the suppressions. Built with -DVALGRIND=ON. There some other spells I need to cast to make it work?

dupe of workdir/analysis.c against a bare repo.
- move duplication between merge/trees/ and merge/workdir/ into merge/analysis{.c,.h}
- remove merge-resolve.git resource, open the existing merge-resolve as a bare repo instead.
- whitespace -> tabs
- comment style
- improve repo naming in merge/trees/analysis tests.
Wrap some missed setup api calls in asserts.
@rcoup rcoup force-pushed the merge-analysis-bare-repo-5017 branch from e406132 to 438c995 Compare June 10, 2019 10:22
@rcoup
Copy link
Contributor Author

rcoup commented Jun 10, 2019

Rebased onto newer master

@ethomson
Copy link
Member

OT: Valgrind on OSX (3.14.0/Homebrew) reports a pile of leaks, even when using tests/valgrind-supp-mac.txt & libgit2_clar.supp, looks like mostly from dyld/ImageLoader. And doesn't report these test leaks, with or without the suppressions. Built with -DVALGRIND=ON. There some other spells I need to cast to make it work?

Although we checked in valgrind-supp-mac.txt, I haven't made valgrind work correctly on macOS in years. (valgrind itself says that the latest supported version is macOS 10.12.)

We use leaks on macOS if you have Xcode installed (which I presume that you do). You can take a look at the CI test script to see how we invoke it:

MallocStackLogging=1 MallocScribble=1 MallocLogFile=/dev/null CLAR_AT_EXIT=\"leaks -quiet \$PPID\" libgit2_clar

@rcoup
Copy link
Contributor Author

rcoup commented Jun 10, 2019

/rebuild

@libgit2-azure-pipelines
Copy link

Okay, @rcoup, I started to rebuild this pull request as build #2028.

@rcoup
Copy link
Contributor Author

rcoup commented Jun 10, 2019

We use leaks on macOS if you have Xcode installed (which I presume that you do). You can take a look at the CI test script to see how we invoke it:

@ethomson aha, victory! that works (I've never used leaks before, only valgrind). Is it worth me adding that to docs somewhere? tests/README?

@ethomson
Copy link
Member

Is it worth me adding that to docs somewhere? tests/README?

Whoa, that would be great. 🙇

@rcoup rcoup mentioned this pull request Jun 10, 2019
@rcoup
Copy link
Contributor Author

rcoup commented Jun 13, 2019

@pks-t you happy for this to be merged now?

@pks-t pks-t merged commit 0c1029b into libgit2:master Jun 13, 2019
@pks-t
Copy link
Member

pks-t commented Jun 13, 2019

Looks good to me now, thanks for your work @rcoup! I'll do a follow-up to make use of our new test variants so that we can avoid the duplication, but seeing as that only got merged a few days ago I don't want to shift that burden on you.

@rcoup rcoup deleted the merge-analysis-bare-repo-5017 branch June 13, 2019 09:42
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.

None yet

4 participants