Re: A better git log --graph?

2015-01-08 Thread Yuri D'Elia
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=cin=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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: A better git log --graph?

2015-01-08 Thread John Szakmeister
On Thu, Jan 8, 2015 at 6:39 AM, Yuri D'Elia wav...@thregr.org wrote:
[snip]
 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.

Try gitk --date-order.  I find it gives me the picture I really want
to see.  I've aliased it to git k in my gitconfig because I find it
very valuable.

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


Re: A better git log --graph?

2015-01-07 Thread Yuri D'Elia
On 01/07/2015 04:47 PM, Johan Herland wrote:
 Have you looked at git show-branch --all?

I didn't. Helpful, but I need to get used to the output.

The first impression after looking at some random repository histories
is that it's still not what I had in mind, though.


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


Re: A better git log --graph?

2015-01-07 Thread Junio C Hamano
Johan Herland jo...@herland.net writes:

 Have you looked at git show-branch --all?

 ...Johan

Yeah, sounds vaguely like it.  Its display certainly is easier to
read while the set of branches you have is minimum and everything
fits in a window; that is exactly why I wrote it back when the
branches I was handling were toy-sized (I am not saying Git itself
was toy-sized---the work-in-progress on top of Git I was doing was).


 On Wed, Jan 7, 2015 at 3:23 PM, Yuri D'Elia wav...@thregr.org wrote:
 Hi everyone,

 git log --graph is hard for me to parse mentally when developing a
 project which has a lot of branches.

 All the tools I've been using seem to just parse log --graph's output,
 and thus are no better at showing history.

 I would love to have a graph mode where each branch is assigned a
 column, and stays there. If my log section shows the history of 3
 branches, column 1 should always refer to master, 2 to the hypothetical
 development branch and 3 to feature.

 Of course the mode will waste more horizontal space, but it would be
 immediately more apparent which branch is merging into which.

 I saw this idea proposed a couple of times in the mailing list, but I
 saw no action behind the proposal. Since I don't have time to work on
 it, has anyone already started some work that he would like to share as
 a starting point? Even just to have a felling if it's worth the effort.

 Does anybody know of another tool to graph the history using something
 that is not based on git log --graph?

 I've seen a couple of graphviz-based ones, but both failed to work out
 of the box for me.

 Thanks a lot for any pointer.

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


Re: A better git log --graph?

2015-01-07 Thread Johan Herland
Have you looked at git show-branch --all?

...Johan

On Wed, Jan 7, 2015 at 3:23 PM, Yuri D'Elia wav...@thregr.org wrote:
 Hi everyone,

 git log --graph is hard for me to parse mentally when developing a
 project which has a lot of branches.

 All the tools I've been using seem to just parse log --graph's output,
 and thus are no better at showing history.

 I would love to have a graph mode where each branch is assigned a
 column, and stays there. If my log section shows the history of 3
 branches, column 1 should always refer to master, 2 to the hypothetical
 development branch and 3 to feature.

 Of course the mode will waste more horizontal space, but it would be
 immediately more apparent which branch is merging into which.

 I saw this idea proposed a couple of times in the mailing list, but I
 saw no action behind the proposal. Since I don't have time to work on
 it, has anyone already started some work that he would like to share as
 a starting point? Even just to have a felling if it's worth the effort.

 Does anybody know of another tool to graph the history using something
 that is not based on git log --graph?

 I've seen a couple of graphviz-based ones, but both failed to work out
 of the box for me.

 Thanks a lot for any pointer.

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



-- 
Johan Herland, jo...@herland.net
www.herland.net
--
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