git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Duy Nguyen <pclouds@gmail.com>
To: Ramkumar Ramachandra <artagnon@gmail.com>
Cc: Git List <git@vger.kernel.org>, Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH v2 0/3] Towards a useable git-branch
Date: Tue, 4 Jun 2013 20:11:25 +0700	[thread overview]
Message-ID: <CACsJy8BpeP0y+wFbNJioR-TwyV1P77moz0x2ZDXzqz2ZKWTahg@mail.gmail.com> (raw)
In-Reply-To: <CALkWK0kGrCDhDFL5THBTTVARTnfY2xucbJaGJGKj8OYv3Q1pBA@mail.gmail.com>

On Tue, Jun 4, 2013 at 7:52 PM, Ramkumar Ramachandra <artagnon@gmail.com> wrote:
> Duy Nguyen wrote:
>> Nobody should ever parse these output
>> with scripts. The color can be generated from color.branch.*.
>
> How do we implement color.branch.(current|local|remote|plain)?  In the
> current code, we take a crude approach by hand-constructing argc, argv
> strings and passing it to cmd_for_each_ref().  There are no
> conditionals in the format syntax (and introducing one is probably not
> a good idea either): so, I'm guessing these configuration variables
> have to be read by for-each-ref?

Maybe. I don't really like the idea that for-each-ref reads _branch_
config. We could introduce the same set of keys but in
color.for-each-ref namespace. %C(auto) will take care of the logic and
choose the correct color key. When we replace branch's listing code
with for-each-ref, I think we could somehow override for-each-ref keys
with branch ones in-core. Too hacky?

>> A bigger
>> problem is show_detached(), --[no-]merged, --with and --contains. We
>> need to move some of those code over to for-each-ref.
>
> I saw that you fixed this.

Nope. --[no-]merged and --contains seem easy. show_detached is still
WIP, mostly because detached HEAD may or may not show when you provide
a pattern to git-branch (e.g. git branch --list 'foo*') and because
HEAD is always the first item, regardless of sorting order.
get_head_description also seems more porcelain-ish than a plumbing
feature..

>> Another problem
>> is the new "branch -v" seems to less responsive than old "branch -v"
>> because (I think) of sorting, even if we don't need it.
>
> Does your track-responsiveness patch fix this?

Yes.

>> I checked out
>> your branch, made some more updates and pushed out to my
>> for-each-ref-pretty again. Changes are:
>
> *pants* Sorry, I'm finding it hard to keep up.

Sorry that branch was in a better shape the day I sent my previous
email. Then I kind of used it as a playground with --[no-]merged,
--contains and stuff :-P
--
Duy

  reply	other threads:[~2013-06-04 13:12 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-24 14:19 [PATCH v2 0/3] Towards a useable git-branch Ramkumar Ramachandra
2013-05-24 14:19 ` [PATCH 1/3] for-each-ref: introduce %C(...) for color Ramkumar Ramachandra
2013-05-24 20:56   ` Antoine Pelisse
2013-05-25 11:50     ` Ramkumar Ramachandra
2013-05-25 12:20       ` John Keeping
2013-05-25 12:54         ` Ramkumar Ramachandra
2013-05-25 12:35       ` Antoine Pelisse
2013-05-24 23:41   ` David Aguilar
2013-05-25 11:51     ` Ramkumar Ramachandra
2013-05-25  6:29   ` Eric Sunshine
2013-05-24 14:19 ` [PATCH 2/3] for-each-ref: introduce %(HEAD) marker Ramkumar Ramachandra
2013-05-24 20:28   ` Philip Oakley
2013-05-24 14:19 ` [PATCH 3/3] for-each-ref: introduce %(upstream:track[short]) Ramkumar Ramachandra
2013-05-24 15:27 ` [PATCH v2 0/3] Towards a useable git-branch Duy Nguyen
2013-05-24 15:58   ` Ramkumar Ramachandra
2013-05-24 17:52   ` Junio C Hamano
2013-05-24 18:01     ` Ramkumar Ramachandra
2013-05-24 18:08     ` Ramkumar Ramachandra
2013-05-24 22:51 ` Duy Nguyen
2013-05-25  6:26   ` Duy Nguyen
2013-05-25 11:35     ` Duy Nguyen
2013-05-25 11:48       ` Ramkumar Ramachandra
2013-05-28 14:01         ` Ramkumar Ramachandra
2013-05-28 14:24           ` Ramkumar Ramachandra
2013-05-30  4:19             ` Duy Nguyen
2013-06-04 12:52               ` Ramkumar Ramachandra
2013-06-04 13:11                 ` Duy Nguyen [this message]
2013-05-28 14:28           ` Ramkumar Ramachandra
2013-05-29  3:04             ` Duy Nguyen
2013-05-29 21:12               ` Ramkumar Ramachandra
2013-05-29  3:22           ` Duy Nguyen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CACsJy8BpeP0y+wFbNJioR-TwyV1P77moz0x2ZDXzqz2ZKWTahg@mail.gmail.com \
    --to=pclouds@gmail.com \
    --cc=artagnon@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).