Re: Proposed conversion strategy

[Marc Balmer <marc%msys.ch@localhost>]

> Am 04.01.2015 um 22:08 schrieb Reinoud Zandijk <reinoud%NetBSD.org@localhost>:
> 
> 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? ;)
> 
> I'm not claiming the beast can't be tamed, and sure there are helpfull sites
> like http://blog.endpoint.com/2014/05/git-workflows-that-work.html but those
> are more about how to use the branches etc. not on the dangers of accidently
> making a mess of things. See f.e.
> https://wiki.jasig.org/display/UPC/Git+Workflow+for+Vendor+Branching too. So
> the least thing we need to do is a very explicit list of commands with all
> parameters for each action or it'll get a mess.
> 
>> 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 :-/
> 
> 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’.

Maybe you just have to learn how to master your tools before using them…

> 
> With regards,
> Reinoud
>