>>>>> Thomas Schwinge <tho...@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? 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.) 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. 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. -- FSF associate member #7257 http://boycottsystemd.org/
