Hi Junio,
On Thu, 13 Nov 2014, Junio C Hamano wrote:
> Johannes Schindelin <johannes.schindelin@xxxxxx> writes:
>
> > This patch series adds support for a new receive.denyCurrentBranch setting
> > to update the working directory (which must be clean, i.e. there must not be
> > any uncommitted changes) when pushing into the current branch.
> >
> > The scenario in which the 'updateInstead' setting became a boon in this
> > developer's daily work is when trying to get a bug fix from a Windows
> > computer, a virtual machine or a user's machine onto his main machine (in
> > all of those cases it is only possible to connect via ssh in one direction,
> > but not in the reverse direction).
> >
> > Interdiff vs v2 below the diffstat.
> >
> > Johannes Schindelin (1):
> > Add another option for receive.denyCurrentBranch
> >
> > Documentation/config.txt | 5 ++++
> > builtin/receive-pack.c | 78 ++++++++++++++++++++++++++++++++++++++++++++++--
> > t/t5516-fetch-push.sh | 17 +++++++++++
> > 3 files changed, 98 insertions(+), 2 deletions(-)
> >
> > diff --git a/Documentation/config.txt b/Documentation/config.txt
> > index 4f9fe81..c384515 100644
> > --- a/Documentation/config.txt
> > +++ b/Documentation/config.txt
> > @@ -2134,10 +2134,6 @@ Another option is "updateInstead" which will update the working
> > directory (must be clean) if pushing into the current branch. This option is
> > intended for synchronizing working directories when one side is not easily
> > accessible via ssh (e.g. inside a VM).
> > -+
> > -Yet another option is "detachInstead" which will detach the HEAD if updates
> > -are pushed into the current branch; That way, the current revision, the
> > -index and the working directory are always left untouched by pushes.
>
> I think we had an exchange to clarify the workflow in which
> updateInstead is useful and how to help readers, but I do not see
> any change on that in this part of documentation. Forgot to revise?
I had revised it for v2 already. It now reads:
-- snip --
Another option is "updateInstead" which will update the working directory
(must be clean) if pushing into the current branch. This option is
intended for synchronizing working directories when one side is not easily
accessible via ssh (e.g. inside a VM).
-- snap --
In my mind, this strikes the balance between sketching a scenario where
the setting makes sense on the one hand and abducting config.txt to tell
my life's story on the other.
> > @@ -737,36 +733,66 @@ static int update_shallow_ref(struct command *cmd, struct shallow_info *si)
> > return 0;
> > }
> >
> > -static const char *merge_worktree(unsigned char *sha1)
> > +static const char *update_worktree(unsigned char *sha1)
> > {
> > const char *update_refresh[] = {
> > "update-index", "--ignore-submodules", "--refresh", NULL
> > };
> > + const char *diff_index[] = {
> > + "diff-index", "--quiet", "--cached", "--ignore-submodules",
> > + "HEAD", "--", NULL
> > + };
> > const char *read_tree[] = {
> > "read-tree", "-u", "-m", sha1_to_hex(sha1), NULL
> > };
>
> OK.
>
> "update-index --refresh && diff-files && diff-index --cached" is how
> we traditionally ensure the working tree is absolutely clean (see
> require_clean_work_tree in git-sh-setup.sh), but I do not think of a
> reason why diff-files step is not redundant.
I fear that my double-negation-fu is still stuck somewhere in dreamland.
Do you mean to say "I could imagine that the diff-files step is
redundant"? If that is what you are telling me, then your explanation of
the exit code of update-index --refresh would suggest so, and so would
https://github.com/git/git/blob/f5709437/read-cache.c#L1201-L1230 *except*
in the case where refresh_cache_ent() returns an updated cache entry:
https://github.com/git/git/blob/f5709437/read-cache.c#L1116-L1131 – but I
could not figure out quickly when this code path is hit.
Ciao,
Johannes