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'. With regards, Reinoud
Attachment:
pgpP0Z51orhRI.pgp
Description: PGP signature