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 b
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
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 havin
Chris Packham 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
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
Hi,
On 06/05/14 11:50, Junio C Hamano wrote:
> John Keeping 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
>>> suggestion
Greg Troxel wrote:
>
> Felipe Contreras 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
> >> binar
Felipe Contreras 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 othe
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;
> >
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
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-conf
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
> re
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_PA
On Wed, May 07, 2014 at 11:56:18AM -0700, Junio C Hamano wrote:
> John Keeping 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 w
John Keeping 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
Junio C Hamano 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
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.
> >
> > $
On Tue, May 06, 2014 at 05:01:59PM -0700, Junio C Hamano wrote:
> John Keeping 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
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 w
John Keeping 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 c
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 t
John Keeping 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 som
Junio C Hamano wrote:
> John Keeping 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 pa
John Keeping 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 th
John Keeping wrote:
> 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
On Mon, May 05, 2014 at 04:50:58PM -0700, Junio C Hamano wrote:
> John Keeping 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 co
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 p
Junio C Hamano wrote:
> John Keeping 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 beca
John Keeping 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', whi
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 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 promo
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
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 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
>
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 som
35 matches
Mail list logo
