savannah-hackers
[Top][All Lists]
Advanced

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

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


From: David Hill
Subject: Re: [savannah-help-public] Gnuspeech - git repository
Date: Fri, 18 Sep 2015 17:57:40 -0700

Dear Steve,

You make a powerful, multithreaded case for submodules. You did see what Assaf said, did you?

"Starting a fresh repository is not a bad idea. Instead of adding the previous history to a git-commit message, I'd simply create a 'ChangeLog-OLD' file, listing the detailed changes. For example, GNU coreutils has multiple 'changelog' files containing detailed old changes: ( http://git.savannah.gnu.org/cgit/coreutils.git/tree/ ). Coreutils stopped updating the 'Changelog' files manually circa 2008 when git commit history replaced it."

Check out that page.

By the way, for how long have you been using Git -- surely not since 2003? So we wouldn't lose 12 years of change history, and none if the change logs were included in the Git repo as Assaf says is a possibility.

Nevertheless, it is looking as though we are probably back to the submodules solution after all, even though there does seem to be an alternative that preserves the change logs.

At least I got some strong responses (to my tentative decision on a single repo) that clears the view quite a bit. :-)

Thank you.

If so that would mean submodules for:

Gnuspeech
GnuspeechSA

plus a README file. Right?

The binaries should go into ftp.gnu.org because it is the place where binaries are put, and it saves cluttering the Git repos and not included in Gnuspeech (they are not there in my tests). I notice a few gratuitous .DS_Stores have remained in a few places. They will have to be removed.

I'll do some more reading on submodules, but presumably I'll need the S-Hs to set me up with two bare submodules in the bare Git repo I generate and in which I then create a brief README file. What else might need to go at the top level, outside the submodules?

Sound reasonable? Comments please. What about the alternative?

Warm regards.

david

On Sep 18, 2015, at 15:37 48PM, Steve Nygard wrote:


On 2015-09-18, at 14:16, David Hill <address@hidden> wrote:

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.

No.

The change history is far more than just the log of commit messages.  It includes the actual changes, and can be manipulated -- diffs between versions, bisecting to find bugs.  When I converted the subversion repository to Git, I was very careful to preserve the entire history of changes.

I have repositories that I've migrated from CVS to Subversion to Mercurial and then to Git, all the while preserving the entire change history.  It's that important.  I consider the history to be almost as important as the source itself, and casually suggesting discarding it is very alarming!

The other thing that wiping out the change history does is separate it from the existing repositories.  You'll no longer be able to easily pull and push changes between them.  It will be harder to incorporate changes that I make in the future, or that Marcelo makes to his.


David, you want a single repository.  Marcelo doesn't want to see all the OS X stuff that he doesn't use.  And I don't want to see 12 years of change history trashed.

Given those constraints, submodules are the best solution.  We can add GnuspeechSA as a submodule of my repository.  Marcelo can continue his work in his repository, and you can have both projects together.  I'll have to read up a bit on submodules, since I rarely use them, but that's not a problem.  (I believe savannah would need to have a clone of GnuspeechSA before we add it as a submodule, otherwise it will refer to the github one.  Although I imagine it would be possible to update after -- I'll have to look at the help.)

Steve




reply via email to

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