[Top][All Lists]

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

Re: Please merge the random translator into the Hurd repository

From: Justus Winter
Subject: Re: Please merge the random translator into the Hurd repository
Date: Thu, 12 Jun 2014 09:38:48 +0200
User-agent: alot/0.3.4

Quoting Ivan Shmakov (2014-06-11 18:13:22)
> >>>>> Thomas Schwinge <thomas@codesourcery.com> writes:
> >>>>> On Mon, 09 Jun 2014 12:17:31 +0200, Justus Winter wrote:
> […]
>  >> I prepared this for your consideration here:
>  >> 
> http://darnassus.sceen.net/gitweb/teythoon/hurd.git/shortlog/refs/heads/merge-random
>  > That looks reasonable.  I would have done the subdirectory move, the
>  > merge itself, and the Hurd Makefile:prog-subdirs change as one big
>  > (merge) commit.  Oh, and also (fold in?) a change to have the random
>  > translator use <version.h>?  Then, push to the abandoned random
>  > translator branch a commit that removes all files but a small README
>  > file containing a note about the move -- or, in fact, just remove the
>  > branch?  However, I'm likewise fine if you just push your
>  > merge-random branch as-is.
>  > That procedure can then also be used for other branches/repositories,
>  > if so desired.
>         I think I’ve already asked this one, but still: why not a Git
>         submodule?  

Complexity.  We are trying to reduce it.

> One problem with the “merge ’em all” approach is
>         that one can /add/ a thing to the repository, but one cannot
>         really /delete/ it later.  (In the sense that from that point
>         on, the code added would remain in the Git history, – and be
>         $ git clone’d forever.)

In my head, that is exactly the point of a vcs, but ymmv.

>         On the contrary, submodules may be added and removed without any
>         hassle.  And from this point, I’d rather see Hurd – a collection
>         of servers – living as a collection of Git repositories.

I'd rather see the Hurd not being a major pain in the ass to develop,
but again, ymmv, as I guess it's a matter of perspective.

>         The only downside I could think of is that a single commit
>         (unless made to the “upper level” repository) cannot really span
>         multiple Git repositories.  Which may be a problem as long as
>         there’re strong interdependencies in the servers’ code.

There are strong interdependencies, some are explicit, some are
implicit.  And being able to change some aspects of the Hurd is part
of why I advocated this merge in the first place (as clearly stated in
my original mail).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]