Re: Proposed conversion strategy

[Justin Cormack <justin%specialbusservice.com@localhost>]

On Sun, Jan 4, 2015 at 9:08 PM, Reinoud Zandijk <reinoud%netbsd.org@localhost> wrote:
> Hi Justin,
>
> On Sun, Jan 04, 2015 at 06:07:00PM +0000, Justin Cormack wrote:
>> On Sun, Jan 4, 2015 at 3:31 PM, Reinoud Zandijk <reinoud%netbsd.org@localhost> wrote:
>> It is not really that helpful giving vague reasons against git, like "its
>> far too easy to screw up a git repo", and "half-baken support for
>> sub-repos". The first has been covered many times in the thread, while the
>
> 'have to admit i haven't completely read all the messages, but i've
> encountered it a few times and it's a PITA. For me it was all to easy to screw
> up a repository simply by having patches around and executing a `git pull' if
> only to ensure noone else had published patches that could make my patches
> fail. At times it goes all well but on other occasions i had to check out a
> new copy, create the diffs of the files i had and then repatch them. It might
> be that there are guard switches against such situations but that makes we
> wonder why they aren't the default. People WILL make mistakes and can cause a
> lot of ugly resolving. Lets hope we can get some kind of sane 1:1 mappings.
> Scriping anyone? ;)

for really simple things just stash, pull, unstash, but normally
branch, rebase, merge. The migration guide is obviously going to have
to go through these workflows.

>> second is only constructive in terms of a conversation about how sub-repos
>> are going to be handled in the context of the NetBSD tree.  You may not like
>> it but git is the most serious contender at this point and half baked
>> dismissals are not helpful, they need to be substantive, and the
>> alternatives need to be significantly better.
>
> Sub-brances are used in say the riscv repository to point to specific releases
> of the various tools needed. Nice at first glance but impossible to do a `git
> diff' and get the entire tree. We could avoid these by demananding such things
> to be handled as vendor branches (which they really are) but IMHO its silly
> that git explicitly allows such subrepo's but has only minimal support for
> them. If the marker is changed you can't just `git update' it since then it
> goes to the head of that branch and when you have patches in those trees it
> really gets ugly :-/

Yes that is clearly the type of situation we need to examine how it
will be done. The method being used by riscv sounds non-ideal, but no
doubt it is tuned to their situation, which is not ours.

> Maybe i'm yapping the wrong tree here but the fact that one can screw up so
> easily doesn't give me much confidence in git, and that is what also matters,
> maybe more that just plain `ok, this works'.

You are. As I said this "one can screw up" stuff is unhelpful. Make a
strong case for an alternative - currently the cases seem weak to me.

Justin