Thanks to visit codestin.com
Credit goes to github.com

Skip to content

git_index_read_index fixes #3808

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

Merged
merged 7 commits into from
Jun 2, 2016
Merged

Conversation

ethomson
Copy link
Member

@ethomson ethomson commented Jun 2, 2016

Some fixes to git_index_read_index, which replaces an the contents of one index with another. (But doing so intelligently - so that if the destination index already has a stat cache for some files, those will be maintained if the new index being read has not updated those files.)

There are two important fixes here:

  1. Remove the tree cache for new files. We were correctly removing the tree cache when removing files from the index, but not when adding them. (We - of course - should have been invalidating the parent trees when adding a new file.)
  2. Clear the error during each file comparison between the two indexes. We may hit GIT_ITEROVER on one of the iterators and we must clear that upon each step, otherwise we may hit a branch that does not update error. (In particular, when there is no dup_entry or add_entry, but there is a remove_entry, we may not clear the GIT_ITEROVER.)

Two minor correctness fixes that are important for indexes that will get persisted to disk:

  1. Treat different modes as having updated the files and blow away any stat cache. (We previously checked only the OID.)
  2. Update the entry's flags that will be persisted as the on disk path length when duplicating an entry. This is generally done during git_index_add and friends, but during the merge into the new index, we should insist upon its existence.

Read a tree into an index using `git_index_read_index` (by reading
a tree into a new index, then reading that index into the current
index), then write the index back out, ensuring that our new index
is treesame to the tree that we read.
@ethomson ethomson changed the title git_index_read_index fixes WIP: git_index_read_index fixes Jun 2, 2016
Edward Thomson added 6 commits June 2, 2016 02:36
Clear any error state upon each iteration.  If one of the iterations
ends (with an error of `GIT_ITEROVER`) we need to reset that error to 0,
lest we stop the whole process prematurely.
Treat index entries with different modes as different, which they
are, at least for the purposes of up-to-date calculations.
Update the flags to reset the path_len (to emulate `index_insert`)
Read a tree into an index, write the index, then re-open the index and
ensure that we are treesame to the original.
Test a rebase (both a merge rebase and an inmemory rebase) with a new
commit that adds files underneath a new subfolder.
When adding a new entry to an existing index via `git_index_read_index`,
be sure to remove the tree cache entry for that new path.  This will
mark all parent trees as dirty.
@ethomson ethomson force-pushed the read_index_fixes branch from 23b205f to 46082c3 Compare June 2, 2016 07:50
@ethomson ethomson changed the title WIP: git_index_read_index fixes git_index_read_index fixes Jun 2, 2016
@ethomson
Copy link
Member Author

ethomson commented Jun 2, 2016

Note that I also pulled in the tests from libgit2/rugged#609

/cc @arthurschreiber

@ethomson
Copy link
Member Author

ethomson commented Jun 2, 2016

These changes are quite safe and nicely contained to git_index_read_index. I'm going to merge them so that I can bump rugged.

@ethomson ethomson merged commit f0ee795 into libgit2:master Jun 2, 2016
@arthurschreiber
Copy link
Member

Thank you so much! ❤️ I'm really excited to test drive this! 😄

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.

2 participants