Milton Soares Filho <milton.soares.filho@xxxxxxxxx> writes:
> On 25 October 2013 15:13, Junio C Hamano <gitster@xxxxxxxxx> wrote:
>> Milton Soares Filho <milton.soares.filho@xxxxxxxxx> writes:
>>
>>> git log --graph --oneline
>>> * a1
>>> * a2
>>> x a3
>>> * b1
>>> * b2
>>> x b3
>>
>> I agree that the problem you are trying to solve is a good thing to
>> tackle, and I also agree that marking a root commit differently from
>> other commits is one way to solve it, but I am not sure if that is
>> the best way. If the stretches of a's and b's in your history are
>> very long, wouldn't it be easier to spot if they are painted in
>> different colours, in addition to or instead of marking the roots
>> differently [*1*], for example?
>
> Thanks for taking your time reviewing this patch, Junio. I didn't really thought
> it would get any attention since multiple root-commits is not a very common
> use-case[1]. However, if most people got excited with git-subtree new
> features as I did, there is a good chance that multiple root-commits are
> going to become a common-place in the near future ;-)
I don't think this is that obscure. I've often thought there should be
some way to distinguish root commits as well. In fact when dealing with
multiple root commits I usually just don't use --oneline and instead use
the full --graph view so I can find root commits by grepping for '^ ' :)
I should also mention that there are lots of situations where you might
see multiple "root commits" not because there are truly multiple commits
with no parent in the repository, but because you're looking at some
subgraph of the history graph -- that is, you have multiple commits in
your display whose parents are purposely excluded. For example, you
might be looking at a revision list like 'C ^A ^B':
master
| .---------------B
| / `-------------.
O< .---`--C
| \ /
| `---------------A
The commits you were looking at would be these ones:
`-------------.
.---`--C
/
So multiple "roots" can appear easily in such cases.
> That said, I completely agree that painting with different colors would be
> a much better fix, however I believe that it can be done in a separate
> changeset by someone that understands better the impact on the rest
> of the system. Personally, changing only the mark is sufficient because:
>
> a) it'll work on terminal types without coloring support and configurations
> whose explicitly disable it
> b) it'll spare myself of running a separate GUI program just
> to spot where each series begin
> c) it won't require any visual design skills from a developer (me)
> without a minimal sense for it :-)
I'm a bit worried that if someone is parsing `git log --graph` output
looking for `*` lines they might suddenly start missing the root commits
that they were previously able to find. I mean, not that anyone should
be doing that, but if we can avoid breaking that, why not do so?
What about just putting an extra blank line after every root commit line
(possibly except the last one)? That should make it plenty easy to see
where the root commits are in --oneline mode. I think it would actually
be easier to spot at a glance than replacing `*` with `x` because it
creates a gap in all columns of the output, rather than only in column
1. Also, this is very subjective but I think it looks kind of ugly to
use "x" :P
By the by, you might want to use the `-v` argument to `git send-email`
so that people reading the list can tell at a glance which patch
versions are newer than which other patch versions.
-Keshav
--
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