From: Junio C Hamano <hidden> Date: 2016-06-15 22:45:39
Jakub Narebski [off-list ref] writes:
Second, this patch wouldn't do what you want from it if there are
remotes with '/' in name. I for example use "gsoc2008/gitweb-caching"
for Lea Wiemann repository with her GSoC 2008 work on adding caching
to gitweb.
I think your point is if you also use gsoc2008/gitstats from another
remote repository, these two sets of remote tracking branches will be
shown grouped together. But is it a bad thing? After all, you chose to
use hierarchical names for them, _and_ you chose to use the same toplevel
hierarchy name for them. Doesn't that mean you _wanted_ to have them both
appear in the same GSoC 2008 group?
From: Giuseppe Bilotta <hidden> Date: 2016-06-15 22:45:39
On Sat, Nov 15, 2008 at 1:14 PM, Junio C Hamano [off-list ref] wrote:
Jakub Narebski [off-list ref] writes:
quoted
Second, this patch wouldn't do what you want from it if there are
remotes with '/' in name. I for example use "gsoc2008/gitweb-caching"
for Lea Wiemann repository with her GSoC 2008 work on adding caching
to gitweb.
I think your point is if you also use gsoc2008/gitstats from another
remote repository, these two sets of remote tracking branches will be
shown grouped together. But is it a bad thing? After all, you chose to
use hierarchical names for them, _and_ you chose to use the same toplevel
hierarchy name for them. Doesn't that mean you _wanted_ to have them both
appear in the same GSoC 2008 group?
The problem is that we have gsoc2008/gitweb-caching/branch1
gsoc2008/gitweb-caching/branch2 gsoc2008/gitstats/branch3
gsoc2008/gitstats/branch3, and my current code would show
gitweb-caching/branch1, gitweb-caching/branch2 etc under gsoc2008.
Having branch1 and branch2 under gsoc2008/gitweb-caching, and branch3
and branch4 under gsoc2008/gitstats would be more logical,
remote-wise, but it would of course lose the coupling between all the
gsoc2008 remotes.
If deep nesting is not a problem, I can code something to have
gitweb-caching and gistats under gsoc2008, and the respective branches
within.
--
Giuseppe "Oblomov" Bilotta
From: Jakub Narebski <hidden> Date: 2016-06-15 22:45:39
Giuseppe Bilotta wrote:
On Sat, Nov 15, 2008 at 1:14 PM, Junio C Hamano [off-list ref] wrote:
quoted
Jakub Narebski [off-list ref] writes:
quoted
Second, this patch wouldn't do what you want from it if there are
remotes with '/' in name. I for example use "gsoc2008/gitweb-caching"
for Lea Wiemann repository with her GSoC 2008 work on adding caching
to gitweb.
I think your point is if you also use gsoc2008/gitstats from another
remote repository, these two sets of remote tracking branches will be
shown grouped together. But is it a bad thing? After all, you chose to
use hierarchical names for them, _and_ you chose to use the same toplevel
hierarchy name for them. Doesn't that mean you _wanted_ to have them both
appear in the same GSoC 2008 group?
Actually I _don't_ have 'gsoc2008/gitstats' remote, nor gsoc2008/gitstats/*
remote-tracking branches. 'gsoc2008/gitweb-caching' is the only remote
with hierarchical name. But I digress...
The problem is that we have gsoc2008/gitweb-caching/branch1
gsoc2008/gitweb-caching/branch2 gsoc2008/gitstats/branch3
gsoc2008/gitstats/branch3, and my current code would show
gitweb-caching/branch1, gitweb-caching/branch2 etc under gsoc2008.
I'm not sure if it wouldn't be simpler solution to just code _sorting_
heads-like view ('heads', 'remotes', 'tags') by ref name, or by age.
It would be best to have both, even...
Even without dividing 'remotes' view into subcategories (and
subsubcategories) you would have natural grouping:
gsoc2008/gitweb-caching/branch1
gsoc2008/gitweb-caching/branch2
gsoc2008/gitstats/branch3
gsoc2008/gitstats/branch4
if sorted by branch (ref) name, and not (possibly)
gsoc2008/gitweb-caching/branch1
gsoc2008/gitstats/branch4
origin/todo
gsoc2008/gitweb-caching/branch2
gsoc2008/gitstats/branch3
when sorted by age (hmmm... committerdate or authordate?)
Having branch1 and branch2 under gsoc2008/gitweb-caching, and branch3
and branch4 under gsoc2008/gitstats would be more logical,
remote-wise, but it would of course lose the coupling between all the
gsoc2008 remotes.
If deep nesting is not a problem, I can code something to have
gitweb-caching and gistats under gsoc2008, and the respective branches
within.
The problems with nesting is those pesky remotes with only single
tracked branch to them; they are I think quote common... well, unless
you do one-shot pull, directly into local branch.
All that said, splitting 'remotes' section is difficult; using first
dirname as section is probably easiest, and good enough in most cases.
That is why I think this part should be put into separate series, to
not hinder rest of patches.
--
Jakub Narebski
Poland
From: Giuseppe Bilotta <hidden> Date: 2016-06-15 22:45:39
On Sun, Nov 16, 2008 at 1:12 PM, Jakub Narebski [off-list ref] wrote:
Giuseppe Bilotta wrote:
quoted
The problem is that we have gsoc2008/gitweb-caching/branch1
gsoc2008/gitweb-caching/branch2 gsoc2008/gitstats/branch3
gsoc2008/gitstats/branch3, and my current code would show
gitweb-caching/branch1, gitweb-caching/branch2 etc under gsoc2008.
I'm not sure if it wouldn't be simpler solution to just code _sorting_
heads-like view ('heads', 'remotes', 'tags') by ref name, or by age.
It would be best to have both, even...
Even without dividing 'remotes' view into subcategories (and
subsubcategories) you would have natural grouping:
gsoc2008/gitweb-caching/branch1
gsoc2008/gitweb-caching/branch2
gsoc2008/gitstats/branch3
gsoc2008/gitstats/branch4
if sorted by branch (ref) name, and not (possibly)
gsoc2008/gitweb-caching/branch1
gsoc2008/gitstats/branch4
origin/todo
gsoc2008/gitweb-caching/branch2
gsoc2008/gitstats/branch3
when sorted by age (hmmm... committerdate or authordate?)
Sorting is another interesting feature to look into, yes, but as you
mention it's a separate feature that would complement grouping.
quoted
Having branch1 and branch2 under gsoc2008/gitweb-caching, and branch3
and branch4 under gsoc2008/gitstats would be more logical,
remote-wise, but it would of course lose the coupling between all the
gsoc2008 remotes.
If deep nesting is not a problem, I can code something to have
gitweb-caching and gistats under gsoc2008, and the respective branches
within.
The problems with nesting is those pesky remotes with only single
tracked branch to them; they are I think quote common... well, unless
you do one-shot pull, directly into local branch.
My idea with this would be to only create a group if it has at least N
1 (probably N=2) entries.
All that said, splitting 'remotes' section is difficult; using first
dirname as section is probably easiest, and good enough in most cases.
That is why I think this part should be put into separate series, to
not hinder rest of patches.
Yes, I will resend the 'remote_heads' feature as a new (reduced)
patchset, then add (separate patchset) grouping for ref lists, and
then add (yet another patchset) detached head.
--
Giuseppe "Oblomov" Bilotta
From: Jakub Narebski <hidden> Date: 2016-06-15 22:45:39
Giuseppe Bilotta wrote:
On Sun, Nov 16, 2008 at 1:12 PM, Jakub Narebski [off-list ref] wrote:
quoted
The problems with nesting is those pesky remotes with only single
tracked branch to them; they are I think quote common... well, unless
you do one-shot pull, directly into local branch.
My idea with this would be to only create a group if it has at least
N > 1 (probably N=2) entries.
A bit of complication is that you would have then series of
'uncategorized' (not in any subsection) entries / remote-tracking
branches.
quoted
All that said, splitting 'remotes' section is difficult; using first
dirname as section is probably easiest, and good enough in most cases.
That is why I think this part should be put into separate series, to
not hinder rest of patches.
Yes, I will resend the 'remote_heads' feature as a new (reduced)
patchset, then add (separate patchset) grouping for ref lists, and
then add (yet another patchset) detached head.
That is I think a good idea.
P.S. I think that sending this patch series for review, even if it was
not perfect was a very good idea... well, perhaps some patches could
be marked as RFC.
It is hard work to prepare good patches, then wait for review, then
wait a bit that there is no further review, working on the patches,
resend and wait for review, or for Ack and merge-in... Keep up good
work.
--
Jakub Narebski
Poland
From: Giuseppe Bilotta <hidden> Date: 2016-06-15 22:45:39
On Sun, Nov 16, 2008 at 3:21 PM, Jakub Narebski [off-list ref] wrote:
Giuseppe Bilotta wrote:
quoted
On Sun, Nov 16, 2008 at 1:12 PM, Jakub Narebski [off-list ref] wrote:
quoted
quoted
The problems with nesting is those pesky remotes with only single
tracked branch to them; they are I think quote common... well, unless
you do one-shot pull, directly into local branch.
My idea with this would be to only create a group if it has at least
N > 1 (probably N=2) entries.
A bit of complication is that you would have then series of
'uncategorized' (not in any subsection) entries / remote-tracking
branches.
We'll put them in their own group 8-)
quoted
Yes, I will resend the 'remote_heads' feature as a new (reduced)
patchset, then add (separate patchset) grouping for ref lists, and
then add (yet another patchset) detached head.
That is I think a good idea.
P.S. I think that sending this patch series for review, even if it was
not perfect was a very good idea... well, perhaps some patches could
be marked as RFC.
That's what they were when I first sent them last year 8-)
It is hard work to prepare good patches, then wait for review, then
wait a bit that there is no further review, working on the patches,
resend and wait for review, or for Ack and merge-in... Keep up good
work.