tech-repository archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Proposed conversion strategy

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 <> 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 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. 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,

Attachment: pgpP0Z51orhRI.pgp
Description: PGP signature

Home | Main Index | Thread Index | Old Index