On Mon, 26 May 2008, Joshua Haberman wrote:
>
> I'm a casual Git user. One thing that's been troubling me about Git is that
> when I look at Git's own Git repository, the revision history is not at all
> easy to understand. I like to view my own Git repositories with:
>
> $ gitk --all --date-order
I would seriously suggest avoiding "--date-order" unless you have some
deep reason to see how the commits on different development paths relate
to each other date-wise - something you should normally not have.
The thing is, --date-order strings out and mixes up the commits on the
same development chain, and by doing so it makes the different chains of
development much harder to see. It also ends up showing the development in
a more "parallel" way, which in turn makes the view even harder to read.
So I would suggest not using --date-order by default. It doesn't add
anything to any normal flow, and it makes the big picture harder to see.
The only time you really want --date-order (or "-d", which is shorthand
for it for just gitk) is really
- when the big picture is really really simple, and you actually want to
see more detail because the big picture is too trivial to even be
interesting otherwise.
(In other words: --date-order is fine for really simple development
where there is only ever just a couple of branches or where you have
pruned away so much of the history that the remaining part is simple)
- when you want to debug "git rev-list" behaviour itself, since the date
order actually matters for how git traverses the commit chains.
The second case is something that I suspect nobody but me and a few other
people have ever done. I found it very useful together with --show-all
when I was debugging the revision walker (see commits
3131b713013f06285cad3ffdcc61f417ac4ba158
7d004199d134c9d465e013064f72dbc04507f6c0
where the first implements --show-all, and the second one is the end
result of my debugging).
In other words: never start out with "-d" or "--date-order" by default.
Only if you have some reason to then think that the view is too simple or
you need to drill down into the commit relationships should you use it.
> 1. what do you all do to get a high-level view of what's going on with Git
> development? do you use gitk? if so, what options?
I use "gitk" almost every time when I pull from anybody in the kernel. I
tend to do it with git itself, when I update from Junio. The most common
arguments I use is
gitk ORIG_HEAD..
or
gitk @{12.hours.ago}..
where the latter in particular is very nice to see an overview of "ok,
what did I pull today".
And I basically *never* use --date-order, nor do I often look at more than
one single branch.
The one special case is when merging, and there are conflicts. In that
case, I often look at two branches, and I often do
gitk MERGE_HEAD... <filenames>
to see the symmetric difference (actually, I usually just do "gitk
--merge" which is just shorthand for the above). And in that case, I do
occasionally add a "-d", because that shows what the relative timing were
for the commits, which is sometimes interesting information (ie if there
are clashes, which commit is the more recently committed one can actually
be somewhat relevant - although it's rare).
So in that case I look at two branches (the one I'm on, and the one I'm
merging), and the "..." format means that I ignore everything that is
common to them.
> 2. as a project, why don't you rebase when merging long-running branches into
> master?
For the kernel, there's been a lot of discussion about why I prefer people
to rebase vs merge (or often - *avoiding* merges entirely), see the kernel
mailing list, and search for merging. There was a thread (subject:
"[alsa-devel] HG -> GIT migration") about a week ago where I tried to
explain my opinions about about some of this.
Linus
--
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
