Eric Wong [off-list ref] writes:
@ Junio: Is there room for this in the git distribution alongside
git-svnimport?
Surely. Things that superficially do similar things are not
necessarily mutually exclusive, if that is what you are worried
about. There is not much incumbent advantage for tools that
support a narrowly defined specific task (e.g. interfacing with
foreign SCM X) on the periphery, while I would perhaps feel more
hesitant to support 47 different variants of git-commit ;-).
Especially, from your description (I haven't looked at the
code), its point is to give a better support for an alternative
workflow from svnimport supports.
I was privately advised (by somebody I respect and trust) that I
should not be too hesitant to expand the scope of the project.
Also there are some interesting developments such as Martin's
git-backed fake CVS server and Aneesh's gitview that I have been
interested in, among other things.
Even having some experimental tools that are only starting to do
useful things might be useful, if we had it in the git.git
repository. For one thing, it would give more exposure to them
and help improve things.
How about first adding a contrib/ directory and see how it goes?
On 2/16/06, Junio C Hamano [off-list ref] wrote:
should not be too hesitant to expand the scope of the project.
Also there are some interesting developments such as Martin's
git-backed fake CVS server and Aneesh's gitview that I have been
interested in, among other things.
Even having some experimental tools that are only starting to do
useful things might be useful, if we had it in the git.git
repository. For one thing, it would give more exposure to them
and help improve things.
How about first adding a contrib/ directory and see how it goes?
I am all for it. Attaching the latest gitview. This include branch and
tag display support and also the option to save diffs in file.
For the screenshot
http://kvaneesh.livejournal.com
-aneesh
Junio C Hamano [off-list ref] wrote:
Eric Wong [off-list ref] writes:
quoted
@ Junio: Is there room for this in the git distribution alongside
git-svnimport?
Surely. Things that superficially do similar things are not
necessarily mutually exclusive, if that is what you are worried
about. There is not much incumbent advantage for tools that
support a narrowly defined specific task (e.g. interfacing with
foreign SCM X) on the periphery, while I would perhaps feel more
hesitant to support 47 different variants of git-commit ;-).
<snip>
Even having some experimental tools that are only starting to do
useful things might be useful, if we had it in the git.git
repository. For one thing, it would give more exposure to them
and help improve things.
Good to know. I fully agree on this point.
How about first adding a contrib/ directory and see how it goes?
Sure thing. Don't worry about development history, there's hardly any
as it was all done pretty quickly. Being able to draw from my
experiences with svn-arch-mirror, arch-svn-merge (this one sucked), and
git-archimport helped greatly; as did the very simple and flexible
nature of git.
--
Eric Wong