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

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

 



Matthieu Moy <Matthieu.Moy@xxxxxxxxxxxxxxx> writes:

> Ramkumar Ramachandra <artagnon@xxxxxxxxx> writes:
>
>> Matthieu Moy wrote:
>>> AFAICT, "git merge --abort" is an alias for "git reset --merge"
>>
>> Yes, that is correct.
>>
>>> which
>>> was precisely designed to reset only modifications comming from a merge,
>>> and not the local changes that were present before the merge was
>>> started. The man pages are relatively obscure on the subject, but I'd
>>> call that a documentation bug.
>>
>> I see.  Either way, we need a clean worktree for it to work, no?
>
> No, you don't. Just try if you're not convinced:

Heh, I still remember breaking "git merge" and got yelled at loudly.

cf. http://thread.gmane.org/gmane.comp.version-control.git/9073

>>> It does. stashing means the user will have to "stash pop" later. One
>>> extra step, one extra opportunity to forget something important.
>>
>> That's only if there are conflicts.  If there are conflicts, you'll
>> have to stash anyway if:
>> - You're doing a pull-merge and want merge --abort to work.
>
> Again, no.
>
>>> A minor annoyance is that it will touch files that have no reason to be
>>> touched, hence may trigger extra rebuilds with "make", disturbing text
>>> editors that have the file open, etc.
>>
>> Okay, I need to ask you something at this point: do you ever run merge
>> on a dirty worktree unless you're absolutely sure that your local
>> changes won't conflict with the changes introduced by the merge? 
>
> Most of the time, I just run "git pull" or "git merge". I know it's
> conservative enough, to it will stop if there's anything dangerous.

Exactly.

> No, I'm not proposing to do anything for merge. There's no reason to try
> being uniform in conflict resolution for pull-merge and pull-rebase as
> it is already different now. We already have "git rebase --continue", we
> don't have "git merge --continue". So what? The fact that merge doesn't
> have the equivalent doesn't mean we should not do something for "rebase
> --continue".

Well said.
--
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]