Added git_stash_apply() and git_stash_pop() APIs #2705

swisspol · 2014-11-14T03:35:38Z

This is a tentative implementation of git_stash_apply() based on the actual Git implementation found at https://github.com/git/git/blob/master/git-stash.sh#L440.

Once you have git_stash_apply(), it's trivial to implement git_stash_pop() so I also added it.

swisspol · 2014-11-14T03:38:11Z

See the comments in apply_untracked() and unstage_modified_files() for the 2 parts where I wasn't sure I had the best implementation.

swisspol · 2014-11-14T04:01:44Z

All the unit tests are passing, plus the new basic ones I added, and also my own functional tests which sit on top of libgit2.

Therzok · 2014-11-14T10:40:30Z

src/stash.c

+
+	/* If applicable, restore untracked / ignored files in workdir */
+	if (untracked_tree) {
+


Empty lines here and below!

Therzok · 2014-11-14T18:13:39Z

Tested it, it's marvelous! <3

nulltoken · 2014-11-14T22:35:20Z

include/git2/stash.h

+ * @param reinstate_index Try to reinstate not only the working tree's changes,
+ * but also the index's ones.
+ *
+ * @return 0 on success, or error code


It maybe interesting to list the common error codes that this function may return.

swisspol · 2014-11-14T23:02:52Z

I addressed the above comments and added some extra unit tests to check error codes.

ethomson · 2014-11-15T15:03:05Z

Thanks @swisspol - I apologize that this has been sitting for a few days, I have been swamped but I am looking forward to taking a look at this next week.

swisspol · 2014-11-17T14:00:57Z

Hummm... not sure where @carlosmn's comment went but I addressed it in this latest revision.

carlosmn · 2014-11-17T14:09:37Z

src/stash.c

+		*out_index_tree = index_tree;
+		*out_index_parent_tree = index_parent_tree;
+		*out_untracked_tree = untracked_tree;
+	}


This part seems odd. It's not about cleanup but about setting the outputs. I'd rather see the contents of the 'else' put before the cleanup label and we can leave everything after cleanup to be freeing memory.

Can you just provide the code how you want it and I'll copy-paste it in? I think it'll save some round trips :)

Basically just

*out_stash_tree = stash_tree; *out_base_tree = base_tree; *out_index_tree = index_tree; *out_index_parent_tree = index_parent_tree; *out_untracked_tree = untracked_tree; cleanup: git_commit_free(...); if (error < 0) { git_tree_free(...); }

swisspol · 2014-11-17T14:17:52Z

Done

ethomson · 2014-11-18T02:05:01Z

include/git2/stash.h

+ * most recent stashed state.
+ *
+ * @param reinstate_index Try to reinstate not only the working tree's changes,
+ * but also the index's ones.


Sigh, ignore that last comment, I always forget how stash works.

swisspol · 2014-11-23T01:01:58Z

I rebased the PR and replaced the reinstate_index arg by a generic flags one as I think that's quite more future proof - one might want customize what happens in case of conflicts for instance.

swisspol · 2014-11-23T02:00:06Z

This latest update significantly improves documentation and test coverage.

swisspol · 2014-11-23T13:31:08Z

@ethomson I found a conflict case that wasn't handled exactly like in native Git so I'm working on fixing it, but I'd need help with #2728.

swisspol · 2014-11-23T14:25:33Z

I added a couple more test cases and fixed 2 bugs where the API would not behave exactly like Git CLT. As far as I can tell it's all good now from a behavior and test case perspective.

swisspol · 2014-11-23T14:27:27Z

I was also able to replace GIT_CHECKOUT_SAFE_CREATE by GIT_CHECKOUT_SAFE now and it works fine.

ethomson · 2014-11-23T17:09:01Z

@ethomson I found a conflict case that wasn't handled exactly like in native Git so I'm working on fixing it, but I'd need help with #2728.

Sorry I'm being a little dense - with the subsequent comments, is this still an issue? If so, can you push up the tests, I'd love to see what's going wrong.

Sorry I've been so very unavailable the last two weeks, I've been 😓 ing it out in the day job for a tight deadline and haven't had much (or really any) time to give to libgit2. I will have some time this afternoon to attempt to grok this in fullness. I really appreciate both your hard work and especially your patience.

ethomson · 2014-11-23T22:01:40Z

include/git2/stash.h

+ * in the stash will be left around in the workdir.
+ *
+ * If passing the GIT_APPLY_REINSTATE_INDEX flag and there are conflicts when
+ * reinstating the index, the function will return GIT_EUNMERGED and both the


Generally we use GIT_EUNMERGED to reflect that there are unmerged changes in the index when you begin the operation. I don't think we use EUNMERGED to indicate that we created conflicts and failed.

For example, now I have a conflict on file bar, and I am trying to unstash a stash that changes bar:

% git stash pop bar: needs merge unable to refresh index

This is the case that I would expect to see GIT_EUNMERGED.

I'm not returning any error code here, just passing through whatever error comes back from the APIs used internally. Am I supposed to remap this error to something else? If so to what?

Actually the use of GIT_EUNMERGED also matches the behavior you described: no conflicts are created and then the function fails mid-course. The index and workdir are left untouched. It fails during preflight in a way.

I can change the description to "...there are [potential] conflicts...", but again I'm just passing through the error from the lower-level API. Let me know.

swisspol · 2014-11-24T00:44:43Z

Sorry I'm being a little dense - with the subsequent comments, is this still an issue? If so, can you push up the tests, I'd love to see what's going wrong.

There's nothing wrong, it's just that I didn't know how to write the unit test to properly detect a given file is in "both modified". Your comment in #2728 helped me.

swisspol · 2014-11-24T01:06:18Z

Sorry I've been so very unavailable the last two weeks, I've been 😓 ing it out in the day job for a tight deadline and haven't had much (or really any) time to give to libgit2. I will have some time this afternoon to attempt to grok this in fullness. I really appreciate both your hard work and especially your patience.

No problem, there's nothing urgent here. It certainly helps to have some visibility into your availability.

To summarize the remaining points to address are:

Finalize the implementation of apply_untracked() (see my long comment above with the 3 choices)
Consider using merge_indexes() in unstage_modified_files() (I have no clue what this would look like nor how to ensure it has the exact same behavior though)
Consider adding docs for GIT_STASH_DEFAULT and GIT_APPLY_DEFAULT
Consider remapping the GIT_EUNMERGED error code in case of conflict when using GIT_APPLY_REINSTATE_INDEX to something else

swisspol · 2014-11-24T02:07:23Z

I realized I was still missing one test case (restoring the stash would overwrite local modifications in GIT_APPLY_DEFAULT mode). Turns out it this case wasn't behaving like Git CLT, but it's all fixed now.

I also updated the docs (again) and changed the error codes / error messages to make them both distinct and explicit.

ethomson · 2014-12-05T17:11:19Z

src/stash.c

+		if ((error = git_checkout_tree(
+				repo, (git_object*)untracked_tree, &options)) < 0)
+			return error;
+	}


Instead of checking out files one-by-one, I think that I would prefer to see us merge the untracked_tree with the unstashed tree and check that out. Eg:

git_merge_trees(&merged_index, repo, NULL, untracked_tree, unstashed_tree); git_checkout_index(repo, merged_index, &options);

Are you 100% sure the result will be exactly the same?

Not 100%, but I'm pretty certain, and we should have tests to ensure that we are accurate.

Also where is unstashed_tree coming from here? You need to merge that untracked_tree with the tree of the workdir which AFAIK is not readily available, no?

You created it in git_stash_apply.

I'm not following you: unstashed_tree is the reinstantiated index if requested, it's not the workdir tree.

The implementation I propose is dirt simple, very robust and predictable. You suggest to use git_merge_trees / git_checkout_index, but the potential side effects / edge cases of this approach (and again how do you get the workdir tree here?) are unknown to me, independently of the git apply unit test passing or not.

I'm not following you: unstashed_tree is the reinstantiated index if requested, it's not the workdir tree.

You just checked it out - so it is the tree that was placed into the workdir. (And if you opted not to use it, then you can just use the index, instead.)

The idea here is that instead of adding one file at a time to the working directory, we can take what's in the index, add this additional data, and write that. checkout_tree is smart enough to only write the difference, but also should do the conflict detection that you've done yourself.

I don't anticipate edge cases - but if there are bugs, then it would be nice to isolate those bugs to only having one place we check out files and do conflict detection and the like.

Here's some sample code of what I'm suggesting. Though this just reloads the index, always, instead of taking the index tree or the unstashed tree that you previously created:

git_index *index; git_repository_index(&index, repo); git_oid current; git_index_write_tree(&current, index); git_tree *current_tree; git_tree_lookup(&current_tree, repo, &current); git_index *merged_index; git_merge_trees(&merged_index, repo, NULL, untracked_tree, current_tree, NULL); git_oid merged_tree_id; git_index_write_tree_to(&merged_tree_id, merged_index, repo); git_tree *merged_tree; git_tree_lookup(&merged_tree, repo, &merged_tree_id); options.checkout_strategy = GIT_CHECKOUT_SAFE | GIT_CHECKOUT_DONT_UPDATE_INDEX; return git_checkout_index(repo, merged_index, &options);

You just checked it out

Where did you see that, it's not supposed to check it out. It's reinstating the index, not touching the workdir.

Therzok · 2014-12-24T11:36:47Z

This is relevant to my interests. Any way we can move it forward? 🙏

swisspol · 2015-01-01T02:22:28Z

This implementation has full coverage and works great AFAIK. I also addressed most comments.

I wrote this implementation mirroring exactly what Git CLT implementation does, so it should be 100% compatible. If it were to be fully written "libgit2" style i.e. taking advantage of every inner API, the resulting code might be more obvious (and maybe, maybe, more compact, but I'm not sure), but then it would "diverge" from Git CLT. The problem is that the stash system in Git has a lot of intricacies and IMO the easiest to handle them correctly is to mirror the Git implementation, rather than trying to reverse engineer every corner case and rebuild it. As seen above with the discussions with @ethomson some changes suggested to have a "cleaner" implementation result in changes in the actual behavior.

Anyway, it's up to the maintainers to decide here :)

ethomson · 2015-01-05T16:16:24Z

As seen above with the discussions with @ethomson some changes suggested to have a "cleaner" implementation result in changes in the actual behavior.

Hmm. I don't see any behavioral changes... all your tests passed with the code that I posted above. Do you have some test that fails?

swisspol · 2015-01-05T19:22:05Z

I don't see any behavioral changes

These were potential changes based on some earlier discussions which are gone from the history for some reason, but anyway it doesn't matter :)

all your tests passed with the code that I posted above

Do you mean this code:

git_index *index;
git_repository_index(&index, repo);

git_oid current;
git_index_write_tree(&current, index);

git_tree *current_tree;
git_tree_lookup(&current_tree, repo, &current);

git_index *merged_index;
git_merge_trees(&merged_index, repo, NULL, untracked_tree, current_tree, NULL);

git_oid merged_tree_id;
git_index_write_tree_to(&merged_tree_id, merged_index, repo);

git_tree *merged_tree;
git_tree_lookup(&merged_tree, repo, &merged_tree_id);

options.checkout_strategy = GIT_CHECKOUT_SAFE | GIT_CHECKOUT_DONT_UPDATE_INDEX;

return git_checkout_index(repo, merged_index, &options);

You said "instead of taking the index tree or the unstashed tree that you previously created" so I assumed you wanted to do that instead.

In any case, what's next here? Do you want to grab the PR and modify it with your change? I'm not super comfortable with it in the sense that I'm not sure I 100% understand it.

swisspol · 2015-03-24T22:04:10Z

Closing per #3018

swisspol mentioned this pull request Nov 14, 2014

Provide a git_stash_apply() API #2636

Closed

swisspol force-pushed the stash_apply branch from 74b2799 to b5749dd Compare November 14, 2014 03:46

swisspol force-pushed the stash_apply branch 2 times, most recently from 7337dd8 to e0d35a5 Compare November 14, 2014 04:06

Therzok reviewed Nov 14, 2014
View reviewed changes

src/stash.c

/* If applicable, restore untracked / ignored files in workdir */

if (untracked_tree) {

Copy link

Member

Therzok Nov 14, 2014

Choose a reason for hiding this comment

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

Empty lines here and below!

swisspol force-pushed the stash_apply branch 2 times, most recently from 26a0a65 to f9589eb Compare November 14, 2014 11:02

Therzok mentioned this pull request Nov 14, 2014

Implement Stash API. libgit2/libgit2sharp#871

Closed

nulltoken reviewed Nov 14, 2014
View reviewed changes

swisspol force-pushed the stash_apply branch from f9589eb to 84571ef Compare November 14, 2014 23:02

swisspol force-pushed the stash_apply branch from 84571ef to f483f06 Compare November 17, 2014 13:59

carlosmn reviewed Nov 17, 2014
View reviewed changes

swisspol force-pushed the stash_apply branch from f483f06 to 6e72bb3 Compare November 17, 2014 14:17

ethomson reviewed Nov 18, 2014
View reviewed changes

swisspol force-pushed the stash_apply branch 2 times, most recently from 50ebd99 to 87fdcaf Compare November 23, 2014 01:00

swisspol force-pushed the stash_apply branch from 87fdcaf to 47b2079 Compare November 23, 2014 02:00

swisspol mentioned this pull request Nov 23, 2014

git_status_file() returns GIT_STATUS_WT_NEW | GIT_STATUS_INDEX_DELETED for unmerged paths #2728

Closed

swisspol force-pushed the stash_apply branch from 47b2079 to 4efab9c Compare November 23, 2014 14:25

swisspol force-pushed the stash_apply branch from 4efab9c to b526200 Compare November 23, 2014 14:26

ethomson reviewed Nov 23, 2014
View reviewed changes

Added git_stash_apply() and git_stash_pop() APIs

ae6bb09

swisspol force-pushed the stash_apply branch from b526200 to ae6bb09 Compare November 24, 2014 02:07

ethomson reviewed Dec 5, 2014
View reviewed changes

PiersonBro mentioned this pull request Feb 7, 2015

Support stashing modocache/Gift#24

Open

tiennou mentioned this pull request Feb 13, 2015

Stash support rowanj/gitx#431

Closed

ethomson mentioned this pull request Mar 24, 2015

Stash apply #3018

Merged

swisspol closed this Mar 24, 2015

swisspol deleted the stash_apply branch March 24, 2015 22:04


		/* If applicable, restore untracked / ignored files in workdir */
		if (untracked_tree) {

Added git_stash_apply() and git_stash_pop() APIs #2705

Added git_stash_apply() and git_stash_pop() APIs #2705

Conversation

swisspol commented Nov 14, 2014

swisspol commented Nov 14, 2014

swisspol commented Nov 14, 2014

Choose a reason for hiding this comment

Therzok commented Nov 14, 2014

Choose a reason for hiding this comment

swisspol commented Nov 14, 2014

ethomson commented Nov 15, 2014

swisspol commented Nov 17, 2014

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

swisspol commented Nov 17, 2014

Choose a reason for hiding this comment

swisspol commented Nov 23, 2014

swisspol commented Nov 23, 2014

swisspol commented Nov 23, 2014

swisspol commented Nov 23, 2014

swisspol commented Nov 23, 2014

ethomson commented Nov 23, 2014

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

swisspol commented Nov 24, 2014

swisspol commented Nov 24, 2014

swisspol commented Nov 24, 2014

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Therzok commented Dec 24, 2014

swisspol commented Jan 1, 2015

ethomson commented Jan 5, 2015

swisspol commented Jan 5, 2015

swisspol commented Mar 24, 2015