Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)
Hi,
On 06/05/14 11:50, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
On Tue, Apr 29, 2014 at 03:38:07PM -0700, Junio C Hamano wrote:
* fc/remote-helpers-hg-bzr-graduation (2014-04-29) 11 commits
...
Move remote-hg and remote-bzr out of contrib/. There were some
suggestions on the follow-up fix patches still not in 'next', which
may result in a reroll.
Will merge to 'next' and keep it there for the remainder of the
cycle.
I'd like to register my opposition to moving git-remote-{bzr,hg} out of
contrib/.
...
In the case of git-remote-hg specifically, the remote helper has to use
an interface that the Mercurial developers consider unstable [1];...
I do not want to end up in a situation where an update to Git is blocked
by a distribution because git-remote-hg is not updated to support newer
versions of Mercurial sufficiently quickly; this previously happened in
Gentoo due to git-svn and meant that was stuck on 1.7.8 until 1.7.13 was
released [2].
The same argument would apply to git-svn, git-p4, and git-cvsimport,
I would think.
A bit of a crazy suggestion and a little off-topic. Assuming maintainers
can be found what about having these foreign vcs interfaces as
submodules. That way they can be in Junio's tree as well as having their
own release cycles. The same could apply to git-gui, gitk and gitweb. It
would also be a chance to eat-our-own-dogfood with submodules.
Among these, I am not sure if we can find willing maintainers who
can give enough love to them. But unlike these other importers,
remote-hg and remote-bzr do have an active maintainer (and IIRC I
think I heard that Hg one even has an active competitor or two?) so
I am reasonably confident that these can live on their own merit
outside of my tree. In the ideal world, I would think it may be
even beneficial to the end users of these helpers to unbundle them.
You raised a good point on the issue of external dependencies may
impact Git as a whole, even for those who are not interested in the
particular remote helpers at all. I'll have to think about it.
The silly thing is that I totally forgot that we almost got
ourselves into a very similar situation on cvsimport when a series
wanted to make it cvsps3-only. It is very possible nobody would
have picked up the entire new release, if we merged that change.
Having said all that, there is one caveat.
Since the remote helper interface is stable and the remote helpers do
not use any of the Git internals, I consider the risks of including them
in core Git to outweigh the benefits of wider distribution.
You are correct to say that a remote helper has to talk with a
foreign system and it would not help to dictate the update schedule
of helpers to match the release cycle of Git itself. At the same
time, however, the interface the remote helpers use to talk to Git
has not been as stable as you seem to think, I am afraid. For
example, a recent remote-hg/bzr series needed some enhancements to
fast-import to achieve the feature parity with native transports by
adding a missing feature or two on the Git side.
So in reality, a helper has to talk with two sides, needs to adjust
to changes in the both sides, and both sides are changing.
Unbundling a helper from Git would place more burden on the helper's
maintainer, because the helper has to know enough about versions and
features of both sides (the foreign system and Git) to adjust its
behaviour, to stay compatible with wider versions of both foreign
systems and Git. Unbundling, when done properly, may give more
ideal user experience to the end users, because such a helper would
allow them to pick up the latest (or stay on an older but known to
be stable) version of the helper and expect it to work with the
foreign system and Git they happen to have.
It however would be easier to maintain if the helper maintainer
knows a change to Git itself will be released at the same time as
the new version of the helper that takes advantage of the modified
Git. The helper maintainer only has to worry about compatibility
with the foreign side if it is bundled with Git.
So it boils down to how much resource are there to make sure a
helper will stay compatible with wider versions of both sides? and
how far backwards are helper maintainers willing to bend to support
users better?.
--
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
--
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
Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)
Chris Packham wrote: On 06/05/14 11:50, Junio C Hamano wrote: The same argument would apply to git-svn, git-p4, and git-cvsimport, I would think. A bit of a crazy suggestion and a little off-topic. Assuming maintainers can be found what about having these foreign vcs interfaces as submodules. That way they can be in Junio's tree as well as having their own release cycles. The same could apply to git-gui, gitk and gitweb. It would also be a chance to eat-our-own-dogfood with submodules. If submodules were an integral part of Git that would be a possibility, but they are more like a hack. -- Felipe Contreras -- 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
Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)
Chris Packham judge.pack...@gmail.com writes: A bit of a crazy suggestion and a little off-topic. Assuming maintainers can be found what about having these foreign vcs interfaces as submodules. That way they can be in Junio's tree as well as having their own release cycles. The same could apply to git-gui, gitk and gitweb. It would also be a chance to eat-our-own-dogfood with submodules. While I agree that submodules may be useful for git-gui and gitk (which already have their own repository and history), I do not think that affects the issue of release cycles for third-party tools, especially the ones with heavier foreign system dependencies like vcs interfaces. The release schedule of Git itself places a lot of stress not to regress anything for existing users of Git, and the gitlink that points at the specific commit in a submodule will stop advancing in the top-level superproject (i.e. my tree) during the feature-freeze period before releases, just like any other paths (i.e. regular file blobs). A third-party product maintainer may have other ideas about stability of their product. They may want to issue an unproven new release to adjust to a recent update made to their external dependencies as soon as code is written, relying on their ability to issue follow-up maintenance updates on their product in quick succession. If many of them are bundled with Git, then we would have to keep following these oops, that was wrong updates from all of these, which would add unscalable burden to a single choking point. Not bundling gives third-party tools the freedom to evolve and worry about compatibility with their dependencies on their own, and allows them to treat Git as just one of the dependencies at the same level as their other dependencies. -- 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
Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)
On Thu, 8 May 2014, Felipe Contreras wrote: Chris Packham wrote: On 06/05/14 11:50, Junio C Hamano wrote: The same argument would apply to git-svn, git-p4, and git-cvsimport, I would think. A bit of a crazy suggestion and a little off-topic. Assuming maintainers can be found what about having these foreign vcs interfaces as submodules. That way they can be in Junio's tree as well as having their own release cycles. The same could apply to git-gui, gitk and gitweb. It would also be a chance to eat-our-own-dogfood with submodules. If submodules were an integral part of Git that would be a possibility, but they are more like a hack. Well, if git.git can't use them, then how can anyone else be expected to. I haven't been paying close attention for a while, what would have to be done to make submodules an integral part of Git? David Lang -- 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
Submodule improvements (Re: What's cooking in git.git (Apr 2014, #09; Tue, 29))
Hi, David Lang wrote: I haven't been paying close attention for a while, what would have to be done to make submodules an integral part of Git? The series at http://thread.gmane.org/gmane.comp.version-control.git/241455 is a start. I'm hoping to get a reroll done soon and then I can talk about later steps. https://github.com/jlehmann/git-submod-enhancements/wiki has a rough roadmap, but really there's lots of commands that could be improved to recurse into submodules and not many interdependencies involved so anyone can bite off a chunk. Thanks, Jonathan -- 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
Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)
David Lang wrote: On Thu, 8 May 2014, Felipe Contreras wrote: If submodules were an integral part of Git that would be a possibility, but they are more like a hack. Well, if git.git can't use them, then how can anyone else be expected to. That is a very good question. I haven't been paying close attention for a while, what would have to be done to make submodules an integral part of Git? This comes to mind: http://article.gmane.org/gmane.comp.version-control.git/220047 -- Felipe Contreras -- 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
Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)
On Tue, May 06, 2014 at 05:01:59PM -0700, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
I'd like to register my opposition to moving git-remote-{bzr,hg} out of
contrib/.
I am not convinced that tools for interoperating with other VCSs need to
be part of core Git; as Junio has pointed out previously, while contrib/
was necessary ... Associated tools can
therefore live on their own and do not need to be promoted as part of
Git itself (as git-imerge is doing successfully).
Another thing to keep in mind is that we need to ensure that we give
a good way for these third-party tools to integrate well with the
core Git tools to form a single toolchest for the users. I would
love to be able to do
$ (cd git.git make install)
$ (cd git-imerge.git make install)
and then say git imerge, git --help imerge, etc. The same for
the remote helpers that we may be splitting out of my tree into
their own stand-alone projects.
This can already work given suitable installation. With
git-integration[1] I can type `git help integration` and it shows me the
man page in the same way that `git help commit` does. When I manually
linked the HTML file to the right place `git help -w integration` worked
as well.
I _think_ it probably is OK for git-imerge.git/Makefile to peek into
our Makefile, e.g.
$ cd git-imerge.git
$ make GIT_SOURCE_DIR=../git.git install
to learn where imerge should install its subcommand implementation
and documentation. It might even want to borrow the test framework
by using $GIT_SOURCE_DIR/t/test-lib.sh or somesuch. There may be
some changes the third-party tool authors would want to have in our
Makefile to help them better when building their tools this way; I
dunno.
I also think that there should be a way to make it really easy to
install these third-party tools to augment the installed version of
Git without having the source tree of Git. We have ways for them to
ask us where things are expected to be, e.g.
$ git --html-path
$ git --man-path
$ git --exec-path
but I am not sure if these are enough, or if it would help them to
add a bit more, then what these a bit more are.
I think this is enough - now I need to go and make git-integration's
Makefile use them by default rather than just using the same defaults as
git.git.
Perhaps it would be useful to have a skeleton external Git utility
project under contrib/ which could demonstrate best practice for
installing utilties that augment Git.
[1] http://johnkeeping.github.io/git-integration/
--
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
Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)
John Keeping wrote: I also think that there should be a way to make it really easy to install these third-party tools to augment the installed version of Git without having the source tree of Git. We have ways for them to ask us where things are expected to be, e.g. $ git --html-path $ git --man-path $ git --exec-path but I am not sure if these are enough, or if it would help them to add a bit more, then what these a bit more are. I think this is enough - now I need to go and make git-integration's Makefile use them by default rather than just using the same defaults as git.git. This is wrong. Subprojects should use /usr/bin/ and /usr/share/man/ and not rely on the output of `git --exec-path` and so on. For example if the user has installed Git in his $home, when building a package the package manager would use ~/libexec/git-core, which is wrong. Moreover, if you are cross-compiling you won't be able to run the target's `git` binary. If anything, it should be `pkg-config --variable=exec-path git`. -- Felipe Contreras -- 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
Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)
Junio C Hamano gits...@pobox.com writes: You raised a good point on the issue of external dependencies may impact Git as a whole, even for those who are not interested in the particular remote helpers at all. I'll have to think about it. (As I'm sure you know, but starting from the beginning.) There are basically two ways that a program can be built. One is by a user on a particular system. There, checking to see if various libraries are installed and if so enabling some additional feature (that isn't that hard/time-consuming to build) is entirely reasonable. In a packaging system, dependencies are much more troublesome. Dependencies have to be declared, and the build limited to use only those declared dependencies, in order to get repeatable builds and binary packages that can be used on other systems. Dependencies that really are required are fine. But optional dependencies are a problem, because e.g. one doesn't want to require the presence of qt to build something (that isn't already enormous). So if git needs mercurial and subversion installed, plus perhaps 5 other things for less popular remote helpers, that starts to be a real burden. (I realize some packaging systems have a style where the union of the possible dependencies must be present to build, and then the resulting binaries are allocated to split packages. But that's not universal, and it still requires large amounts of unnecessary dependencies to build a package from source.) Ideally, the core of git would have a small set of dependencies, and optional language bindings or remote helpers could be built independently (by running a different build, after git proper was built and installed). It seems more likely that the property of independent builds of optional components will be preserved if the various git-foo pieces are in seaprate trees. But if they are in subdirs of the main git tree, and build by ./configure make make install in the subdir, that's arguably equivalent. pgppg0HzmvEjx.pgp Description: PGP signature
Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)
John Keeping j...@keeping.me.uk writes: On Tue, May 06, 2014 at 05:01:59PM -0700, Junio C Hamano wrote: ... Another thing to keep in mind is that we need to ensure that we give a good way for these third-party tools to integrate well with the core Git tools to form a single toolchest for the users. I would love to be able to do $ (cd git.git make install) $ (cd git-imerge.git make install) and then say git imerge, git --help imerge, etc. The same for the remote helpers that we may be splitting out of my tree into their own stand-alone projects. This can already work given suitable installation. With git-integration[1] I can type `git help integration` and it shows me the man page in the same way that `git help commit` does. When I manually linked the HTML file to the right place `git help -w integration` worked as well. That when I manually part is what I meant by we give a good way for these third-party tools above, and make it really easy to install these third-party tools in the remaining part of the message you are responding to. I think this is enough... Thanks. The reason why I CC'ed Michael was primarily because I thought you were not one of those third-party tools maintainers (and secondarily I am a fairly big fan of imerge), but it is good to hear your opinion as another third-party provider. Your git-integrate might turn into something I could augment my workflow with with some additions. What is missing (I only read the full manual page at http://johnkeeping.github.io/git-integration/git-integration.html) to support my workflow seems to be: - specifying a merge strategy per branch being merged; - support evil merges or picking a fix-up commit; - leaving an empty commit only to leave comment in the history. and until that happens, I'll keep using the Reintegrate script found in my 'todo' branch. -- 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
Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)
On Wed, May 07, 2014 at 11:56:18AM -0700, Junio C Hamano wrote: John Keeping j...@keeping.me.uk writes: On Tue, May 06, 2014 at 05:01:59PM -0700, Junio C Hamano wrote: ... Another thing to keep in mind is that we need to ensure that we give a good way for these third-party tools to integrate well with the core Git tools to form a single toolchest for the users. I would love to be able to do $ (cd git.git make install) $ (cd git-imerge.git make install) and then say git imerge, git --help imerge, etc. The same for the remote helpers that we may be splitting out of my tree into their own stand-alone projects. This can already work given suitable installation. With git-integration[1] I can type `git help integration` and it shows me the man page in the same way that `git help commit` does. When I manually linked the HTML file to the right place `git help -w integration` worked as well. That when I manually part is what I meant by we give a good way for these third-party tools above, and make it really easy to install these third-party tools in the remaining part of the message you are responding to. I think this is enough... Having thought about it a bit more after reading Felipe's reply, it would be nice if there were some way for third-party tools to install HTML documentation without relying on `git --html-path` but I cannot see an obvious way to do that as there isn't a standard $HTML_PATH to match $MAN_PATH and $PATH. I've never tried `git help --info` until this thread, but I think we could make some trivial improvements to that in order to support .info documentation for third-party tools. The reason why I CC'ed Michael was primarily because I thought you were not one of those third-party tools maintainers (and secondarily I am a fairly big fan of imerge), but it is good to hear your opinion as another third-party provider. Your git-integrate might turn into something I could augment my workflow with with some additions. What is missing (I only read the full manual page at http://johnkeeping.github.io/git-integration/git-integration.html) to support my workflow seems to be: - specifying a merge strategy per branch being merged; This is already supported by the merge instruction: If any options are given after the ref (and on the same line) then these are passed to git merge. This may be useful for specifying an alternative merge strategy for a branch. - support evil merges or picking a fix-up commit; I have an implementation of this on a branch, but have never merged it because it's not something I need to do often and it is very hard to support for git-integration's status output. One of my primary use cases for git-integration involves pulling together branches owned by others (either in the same repository or by having fetched from their repositories); in this case it is interesting to see if/how a branch has changed since the last time the integration branch was built. This also handles changes to the instruction sheet without an immediate rebuild. I have not found a good way of figuring out whether a fixup commit has been applied and squashed into a merge) so I have let the branch sit there awaiting a perfect solution (which I doubt exists). It may be that the status of a fixup is unimportant, so it could just be marked as unknown; I am mostly convinced that marking it as unknown is going to be better than an heuristic that is right most of the time. - leaving an empty commit only to leave comment in the history. This would be easy to add. and until that happens, I'll keep using the Reintegrate script found in my 'todo' branch. When I originally wrote git-integration I purposefully did not target your workflow because I (perhaps wrongly) assumed that the interaction between the different integration branches would mean that Git was better served sticking to the custom Reintegrate script. -- 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
Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)
John Keeping wrote: Having thought about it a bit more after reading Felipe's reply, it would be nice if there were some way for third-party tools to install HTML documentation without relying on `git --html-path` but I cannot see an obvious way to do that as there isn't a standard $HTML_PATH to match $MAN_PATH and $PATH. Using `git --html-path` for that is wrong. -- Felipe Contreras -- 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
Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)
Greg Troxel wrote: In a packaging system, dependencies are much more troublesome. Dependencies have to be declared, and the build limited to use only those declared dependencies, in order to get repeatable builds and binary packages that can be used on other systems. Dependencies that really are required are fine. But optional dependencies are a problem, because e.g. one doesn't want to require the presence of qt to build something (that isn't already enormous). So if git needs mercurial and subversion installed, plus perhaps 5 other things for less popular remote helpers, that starts to be a real burden. It doesn't *need* them to build. The Mercurial/Bazaar dependencies are optional, both at build-time and at run-time. Most distributions would want to test the functionality they are distributing, and for testing they do need these dependencies. -- Felipe Contreras -- 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
Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)
Junio C Hamano wrote: That when I manually part is what I meant by we give a good way for these third-party tools above, and make it really easy to install these third-party tools in the remaining part of the message you are responding to. We need two things: 1) Provied a pkg-config, as all sane shared components do 2) Split the testing framework so third-parties don't have to rely on yet another third-parth (shareness) Your git-integrate might turn into something I could augment my workflow with with some additions. - specifying a merge strategy per branch being merged; git-reintegrate[1] supports this. - support evil merges or picking a fix-up commit; git-reintegrate supports this. - leaving an empty commit only to leave comment in the history. Done[2]. and until that happens, I'll keep using the Reintegrate script found in my 'todo' branch. My git-reintegrate supports everything John's git-integrate and in addition it supports generating the commands from an existing branch, like your Reintegrate. IOW; it's superior. [1] https://github.com/felipec/git-reintegrate [2] https://github.com/felipec/git-reintegrate/commit/332412470c6e084f10ac2f8dc11e86ab4680974a -- Felipe Contreras -- 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
Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)
On Wed, May 07, 2014 at 03:26:15PM -0500, Felipe Contreras wrote: Junio C Hamano wrote: Your git-integrate might turn into something I could augment my workflow with with some additions. - specifying a merge strategy per branch being merged; git-reintegrate[1] supports this. - support evil merges or picking a fix-up commit; git-reintegrate supports this. - leaving an empty commit only to leave comment in the history. Done[2]. and until that happens, I'll keep using the Reintegrate script found in my 'todo' branch. My git-reintegrate supports everything John's git-integrate and in addition it supports generating the commands from an existing branch, like your Reintegrate. IOW; it's superior. And yet the documentation is unchanged from the version you copied in from git-integration. Personally I would much rather use a project which takes time to document all of the features rather than relying on reading the code to figure out the options. More features does not make a project superior. -- 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
Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)
John Keeping wrote: On Wed, May 07, 2014 at 03:26:15PM -0500, Felipe Contreras wrote: Junio C Hamano wrote: Your git-integrate might turn into something I could augment my workflow with with some additions. - specifying a merge strategy per branch being merged; git-reintegrate[1] supports this. - support evil merges or picking a fix-up commit; git-reintegrate supports this. - leaving an empty commit only to leave comment in the history. Done[2]. and until that happens, I'll keep using the Reintegrate script found in my 'todo' branch. My git-reintegrate supports everything John's git-integrate and in addition it supports generating the commands from an existing branch, like your Reintegrate. IOW; it's superior. And yet the documentation is unchanged from the version you copied in from git-integration. Not much has changed since v0.1 since that version already worked perfectly. But I'll update it. Personally I would much rather use a project which takes time to document all of the features rather than relying on reading the code to figure out the options. And I would rather use a project that concentrates on having the features users need. More features does not make a project superior. No, better features do. Either way. Documentation updated. -- Felipe Contreras -- 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
Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)
Felipe Contreras felipe.contre...@gmail.com writes: Greg Troxel wrote: In a packaging system, dependencies are much more troublesome. Dependencies have to be declared, and the build limited to use only those declared dependencies, in order to get repeatable builds and binary packages that can be used on other systems. Dependencies that really are required are fine. But optional dependencies are a problem, because e.g. one doesn't want to require the presence of qt to build something (that isn't already enormous). So if git needs mercurial and subversion installed, plus perhaps 5 other things for less popular remote helpers, that starts to be a real burden. It doesn't *need* them to build. The Mercurial/Bazaar dependencies are optional, both at build-time and at run-time. Most distributions would want to test the functionality they are distributing, and for testing they do need these dependencies. My point is that a packaging of git needs to either decide to forego these optional parts, or to include them, in the default case. One choice means that anyone who builds the package from source has to have the dependencies, and the other means that users of the built package(s) can't use the features. I realize that in Linux it's perhaps typical to not worry about burdening builders because actually building is very rare, but that's only reasonable because of having only one OS and perhaps three CPUs; with dozens each, building from source becomes more frequent. So I'm merely trying to suggest that it's better to have a core package with a restrained set of dependencies, and then a way to build the other things independently (perhaps assuming the core is built/installed), each with their own dependencies. It turns out in pkgsrc that git-svn is a meta-package (with no files) that depends on git-base (no man pages, no gitk) and p5-subversion. hg-git appears to be a separate source distribution, depending on a python implementation of the git formats. So perhaps the situation is currently ok. I was just trying to point out the issue to avoid regressions in the packaging situation. pgptdIoL4IFDe.pgp Description: PGP signature
Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)
Greg Troxel wrote: Felipe Contreras felipe.contre...@gmail.com writes: Greg Troxel wrote: In a packaging system, dependencies are much more troublesome. Dependencies have to be declared, and the build limited to use only those declared dependencies, in order to get repeatable builds and binary packages that can be used on other systems. Dependencies that really are required are fine. But optional dependencies are a problem, because e.g. one doesn't want to require the presence of qt to build something (that isn't already enormous). So if git needs mercurial and subversion installed, plus perhaps 5 other things for less popular remote helpers, that starts to be a real burden. It doesn't *need* them to build. The Mercurial/Bazaar dependencies are optional, both at build-time and at run-time. Most distributions would want to test the functionality they are distributing, and for testing they do need these dependencies. My point is that a packaging of git needs to either decide to forego these optional parts, or to include them, in the default case. That is currently the case. They would be included by default, but not usable unless the *optional* dependencies are installed. So I'm merely trying to suggest that it's better to have a core package with a restrained set of dependencies, and then a way to build the other things independently (perhaps assuming the core is built/installed), each with their own dependencies. I'm all in favor of 'make install' installing only the core of Git, and different targets for all the other parts. However, if you take a look at any distribution's packaing of Git you would see why that wouldn't be desirable (they are full of hacks and fixes). If the build system is eventually fixed so one package can do 'make install', another 'make install-p4', another 'make install-hg' and so on, that would be great. But we are pretty far from that. -- Felipe Contreras -- 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
Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)
On Mon, May 05, 2014 at 04:50:58PM -0700, Junio C Hamano wrote: John Keeping j...@keeping.me.uk writes: Having said all that, there is one caveat. Since the remote helper interface is stable and the remote helpers do not use any of the Git internals, I consider the risks of including them in core Git to outweigh the benefits of wider distribution. You are correct to say that a remote helper has to talk with a foreign system and it would not help to dictate the update schedule of helpers to match the release cycle of Git itself. At the same time, however, the interface the remote helpers use to talk to Git has not been as stable as you seem to think, I am afraid. For example, a recent remote-hg/bzr series needed some enhancements to fast-import to achieve the feature parity with native transports by adding a missing feature or two on the Git side. This doesn't qualify as an unstable interface for me. In this case, the remote helpers could not support a feature without Git supporting it first, which is quite natural and the remote helper can then guard that feature with a capability check. I do not think it likely that the remote helper interface will ever change in such a way that all remote helpers must be updated, at least not without a long deprecation period. The Mercurial API makes no such guarantee; it is considered a private implementation detail and most releases seem to contain some changes that require all consumers to be updated. There is a different level of urgency between you cannot use this new feature until you update Git and if you update Mercurial then the remote helper will stop working, and that's why I think the remote helpers may benefit from a separate release schedule. -- 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
Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)
John Keeping j...@keeping.me.uk writes: And it is now probably too late for that to make Git 2.0,... Anything with end-user visible changes in the core part that is not a fix to a regression introduced between v1.9.0..master is too late for the upcoming release. We are way past -rc1. So I think these are the two options: 1) Include git-remote-hg/bzr to the core and distribute them by default (as is the current intention) 2) Remove git-remote-hg/bzr entirely from the Git tree. And do the same for other tools: git-p4, git-svn, git-cvs*. Given the huge amount of people using Subversion, we might want to defer that one for later, but eventually do it. Isn't there a middle ground? The option 1.5 may be like this: - Eject tools in contrib/ that would benefit the users better if they were outside my tree. There are a few points to consider when judging benefit better if outside: * Their release cycle requirements are better met outside my tree (the remote-hg depends not just on Git but Hg internal issue we have discussed). * They are actively maintained. The overall Git maintainer would merely be being a bottleneck than being a helpful editor with respect to these tools if we keep them in my tree, and we expect that the tool maintainer would do a much better job without me. - Keep tools that are not actively maintained but still used by the users widely in my tree, but when their external dependencies become baggage to Git as a whole, demote them to contrib/ and stop installing them by default. - I would not mind having install.contrib-frotz target in the top-level Makefile for each of the remaining contrib/frotz hierarchies for those users and distro packagers who know their platform meets the dependency requirements. I'm not sure it needs to wait for a major Git release since most of the impact is on package maintainers and not end users. Removal of features is a big deal, I would think, though. -- 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
Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)
Junio C Hamano wrote: John Keeping j...@keeping.me.uk writes: And it is now probably too late for that to make Git 2.0,... Anything with end-user visible changes in the core part that is not a fix to a regression introduced between v1.9.0..master is too late for the upcoming release. We are way past -rc1. The patch in question only affects users of hg v3.0 since it's surrounded by a 'check_version(3, 0)'. Therefore it cannot introduce regressions, there's no reason not to apply it. So I think these are the two options: 1) Include git-remote-hg/bzr to the core and distribute them by default (as is the current intention) 2) Remove git-remote-hg/bzr entirely from the Git tree. And do the same for other tools: git-p4, git-svn, git-cvs*. Given the huge amount of people using Subversion, we might want to defer that one for later, but eventually do it. Isn't there a middle ground? The option 1.5 may be like this: - Eject tools in contrib/ that would benefit the users better if they were outside my tree. There are a few points to consider when judging benefit better if outside: * Their release cycle requirements are better met outside my tree (the remote-hg depends not just on Git but Hg internal issue we have discussed). Shouldn't *I* be the one most qualified to know if the release cycle requirements are better met outside the git.git tree? * They are actively maintained. The overall Git maintainer would merely be being a bottleneck than being a helpful editor with respect to these tools if we keep them in my tree, and we expect that the tool maintainer would do a much better job without me. Perhaps. But only if the patches are reviewed throught the git mailing list. And what about the tools that are not actively maintainted? For example 'contrib/hg-to-git'. - Keep tools that are not actively maintained but still used by the users widely in my tree, but when their external dependencies become baggage to Git as a whole, demote them to contrib/ and stop installing them by default. That implies that git-remote-hg would become a baggage to Git as a whole. If you are arguing that git-remote-hg should be distributed by default, and only if the dependencies become a problem, demote to 'contrib/' that is fine. The same for git-p4 and other tools already out of contrib. -- Felipe Contreras -- 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
Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)
John Keeping j...@keeping.me.uk writes: On Mon, May 05, 2014 at 04:50:58PM -0700, Junio C Hamano wrote: ... At the same time, however, the interface the remote helpers use to talk to Git has not been as stable as you seem to think, I am afraid. For example, a recent remote-hg/bzr series needed some enhancements to fast-import to achieve the feature parity with native transports by adding a missing feature or two on the Git side. This doesn't qualify as an unstable interface for me. That is true, but that does not change the equation very much, no? To a remote-helper maintainer, bundled is easier to maintain than unbundled, because both sides are changing, and regardless of the nature of the change, s/he would know how the Git side looks like if bundled. Having said that, I agree with the conclusion of your message: There is a different level of urgency between you cannot use this new feature until you update Git and if you update Mercurial then the remote helper will stop working, and that's why I think the remote helpers may benefit from a separate release schedule. and I am inclined to be persuaded that the users of remote-hg/bzr may better off if they are unbundled from my tree. -- 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
Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)
Junio C Hamano wrote: Having said that, I agree with the conclusion of your message: There is a different level of urgency between you cannot use this new feature until you update Git and if you update Mercurial then the remote helper will stop working, and that's why I think the remote helpers may benefit from a separate release schedule. The conclusion is correct, the premises are not. -- Felipe Contreras -- 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
Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)
John Keeping j...@keeping.me.uk writes:
I'd like to register my opposition to moving git-remote-{bzr,hg} out of
contrib/.
I am not convinced that tools for interoperating with other VCSs need to
be part of core Git; as Junio has pointed out previously, while contrib/
was necessary ... Associated tools can
therefore live on their own and do not need to be promoted as part of
Git itself (as git-imerge is doing successfully).
Another thing to keep in mind is that we need to ensure that we give
a good way for these third-party tools to integrate well with the
core Git tools to form a single toolchest for the users. I would
love to be able to do
$ (cd git.git make install)
$ (cd git-imerge.git make install)
and then say git imerge, git --help imerge, etc. The same for
the remote helpers that we may be splitting out of my tree into
their own stand-alone projects.
I _think_ it probably is OK for git-imerge.git/Makefile to peek into
our Makefile, e.g.
$ cd git-imerge.git
$ make GIT_SOURCE_DIR=../git.git install
to learn where imerge should install its subcommand implementation
and documentation. It might even want to borrow the test framework
by using $GIT_SOURCE_DIR/t/test-lib.sh or somesuch. There may be
some changes the third-party tool authors would want to have in our
Makefile to help them better when building their tools this way; I
dunno.
I also think that there should be a way to make it really easy to
install these third-party tools to augment the installed version of
Git without having the source tree of Git. We have ways for them to
ask us where things are expected to be, e.g.
$ git --html-path
$ git --man-path
$ git --exec-path
but I am not sure if these are enough, or if it would help them to
add a bit more, then what these a bit more are.
--
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
Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)
Junio C Hamano wrote: I _think_ it probably is OK for git-imerge.git/Makefile to peek into our Makefile, e.g. $ cd git-imerge.git $ make GIT_SOURCE_DIR=../git.git install to learn where imerge should install its subcommand implementation and documentation. It might even want to borrow the test framework by using $GIT_SOURCE_DIR/t/test-lib.sh or somesuch. Since Git's test framework heavily tied to git.git, sharness[1] is the only sensible option. It might not have all the latest features of Git's test framework, but it's standalone. [1] https://github.com/mlafeldt/sharness -- Felipe Contreras -- 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
Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)
On Tue, Apr 29, 2014 at 03:38:07PM -0700, Junio C Hamano wrote:
* fc/remote-helpers-hg-bzr-graduation (2014-04-29) 11 commits
- remote-hg: trivial cleanups
- remote-hg: make sure we omit multiple heads
- git-remote-hg: use internal clone's hgrc
- t: remote-hg: split into setup test
- remote-hg: properly detect missing contexts
- remote-{hg,bzr}: store marks only on success
- remote-hg: update to 'public' phase when pushing
- remote-hg: fix parsing of custom committer
(merged to 'next' on 2014-04-22 at fed170a)
+ remote-helpers: move tests out of contrib
+ remote-helpers: move out of contrib
+ remote-helpers: squelch python import exceptions
Move remote-hg and remote-bzr out of contrib/. There were some
suggestions on the follow-up fix patches still not in 'next', which
may result in a reroll.
Will merge to 'next' and keep it there for the remainder of the
cycle.
I'd like to register my opposition to moving git-remote-{bzr,hg} out of
contrib/.
I am not convinced that tools for interoperating with other VCSs need to
be part of core Git; as Junio has pointed out previously, while contrib/
was necessary for promoting associated tools when Git was young and had
not established mindshare, Git is now by far the most popular DVCS and
is rapidly catching up with centralized systems. Associated tools can
therefore live on their own and do not need to be promoted as part of
Git itself (as git-imerge is doing successfully).
In the case of git-remote-hg specifically, the remote helper has to use
an interface that the Mercurial developers consider unstable [1]; the
version currently on 'pu' fails the test suite for me because I have
Mercurial 3.0:
AttributeError: 'mqrepo' object has no attribute 'getbundle'
I do not want to end up in a situation where an update to Git is blocked
by a distribution because git-remote-hg is not updated to support newer
versions of Mercurial sufficiently quickly; this previously happened in
Gentoo due to git-svn and meant that was stuck on 1.7.8 until 1.7.13 was
released [2].
Since the remote helper interface is stable and the remote helpers do
not use any of the Git internals, I consider the risks of including them
in core Git to outweigh the benefits of wider distribution. In fact,
the remote helpers may benefit from having their own release cadences
so that they can respond to changes in related projects more quickly
than the normal Git release cycle.
[1]
http://mercurial.selenic.com/wiki/MercurialApi#Why_you_shouldn.27t_use_Mercurial.27s_internal_API
[2] https://bugs.gentoo.org/show_bug.cgi?id=418431
--
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
Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)
John Keeping wrote: I am not convinced that tools for interoperating with other VCSs need to be part of core Git; as Junio has pointed out previously, while contrib/ was necessary for promoting associated tools when Git was young and had not established mindshare, Git is now by far the most popular DVCS and is rapidly catching up with centralized systems. Associated tools can therefore live on their own and do not need to be promoted as part of Git itself (as git-imerge is doing successfully). Then let's remove git-p4. In the case of git-remote-hg specifically, the remote helper has to use an interface that the Mercurial developers consider unstable [1]; There is no other sensible way of doing them. the version currently on 'pu' fails the test suite for me because I have Mercurial 3.0: AttributeError: 'mqrepo' object has no attribute 'getbundle' And because this patch has not been picked up[1]. I do not want to end up in a situation where an update to Git is blocked by a distribution because git-remote-hg is not updated to support newer versions of Mercurial sufficiently quickly; this previously happened in Gentoo due to git-svn and meant that was stuck on 1.7.8 until 1.7.13 was released [2]. Travis-CI ensures that won't happen[2]. Since the remote helper interface is stable and the remote helpers do not use any of the Git internals, I consider the risks of including them in core Git to outweigh the benefits of wider distribution. In fact, the remote helpers may benefit from having their own release cadences so that they can respond to changes in related projects more quickly than the normal Git release cycle. Maybe, but git-remote-hg has already benefitted a lot from the wider exposure of being in 'contrib/', I'm sure it would benefit even more if it's distributed by default. Moreover, there's a ton of subpar tools out there[3], and I believe giving the burden of choosing one to the user is detrimental to the Git project. If we as a project say: this is the one we recommend, and has the Git stamp, that helps the users tremendously. Your point is valid though, but it's valid not just for git-remote-hg/bzr. So I think these are the two options: 1) Include git-remote-hg/bzr to the core and distribute them by default (as is the current intention) 2) Remove git-remote-hg/bzr entirely from the Git tree. And do the same for other tools: git-p4, git-svn, git-cvs*. Given the huge amount of people using Subversion, we might want to defer that one for later, but eventually do it. I'd say for v2.0 we should go for 1), and 2) should be considered for v3.0, perhaps. [1] http://article.gmane.org/gmane.comp.version-control.git/248065 [2] https://travis-ci.org/felipec/git [3] https://github.com/felipec/git/wiki/Comparison-of-git-remote-hg-alternatives -- Felipe Contreras -- 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
Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)
On Mon, May 05, 2014 at 02:08:28PM -0500, Felipe Contreras wrote: John Keeping wrote: I am not convinced that tools for interoperating with other VCSs need to be part of core Git; as Junio has pointed out previously, while contrib/ was necessary for promoting associated tools when Git was young and had not established mindshare, Git is now by far the most popular DVCS and is rapidly catching up with centralized systems. Associated tools can therefore live on their own and do not need to be promoted as part of Git itself (as git-imerge is doing successfully). Then let's remove git-p4. If git-p4 were not already in the core, I would be making precisely the same argument regarding it (and the others you identify below). In the case of git-remote-hg specifically, the remote helper has to use an interface that the Mercurial developers consider unstable [1]; There is no other sensible way of doing them. the version currently on 'pu' fails the test suite for me because I have Mercurial 3.0: AttributeError: 'mqrepo' object has no attribute 'getbundle' And because this patch has not been picked up[1]. And it is now probably too late for that to make Git 2.0, which means it may be another 12 weeks before it makes it into a Git release. Since this is quite a minor change it may make it into a stable release, but what would happen if the required changes were much more involved? I do not want to end up in a situation where an update to Git is blocked by a distribution because git-remote-hg is not updated to support newer versions of Mercurial sufficiently quickly; this previously happened in Gentoo due to git-svn and meant that was stuck on 1.7.8 until 1.7.13 was released [2]. Travis-CI ensures that won't happen[2]. I don't see that building against Mercurial's default branch, so it will not help with future releases. Since the remote helper interface is stable and the remote helpers do not use any of the Git internals, I consider the risks of including them in core Git to outweigh the benefits of wider distribution. In fact, the remote helpers may benefit from having their own release cadences so that they can respond to changes in related projects more quickly than the normal Git release cycle. Maybe, but git-remote-hg has already benefitted a lot from the wider exposure of being in 'contrib/', I'm sure it would benefit even more if it's distributed by default. Is that because it was included in contrib/ or just as a result of being publicised on this list and elsewhere? I don't think git-imerge is suffering from being its own project and git-subtree appears to have received very little attention despite being in contrib/. Moreover, there's a ton of subpar tools out there[3], and I believe giving the burden of choosing one to the user is detrimental to the Git project. If we as a project say: this is the one we recommend, and has the Git stamp, that helps the users tremendously. But by choosing one now, we are stuck promoting that one even if a better alternative comes along in the future. We have seen that with git-cvsimport and it's not dissimilar to the situation with git-pull. Your point is valid though, but it's valid not just for git-remote-hg/bzr. So I think these are the two options: 1) Include git-remote-hg/bzr to the core and distribute them by default (as is the current intention) 2) Remove git-remote-hg/bzr entirely from the Git tree. And do the same for other tools: git-p4, git-svn, git-cvs*. Given the huge amount of people using Subversion, we might want to defer that one for later, but eventually do it. Don't forget git-archimport... My personal vote would be for 2), splitting the bridges to other VCSs into their own repositories but there would need to be some guarantee that they would continue to be maintained. I'm not sure it needs to wait for a major Git release since most of the impact is on package maintainers and not end users. I'd say for v2.0 we should go for 1), and 2) should be considered for v3.0, perhaps. I don't think there is any advantage to adding new tools now if we only intend to remove them in the future. [1] http://article.gmane.org/gmane.comp.version-control.git/248065 [2] https://travis-ci.org/felipec/git [3] https://github.com/felipec/git/wiki/Comparison-of-git-remote-hg-alternatives -- 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
Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)
John Keeping wrote: On Mon, May 05, 2014 at 02:08:28PM -0500, Felipe Contreras wrote: John Keeping wrote: I am not convinced that tools for interoperating with other VCSs need to be part of core Git; as Junio has pointed out previously, while contrib/ was necessary for promoting associated tools when Git was young and had not established mindshare, Git is now by far the most popular DVCS and is rapidly catching up with centralized systems. Associated tools can therefore live on their own and do not need to be promoted as part of Git itself (as git-imerge is doing successfully). Then let's remove git-p4. If git-p4 were not already in the core, I would be making precisely the same argument regarding it (and the others you identify below). So basically you are arguing against any change. the version currently on 'pu' fails the test suite for me because I have Mercurial 3.0: AttributeError: 'mqrepo' object has no attribute 'getbundle' And because this patch has not been picked up[1]. And it is now probably too late for that to make Git 2.0, That's not for you to decide. which means it may be another 12 weeks before it makes it into a Git release. Since this is quite a minor change it may make it into a stable release, but what would happen if the required changes were much more involved? All the Mercurial API compatibility issues I have seen are trivial. I do not want to end up in a situation where an update to Git is blocked by a distribution because git-remote-hg is not updated to support newer versions of Mercurial sufficiently quickly; this previously happened in Gentoo due to git-svn and meant that was stuck on 1.7.8 until 1.7.13 was released [2]. Travis-CI ensures that won't happen[2]. I don't see that building against Mercurial's default branch, so it will not help with future releases. I can easily add that. Since the remote helper interface is stable and the remote helpers do not use any of the Git internals, I consider the risks of including them in core Git to outweigh the benefits of wider distribution. In fact, the remote helpers may benefit from having their own release cadences so that they can respond to changes in related projects more quickly than the normal Git release cycle. Maybe, but git-remote-hg has already benefitted a lot from the wider exposure of being in 'contrib/', I'm sure it would benefit even more if it's distributed by default. Is that because it was included in contrib/ or just as a result of being publicised on this list and elsewhere? The former I'd bet. I don't think git-imerge is suffering from being its own project and git-subtree appears to have received very little attention despite being in contrib/. Apples and oranges. There aren't scores of tools out there trying to do what git-subtree does. Moreover, there's a ton of subpar tools out there[3], and I believe giving the burden of choosing one to the user is detrimental to the Git project. If we as a project say: this is the one we recommend, and has the Git stamp, that helps the users tremendously. But by choosing one now, we are stuck promoting that one even if a better alternative comes along in the future. Are there better alternatives coming in the future? Your point is valid though, but it's valid not just for git-remote-hg/bzr. So I think these are the two options: 1) Include git-remote-hg/bzr to the core and distribute them by default (as is the current intention) 2) Remove git-remote-hg/bzr entirely from the Git tree. And do the same for other tools: git-p4, git-svn, git-cvs*. Given the huge amount of people using Subversion, we might want to defer that one for later, but eventually do it. Don't forget git-archimport... My personal vote would be for 2), splitting the bridges to other VCSs into their own repositories but there would need to be some guarantee that they would continue to be maintained. I'm not sure it needs to wait for a major Git release since most of the impact is on package maintainers and not end users. Sure, we might not need to wait for v3.0, but that's not the point. The point is that we should be consistent, and that means going for 1) in v2.0. I'd say for v2.0 we should go for 1), and 2) should be considered for v3.0, perhaps. I don't think there is any advantage to adding new tools now if we only intend to remove them in the future. Do we intend to remove them in the future? That hasn't been decided. -- Felipe Contreras -- 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
Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)
Felipe Contreras wrote: John Keeping wrote: I don't see that building against Mercurial's default branch, so it will not help with future releases. I can easily add that. There: https://travis-ci.org/felipec/git -- Felipe Contreras -- 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
Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)
John Keeping j...@keeping.me.uk writes:
On Tue, Apr 29, 2014 at 03:38:07PM -0700, Junio C Hamano wrote:
* fc/remote-helpers-hg-bzr-graduation (2014-04-29) 11 commits
...
Move remote-hg and remote-bzr out of contrib/. There were some
suggestions on the follow-up fix patches still not in 'next', which
may result in a reroll.
Will merge to 'next' and keep it there for the remainder of the
cycle.
I'd like to register my opposition to moving git-remote-{bzr,hg} out of
contrib/.
...
In the case of git-remote-hg specifically, the remote helper has to use
an interface that the Mercurial developers consider unstable [1];...
I do not want to end up in a situation where an update to Git is blocked
by a distribution because git-remote-hg is not updated to support newer
versions of Mercurial sufficiently quickly; this previously happened in
Gentoo due to git-svn and meant that was stuck on 1.7.8 until 1.7.13 was
released [2].
The same argument would apply to git-svn, git-p4, and git-cvsimport,
I would think.
Among these, I am not sure if we can find willing maintainers who
can give enough love to them. But unlike these other importers,
remote-hg and remote-bzr do have an active maintainer (and IIRC I
think I heard that Hg one even has an active competitor or two?) so
I am reasonably confident that these can live on their own merit
outside of my tree. In the ideal world, I would think it may be
even beneficial to the end users of these helpers to unbundle them.
You raised a good point on the issue of external dependencies may
impact Git as a whole, even for those who are not interested in the
particular remote helpers at all. I'll have to think about it.
The silly thing is that I totally forgot that we almost got
ourselves into a very similar situation on cvsimport when a series
wanted to make it cvsps3-only. It is very possible nobody would
have picked up the entire new release, if we merged that change.
Having said all that, there is one caveat.
Since the remote helper interface is stable and the remote helpers do
not use any of the Git internals, I consider the risks of including them
in core Git to outweigh the benefits of wider distribution.
You are correct to say that a remote helper has to talk with a
foreign system and it would not help to dictate the update schedule
of helpers to match the release cycle of Git itself. At the same
time, however, the interface the remote helpers use to talk to Git
has not been as stable as you seem to think, I am afraid. For
example, a recent remote-hg/bzr series needed some enhancements to
fast-import to achieve the feature parity with native transports by
adding a missing feature or two on the Git side.
So in reality, a helper has to talk with two sides, needs to adjust
to changes in the both sides, and both sides are changing.
Unbundling a helper from Git would place more burden on the helper's
maintainer, because the helper has to know enough about versions and
features of both sides (the foreign system and Git) to adjust its
behaviour, to stay compatible with wider versions of both foreign
systems and Git. Unbundling, when done properly, may give more
ideal user experience to the end users, because such a helper would
allow them to pick up the latest (or stay on an older but known to
be stable) version of the helper and expect it to work with the
foreign system and Git they happen to have.
It however would be easier to maintain if the helper maintainer
knows a change to Git itself will be released at the same time as
the new version of the helper that takes advantage of the modified
Git. The helper maintainer only has to worry about compatibility
with the foreign side if it is bundled with Git.
So it boils down to how much resource are there to make sure a
helper will stay compatible with wider versions of both sides? and
how far backwards are helper maintainers willing to bend to support
users better?.
--
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
Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)
Junio C Hamano wrote: John Keeping j...@keeping.me.uk writes: In the case of git-remote-hg specifically, the remote helper has to use an interface that the Mercurial developers consider unstable [1];... I do not want to end up in a situation where an update to Git is blocked by a distribution because git-remote-hg is not updated to support newer versions of Mercurial sufficiently quickly; this previously happened in Gentoo due to git-svn and meant that was stuck on 1.7.8 until 1.7.13 was released [2]. The same argument would apply to git-svn, git-p4, and git-cvsimport, I would think. Among these, I am not sure if we can find willing maintainers who can give enough love to them. But unlike these other importers, remote-hg and remote-bzr do have an active maintainer (and IIRC I think I heard that Hg one even has an active competitor or two?) Unfortunately there are no more real competitors to remote-hg. A far as I can tell msysgit has dropped their remote helper, and gitifyhg is not being actively maintatined and it's even pointing to our git-remote-hg as probably the best alternative to use at the moment. so I am reasonably confident that these can live on their own merit outside of my tree. In the ideal world, I would think it may be even beneficial to the end users of these helpers to unbundle them. It might be benefitial in the future, but right now I'm willing to bet there's many people that don't know git-remote-hg/bzr even exist. If Git v2.0 distributes them by default, and they are mentioned in the release notes: * Transparent support to pull and push to and from Mercurial and Bazaar repositories is now enabled by default. Many more people will know about that, and in the future when we try to unbundle them they can shout if for some reason it would be inconvenient for them. At the moment I don't think we can say for sure. Even if people don't use these bridges, I think just mentioning that feature helps the project in general. You raised a good point on the issue of external dependencies may impact Git as a whole, even for those who are not interested in the particular remote helpers at all. I'll have to think about it. Yes, it's worth thinking about it because it's a real possibility. However, real possibilities are many times not likely to happen, and I think this is one of those cases. As I've said, if history is any indication these issues won't happen. As far as I can remember the only issues that have happened are backwards compatibility issues, not present or future. And as I said I've setup TravisCI builds to detect those, which is why we haven't had those issues since then. So it boils down to how much resource are there to make sure a helper will stay compatible with wider versions of both sides? and how far backwards are helper maintainers willing to bend to support users better?. This is not that big of an issue. For example, notice how the changes in the transport-helper to enable say --force and --dry-run did not require to align changes in remote-hg/bzr. That's because remote-hg/bzr had already the code for these features, it was just not exercised until the transport-helper was modified. I think the current transport-helper infraestructure is already good enough to detect the features and options of the remote helpers so unbundling wouldn't be a major problem. Having said that alignment issues do happen, and we have one of those in Git v2.0, but I don't think they are a major concern (at least for remote-hg/bzr). -- Felipe Contreras -- 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
Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)
Felipe Contreras wrote:
Having said that alignment issues do happen, and we have one of those
in Git v2.0, but I don't think they are a major concern (at least for
remote-hg/bzr).
Actually I just noticed that the remote-helpers side is not in the
master branch.
I don't know what is your plan with fc/remote-helpers-hg-bzr-graduation,
but for v2.0 we really want the patch 'remote-{hg,bzr}: store marks only
on success'. Explaining precisely why would take a lot of effort, but
basically it's related to 3994e64 (transport-helper: fix sync issue on
crashes).
If you are worried about merging the whole branch, I could pick only the
important patches and reroll.
--
Felipe Contreras
--
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
What's cooking in git.git (Apr 2014, #09; Tue, 29)
Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. The tip of the 'master' branch has passed v2.0.0-rc1. Last minute fixes to newly added code keep flowing in, which is good. I've picked up some topics that will not be part of the upcoming release to 'pu' not to lose them, but I didn't have time to give them a deep reading. You can find the changes described here in the integration branches of the repositories listed at http://git-blame.blogspot.com/p/git-public-repositories.html -- [New Topics] * cc/replace-edit (2014-04-29) 4 commits - replace: add --edit option - replace: factor object resolution out of replace_object - replace: use OPT_CMDMODE to handle modes - replace: refactor command-mode determination * da/imap-send-use-credential-helper (2014-04-29) 1 commit - imap-send: use git-credential * dk/blame-reorg (2014-04-28) 1 commit - blame: large-scale performance rewrite * je/pager-do-not-recurse (2014-04-28) 1 commit - pager: do allow spawning pager recursively * jk/commit-C-pick-empty (2014-04-28) 1 commit - commit: do not complain of empty messages from -C * jk/utf8-switch-between-nfd-and-nfc (2014-04-29) 1 commit - t3910: show failure of core.precomposeunicode with decomposed filenames * mt/send-email-cover-to-cc (2014-04-29) 2 commits - test/send-email: to-cover, cc-cover tests - git-send-email: two new options: to-cover, cc-cover * nd/split-index (2014-04-29) 33 commits - SQUASH??? - t1700: new tests for split-index mode - t2104: make sure split index mode is off for the version test - read-cache: force split index mode with GIT_TEST_SPLIT_INDEX - read-tree: note about dropping split-index mode or index version - read-tree: force split-index mode off on --index-output - rev-parse: add --shared-index-path to get shared index path - update-index --split-index: do not split if $GIT_DIR is read only - update-index: new options to enable/disable split index mode - split-index: strip pathname of on-disk replaced entries - split-index: do not invalidate cache-tree at read time - split-index: the reading part - split-index: the writing part - read-cache: mark updated entries for split index - read-cache: save deleted entries in split index - read-cache: mark new entries for split index - read-cache: split-index mode - read-cache: save index SHA-1 after reading - entry.c: update cache_changed if refresh_cache is set in checkout_entry() - cache-tree: mark istate-cache_changed on prime_cache_tree() - cache-tree: mark istate-cache_changed on cache tree update - cache-tree: mark istate-cache_changed on cache tree invalidation - unpack-trees: be specific what part of the index has changed - resolve-undo: be specific what part of the index has changed - update-index: be specific what part of the index has changed - read-cache: be specific what part of the index has changed - read-cache: be strict about changed in remove_marked_cache_entries() - read-cache: store in-memory flags in the first 12 bits of ce_flags - read-cache: relocate and unexport commit_locked_index() - read-cache: new API write_locked_index instead of write_index/write_cache - sequencer: do not update/refresh index if the lock cannot be held - ewah: delete unused ewah_read_mmap_native declaration - ewah: fix constness of ewah_read_mmap * tl/relax-in-poll-emulation (2014-04-29) 1 commit - compat/poll: sleep 1 millisecond to avoid busy wait -- [Stalled] * tr/merge-recursive-index-only (2014-02-05) 3 commits - merge-recursive: -Xindex-only to leave worktree unchanged - merge-recursive: internal flag to avoid touching the worktree - merge-recursive: remove dead conditional in update_stages() (this branch is used by tr/remerge-diff.) Will hold. * tr/remerge-diff (2014-02-26) 5 commits . log --remerge-diff: show what the conflict resolution changed . name-hash: allow dir hashing even when !ignore_case . merge-recursive: allow storing conflict hunks in index . revision: fold all merge diff variants into an enum merge_diff_mode . combine-diff: do not pass revs-dense_combined_merges redundantly (this branch uses tr/merge-recursive-index-only.) log -p output learns a new way to let users inspect a merge commit by showing the differences between the automerged result with conflicts the person who recorded the merge would have seen and the final conflict resolution that was recorded in the merge. Needs to be rebased, now kb/fast-hashmap topic is in. * jk/makefile (2014-02-05) 16 commits - FIXUP - move LESS/LV pager environment to Makefile - Makefile: teach scripts to include make variables - FIXUP - Makefile: auto-build C strings from make variables - Makefile: drop *_SQ variables - FIXUP - Makefile: add c-quote helper function - Makefile: introduce sq
