All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ramkumar Ramachandra <artagnon@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Git List <git@vger.kernel.org>
Subject: Re: [PATCH 3/3] git-pull.sh: introduce --[no-]autostash and pull.autostash
Date: Mon, 25 Mar 2013 02:42:24 +0530	[thread overview]
Message-ID: <CALkWK0k0Ek0Dqxrrv7dAzUgF2X2hCcz2SodcPEgiRdLFgc-gXA@mail.gmail.com> (raw)
In-Reply-To: <CALkWK0k=jei8Z+n-4O92obQOR88FR6iFCSifVhDDS8jv37rOjA@mail.gmail.com>

Ramkumar Ramachandra wrote:
> Junio C Hamano wrote:
>> Ramkumar Ramachandra <artagnon@gmail.com> writes:
>>
>>>>> +     elif test "$autostash" = false
>>>>> +     then
>>>>>               require_clean_work_tree "pull with rebase" "Please commit or stash them."
>>>>>       fi
>>>>
>>>> A safety net, after you run "git stash", to validate that the
>>>> added "git stash" indeed made the working tree clean, is necessary
>>>> below, but there does not seem to be any.
>>>
>>> Um, isn't that part of the "git stash" testsuite?
>>
>> You should always "trust but verify" what other commands do at key
>> points of the operation; and I think this "require-clean-work-tree"
>> is a key precondition for this mode of operation to work correctly.
>>
>> Especially because you do not even bother to check the result of
>> "git stash" before continuing ;-).
>
> If you think it's enough to replicate the codepath that precedes the
> actual saving in 'git stash' (which is essentially
> require-clean-work-tree), I'm in agreement with you.  I thought you
> were implying a wider safety net, that wouldn't even assume the basic
> sanity of stash.

Er, s/codepath that precedes the actual saving in 'git stash'/codepath
that precedes the actual pulling or merging in 'git pull'/

I'm feeling a little muddled up today; weekends are usually bad.

      reply	other threads:[~2013-03-24 21:13 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-22 12:29 [PATCH 0/3] Introduce pull.autostash Ramkumar Ramachandra
2013-03-22 12:29 ` [PATCH 1/3] git-pull.sh: prefer invoking "git <command>" over "git-<command>" Ramkumar Ramachandra
2013-03-22 12:29 ` [PATCH 2/3] t5521 (pull-options): use test_commit() where appropriate Ramkumar Ramachandra
2013-03-22 16:51   ` Junio C Hamano
2013-03-23 12:38     ` Ramkumar Ramachandra
2013-03-22 12:29 ` [PATCH 3/3] git-pull.sh: introduce --[no-]autostash and pull.autostash Ramkumar Ramachandra
2013-03-22 17:02   ` Junio C Hamano
2013-03-23 12:48     ` Ramkumar Ramachandra
2013-03-24  7:28       ` Junio C Hamano
2013-03-24 17:56         ` Ramkumar Ramachandra
2013-03-24 21:12           ` Ramkumar Ramachandra [this message]

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=CALkWK0k0Ek0Dqxrrv7dAzUgF2X2hCcz2SodcPEgiRdLFgc-gXA@mail.gmail.com \
    --to=artagnon@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.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.