Re: [PATCH] pull: require choice between rebase/merge on non-fast-forward pull

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

 



"W. Trevor King" <wking@xxxxxxxxxx> writes:

> On Thu, Jun 27, 2013 at 12:48:52PM -0700, Junio C Hamano wrote:
>> Because letting a trivial merge automatically handled by Git is so
>> easy with "git pull", a person who is new to Git may not realize
>> that the project s/he is interacting with may prefer "rebase"
>> workflow.
>
> Or they may not even realize that they've just merged an unrelated
> branch at all, dragging in a thousand unrelated commits which they
> accidentally push to a central repository without looking,
> contaminating future branches based on the central repostitory without
> drastic rebase surgery ;).  I just saw one of these earlier this week.

I am not sure "running pull and integrate other's work in random
branches" is something the proposed (not by me) change would help to
prevent from happening.

Your "accident user" could have just been on a 'maint' branch,
pulled the 'master' branch which would fast-forward and then pushed
the result back to 'maint', contaminating the shared 'maint' branch
with commits that do not match the purpose of it, which is to hold
only fixes without enhancements.



--
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]