On 7/16/08, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> "Avery Pennarun" <apenwarr@xxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
