Re: A better git log --graph?

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

 



On 01/08/2015 08:52 AM, Kyle J. McKay wrote:
> Since --graph is text-based, this response may not be on-topic hence  
> no cc: to the list.

I see --graph as an important tool to get an overview on how the
development is being done. I don't mind having a graphical tool for the
job, and I was even suggesting if there was a graphviz-based tool that
could do a better job.

I have a couple of projects where we made heavy use of topic branches,
cherrypicks and whatnot. Not the best way to work, but I realized I just
needed a graphical overview of the layout to streamline a bit the
development.

I normally use tig, but the drawn graph, even when turning on bar
drawing, is really poor.

> I assume that you've tried gitk?  It has a graphic viewer for the log,  
> but I also find it difficult to tell what's going on in its graph  
> although it's somewhat better than the --graph graph.  It does not  
> parse --graph output.

I usually never use frontends. The notable exception is "tig" when I
want to get a feeling of the status of several branches and/or "blame"
some files. It haves a lot of typing. That being said, I tried gitk, but
assumed it was also parsing --graph layout.

Now looking again, I notice some differencies, but it doesn't give me a
better picture.

> A better repository to view it on is the scons mirror (http://repo.or.cz/scons 
> ) as it doesn't have nearly the number of branches/merges as Git  
> (direct link is <http://repo.or.cz/git-browser/by-commit.html?r=scons.git 
>  >).

It's better, but still not something I would feel like using.

Github's network "graph" is a bit better in my mind, but it also has his
own share of problems, namely trying his own logic to reduce the height
of the graph recyling the row for multiple branches.

> However, I find its graphs much easier to grok as it draws --first- 
> parent links in a much thicker line style and they stay the same color  
> so it's very easy to see forks, merges and where a fork was re-merged  
> into a main branch.

Yes, this does make a lot of difference when just looking at it. It
immediately becomes much more apparent.

I'm wondering if just turning on the bold attribute in --graph --color
would help improve the output.

> P.S. I'm not 100%, but I think that fossil shows the kinds of graphs  
> you're looking for (see a sample at <http://sqlite.org/src/timeline?y=ci&n=200 
>  >) -- each branch head stays in the same column and non-first-parent  
> links are thinner lines.

Now that's *really* readable for me! Isn't it?
I never used fossil so this is the first time I see it.

The symbols are really well chosen as well.

Can we have something like this in git?
It might entirely be that it breaks for 200 branches, but hell, for
smaller projects it's a boon.

> P.P.S. In any case if this isn't too much off-topic for your original  
> message, feel free to include any parts of the above message in a  
> reply to the list.

It was very helpful, so it's done.


--
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]