Re: [savannah-help-public] Gnuspeech - git repository

[David Hill]

Dear Assaf,

Thanks again for your detailed, helpful comments. Much appreciated.

You will have just seen a copy of my response to Marcelo. If, in fact, the full 
history from Steve's work on Monet is worth keeping in full for git log access, 
instead of putting it in a text file, I could add it to the initial commit 
message, so it would appear almost as if the log were complete.

I don't think it is worth importing all the SVN stuff -- more confusing than 
helpful, and an awful burden on the new repo. People can access it if they want 
to.

I did experiment with a non-savannah bare repo and when I figured the results 
were good (including a test of what cloned when I cloned the finished bare 
repo) I sent my message saying I was ready to go.

However, I am all to well aware that (like all humans) I can be wrong. However, 
what I have done & said seems reasonable.

You wrote:

> The "guix" example I wrote about - is case #2.
> The related guix repositories (eg. guix/dhcp.git) are related just by being 
> under the "guix" directory.
> Users can pick-and-choose which repository they are interested in.

Are you suggesting that we use one or more guix repositories and not put the 
material on the savannah project site at all? Keeping two different repos 
(savannah and guix), differently structured, would introduce problems of 
synchronisation and (in my opinion) be quite confusing, so I am not happy about 
having both.

What do you think of all this (especially the idea of simply adding the 
existing history to the initial commit message)?

Then, of course, there's the release. If I were to have more than one savannah 
repo, would that require having more than one tarball. I was just about to 
start looking at the procedures for a first release. Marcelo says it looks 
fairly complicated. I want to keep that as straightforward as possible.

Warm regards.

david


On Sep 18, 2015, at 8:30 06AM, Assaf Gordon wrote:

> Hello David and all,
> 
> Few comments, hopefully helpful:
> 
> Regarding "histories":
> 
> The histories in this context is the commit logs of the existing project,
> i.e. the date, author, and diff to the source code files.
> You can see the current history (of the SVN repo) by doing:
>    svn co svn://svn.sv.gnu.org/gnuspeech
>    cd gnuspeech/
>    svn log | less
> 
> If you decide to copy the files as is, and start a new git repository,
> those entries will not be preserved in the git repository.
> When someone will do "git log", the first entry will be
> you (presumably) on Sept-2015 committing all the files.
> 
> Depending on your POV, it might be perfectly acceptable to 'reset' the 
> history,
> start fresh, and mention in a README that all previous commits are available 
> from the
> (now stale) SVN repository. You can keep the SVN (and CVS) repositories 
> available forever on Savannah.
> 
> Alternatively, there are tools to import an existing CVS/SVN repository into 
> a GIT repository.
> The advantage: you preserve the rich and detailed commit history.
> The disadvantage: the repository is not started in a 'clean' state which 
> allows you to carefully determine what goes in (everything that was in the 
> SVN will be in it initially).
> 
> IMHO there's no one "correct" approach here, it's a decision you'll need to 
> make.
> 
> ---
> 
> Regarding multiple independent git repositories and submodules:
> 
> I agree with previous commenters, you can decide to have:
> 1. one big repository with everything
> 2. multiple git repositories, but keep them completely independent
> 3. multiple git repositories, and set them as git submodules.
> Each has its own advantages and disadvantages.
> 
> The "guix" example I wrote about - is case #2.
> The related guix repositories (eg. guix/dhcp.git) are related just by being 
> under the "guix" directory.
> Users can pick-and-choose which repository they are interested in.
> 
> Example of case #3 is GNU coreutils, which uses gnulib as a git-submodule.
> If a user runs:
>    $ git clone --recursive git://git.sv.gnu.org/coreutils.git
> It will also pull files from the submodule at git://git.sv.gnu.org/gnulib.git
> 
> Again, IMHO there's no "correct" answer.
> 
> ---
> 
> Regarding experimentation:
> Yes, the best option is to experiment (current with another, non-savannah 
> service).
> That is simply because on these services you can create and delete 
> repositories over and over again,
> until you are pleased with the result.
> 
> But in the grand scheme of things,
> pushing a bad commit to savannah is not the end of the world.
> It simply means you'll need to push another commit, undoing the previous one.
> The main disadvantage is that you end-up with a messy repository (and 
> potentially a very large one).
> (Other hosting services allow you to do a "force push" or non-fast-forward 
> commit, which literally removes the bad commit from the history.
> This is cleaner, but opens the door to code removal. Savannah does not allow 
> it).
> 
> regards,
> - assaf
>