Re: [PATCH 3/3] git-pull.sh: introduce --[no-]autostash and pull.autostash

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

 



Junio C Hamano wrote:
> Ramkumar Ramachandra <artagnon@xxxxxxxxx> 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.

>>>> +if test "$autostash" = true && stash_required
>>>> +then
>>>> +     git stash
>>>> +     eval "$eval"
>>>> +     test $? = 0 && git stash pop
>>>> +else
>>>> +     eval "exec $eval"
>>>> +fi
>>>
>>> Delaying to run "git stash" as much as possible is fine, but with
>>> the above, can the user tell if something was stashed and she has
>>> to "stash pop" once she is done helping the command to resolve the
>>> conflicts, or she shouldn't run "stash pop" after she is done
>>> (because if nothing is stashed at this point, that "pop" will pop an
>>> unrelated stash)?
>>
>> I could easily tell, from the "git pull" output: if conflict, then
>> stash hasn't been applied.
>
> The question was about "git stash save".  Depending on the cleanness
> of the tree when "git pull" was started, "save" may or may not have
> been done.  After resolving a conflicted "git pull" and committing
> the result, the user does not have much clue if she needs to pop
> anything, does she?  Instead of the usual "resolve the conflicts and
> commit the result", she may need to see "resolve the conflicts,
> commit the result, *AND* UNSTASH".

Yes, good point.  Will it suffice to print a message?
--
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]