* 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
* Re: help reverting a merge
From: Justin P. Mattock @ 2009-11-30 8:31 UTC (permalink / raw)
To: Jeff King; +Cc: Christian Couder, git
In-Reply-To: <20091130081315.GA587@coredump.intra.peff.net>
On 11/30/09 00:13, Jeff King wrote:
> 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
>
ahh cool..
I'll have a read on this in the
morning(late now)and see if I can do this
to find the bug.(keep in mind might take
some time i.g. not good at using git,
but am willing to learn a thing or two).
Justin P. Mattock
^ permalink raw reply
* Re: [PATCH] tests: handle NO_PYTHON setting
From: Sverre Rabbelier @ 2009-11-30 8:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Johan Herland, Daniel Barkalow, git
In-Reply-To: <7v4oocwh5o.fsf@alter.siamese.dyndns.org>
Heya,
On Mon, Nov 30, 2009 at 09:28, Junio C Hamano <gitster@pobox.com> wrote:
> Sverre Rabbelier <srabbelier@gmail.com> writes:
>> 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?
I don't understand why that would be needed? The reason we added a
single git_remote_helpers directory is because we wanted to share
common code, having a single python package makes that easy.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [RFC/PATCH 2/2] builtin-merge: show user-friendly error messages for fast-forward too.
From: Matthieu Moy @ 2009-11-30 8:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy6lo7nu8.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Matthieu Moy <Matthieu.Moy@imag.fr> writes:
>
>> This is where I'm not 100% sure I'm not breaking some plumbing.
>
> I think this change is safe [...]
>
> Or did you have something a lot more subtle in mind?
Not at all. But since I found the place to add my code more or less
randomly with gdb, I feel safer with your comment ;-).
Thanks,
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH] tests: handle NO_PYTHON setting
From: Junio C Hamano @ 2009-11-30 8:49 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Jeff King, Johan Herland, Daniel Barkalow, git
In-Reply-To: <fabb9a1e0911300035o532153b7qdc2ecd768200ce09@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
> On Mon, Nov 30, 2009 at 09:28, Junio C Hamano <gitster@pobox.com> wrote:
>> Sverre Rabbelier <srabbelier@gmail.com> writes:
>>> 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?
>
> I don't understand why that would be needed? The reason we added a
> single git_remote_helpers directory is because we wanted to share
> common code, having a single python package makes that easy.
Sorry, I don't understand that. With that reasoning, isn't having a
single git package, be it python or not, even easier? Why would anybody
want a separate egg that includes everything that _happen_ to be written
in Python in the first place? It doesn't make sense at all from packaging
point of view to me.
A separate egg per remote-helper that you can pick and choose which ones
to install and which ones to leave out would make perfect sense, exactly
the same way that distros already split git into "git-core", "git-svn",
etc., though. Your "git-hg" may consist of a single egg and perhaps some
other supporting code, and people who want to convert away from legacy Hg
repository may want to install it, but it is entirely up to them if they
also want to install "git-cvs" that is implemented as a remote-helper that
happens to be written in Python, no?
^ permalink raw reply
* Re: [PATCH v3] Give the hunk comment its own color
From: Junio C Hamano @ 2009-11-30 9:00 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Bert Wesarg, Jeff King, git
In-Reply-To: <fabb9a1e0911300009j1574c06cy500dde75fc68662f@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
> 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?
If you run "git log --oneline --first-parent master..pu", you will notice
that there is no "Merge ... into next" at all.
I maintain a private 'jch' branch that merges everything that has been
merged so far to 'next' and the branch always builds on top of 'master'
whenever 'pu' is pushed out. The tree object recorded by the tip of 'jch'
is designed to always match that of 'next'. And 'pu' is built on top of
'jch', instead of 'next', these days.
The Reintegrate script fron 'todo' (recall that I have a checkout of the
branch in "Meta/" directory) is used this way:
... update 'jch' by merging topics that had new commits
$ git checkout jch && git merge xx/topic && ...
... update the list of topics
$ Meta/Reintegrate master..jch >/var/tmp/redo-jch.sh
... update 'master' with commits and merges
$ git checkout master
$ git am trivially-correct-patch.mbox
$ git merge yy/topic
... update 'next'
$ git checkout next
$ git merge master
... will merge new topics and topics that had new commits
$ sh /var/tmp/redo-jch.sh
... rebuild 'jch' on top of the updated master
$ git checkout jch
$ git reset --hard master
$ sh /var/tmp/redo-jch.sh
... then this shouldn't produce any output
$ git diff next
This time, what I did _after_ Bert noticed my typo was:
$ git checkout bw/diff-color-hunk-header
$ edit diff.c ;# fix my typo
$ git commit --amend -a
$ git diff HEAD@{1} >P.diff
$ git checkout next
$ git apply --index P.diff
$ git commit -m 'typofix'
After this, while rebuilding 'jch' branch the next time, Reintegrate
script will notice that the bw/diff-color-hunk-header topic has been
rebased. I can simply edit that note out in the /var/tmp/redo-jch.sh
script and rebuild 'jch' branch---the result will exactly match 'next'.
The end result is that the commit merged in 'next' is not the tip of
bw/diff-color-hunk-header anymore, but merging the _current_ tip of that
branch together with all the other topics on top of 'master' would produce
the desired result without "oops---that was a stupid typo" fixups.
^ permalink raw reply
* Re: [PATCH v3] Give the hunk comment its own color
From: Sverre Rabbelier @ 2009-11-30 9:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Bert Wesarg, Jeff King, git
In-Reply-To: <7vvdgstmic.fsf@alter.siamese.dyndns.org>
Heya,
On Mon, Nov 30, 2009 at 10:00, Junio C Hamano <gitster@pobox.com> wrote:
> I maintain a private 'jch' branch that merges everything that has been
> merged so far to 'next' and the branch always builds on top of 'master'
> whenever 'pu' is pushed out. The tree object recorded by the tip of 'jch'
> is designed to always match that of 'next'. And 'pu' is built on top of
> 'jch', instead of 'next', these days.
Ah, so _that''s_ how you pull of not rebasing and still maintaining a
clean history in master: keeping a private shadow branch with the
cleaned up history that is tree-identical to the no-rebase next
branch. Interesting.
> The end result is that the commit merged in 'next' is not the tip of
> bw/diff-color-hunk-header anymore, but merging the _current_ tip of that
> branch together with all the other topics on top of 'master' would produce
> the desired result without "oops---that was a stupid typo" fixups.
Thanks for explaining, git really does allow for a lot of interesting
workflows :).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [LIBGIT2 PATCH] git_odb_open ckeck for valid path to database
From: Esben Mose Hansen @ 2009-11-30 9:37 UTC (permalink / raw)
To: Ramsay Jones; +Cc: ae, git
In-Reply-To: <200911102207.04135.kde@mosehansen.dk>
On Tuesday 10 November 2009 22:07:04 Esben Mose Hansen wrote:
> On Monday 09 November 2009 20:16:15 Ramsay Jones wrote:
>
> I have made 2 new patchsets: One
Did these get lost in transit? Or am I going about it in the wrong way? :)
Thank you for your time
--
Kind regards, Esben
^ permalink raw reply
* Re: [PATCH] tests: handle NO_PYTHON setting
From: Sverre Rabbelier @ 2009-11-30 9:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Johan Herland, Daniel Barkalow, git
In-Reply-To: <7vr5rgv1lr.fsf@alter.siamese.dyndns.org>
Heya,
On Mon, Nov 30, 2009 at 09:49, Junio C Hamano <gitster@pobox.com> wrote:
> Sorry, I don't understand that. With that reasoning, isn't having a
> single git package, be it python or not, even easier? Why would anybody
> want a separate egg that includes everything that _happen_ to be written
> in Python in the first place? It doesn't make sense at all from packaging
> point of view to me.
Because that's the recommended way to create a python package, create
a new directory, put the files in it, and distribute it.
> A separate egg per remote-helper that you can pick and choose which ones
> to install and which ones to leave out would make perfect sense, exactly
> the same way that distros already split git into "git-core", "git-svn",
> etc., though. Your "git-hg" may consist of a single egg and perhaps some
> other supporting code, and people who want to convert away from legacy Hg
> repository may want to install it, but it is entirely up to them if they
> also want to install "git-cvs" that is implemented as a remote-helper that
> happens to be written in Python, no?
Yes, fair enough, but we don't do that for any other files in git.git.
The packagers do so, sure, but a different concern. The reason we want
to distribute the git_remote_helpers package is so that
git-remote-hg.py, which lives in git.git/ and is installed as
git-remote-hg can say "from git_remote_helpers.hg import export".
The only reason this is needed in the first place is because we can't
just add the python files to libgit.a or embed it in git-remote-hg
statically, python does not support that. That is the only reason we
need to distribute the package, which is why we need a separate
directory.
That is, if I've understood Johan's reasoning and intention correctly.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH] reset: add --quiet option
From: Felipe Contreras @ 2009-11-30 10:19 UTC (permalink / raw)
To: Stephen Boyd; +Cc: git
In-Reply-To: <1259543939.5679.5.camel@swboyd-laptop>
On Mon, Nov 30, 2009 at 3:18 AM, Stephen Boyd <bebarino@gmail.com> wrote:
> Why not just OPT__QUIET? We lose the specific help string but it's
> possible that what quiet is silencing will change in the future.
I thought somebody would complain about loosing that string. In any
case, first step is adding --query to 'git reset', second step is
moving all OPT_BOOLEAN('q' to OPT__QUIET; there are other commands
doing the same.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH] tests: handle NO_PYTHON setting
From: Johan Herland @ 2009-11-30 10:59 UTC (permalink / raw)
To: git; +Cc: Sverre Rabbelier, Junio C Hamano, Jeff King, Daniel Barkalow
In-Reply-To: <fabb9a1e0911300156l7f8dbe55p7da26540b0360773@mail.gmail.com>
On Monday 30 November 2009, Sverre Rabbelier wrote:
> Heya,
>
> On Mon, Nov 30, 2009 at 09:49, Junio C Hamano <gitster@pobox.com> wrote:
> > Sorry, I don't understand that. With that reasoning, isn't having a
> > single git package, be it python or not, even easier? Why would
> > anybody want a separate egg that includes everything that _happen_ to
> > be written in Python in the first place? It doesn't make sense at all
> > from packaging point of view to me.
>
> Because that's the recommended way to create a python package, create
> a new directory, put the files in it, and distribute it.
>
> > A separate egg per remote-helper that you can pick and choose which
> > ones to install and which ones to leave out would make perfect sense,
> > exactly the same way that distros already split git into "git-core",
> > "git-svn", etc., though. Your "git-hg" may consist of a single egg and
> > perhaps some other supporting code, and people who want to convert away
> > from legacy Hg repository may want to install it, but it is entirely up
> > to them if they also want to install "git-cvs" that is implemented as a
> > remote-helper that happens to be written in Python, no?
>
> Yes, fair enough, but we don't do that for any other files in git.git.
> The packagers do so, sure, but a different concern. The reason we want
> to distribute the git_remote_helpers package is so that
> git-remote-hg.py, which lives in git.git/ and is installed as
> git-remote-hg can say "from git_remote_helpers.hg import export".
>
> The only reason this is needed in the first place is because we can't
> just add the python files to libgit.a or embed it in git-remote-hg
> statically, python does not support that. That is the only reason we
> need to distribute the package, which is why we need a separate
> directory.
>
> That is, if I've understood Johan's reasoning and intention correctly.
Yes, you have. I'll repeat the history of this to hopefully clarify:
I first created a "git-remote-cvs.py" script (originally under a different
name, but that is not important), that was transformed (essentially copied)
to "git-remote-cvs" by the build process. This script was large and
unwieldy, however, and I found it more maintainable to split it into several
python scripts. So I created a "git_remote_cvs", and put the supporting
scripts in there.
Now, in order for the smaller "git-remote-cvs" executable to do its job, it
needed to import the supporting scripts at runtime, so I decided to make a
python egg from the "git_remote_cvs" subdir, that would be installed using
Python's infrastructure. This, I deemed, was the safest way to ensure that
the "git_remote_cvs" scripts were always available at runtime.
Next, Sverre started his "git-remote-hg.py" script, and found that he could
re-use some of the scripts in the "git_remote_cvs" package. He therefore
(with my blessing) refactored this subdir into the "git_remote_helpers"
subdir/package that is currently under discussion. Hence, this subdir is
meant to contain the support scripts for remote helper written in Python,
both common support scripts, and support scripts specific to each remote
helper. So far, only the common code is there, but we expect the Hg and CVS
helpers to add scripts to the "hg" and "cvs" subsubdirs, respectively.
END_OF_HISTORY
Just to clarify, Git remote helpers does not live in the
"git_remote_helpers" subdir. The subdir (which is installed as a Python
library package) does not contain anything resembling a complete remote
helper. Instead, the remote helper scripts live as regular scripts in the
git.git root dir, and (like any other git program) are turned into
executables by the build process. The difference is that two of the remote
helpers currently being developed (Sverre's "git-remote-hg", and my "git-
remote-cvs") are written in Python, and (want to) share some common
supporting code currently located in the "git_remote_helpers" subdir.
We _could_ split up the "git_remote_helpers" package into a "git-remote-hg"-
specific package, and a "git-remote-cvs"-specific package, but that would
mean either having two copies of the current support code. Alternately, we
could create a _third_ package containing the common support code, that each
of our hg/cvs support packages would in turn depend on. I don't think we
want to go there, at least not yet.
Also, to prevent this misunderstanding, we could create a "python" subdir in
git.git, and move the "git_remote_helpers" into there. However, it would
slightly complicate (at least) the git-remote-cvs.py script which currently
exploits the "coincidence" that the subdir has the same name as the
corresponding python package, and is therefore testable in both its unbuilt
and built state.
Hope this helps,
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: git am and CRLF files
From: Daniele Segato @ 2009-11-30 12:06 UTC (permalink / raw)
To: kusmabite; +Cc: Nanako Shiraishi, Stefan Naewe, git@vger.kernel.org
In-Reply-To: <40aa078e0911160343k41393197s56d26576bcbfbe90@mail.gmail.com>
On Mon, Nov 16, 2009 at 12:43 PM, Erik Faye-Lund
<kusmabite@googlemail.com> wrote:
> According to RFC 5322, email messages use CRLF as the
> newline-sequence. In order to be able to distinguish between CRLF and
> LF in an e-mail patch, the message needs to be use some
> transfer-encoding that preserves newline style (like base64).
>
> Perhaps this would be better fixed by having format-patch (or prehaps
> the MUA ?) base64-encode the message body if the file contains
> non-LF-newlines, and normalizing CRLF to LF before transport-decoding?
> Or does some MUAs transport-decode before storing the message to disk?
>
> I realize this might make it a bit tricky to review patches that
> contains CRLF-newlines before mailing them out, but perhaps inspecting
> the format-patch output is the wrong place to do this?
why don't adding that information in the mail header?
or may be made format-patch create a "comment line" with that information?
if that line is missing it could keep the default behavior (what it
did until now)
^ 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