Re: [PATCH] reset: trivial refactoring
On Thu, Jun 13, 2013 at 11:15 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
@@ -82,7 +82,7 @@ static int reset_index(const unsigned char *sha1, int
reset_type, int quiet)
if (unpack_trees(nr, desc, opts))
return -1;
- if (reset_type == MIXED || reset_type == HARD) {
+ if (reset_type == HARD) {
Are you sure that this can not be reached given that...
@@ -323,8 +323,11 @@ int cmd_reset(int argc, const char **argv, const char
*prefix)
struct lock_file *lock = xcalloc(1, sizeof(struct lock_file));
int newfd = hold_locked_index(lock, 1);
if (reset_type == MIXED) {
+ int flags = quiet ? REFRESH_QUIET :
REFRESH_IN_PORCELAIN;
if (read_from_tree(pathspec, sha1))
return 1;
+ refresh_index(the_index, flags, NULL, NULL,
+ _(Unstaged changes after reset:));
} else {
int err = reset_index(sha1, reset_type, quiet);
if (reset_type == KEEP !err)
...the line after this one reads
err = reset_index(sha1, MIXED, quiet);
? I don't know what the consequence of not calling prime_cache_tree()
would be, though.
The merging of the two if blocks looks good. Thanks.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] reset: trivial refactoring
On Thu, Jun 13, 2013 at 4:13 PM, Martin von Zweigbergk
martinv...@gmail.com wrote:
On Thu, Jun 13, 2013 at 11:15 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
@@ -82,7 +82,7 @@ static int reset_index(const unsigned char *sha1, int
reset_type, int quiet)
if (unpack_trees(nr, desc, opts))
return -1;
- if (reset_type == MIXED || reset_type == HARD) {
+ if (reset_type == HARD) {
Are you sure that this can not be reached given that...
@@ -323,8 +323,11 @@ int cmd_reset(int argc, const char **argv, const char
*prefix)
struct lock_file *lock = xcalloc(1, sizeof(struct
lock_file));
int newfd = hold_locked_index(lock, 1);
if (reset_type == MIXED) {
+ int flags = quiet ? REFRESH_QUIET :
REFRESH_IN_PORCELAIN;
if (read_from_tree(pathspec, sha1))
return 1;
+ refresh_index(the_index, flags, NULL, NULL,
+ _(Unstaged changes after reset:));
} else {
int err = reset_index(sha1, reset_type, quiet);
if (reset_type == KEEP !err)
...the line after this one reads
err = reset_index(sha1, MIXED, quiet);
That's true. Only the rest of the patch makes sense then. It seems
there should be a way to have a single call reset_index(KEEP), so we
don't have to call again with MIXED, but perhaps that's for later.
--
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] reset: trivial refactoring
Martin von Zweigbergk martinv...@gmail.com writes:
...the line after this one reads
err = reset_index(sha1, MIXED, quiet);
? I don't know what the consequence of not calling prime_cache_tree()
would be, though.
It does not affect correctness, but makes the subsequent git
status, the part that internally computes diff-cache --index to
see what changes have been added to the index, more costly.
After doing reset --hard $commit or just reset $commit, we know
that the contents of the index must match $commit^{tree}, and
writing out any subpart of the index that corresponds to a directory
(including the top-level one, i.e. the whole index) must match the
corresponding subtree of $commit^{tree}. And that is why we prime
the cache-tree that was discarded by unpack_trees() at the very end.
Then incremental git add to the resulting index after that can
invalidate only the parts of the index and cache-tree while
relieving the next write-tree (most often done by the next git
commit) from having to compute the tree objects for parts of the
index that have not been touched since the reset operation.
I do not use reset --keep $commit very often myself, but IIRC, it
is like checkout $commit (and not checkout -m $commit) in that
the resulting index matches $commit^{tree}, so I think priming the
cache-tree just like --hard/--mixed is the right thing to do.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
