* git include
From: Rakotomandimby Mihamina @ 2009-11-30 6:41 UTC (permalink / raw)
To: git
Hi all,
I would like to track only *.ml files and ignore all others.
Is there a way to do that in .gitignore?
Thanks.
--
Architecte Informatique chez Blueline/Gulfsat:
Administration Systeme, Recherche & Developpement
+261 33 11 207 36
^ permalink raw reply
* Re: git include
From: Nguyen Thai Ngoc Duy @ 2009-11-30 6:45 UTC (permalink / raw)
To: Rakotomandimby Mihamina; +Cc: git
In-Reply-To: <4B136932.9000908@gulfsat.mg>
On Mon, Nov 30, 2009 at 1:41 PM, Rakotomandimby Mihamina
<mihamina@gulfsat.mg> wrote:
> Hi all,
>
> I would like to track only *.ml files and ignore all others.
> Is there a way to do that in .gitignore?
This .gitignore should work (of course for new files only):
-->8--
*
!*.ml
-->8--
--
Duy
^ permalink raw reply
* Re: [PATCH v2 6/6] INSTALL: document a simpler way to run uninstalled builds
From: Junio C Hamano @ 2009-11-30 6:48 UTC (permalink / raw)
To: Matthew Ogilvie; +Cc: git
In-Reply-To: <1259561971-25730-7-git-send-email-mmogilvi_git@miniinfo.net>
Matthew Ogilvie <mmogilvi_git@miniinfo.net> writes:
> diff --git a/INSTALL b/INSTALL
> index be504c9..ee718c6 100644
> --- a/INSTALL
> +++ b/INSTALL
> @@ -39,7 +39,19 @@ Issues of note:
> with --disable-transition option to avoid this.
>
> - You can use git after building but without installing if you
> - wanted to. Various git commands need to find other git
> + want to.
> +
> + The simplest option for running some manual tests of a build
> + before installing it is to use the wrapper scripts that are built
> + and saved into `pwd`/bin-wrappers. Either invoke the scripts in
> + bin-wrappers using their full paths, put bin-wrappers in your
> + PATH, or copy/symlink just the bin-wrappers scripts into somewhere
> + already in your PATH. But this option is slightly inefficient,
> + so for a more permanent solution we recommend either installing
> + git (you can set a prefix to install right next to your
> + build directory), or use the alternative below.
Drop "simplest" and "slightly".
I think you forgot to mention an important improvement you made since the
earlier iteration on the wrap-for-bin script in the cover letter. With
the new wrap-for-bin, we do not have to worry about the case a random
binary in the directory is run without first adding anything to user's
$PATH anymore, no?
With that change, this round's implementation deserves to be recommended
as the new preferred way to run "use after building without installing", I
think. So how about making the text like this?
You can use git after building but without installing if you want to
test drive it. Simply run git found in bin-wrappers directory in the
build directory, or prepend that directory to your $PATH. This
however is less efficient than running an installed git, as you always
need an extra fork+exec to run any git subcommand.
It is still possible to use git without installing by setting a few
environment variables, which was the way this was done traditionally.
But using git found in bin-wrappers directory in the build directory
is far simpler. Just for a historical reference, the old way went
like this:
GIT_EXEC_PATH=`pwd`
PATH=`pwd`:$PATH
GITPERLLIB=`pwd`/perl/blib/lib
export GIT_EXEC_PATH PATH GITPERLLIB
^ permalink raw reply
* Re: [PATCH v3] Give the hunk comment its own color
From: Bert Wesarg @ 2009-11-30 7:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <36ca99e90911280408v186777f1h22254744fb61bf1f@mail.gmail.com>
>> /* blank before the func header */
>> for (cp = ep; ep - line < len; ep++)
>> if (*ep != ' ' && *ep != 't')
> Please check that its really an *ep != '\t'. Its wrong in this mail, I
> see only an *ep != 't'.
Obviously, you have not checked it. Please squash this in:
diff --git i/diff.c w/diff.c
index eaa1983..e126304 100644
--- i/diff.c
+++ w/diff.c
@@ -376,7 +376,7 @@ static void emit_hunk_header(struct emit_callback *ecbdata,
/* blank before the func header */
for (cp = ep; ep - line < len; ep++)
- if (*ep != ' ' && *ep != 't')
+ if (*ep != ' ' && *ep != '\t')
break;
if (ep != cp)
emit_line(ecbdata->file, plain, reset, cp, ep - cp);
Bert
^ permalink raw reply related
* Re: [PATCH 3/4] build dashless "test-bin" directory similar to installed bindir
From: Nanako Shiraishi @ 2009-11-30 7:07 UTC (permalink / raw)
To: Matthew Ogilvie; +Cc: Junio C Hamano, git, peff
In-Reply-To: <20091129025251.GA1771@comcast.net>
Quoting Matthew Ogilvie <mmogilvi_git@miniinfo.net>
> 4. Rename test-bin. Perhaps "bin-wrappers", "bin-dashless",
> "bin-install", "bin", or "bindir". Any preferences?
"gitrun" or "rungit"?
I prefer the latter because too many files begin with "git" after compiling.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [PATCH v3] Give the hunk comment its own color
From: Junio C Hamano @ 2009-11-30 7:15 UTC (permalink / raw)
To: Bert Wesarg; +Cc: Junio C Hamano, Jeff King, git
In-Reply-To: <36ca99e90911292307w769913fdn1f610eeb065b41e@mail.gmail.com>
Sorry, but I think the fix is already in 'next', no?
^ permalink raw reply
* Re: [PATCH v2 0/6] Run test suite without dashed commands in PATH
From: Junio C Hamano @ 2009-11-30 7:16 UTC (permalink / raw)
To: Matthew Ogilvie; +Cc: git
In-Reply-To: <1259561971-25730-1-git-send-email-mmogilvi_git@miniinfo.net>
I added t9150 to your second patch and pushed the result out on 'pu'.
^ permalink raw reply
* Re: [PATCH] reset: add --quiet option
From: Junio C Hamano @ 2009-11-30 7:17 UTC (permalink / raw)
To: Stephen Boyd; +Cc: Felipe Contreras, git
In-Reply-To: <1259543939.5679.5.camel@swboyd-laptop>
Stephen Boyd <bebarino@gmail.com> writes:
> Why not just OPT__QUIET?
Good question. I was in no hurry to queue this, so Felipe has plenty time
to respond.
^ permalink raw reply
* Re: git include
From: Armen Baghumian @ 2009-11-30 7:10 UTC (permalink / raw)
To: git
In-Reply-To: <fcaeb9bf0911292245t6b18c238s2859d2cbd5dd26be@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 480 bytes --]
Probably you want to add .gitignore too
*
!*.ml
!.gitignore
On Mon, 30 Nov 2009 13:45:57 +0700
Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> On Mon, Nov 30, 2009 at 1:41 PM, Rakotomandimby Mihamina
> <mihamina@gulfsat.mg> wrote:
> > Hi all,
> >
> > I would like to track only *.ml files and ignore all others.
> > Is there a way to do that in .gitignore?
>
> This .gitignore should work (of course for new files only):
> -->8--
> *
> !*.ml
> -->8--
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: git include
From: Nguyen Thai Ngoc Duy @ 2009-11-30 7:29 UTC (permalink / raw)
To: Armen Baghumian; +Cc: git
In-Reply-To: <20091130104055.3c3274f5@Office>
On Mon, Nov 30, 2009 at 2:10 PM, Armen Baghumian
<armen@opensourceclub.org> wrote:
>
> Probably you want to add .gitignore too
>
> *
> !*.ml
> !.gitignore
In that case it should be "!.git*" as you may miss .gitattributes or .gitmodules
--
Duy
^ permalink raw reply
* Re: git include
From: Rakotomandimby Mihamina @ 2009-11-30 7:33 UTC (permalink / raw)
To: git
In-Reply-To: <fcaeb9bf0911292329p672572dcmbe0c01912d50fd0a@mail.gmail.com>
11/30/2009 10:29 AM, Nguyen Thai Ngoc Duy::
>> Probably you want to add .gitignore too
>> *
>> !*.ml
>> !.gitignore
> In that case it should be "!.git*" as you may miss .gitattributes or .gitmodules
*
!*.ml
Is perfect for me.
Thanks, guys.
--
Architecte Informatique chez Blueline/Gulfsat:
Administration Systeme, Recherche & Developpement
+261 33 11 207 36
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2009, #07; Sun, 29)
From: Junio C Hamano @ 2009-11-30 7:34 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <7vocmlbq8d.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> This will be the last update before deciding what should go in 1.6.6-rc1
> and describes my current thinking.
I do not want to decide unilaterally what will be in and what will be left
out of 1.6.6, so here is a seocnd call for comments.
I said "Perhaps merge it to 'master' before 1.6.6-rc1?" for these:
> * uk/maint-shortlog-encoding (2009-11-25) 1 commit.
> * fc/send-email-envelope (2009-11-26) 2 commits.
> * jc/mailinfo-remove-brackets (2009-07-15) 1 commit.
> * tr/reset-checkout-patch (2009-11-19) 1 commit.
> * em/commit-claim (2009-11-04) 1 commit
> * cc/bisect-doc (2009-11-08) 1 commit
> * jc/pretty-lf (2009-10-04) 1 commit.
> * ns/send-email-no-chain-reply-to (2009-11-29) 1 commit
I didn't say so in the message but I think this is Ok for 1.6.6-rc1.
> * bw/diff-color-hunk-header (2009-11-27) 2 commits
I would love to see necessary fix-ups to make them suitable and include in
the 1.6.6 final for these:
> * jn/gitweb-blame (2009-11-24) 8 commits.
I am inclined to keep the rest out of 1.6.6.
Even though I did it myself, I am ambivalent about the diff.bwoutputonly
anti-procrastination measure. The send-email one looked fine and is a
welcome addition to the "don't surprise users" effort to prepare for 1.7.0,
and diff.bwoutputonly is in a sense in a similar spirit, but an option to
keep an old and broken semantics feels somewhat wrong.
Also anybody has comments on the part for preparing users for 1.7.0 in the
draft release notes?
^ permalink raw reply
* Re: [PATCH v3] Give the hunk comment its own color
From: Bert Wesarg @ 2009-11-30 7:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <7v4ooczdoe.fsf@alter.siamese.dyndns.org>
On Mon, Nov 30, 2009 at 08:15, Junio C Hamano <gitster@pobox.com> wrote:
> Sorry, but I think the fix is already in 'next', no?
Yes it is, should have fetched first. sorry.
^ permalink raw reply
* Re: [PATCH v3] Give the hunk comment its own color
From: Junio C Hamano @ 2009-11-30 7:47 UTC (permalink / raw)
To: Bert Wesarg; +Cc: Junio C Hamano, Jeff King, git
In-Reply-To: <36ca99e90911292341o524840ebo47d79f06b1588d5c@mail.gmail.com>
Bert Wesarg <bert.wesarg@googlemail.com> writes:
> On Mon, Nov 30, 2009 at 08:15, Junio C Hamano <gitster@pobox.com> wrote:
>> Sorry, but I think the fix is already in 'next', no?
> Yes it is, should have fetched first. sorry.
Don't be sorry; thanks for catching it.
The current 'next' branch has the original commit with a botched rewrite
by mine, and also a fixed commit, so unfortunately shortlog would list the
patch twice. I'll merge the updated (i.e. rewound and then rebuilt) tip
of the topic branch when the topic graduates to the master (hopefully
before 1.6.6-rc1), so we won't see the botched one in the end result.
^ permalink raw reply
* Re: [PATCH] Update $GIT_DIR/remotes to $GIT_DIR/refs/remotes in docs
From: Nazri Ramliy @ 2009-11-30 7:48 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20091130050333.GA26585@coredump.intra.peff.net>
On Mon, Nov 30, 2009 at 1:03 PM, Jeff King <peff@peff.net> wrote:
> Er, what? $GIT_DIR/remotes/ and $GIT_DIR/refs/remotes/ are not even
> remotely the same thing. The former holds information about how to
> contact remotes (but that information is usually held in the config file
> these days). The latter holds any tracking refs we have fetched from
> the remotes.
Erg.. thanks for the enlightenment.
I was reading 'git help remote' while attempting to change my local git
repo from tracking
http://www.kernel.org/pub/scm/git/git.git
to
git://git.kernel.org/pub/scm/git/git.git
and noticed that the documentation refers to $GIT_DIR/remotes and
(wrongly) thought that it meant $GIT_DIR/refs/remotes.
Sorry for the noise.
Nazri.
^ permalink raw reply
* [PATCH] tests: handle NO_PYTHON setting
From: Jeff King @ 2009-11-30 7:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sverre Rabbelier, git
Without this, test-lib checks that the git_remote_helpers
directory has been built. However, if we are building
without python, we will not have done anything at all in
that directory, and test-lib's sanity check will fail.
Signed-off-by: Jeff King <peff@peff.net>
---
On top of sr/vcs-helper.
This feels a little funny for NO_PYTHON to mean "no remote helpers at
all". But that is the way the Makefile is set up, since we seem to have
only python helpers.
Makefile | 1 +
t/test-lib.sh | 2 +-
2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 42744a4..443565e 100644
--- a/Makefile
+++ b/Makefile
@@ -1743,6 +1743,7 @@ GIT-BUILD-OPTIONS: .FORCE-GIT-BUILD-OPTIONS
@echo TAR=\''$(subst ','\'',$(subst ','\'',$(TAR)))'\' >>$@
@echo NO_CURL=\''$(subst ','\'',$(subst ','\'',$(NO_CURL)))'\' >>$@
@echo NO_PERL=\''$(subst ','\'',$(subst ','\'',$(NO_PERL)))'\' >>$@
+ @echo NO_PYTHON=\''$(subst ','\'',$(subst ','\'',$(NO_PYTHON)))'\' >>$@
### Detect Tck/Tk interpreter path changes
ifndef NO_TCLTK
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 4a40520..ca0839c 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -638,7 +638,7 @@ test -d ../templates/blt || {
error "You haven't built things yet, have you?"
}
-if test -z "$GIT_TEST_INSTALLED"
+if test -z "$GIT_TEST_INSTALLED" && test -z "$NO_PYTHON"
then
GITPYTHONLIB="$(pwd)/../git_remote_helpers/build/lib"
export GITPYTHONLIB
--
1.6.6.rc0.327.gd49b
^ permalink raw reply related
* Re: git include
From: Armen Baghumian @ 2009-11-30 7:53 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <fcaeb9bf0911292329p672572dcmbe0c01912d50fd0a@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 372 bytes --]
Yups, right
On Mon, 30 Nov 2009 14:29:46 +0700
Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> On Mon, Nov 30, 2009 at 2:10 PM, Armen Baghumian
> <armen@opensourceclub.org> wrote:
> >
> > Probably you want to add .gitignore too
> >
> > *
> > !*.ml
> > !.gitignore
>
> In that case it should be "!.git*" as you may miss .gitattributes
> or .gitmodules
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] tests: handle NO_PYTHON setting
From: Sverre Rabbelier @ 2009-11-30 7:55 UTC (permalink / raw)
To: Jeff King, Johan Herland, Daniel Barkalow; +Cc: Junio C Hamano, git
In-Reply-To: <20091130075221.GA5421@coredump.intra.peff.net>
Heya,
On Mon, Nov 30, 2009 at 08:52, Jeff King <peff@peff.net> wrote:
> This feels a little funny for NO_PYTHON to mean "no remote helpers at
> all". But that is the way the Makefile is set up, since we seem to have
> only python helpers.
I don't understand what you mean? Do you mean NO_PYTHON implies "no
remote helpers at all", or "not having any remote helpers" implies
NO_PYTHON? Either way, I'm not sure how to set it up differently, not
having that much Makefile foo myself, so maybe Johan and Daniel could
comment?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH] tests: handle NO_PYTHON setting
From: Jeff King @ 2009-11-30 7:59 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Johan Herland, Daniel Barkalow, Junio C Hamano, git
In-Reply-To: <fabb9a1e0911292355v260b9f0ck79d993e25f0c5c61@mail.gmail.com>
On Mon, Nov 30, 2009 at 08:55:51AM +0100, Sverre Rabbelier wrote:
> > This feels a little funny for NO_PYTHON to mean "no remote helpers at
> > all". But that is the way the Makefile is set up, since we seem to have
> > only python helpers.
>
> I don't understand what you mean? Do you mean NO_PYTHON implies "no
> remote helpers at all", or "not having any remote helpers" implies
> NO_PYTHON? Either way, I'm not sure how to set it up differently, not
> having that much Makefile foo myself, so maybe Johan and Daniel could
> comment?
I mean, I would think that the "git_remote_helpers" directory contained
remote helpers of all sorts, not just the python ones. Right now we
_only_ have python ones. So checking for NO_PYTHON in test-lib.sh before
looking at git_remote_helpers makes sense. But I am concerned that
assumption will be broken silently in the future if non-python helpers
are added to git_remote_helpers.
It is probably not worth caring about too much, though.
-Peff
^ permalink raw reply
* Re: [PATCH] tests: handle NO_PYTHON setting
From: Sverre Rabbelier @ 2009-11-30 8:04 UTC (permalink / raw)
To: Jeff King; +Cc: Johan Herland, Daniel Barkalow, Junio C Hamano, git
In-Reply-To: <20091130075927.GA5767@coredump.intra.peff.net>
Heya,
On Mon, Nov 30, 2009 at 08:59, Jeff King <peff@peff.net> wrote:
> I mean, I would think that the "git_remote_helpers" directory contained
> remote helpers of all sorts, not just the python ones.
I don't think that's true, git.git currently does not have such a
structure (everything is just dumped in the root directory). The only
reason git_remote_helpers exists is to make it easier to create a
python egg out of it and install that. At least, that's what I think
is going on, Johan and Daniel might have comments to the contrary.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH] tests: handle NO_PYTHON setting
From: Jeff King @ 2009-11-30 8:05 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Johan Herland, Daniel Barkalow, Junio C Hamano, git
In-Reply-To: <fabb9a1e0911300004w36c5da45q354aa4ff3153b6f4@mail.gmail.com>
On Mon, Nov 30, 2009 at 09:04:25AM +0100, Sverre Rabbelier wrote:
> On Mon, Nov 30, 2009 at 08:59, Jeff King <peff@peff.net> wrote:
> > I mean, I would think that the "git_remote_helpers" directory contained
> > remote helpers of all sorts, not just the python ones.
>
> I don't think that's true, git.git currently does not have such a
> structure (everything is just dumped in the root directory). The only
> reason git_remote_helpers exists is to make it easier to create a
> python egg out of it and install that. At least, that's what I think
> is going on, Johan and Daniel might have comments to the contrary.
OK. It is just my confusion, then. Don't worry about it.
-Peff
^ permalink raw reply
* Re: [PATCH v3] Give the hunk comment its own color
From: Sverre Rabbelier @ 2009-11-30 8:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Bert Wesarg, Jeff King, git
In-Reply-To: <7vtywcwj1o.fsf@alter.siamese.dyndns.org>
Heya,
On Mon, Nov 30, 2009 at 08:47, Junio C Hamano <gitster@pobox.com> wrote:
> I'll merge the updated (i.e. rewound and then rebuilt) tip
> of the topic branch when the topic graduates to the master (hopefully
> before 1.6.6-rc1), so we won't see the botched one in the end result.
I'm curious how you do this. Do you keep a list of replacements, that
is "when merging branch foo from next to master, instead merge bar",
or is it something the original author should remind you of when it's
time to merge to master?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: help reverting a merge
From: Jeff King @ 2009-11-30 8:13 UTC (permalink / raw)
To: Justin Mattock; +Cc: Christian Couder, git
In-Reply-To: <dd18b0c30911291524q7ea7e9c7v980340ddf7269519@mail.gmail.com>
On Sun, Nov 29, 2009 at 03:24:09PM -0800, Justin Mattock wrote:
> I've done a bisect on a problem with the kernel,
> and am a bit confused on what to do. i.g. the
> results are showing this:
> a03fdb7612874834d6847107198712d18b5242c7 is the first bad commit
>
> [...]
>
> how do I find out the commits in this merge to automatically
> revert to find the problem that's causing this bug?
There is some discussion here:
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#bisect-merges
Basically neither merged branch was buggy on its own, but together they
have a bug. You can try rebasing the two sides of the merge into a
linear history, and then bisecting on that:
# order doesn't matter here, but rebasing 12e0933 on top makes more
# sense since it has many fewer commits between it and the merge-base
# (and you'll need to fix up conflicts manually, so the smaller the
# rebase the better)
git checkout 12e0933
git rebase 202c467
# to be safe, confirm that the rebase result shows your bug;
# we know that 202c467 doesn't have the bug, or we would not have
# bisected to the merge commit before
test test test
git bisect start
git bisect bad HEAD
git bisect good 202c467
which should give you the specific commit on the side branch where the
breakage occurred.
This has been discussed as a technique before, and I have a feeling in
the back of my mind that maybe there was talk of having git-bisect help
with this case, but I don't think anything ever came of it. Christian
(cc'd) would probably know more.
-Peff
^ permalink raw reply
* Re: does clone --depth work?
From: Dan Carpenter @ 2009-11-30 8:18 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: git
In-Reply-To: <20091129163242.GA7921@atjola.homenet>
On Sun, Nov 29, 2009 at 05:32:42PM +0100, Björn Steinbrink wrote:
> On 2009.11.29 18:03:52 +0200, Dan Carpenter wrote:
> > I do: `git clone --depth 0 ./repo1/ repo2` I expected that
> > "git log" in repo2 wouldn't show any revisions, but it does.
> >
> > I'm using 1.6.5.3.171.ge36e.dirty (small unrelated modification).
> >
> > Am I doing something incorrectly?
>
> Two problems:
> a) IIRC depth = 0 is like not specifying depth at all
> b) When using plain paths, clone optimizes the process by just doing a
> copy, that doesn't apply the depth setting at all
>
> git clone --depth=1 file://$PWD/repo1 repo2
>
Awesome. That does work.
thanks,
dan
> That should work. Of course you still got some commits, so "git log"
> will show them. You just don't get all of them, but only to a certain
> depth.
>
> Björn
^ permalink raw reply
* Re: [PATCH] tests: handle NO_PYTHON setting
From: Junio C Hamano @ 2009-11-30 8:28 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Jeff King, Johan Herland, Daniel Barkalow, Junio C Hamano, git
In-Reply-To: <fabb9a1e0911300004w36c5da45q354aa4ff3153b6f4@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
> On Mon, Nov 30, 2009 at 08:59, Jeff King <peff@peff.net> wrote:
>> I mean, I would think that the "git_remote_helpers" directory contained
>> remote helpers of all sorts, not just the python ones.
>
> I don't think that's true, git.git currently does not have such a
> structure (everything is just dumped in the root directory). The only
> reason git_remote_helpers exists is to make it easier to create a
> python egg out of it and install that.
If that is the case, shouldn't each of the helper written in Python need
to have a separate directory, not just a single git_remote_helpers
directory shared among them?
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox