Re: [PATCH] reset: trivial refactoring

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Jun 13, 2013 at 11:15 AM, Felipe Contreras
<felipe.contreras@xxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]