All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brad King <brad.king@kitware.com>
To: git@vger.kernel.org
Cc: gitster@pobox.com, newren@gmail.com
Subject: [PATCH/RFC 0/3] merge-recursive: Avoid diagnostic on empty work tree
Date: Fri, 24 Jan 2014 10:01:00 -0500	[thread overview]
Message-ID: <cover.1390574980.git.brad.king@kitware.com> (raw)
In-Reply-To: <CABPp-BGAsrrjcZxVirzKU_VEyUM1U=4TFj18CieKKE7==c7v2A@mail.gmail.com>

On 01/23/2014 07:24 PM, Elijah Newren wrote:
> Two options are just doing a stat to determine whether the file
> is present (which means we'll be stat'ing the file multiple times
> in these cases, which feels wasteful), or perhaps writing a
> modified make_cache_entry() with the behavior we want
> (seems like ugly code duplication).  Suggestions?

Perhaps we can thread enough information through the make_cache_entry
signature to allow the caller to know when lstat reported ENOENT.
Here is a series that takes such an approach.

* Patch 1 is the original test case from $gmane/240853.

* Patch 2 extends the make_cache_entry signature to return lstat errno.

* Patch 3 uses this information to silence the add_cacheinfo diagnostic

-Brad

Brad King (3):
  t3030-merge-recursive: Test known breakage with empty work tree
  read-cache.c: Thread lstat error through make_cache_entry signature
  merge-recursive: Tolerate missing file when HEAD is up to date

 builtin/apply.c            |  2 +-
 builtin/checkout.c         |  2 +-
 builtin/reset.c            |  2 +-
 cache.h                    |  2 +-
 merge-recursive.c          | 22 ++++++++++++++--------
 read-cache.c               | 12 +++++++-----
 resolve-undo.c             |  2 +-
 t/t3030-merge-recursive.sh | 47 ++++++++++++++++++++++++++++++++++++++++++++++
 8 files changed, 73 insertions(+), 18 deletions(-)

-- 
1.8.5.2

       reply	other threads:[~2014-01-24 15:00 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CABPp-BGAsrrjcZxVirzKU_VEyUM1U=4TFj18CieKKE7==c7v2A@mail.gmail.com>
2014-01-24 15:01 ` Brad King [this message]
2014-01-24 15:01   ` [PATCH/RFC 1/3] t3030-merge-recursive: Test known breakage with empty work tree Brad King
2014-01-24 16:51     ` Jonathan Nieder
2014-01-24 17:50       ` Brad King
2014-01-24 15:01   ` [PATCH/RFC 2/3] read-cache.c: Thread lstat error through make_cache_entry signature Brad King
2014-01-24 15:01   ` [PATCH/RFC 3/3] merge-recursive: Tolerate missing file when HEAD is up to date Brad King
     [not found]     ` <CABPp-BEK9+_ebRiodCp59DHJZExYn3N1jjtBsikSmwt-s_v_0A@mail.gmail.com>
2014-01-24 19:37       ` Fwd: " newren
2014-01-24 19:45       ` Brad King
2014-01-24 19:50     ` Junio C Hamano
2014-01-24 20:02       ` Brad King
2014-01-24 20:10   ` [PATCH v2 0/3] merge-recursive: Avoid diagnostic on empty work tree Brad King
2014-01-24 20:10     ` [PATCH v2 1/3] t3030-merge-recursive: Test known breakage with " Brad King
2014-01-24 20:10     ` [PATCH v2 2/3] read-cache.c: Optionally tolerate missing files in make_cache_entry Brad King
2014-01-24 20:39       ` Junio C Hamano
2014-01-24 20:10     ` [PATCH v2 3/3] merge-recursive.c: Tolerate missing files while refreshing index Brad King
2014-01-27 14:45     ` [PATCH v3 0/3] merge-recursive: Avoid diagnostic on empty work tree Brad King
2014-01-27 14:45       ` [PATCH v3 1/4] t3030-merge-recursive: Test known breakage with " Brad King
2014-01-27 14:45       ` [PATCH v3 2/4] read-cache.c: Refactor --ignore-missing implementation Brad King
2014-01-27 17:39         ` Junio C Hamano
2014-01-27 14:45       ` [PATCH v3 3/4] read-cache.c: Extend make_cache_entry refresh flag with options Brad King
2014-01-27 14:45       ` [PATCH v3 4/4] merge-recursive.c: Tolerate missing files while refreshing index Brad King

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cover.1390574980.git.brad.king@kitware.com \
    --to=brad.king@kitware.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=newren@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.