Re: Considering teaching plumbing to users harmful

> On 7/16/08, Junio C Hamano <gitster@pobox.com> wrote:
>> "Avery Pennarun" <apenwarr@gmail.com> writes:
>> >        git diff :{1,3}:path/to/filename
>> >
>> > Which is a great command, but svn definitely makes it easier to do the
>> > same thing.
>>
>> I've never seen anybody who finds "diff :{1,3}:path" *useful*.
>
> Dunno.  I use it frequently, and it works great for me.  Perhaps my
> brain is just poisoned by svn.

> I've never tried "git log -p --merge".  I'll try it next time.  This
> is certainly not common knowledge, however.  (But to save Dscho the
> trouble: git usability in general is not the subject of this thread.)
>
>> > Even if you have a repo with widespread push access, git's log looks
>> > annoying compared to svn because of all the merge commits.  That's a
>> > primary reason why rebase was invented, of course.
>>
>> Please don't talk nonsense if you do not know history.  I invented rebase
>>  primarily because I wanted to help e-mail based contributors.  There is
>>  nothing about merge avoidance to it.
>
> Sorry, I mixed up git-rerere and git-rebase.  From git-rerere's man page:
>
>       When your topic branch is long-lived, however, your topic branch would
>       end up having many such "Merge from master" commits on it, which would
>       unnecessarily clutter the development history. Readers of the Linux
>       kernel mailing list may remember that Linus complained about such too
>       frequent test merges when a subsystem maintainer asked to pull from a
>       branch full of "useless merges".
>
> Nowadays, I'm pretty sure people use git-rebase to avoid this sort of
> problem (or "git pull --rebase" presumably wouldn't have appeared),
> but I can now see how git-rebase was not written *for* this problem.
>
> Anyway, my point was that git-rebase (or at least git-rerere and
> git-reset) are needed if you want to avoid a lot of merge commits.
> And, to relate it back to this thread, git-rebase cannot possibly be
> understood without understanding git internals, and git internals are
> easiest to understand by learning the plumbing.
>
> svn avoids these excess merges by default, albeit because it puts your
> working copy at risk every time you do "svn update".
>
>>  You can skip merges with "git log --no-merges", just in case you didn't
>>  know.
>
> Perhaps this is mostly a user education or documentation issue.  I
> know about --no-merges, but it's unclear that this is really a safe
> thing to use, particularly if some of your merges have conflicts.
> Leaving them out leaves out an important part of history.  Do you use
> this option yourself?
>
> Have fun,
>
> Avery
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>