On Sat, Jun 4, 2016 at 11:30 PM, Junio C Hamano wrote:
>> The patch does not do fancy stuff like this yet, but it can because
>> lines exceeding terminal width is already excluded from column width
>> calculation. So far the output looks good on my terminal (192 chars,
>> can't overflow or refname
Duy Nguyen writes:
>> Peff suggested that a two-pass approach might not be too bad, but had
>> problems when he tried it with extra-long refs. Maybe those problems
>> could be dealt with, and we could get a simple, aligned output?
>
> The good thing about 2/3 is we can customize the output eas
On Fri, Jun 3, 2016 at 4:52 PM, Duy Nguyen wrote:
> A placeholder can still keep the variable part at the end, e.g.
> "refs/$/head -> pull/123"
I somehow like this very much.
A more typical "their topic went to remote-tracking namespace under 'origin'",
aka
topic -> origin/topic
aka
{
On Sat, Jun 4, 2016 at 3:53 AM, Junio C Hamano wrote:
> By punting on the effort to find a readable format that does not
> repeat the same info twice, we are sending a signal to the users
> that they cannot use a meaningful sentence as the name of a branch
> name; they need to stay within a relati
On Fri, Jun 03, 2016 at 10:53:27AM -0400, Marc Branchaud wrote:
> On 2016-06-03 07:08 AM, Nguyễn Thái Ngọc Duy wrote:
> > When there are lots of ref updates, each has different name length, this
> > will make it easier to look because the variable part is at the end.
>
> s/look/read/
>
> For the
On Sat, Jun 4, 2016 at 12:06 AM, Jeff King wrote:
> On Fri, Jun 03, 2016 at 06:08:43PM +0700, Nguyễn Thái Ngọc Duy wrote:
>
>> When there are lots of ref updates, each has different name length, this
>> will make it easier to look because the variable part is at the end.
>
> Is it worth handling m
On Sat, Jun 4, 2016 at 12:00 AM, Junio C Hamano wrote:
>
> Nguyễn Thái Ngọc Duy writes:
>
> > +static int common_suffix_length(const char *a, const char *b)
> > +{
> > + const char *pa = a + strlen(a);
> > + const char *pb = b + strlen(b);
> > + int count = 0;
> > +
> > + while (
Marc Branchaud writes:
>>> * [new branch] 2nd-index -> pclouds/2nd-index
>>> * [new branch] some-kind-of-long-ref-name
>>> -> pclouds/some-kind-of-long-ref-name
>>> * [new branch] 3nd-index -> pclouds/3nd-index
> ...
> I think aligning it with
On 2016-06-03 01:04 PM, Junio C Hamano wrote:
Marc Branchaud writes:
What if we detect when the full line exceeds the terminal width, and
insert a newline after the remote ref and indent the -> to the same
offset as its surrounding lines, like this:
* [new branch] 2nd-index -> pclouds
On Fri, Jun 03, 2016 at 06:08:43PM +0700, Nguyễn Thái Ngọc Duy wrote:
> When there are lots of ref updates, each has different name length, this
> will make it easier to look because the variable part is at the end.
Is it worth handling more complicated cases, where there is a similar
"middle", b
Marc Branchaud writes:
> What if we detect when the full line exceeds the terminal width, and
> insert a newline after the remote ref and indent the -> to the same
> offset as its surrounding lines, like this:
>
> * [new branch] 2nd-index -> pclouds/2nd-index
> * [new branch] some-ki
Nguyễn Thái Ngọc Duy writes:
> +static int common_suffix_length(const char *a, const char *b)
> +{
> + const char *pa = a + strlen(a);
> + const char *pb = b + strlen(b);
> + int count = 0;
> +
> + while (pa > a && pb > b && pa[-1] == pb[-1]) {
> + pa--;
> +
On 2016-06-03 07:08 AM, Nguyễn Thái Ngọc Duy wrote:
When there are lots of ref updates, each has different name length, this
will make it easier to look because the variable part is at the end.
s/look/read/
For the record, I prefer the earlier stair-step format to this
{xxx -> yyy}/foo
When there are lots of ref updates, each has different name length, this
will make it easier to look because the variable part is at the end.
---
Documentation/git-fetch.txt | 7 +++
builtin/fetch.c | 37 -
t/t5510-fetch.sh| 4 ++--
14 matches
Mail list logo
