public inbox for git@vger.kernel.org 
 help / color / mirror / Atom feed
From: Matthieu Moy <Matthieu.Moy@grenoble-inp•fr>
To: Junio C Hamano <gitster@pobox•com>
Cc: Karthik Nayak <karthik.188@gmail•com>, Git <git@vger•kernel.org>,
	Christian Couder <christian.couder@gmail•com>
Subject: Re: [PATCH v4 3/8] branch: roll show_detached HEAD into regular ref_list
Date: Thu, 17 Sep 2015 17:43:05 +0200	[thread overview]
Message-ID: <vpqio79oxva.fsf@anie.imag.fr> (raw)
In-Reply-To: <xmqqh9mtkrg0.fsf@gitster.mtv.corp.google.com> (Junio C. Hamano's message of "Thu, 17 Sep 2015 08:15:27 -0700")

Junio C Hamano <gitster@pobox•com> writes:

> Matthieu Moy <Matthieu.Moy@grenoble-inp•fr> writes:
>
>> Karthik Nayak <karthik.188@gmail•com> writes:
>>
>>> So either we could introduce a new atom for sorting something like
>>> `branch_sort` which uses the FILTER_REFS_(DETACHED_HEAD | BRANCHES |
>>> REMOTES)
>>
>> I don't think you need a new atom. You can just change the sorting
>> function to consider that detached HEAD is always first, and when
>> comparing two non-detached-HEAD branches, use the atom supplied by the
>> user.
>>
>> That would mean the detached HEAD would be displayed first regardless of
>> --sort (which is the case right now).
>
> I am a bit fuzzy about this.  I do not understand why Karthik thinks
> a new atom is necessary in the first place, and I do agree that the
> best way to go would be to teach the sort function to do "the right
> thing", but I am not sure why it has to be "regardless of --sort".

I think Karthik meant that branch could default to
"--sort=my_magic_atom_that_does_the_right_thing". In this case, the
default would be to show HEAD first, but using "--sort" explicitly would
change the order and interleave HEAD within other branches.

IOW, we have:

struct ref_sorting *ref_default_sorting(void)
{
	static const char cstr_name[] = "refname";

	struct ref_sorting *sorting = xcalloc(1, sizeof(*sorting));

	sorting->next = NULL;
	sorting->atom = parse_ref_filter_atom(cstr_name, cstr_name + strlen(cstr_name));
	return sorting;
}

and we could

-	static const char cstr_name[] = "refname";
+	static const char cstr_name[] = "some_magic_atom";

But you convinced me that this is not a good idea.

> When the user does give a custom --sort criteria, the logic in
> default_sort()

The logic itself is not in ref_default_sorting() (I guess this is what
you meant by "default_sort"): this function just builds a struct
ref_sorting that is later used by the more general cmp_ref_sorting.

But that's still workable: struct ref_sorting could contain a flag
"head_first" that would be set by ref_default_sorting() and only it, and
then read by cmp_ref_sorting.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

  reply	other threads:[~2015-09-17 15:43 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-13  7:23 [PATCH v4 0/8] port the filtering part of branch.c to use ref-filter APIs Karthik Nayak
2015-09-13  7:23 ` [PATCH v4 1/8] branch: refactor width computation Karthik Nayak
2015-09-13 11:51   ` Matthieu Moy
2015-09-13 12:23     ` Karthik Nayak
2015-09-13 12:33       ` Matthieu Moy
2015-09-13  7:23 ` [PATCH v4 2/8] branch: bump get_head_description() to the top Karthik Nayak
2015-09-13  7:23 ` [PATCH v4 3/8] branch: roll show_detached HEAD into regular ref_list Karthik Nayak
2015-09-13 12:12   ` Matthieu Moy
2015-09-13 13:24     ` Karthik Nayak
2015-09-13 16:46     ` Eric Sunshine
2015-09-13 18:31       ` Eric Sunshine
2015-09-14 14:48         ` Karthik Nayak
2015-09-14 14:54           ` Matthieu Moy
2015-09-14 19:35   ` Junio C Hamano
2015-09-16  6:23     ` Karthik Nayak
2015-09-17  9:47       ` Karthik Nayak
2015-09-17 14:18         ` Matthieu Moy
2015-09-17 15:15           ` Junio C Hamano
2015-09-17 15:43             ` Matthieu Moy [this message]
2015-09-17 16:49               ` Junio C Hamano
2015-09-17 17:08                 ` Matthieu Moy
2015-09-17 17:21                   ` Junio C Hamano
2015-09-17 18:25                   ` Karthik Nayak
2015-09-13  7:23 ` [PATCH v4 4/8] branch: move 'current' check down to the presentation layer Karthik Nayak
2015-09-13 12:15   ` Matthieu Moy
2015-09-13 13:22     ` Karthik Nayak
2015-09-13 15:35   ` Karthik Nayak
2015-09-13  7:23 ` [PATCH v4 5/8] branch: drop non-commit error reporting Karthik Nayak
2015-09-14 19:49   ` Junio C Hamano
2015-09-16  6:04     ` Karthik Nayak
2015-09-13  7:23 ` [PATCH v4 6/8] branch.c: use 'ref-filter' data structures Karthik Nayak
2015-09-13 12:26   ` Matthieu Moy
2015-09-13 13:19     ` Karthik Nayak
2015-09-13 17:49       ` Matthieu Moy
2015-09-13  7:23 ` Karthik Nayak
2015-09-13  7:32   ` Karthik Nayak
2015-09-13  7:23 ` [PATCH v4 8/8] branch: add '--points-at' option Karthik Nayak
2015-09-13  7:29 ` [PATCH v4 7/8] branch.c: use 'ref-filter' APIs Karthik Nayak

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

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

  git send-email \
    --in-reply-to=vpqio79oxva.fsf@anie.imag.fr \
    --to=matthieu.moy@grenoble-inp$(echo .)fr \
    --cc=christian.couder@gmail$(echo .)com \
    --cc=git@vger$(echo .)kernel.org \
    --cc=gitster@pobox$(echo .)com \
    --cc=karthik.188@gmail$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox