Junio C Hamano <gits...@pobox.com> writes: > I have a mildly strong suspicion that a better approach might be to: > > - Copy the current stable snapshot to the contrib/ area, [...] > > - Keep the development at your GitHub repository, [...] > > - Update what is in contrib/ in my tree with a stable snapshot, > every once in a while [...]
I think this is not very different from - merge the current version in the contrib/ area - keep the development at the GitHub repository - merge the GitHub repository into the git.git once in a while (which is essentially what happens with gitk and git-gui as far as I understood) I tend to prefer the "merge" approach to the "copy files from one repo to another", even if git_multimail is never edited directly from git.git. I find it conceptually cleaner, and it gives a bit more flexibility (e.g. if someone accidentally commits in git.git's repository, the commit would also be valid wrt git_multimail's GitHub repo, and can serve as a pull request). -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
