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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
-
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;
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
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
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
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
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
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
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
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 ...
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
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
-
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
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
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
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
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
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
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
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
34 matches
Mail list logo
