[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).
Justus