RE: Pull is Evil (was: Re: A failing attempt to use Git in a centralized environment)

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

 



Marc Branchaud wrote:
> But I'm definitely biased because I think pull is pretty much broken:
> 
> * New users are encouraged to use pull, but all too often the default
> fetch-then-merge behaviour doesn't match their expectations and they end up
> starting threads like this one on the mailing list.

Yes, this has been discussed many times in the past, and everyone agrees
the default behavior is not correct.

Most people agree it has to be changed.

And we have patches for it[1].

But it's not going to change. Why? No reason given, it's just not going
to.

> * If we change pull's default behaviour, we'll just be shifting the
> mismatched expectations onto the other half of the new users who would be
> happy with fetch-then-merge.

Not true. As it has been agreed in the discussions, very few people
would be affected negatively by this change, and even then an
appropriate error message like:

  The pull was not fast-forward, please either merge or rebase.
  If unsure, run 'git pull --merge'.

Should do the trick.

[1] http://article.gmane.org/gmane.comp.version-control.git/247567

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