* Re: [PATCH 3/8] git-merge-recursive-{ours,theirs}
From: Junio C Hamano @ 2009-11-30 6:21 UTC (permalink / raw)
To: Avery Pennarun; +Cc: git
In-Reply-To: <32541b130911261405q6564d8f2o30b7d7fd6f708d05@mail.gmail.com>
Avery Pennarun <apenwarr@gmail.com> writes:
>> - I think we should avoid adding the extra argument to ll_merge_fn() by
>> combining virtual_ancestor and favor into one "flags" parameter. If
>> you do so, we do not have to change the callsites again next time we
>> need to add new optional features that needs only a few bits.
>>
>> I vaguely recall that I did the counterpart of this patch that way
>> exactly for the above reason, but it is more than a year ago, so maybe
>> I didn't do it that way.
>
> You did do that, in fact,... <<rationale omitted>>
Think of the "flag" parameter as a mini "struct option". When you add a
feature to a function at or near the leaf level of call chains that are
potentially deep, you add one element to the option structure, and take
advantage of the fact that existing callers put a sane default value in
the new field, i.e. 0, by doing a "memset(&opt, 0, sizeof(opt))" already,
so that the callsites that do not even have to know about the new feature
will keep working the same old way without breakage. You saw this exact
pattern in the [1/8] patch in your series to cram new "favor this side"
information into an existing parameter.
As you mentioned, sometimes changing function signature is preferred to
catch semantic differences at compilation time. The report given by the
compiler of extra or missing parameter at the call site is a wonderful way
to find out that you forgot to convert them to the new semantics of the
function. This also helps when there is an in-flight patch that adds a
new callsite to the function whose semantics you are changing. The
semantic conflict is caught when compiling the result of a merge with a
branch with such a patch. It is a trick worth knowing about.
The approach however cuts both ways. When you are adding an optional
feature that is used only in a very few call sites, the semantic merge
conflict resulting from such a function signature change is rarely worth
it.
As long as you choose the default "no-op" value carefully enough so that
existing callers will naturally use it without modification, the old code
will work the way they did before the new optional feature was added. In
other words, "let's implement this as purely an opt-in feature" is often
preferrable over "let's force semantic conflict and compilation failure,
just in case existing callsites may also want to trigger this new
feature".
That is why [1/8] patch in your series uses 0 to mean "don't do the funny
'favor' trick, but just leave the conflicts there".
I've queued the series with minor fixes to 'pu' and pushed it out.
^ permalink raw reply
* [PATCH v2 6/6] INSTALL: document a simpler way to run uninstalled builds
From: Matthew Ogilvie @ 2009-11-30 6:19 UTC (permalink / raw)
To: git, gitster; +Cc: Matthew Ogilvie
In-Reply-To: <1259561971-25730-6-git-send-email-mmogilvi_git@miniinfo.net>
The new scripts automatically saved in the bin-wrappers
directory allow you test run a build when you have neither installed
git nor tweaked environment variables. Mention this in INSTALL,
along with the slight performance issue of doing so.
This can be especially handy for manually testing
network-invoked git (from ssh, web servers, or similar), but
it is also handy with a plain command prompt.
Signed-off-by: Matthew Ogilvie <mmogilvi_git@miniinfo.net>
---
INSTALL | 14 +++++++++++++-
1 files changed, 13 insertions(+), 1 deletions(-)
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.
+
+ Alternatively, various git commands need to find other git
commands and scripts to do their work, so you would need to
arrange a few environment variables to tell them that their
friends will be found in your built source area instead of at
--
1.6.4.GIT
^ permalink raw reply related
* Re: [PATCH v2 4/6] build dashless "bin-wrappers" directory similar to installed bindir
From: Junio C Hamano @ 2009-11-30 6:28 UTC (permalink / raw)
To: Matthew Ogilvie; +Cc: git
In-Reply-To: <1259561971-25730-5-git-send-email-mmogilvi_git@miniinfo.net>
Matthew Ogilvie <mmogilvi_git@miniinfo.net> writes:
> diff --git a/wrap-for-bin.sh b/wrap-for-bin.sh
> new file mode 100644
> index 0000000..ee2bc98
> --- /dev/null
> +++ b/wrap-for-bin.sh
> @@ -0,0 +1,15 @@
> +#!/bin/sh
> +
> +# wrap-for-bin.sh: Template for git executable wrapper scripts
> +# to run test suite against sandbox, but with only bindir-installed
> +# executables in PATH. The Makefile copies this into various
> +# files in bin-wrappers, substituting
> +# __GIT_EXEC_PATH__ and __PROG__.
> +
> +GIT_EXEC_PATH="__GIT_EXEC_PATH__"
> +GIT_TEMPLATE_DIR="__GIT_EXEC_PATH__/templates/blt"
> +GITPERLLIB="__GIT_EXEC_PATH__/perl/blib/lib"
> +PATH="__GIT_EXEC_PATH__/bin-wrappers:$PATH"
> +export GIT_EXEC_PATH GIT_TEMPLATE_DIR GITPERLLIB PATH
> +
> +exec "${GIT_EXEC_PATH}/__PROG__" "$@"
Two issues, one minor and one not so minor but not grave:
- Everywhere else we seem to use "@@UPPERCASE_NAME@@" not
double-underscore as placeholders like the above.
- @@PROG@@ is under our control and it is easy for us to guarantee that
it won't have any funny letters, but GIT_EXEC_PATH is not. Is it safe
to do a simple-minded "sed" replacement, or does it need the usual sq
trick employed in the other replacement in our Makefile?
^ permalink raw reply
* 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
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