List for cgit developers and users
 help / color / mirror / Atom feed
From: petr.vorel at gmail.com (Petr Vorel)
Subject: [PATCH v5 1/1] ui-shared: allow to split the repository link
Date: Sun, 27 Nov 2016 07:51:30 +0100	[thread overview]
Message-ID: <20161127065129.7ppu2jcrtrnrw2jy@x230> (raw)
In-Reply-To: <20161124191400.GE24063@john.keeping.me.uk>

Hi Jason, John,

thank you both for your reviews!

> On Thu, Nov 24, 2016 at 06:42:32PM +0100, Jason A. Donenfeld wrote:
> > On Thu, Nov 24, 2016 at 6:32 PM, Petr Vorel <petr.vorel at gmail.com> wrote:
> > > Any idea how to cope with it? I thought to use this feature only if repo.name and repo.url
> > > are the same.

> > One way might be to always use the `name` part and not the `url`, but
> > to ensure that any clickable links are actually useful. Namely, ensure
> > that any clickable links go to subtrees that contain other
> > repositories. This would also help collapse single-child directories,
> > like what we now do in tree view.

> > @John - any opinions on this?

> I originally suggested using this only when repo.name and repo.url are
> the same and I still can't think of a good behaviour for when they
> differ.

> I guess if there is a common path prefix between repo.name and repo.url
> then we could implement this behaviour for that, but that feels like
> we're getting too far into edge cases.

> Basically, this feels like a good initial implementation that punts the
> complexity for us to deal with when/if someone has a use case.  It also
> has the advantage of being easy to explain in documentation.
Any conclusion on this? Keep it the same as it is in v5 or make items of common prefix
clickable? I'd personally prefer the first variant as users might get confused with the
second variant.


> > >> I realize that John asked for a config variable in v3. But I do wonder
> > >> if this really is so necessary. In what case would somebody _not_ want
> > >> this behavior?
> > > I don't think so, I'd also remove the config variable.

> > I'll defer to John, then, to defend having a config variable.

> It looks like my original argument was essentially "some people might
> object to the change in behaviour", so I have no problem with just
> changing it and adding a config variable later if people scream.
Right, I'll drop it in v6.


Kind regards,
Petr


      reply	other threads:[~2016-11-27  6:51 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-12 15:44 petr.vorel
2016-06-06 11:20 ` petr.vorel
2016-08-29 23:11 ` petr.vorel
2016-08-30  2:55   ` Jason
2016-11-23  4:15 ` Jason
2016-11-24 17:32   ` petr.vorel
2016-11-24 17:42     ` Jason
2016-11-24 19:14       ` john
2016-11-27  6:51         ` petr.vorel [this message]

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=20161127065129.7ppu2jcrtrnrw2jy@x230 \
    --to=cgit@lists.zx2c4.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.
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 NNTP newsgroup(s).