Re: first parent, commit graph layout, and pull merge direction

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

 



John Keeping <john@xxxxxxxxxxxxx> writes:

> This isn't about "swap parents", it's about helping people realise that
> just "git pull" isn't necessarily the best thing for them to do, and
> that they may want --rebase.
>
> So I was asking if it would be sensible (possibly in Git 2.0) to make
> git-pull pass --ff-only to git-merge by default.

Unless your primary user base is those who use Git as a deployment
tool to always follow along the tip of some external repository
without doing anything on your own on the branch you run your "git
pull" on, defaulting it to --ff-only does not make much sense to me.

If the proposal were to make pull.rebase the default at a major
version bump and force all integrators and other people who are
happy with how "pull = fetch + merge" (not "fetch + rebase") works
to say "pull.rebase = false" in their configuration, I think I can
see why some people may think it makes sense, though.

But neither is an easy sell, I would imagine.  It is not about
passing me, but about not hurting users like kernel folks we
accumulated over 7-8 years.

Also "rebase" of the branch you attempted to push out is sometimes a
good solution (fixing "just a small change on 'master'" that was
beaten by somebody else pushing first), but is a bad workaround (you
had many changes on that branch, which would have been better if
they were done on a topic branch, but you do not want to merge with
the upstream because you worked on 'master') some other times, so I
have this suspicion that 'pull.rebase' is not necessarily a good
thing to encourage in the first place.
--
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]