-
-
Notifications
You must be signed in to change notification settings - Fork 354
gix-status-improvements #1030
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
gix-status-improvements #1030
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
fa7fef7
to
ba307f5
Compare
That way it's possible to hash entire files as object. Previously it wasn't possible to read more than u32::MAX bytes even on 32 bit system even though we are streaming the data.
af488c1
to
8d76af7
Compare
The motivation for this is git/git@f62ce3d .
Previously, submodules where ignored. Now they are treated correctly as 'directory' which is compared to what's in the worktree. We also simplify blob handling.
That way, 'is_dirty()` scenarios can be done without wasting too much time.
It adds `Stack::from_state_and_ignore_case()` as utility to more easily instantiate a stack the is configured correctly. This also removes the `stack::State::for_status()` method as it's not actually suitable for status retrieval per se.
…onvert::to_git::IndexObjectFn()`. It implies that one has to be ready to fetch any kind of path from the index, even though it's always the path to the file that is currently converted. Also fix a bug that could cause it to return input as unchanged even though it was read into a buffer already.
…bit systems. Previously, larger than 4GB files wouldn't be supported, which causes problems when genrating hashes even when streaming data.
This is important as it allows to streaming-read from the worktree and correctly change, for example, `git-lfs` files back into their manifests, and to arrive at the correct hash.
That way it's possible to lookup other, surrounding entries in case of conflicts or easily find entries that didn't change.
0de13de
to
7e82b92
Compare
We also adjust the returned data structure to allow the input to be immutable, which delegates entry updates to the caller. This also paves the way for rename tracking, which requires free access to entries for searching renames among the added and removed items, and/or copies among the added ones.
This is useful if a missing index should mean it's empty.
…n what happened. This is useful for understanding performance characteristics in detail.
This codepath was never tested and its function more subtle than one could have known. Also fix incorrect configuration handling which could lead to binary files with `text=auto` to be identified as text, which would then require conversion.
This prevents expensive operations to re-occour.
It seems to work now, but let's keep an eye on it.
It seems windows now has a windows-unspecific `echo` program and one can't really rely on it producing windows style newlines. Now we use printf which is more standard and can be used to validate multiple arguments as well.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Based on #1021
Improve
gix status
to the point where it's suitable for use in reset functinoality.Leads to a proper worktree reset implementation, eventually leading to a high-level reset similar to how git supports it.
Architecture
The reason this PR deals quite a bit with
gix status
is that for a safe implementation ofreset()
we need to be sure that the files we would want to touch don't don't carry modifications or are untracked files. In order to know what would need to be done, we have to diff thecurrent-index with target-index
. The set of files to touch can then be used to lookup information provided bygit-status
, like worktree modifications, index modifications, and untracked files, to know if we can proceed or not. Here is also where the reset-modes would affect the outcome, i.e. what to change and how.This is a very modular approach which facilitates testing and understanding of what otherwise would be a very complex algorithm. Having a set of changes as output also allows to one day parallelize applying these changes.
This leaves us in a situation where the current
checkout()
implementation wants to become a fastpath for situations where the reset involves an empty tree as source (i.e. create everything and overwrite local changes).On the way to
reset()
it's a valid choice to warm up more with the matter by improving on the currentgix status
implementation and assure correctness of what's there, which currently doesn't seem to be the case in comparison. Further, implementinggix status
similarly togit status
should be made possible.Tasks
index-as-worktree
ingix-status
- changes to the entry itself should be detected (i.e. must be dir)Outcome
(helps to determine early aborts)gix-filter
due to ownership/streaming semanticsgit
still think that an entry is changed even after we have updated it? Use index debug mode?gix
seems to not set it correctly, even though it should be able to. This is whygit
thinks the file changed, it trusts the CTime by default.[warn]: in the working copy of './Source/ThirdParty/ANGLE/src/android_system_settings/res/drawable/icon.png', CRLF will be replaced by LF next time git touches it
due to undoing a filter which maybe, isn't applied?git
?optionally include unmodified likeOr is there a way to implement it on top maybe by providing indices? Indices are now provided with each listed entry, which allows to both enrich conflict information and list unchanged statuses efficiently.git2
can do?gix status
with statisticsgix-status
incrates-status.md
Next PR
gix
cratereset()
that checks if it's allowed to perform a worktree modification is allowed, or if an entry should be skipped. That way we can postpone safety checks like --hardPostponed
What follows is important for resets, but won't be needed for
cargo
worktree resets.git2
can do that. Needs generalization of what's available fortree/tree
diffs, at least learn from it.gix status
with actual submodule support - needsstatus
ingix
(crate) effectivelygix status
with actual conflict supportLimitations
git
will rewrite that next time it runs. This can be fixed withcore.trustCTime=false
Research
gix status
can deal a little better with submodules. Even though in this case a lot of submodule-related information is needed for a complete reset, probably only doable by a higher-level caller which orchestrates it.merge
andkeep
? How to controlrefresh
? Maybe partial (only the files we touch), and full, to also update the files we don't touch as part of status? Maybe it's part of status if that is run before.git reset
andgit checkout
in terms ofHEAD
modifications. With the former changingHEAD
s referent, and the latter changingHEAD
itself.checkout()
method as technically that's areset --hard
with optional overwrite check. Could it be rolled into one, with pathspec support added?reset()
performs just as well, which is unlikely as there is more overhead. But maybe it's not worth to maintain two versions over it. But if so, one should probably rename it.git status
: what about rename tracking? It's available for tree-diffs and quite complex on its own. Probably only needs HEAD-vs-index rename tracking.git status
: How to deal with detailed conflict messages? Right now we only know if there is a conflict or not and it seems we would need access to the other entries (or condense that knowledge to be status-suitable).rm -Rf dir
-> deleted dirtouch dir
-> typechangerm dir && mkdir dir
-> no changerm -Rf .git/modules/dir
-> no changegit status
can detect:sha1collisiondetection (new commits, modified content, untracked content)