> On Dec 3, 2019, at 11:10 PM, Richard Earnshaw (lists)
> <richard.earns...@arm.com> wrote:
>
> On 03/12/2019 18:56, Segher Boessenkool wrote:
>> On Tue, Dec 03, 2019 at 09:16:43AM +0000, Richard Earnshaw (lists) wrote:
>>> On 03/12/2019 00:56, Segher Boessenkool wrote:
>>>> That sounds simpler than it is... After using this for a while you'll
>>>> get names that you want to delete, but that name *already* is in
>>>> /refs/deleted. So what will you name it then? People will still need
>>>> to be able to find it.
>>>>
>>>> But we could make an "old-svn" hierarchy or similar that just has
>>>> everything svn has now (and will never change, so it will never cause
>>>> conflicts).
>>>
>>> Well that's true of /any/ renaming scheme for dead branches.
>>
>> No, it is not. If you have a simple "deleted" hierarchy, to which you
>> add things, you will get conflicts. If you have one just for things
>> imported from SVN, it will never change (since SVN is set in stone after
>> the conversion), and there will not be conflicts.
>
> But you've still got the ongoing branch death issue to deal with, and
> that was my point. If you want to keep them, and you don't want them
> polluting the working namespace, you have to do *some* renaming of them.
>
>
>>
>>> There's
>>> nothing special about this one. On the other hand, there's nothing that
>>> says that the renamed branch has to have exactly the same name as the
>>> live one: it's a rename after all.
>>
>> Renamed tags and branches are *useless*, we could just as well delete
>> them completely, if people can no longer find them.
>
> They can be found, it's just that they don't appear in the standard list
> since they aren't pulled by default from the upstream repository. It's
> no different from the situation where if you clone from a clone, the
> things in the local repository that are in refs/remotes are not pulled
> into the secondary clone, unless you add an explicit fetch entry to your
> remote's configuration, something like
>
> [origin]
> ...
> fetch = refs/deleted/*:refs/remotes/origin/deleted/*
>
>
> So they're not useless as you put it. They're out of the way, but can
> be recovered if there's need. What's more, if the branch died without
> being merged, the blobs for it will stay *on the server* and not waste
> users' time and bandwidth by being repeatedly pulled.
>
>>
>>> You only have to run 'svn ls' on the current gcc branches directory in
>>> SVN to realize just what a mess our current naming scheme it, so I'd
>>> also suggest that we do some general reorganization of the other
>>> branches/tags we have, especially if we have a /refs/svn namespace after
>>> conversion:
>>>
>>> a) Only live development branches get moved to the normal git namespace,
>>> but see d) & e) below
>>
>> Yes, I called it "old-svn" for a reason. One idea is to move *everything*
>> there, and let people make a copy to the "live" stuff if they want it.
>> And we can pre-populate the things we know are still used, of course, and
>> all release branches (closed or not), that kind of thing. But we could
>> just shovel all that is in SVN into some nice tidy subdir, that normal
>> people never have to look at again :-)
>>
>>> b) vendor branches should move to something like
>>> refs/vendors/<vendor>/{heads/tags} (these won't be pulled by default by
>>> a normal clone, you'd have to add an explicit map request to see them.
>>> c) user branches should only be in something line
>>> refs/users/<userid>/{heads/tags} (similar to above)
>>
>> Yup.
>
> And see above for the type of fetch spec you'd need to pull and see them
> locally, with the structure I suggest, you can even write
>
> fetch = refs/vendors/ibm/heads/*:refs/remotes/origin/ibm/*
>
> and only the ibm sub-part of that hierarchy would be fetched.
IMO, it is valuable to have user and vendor branches under default refs/heads/*
hierarchy. I find it useful to see that IBM's or Arm's branches were updated
since I last pulled from upstream. The fact that branches were updated means
that there are development I may want to look at or keep note of.
I feel strongly about vendor branches, and much less strongly about user
branches. Individual users can be less careful in following best git
practices, can commit random stuff and rewrite history of their branches.
Therefore, it may make for a smoother git experience to put user branches out
of sight. Vendors, otoh, tend to keep their branches very clean.
>
>>
>>> d) releases should go into refs/{heads/tags}/releases (makes it clearer
>>> to casual users of the repo that these are 'official')
>>
>> What are releases? Release branches?
>
> branches in the heads space, tags in the tags space.
>
>>
>> It would be very inconvenient to not have the recent releases immediately
>> accessible, fwiw, but those could be just a copy. And then delete that
>> one after a branch is closed?
>>
>>> e) other general development branches in refs/{heads/tags}/devt
>>
>> What does this mean? "other", "general"?
>
> Anything that's not vendor/user specific and not a release - a topic
> branch most likely
>>
>>> That probably means the top-level heads/tags spaces are empty; but I
>>> have no problem with that.
>>
>> It is good when people get the most often used things immediately.
>
> git branch -a will show anything in refs/remotes, and the default pull
> spec is to pull refs/heads/* (and anything under that), so all release
> and topic branches would be pulled by default, but not anything else.
>
> According to the git fetch manual page, tags are fetched if an object
> they point to is fetched. I presume this only applies to tags under
> refs/tags. But this is getting into details of git that I've not used
> before. I need to experiment a bit more here.
>
> R.
>
> PS. Just seen https://git-scm.com/docs/gitnamespaces, that might be
> exactly what we want for users, vendors and legacy stuff. I'll
> investigate some more...
--
Maxim Kuvyrkov
https://www.linaro.org
