From: Junio C Hamano <gitster@pobox.com>
To: Thomas Rast <tr@thomasrast.ch>
Cc: git@vger.kernel.org, Jonathan Nieder <jrnieder@gmail.com>,
Eric Sunshine <sunshine@sunshineco.com>,
Thomas Rast <trast@inf.ethz.ch>
Subject: Re: [PATCH v3 2/8] merge-recursive: internal flag to avoid touching the worktree
Date: Mon, 08 Sep 2014 10:37:37 -0700 [thread overview]
Message-ID: <xmqqk35enhcu.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: 5bd5960659d85943477d2a5fbca3dd5ccd0da686.1409860234.git.tr@thomasrast.ch
Thomas Rast <tr@thomasrast.ch> writes:
> From: Thomas Rast <trast@inf.ethz.ch>
>
> o->call_depth has a double function: a nonzero call_depth means we
> want to construct virtual merge bases, but it also means we want to
> avoid touching the worktree. Introduce a new flag o->no_worktree to
> trigger only the latter.
>
> Signed-off-by: Thomas Rast <trast@inf.ethz.ch>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
I notice that many hits from
$ git grep -e '->call_depth' --and --not -e '->no_worktree'
are about how the progress is reported during recursive operations
or setting up ll_opts suitable for ancestor merges (both of which
are perfectly fine not to pay any attention to no_worktree), but
some others look iffy. For example, function remove_file() decides
to update the in-core index only when call_depth is set (i.e. we are
doing a virtual parent) or clean (clean merge at the content level,
i.e. "both removed"), and decides to update the working tree only at
the top-level of the recursion and no_wd is passed.
- As to "update_cache", if you do not update it while you are
operating in the cache-only mode (aka ->no_worktree), I wonder
where the result goes. Shouldn't it be done for in-core merge as
well?
- As to "update_working_tree", there are few places where the
function is called with no_wd that is not true, even when
->no_worktree is set. Do you want to allow working tree to be
modified in such a call?
next prev parent reply other threads:[~2014-09-08 17:37 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-06 17:56 [PATCH v3 0/8] --remerge-diff Thomas Rast
2014-09-06 17:56 ` [PATCH v3 1/8] merge-recursive: remove dead conditional in update_stages() Thomas Rast
2014-09-06 17:57 ` [PATCH v3 2/8] merge-recursive: internal flag to avoid touching the worktree Thomas Rast
2014-09-08 17:37 ` Junio C Hamano [this message]
2014-09-06 17:57 ` [PATCH v3 3/8] merge-recursive: -Xindex-only to leave worktree unchanged Thomas Rast
2014-09-06 17:57 ` [PATCH v3 4/8] combine-diff: do not pass revs->dense_combined_merges redundantly Thomas Rast
2014-09-08 17:29 ` Junio C Hamano
2014-09-11 19:37 ` Jens Lehmann
2014-09-06 17:57 ` [PATCH v3 5/8] Fold all merge diff variants into an enum Thomas Rast
2014-09-08 17:36 ` Junio C Hamano
2014-09-06 17:57 ` [PATCH v3 6/8] merge-recursive: allow storing conflict hunks in index Thomas Rast
2014-09-09 17:47 ` Junio C Hamano
2014-09-06 17:57 ` [PATCH v3 7/8] name-hash: allow dir hashing even when !ignore_case Thomas Rast
2014-09-09 17:49 ` Junio C Hamano
2014-09-06 17:57 ` [PATCH v3 8/8] log --remerge-diff: show what the conflict resolution changed Thomas Rast
2014-09-08 18:28 ` Junio C Hamano
2014-09-09 18:58 ` Junio C Hamano
2014-09-09 19:08 ` Junio C Hamano
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=xmqqk35enhcu.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=jrnieder@gmail.com \
--cc=sunshine@sunshineco.com \
--cc=tr@thomasrast.ch \
--cc=trast@inf.ethz.ch \
/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.