On Sat, Sep 7, 2013 at 11:43 PM, Jeff King <p...@peff.net> wrote:
> On Sat, Sep 07, 2013 at 11:37:13PM -0500, Felipe Contreras wrote:
>> > By "svn-like", I mean the people whose workflow is:
>> > $ hack hack hack
>> > $ git commit
>> > $ git push ;# oops, somebody else pushed in the meantime
>> > $ git pull
>> > $ git push
>> But that's not svn-like at all.
> It's not if you understand the difference between merge-then-commit and
> commit-then-merge. But for a clueless user who has been told "replace
> svn commit" with "git commit && git push" and replace "svn update" with
> "git pull", it is quite similar.
Well, yeah, but if they are so clueless they have to be told what to
do, they can be told to do 'git pull --merge' instead, no?
>> > Those people would now have to learn enough to choose between merge and
>> > rebase when running the "git pull".
>> But that's only if they don't care about the shape of history. In my
>> experience the people that cling more to centralized VCS do not like
>> merges, so they rebase everything to make it a straight line. That is
>> much more "svn-like".
>> So chances are they are already doing 'git pull --rebase' (or
>> similar), so their workflow wouldn't be affected.
> I think we are talking about two classes of users. People who truly
> don't care about the shape of history will also not care about using
> "git pull --rebase", because the only reason to use it is to impact the
> shape of history.
> I agree there is also a set of people coming from the centralized vcs
> world who want to keep a linear history.
Yeah, and based on the evidence, one set of people is much much larger
than the other; the people that care what the history look like.
Either way, we can start by making it a warning, and then an error,
and if more people complain that they have to do 'git pull --merge'
now (I bet there won't be any), then you would be right, and we
revert. No problem.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html