* Re: [ANNOUNCE] EasyGit (eg) 0.97
From: Jeff King @ 2009-01-30 19:47 UTC (permalink / raw)
To: Elijah Newren; +Cc: Mike Ralphson, Git Mailing List
In-Reply-To: <51419b2c0901301035g6867b9d8l2d4de9590035bd4e@mail.gmail.com>
On Fri, Jan 30, 2009 at 11:35:50AM -0700, Elijah Newren wrote:
> > 2009/1/30 Elijah Newren <newren@gmail.com>:
> >> [5] The bug I can only occasionally trigger and which I don't know the
> >> cause of yet: when exiting from eg log the terminal settings sometimes
> >> are messed up (with echo off and such), requiring a "reset" to get the
> >> terminal back to normal.
> >
> > Are you sure that isn't this bug in git.git ?
> >
> > pager: do wait_for_pager on signal death
> > http://article.gmane.org/gmane.comp.version-control.git/106728
>
> Interesting. I just went and tried out next (git version
> 1.6.1.2.418.gd79e6), which I believe has this patch...and after a
> while I was still able to duplicate the eg bug on one of my
> machines[1]. So it doesn't seem to be that particular issue, at
> least.
There is also a related set of fixes for spawning externals via fork,
which fixes a bug with the pager not getting cleaned up. But it looks
like it is also in the version you tested.
Can you give a more complete recipe for reproducing? Since I was just
touching this area in git, I want to make sure it isn't a git bug you
are triggering. :)
As an aside, I found some related weirdness. In my git repo, if I do
this:
$ git checkout next
$ eg log -p
I get log output, but the diff is not colorized (and I have color.diff
set to "auto" in my ~/.gitconfig). But if I detach my HEAD and show the
log:
$ git checkout next^0
$ eg log -p
then I _do_ get color in the patch. I also get this error:
Use of uninitialized value $branch in concatenation (.) or string at
/home/peff/eg line 2854.
eg: command (git rev-parse refs/heads/) failed
eg: received signal 13
The error is easy to explain. The offending code is:
my $branch = RepoUtil::current_branch();
my ($ret, $revision) =
ExecUtil::execute_captured("git rev-parse refs/heads/$branch");
So it is clear that you just need to handle the case of there being no
current branch. But the color thing is certainly exotic. :)
-Peff
^ permalink raw reply
* Re: [ANNOUNCE] EasyGit (eg) 0.97
From: Jeff King @ 2009-01-30 20:03 UTC (permalink / raw)
To: Elijah Newren; +Cc: Mike Ralphson, Git Mailing List
In-Reply-To: <20090130194727.GA31927@coredump.intra.peff.net>
On Fri, Jan 30, 2009 at 02:47:27PM -0500, Jeff King wrote:
> There is also a related set of fixes for spawning externals via fork,
> which fixes a bug with the pager not getting cleaned up. But it looks
> like it is also in the version you tested.
>
> Can you give a more complete recipe for reproducing? Since I was just
> touching this area in git, I want to make sure it isn't a git bug you
> are triggering. :)
Ah, OK. I just peeked through the 'eg' source. It looks like you may
have replicated the same bug that I just fixed in git. :)
You want to make sure that "eg" is the last process to die (i.e.,
_after_ the pager). Otherwise after it dies, less has trouble reading
from the terminal (I don't know for sure, but I assume this has to do
with the shell making "eg" the process group leader and magic about
process groups and controlling terminals).
I think perl may even do the wait() for you under ordinary
circumstances. But, for example, if I kill "eg" with a signal (say, by
hitting ^C), then it will die but the pager will live on. In git, we
catch the signal and wait() before dying.
So I don't know for sure that is your problem (it really depends on how
much magic perl is doing behind the scenes with wait()ing on children,
and I don't recall the exact details of that). But it is something to
look into.
I don't think it's a git problem, though. "eg log" doesn't spawn a git
pager, since you pipe the output into eg. The paging is all your local
"less" invocation.
-Peff
^ permalink raw reply
* Re: diff-index --cached on bare repository
From: Jeff King @ 2009-01-30 20:06 UTC (permalink / raw)
To: Johannes Gilger; +Cc: git
In-Reply-To: <glv901$c5v$1@ger.gmane.org>
On Fri, Jan 30, 2009 at 04:13:53PM +0000, Johannes Gilger wrote:
> today I stumbled over the output of "git diff-index --cached HEAD" in a
> bare repository. While diff-index HEAD just reminds me that I got to
> have a work-tree, --cached outputs all the files in HEAD as deleted. The
> question is if this is intended behaviour? Or is it irrelevant because
> diff-index is only plumbing? I found a mail of the gitk-team working
> around this, which is funny because I discovered this while working on
> GitX.
Generally commands which don't make sense in a bare repository are
forbidden. But diff-index _can_ work in a bare repository, since there
is no reason you can't do index-only operations. However, a bare repo
has no index by default, in which case diff-index shows the results you
saw.
So no, it's not a bug, but it is potentially confusing. I think nobody
ever worried about it because diff-index is plumbing, so users are
unlikely to stumble into it.
-Peff
^ permalink raw reply
* Re: [ANNOUNCE] EasyGit (eg) 0.97
From: Elijah Newren @ 2009-01-30 20:21 UTC (permalink / raw)
To: Jeff King; +Cc: Mike Ralphson, Git Mailing List
In-Reply-To: <20090130194727.GA31927@coredump.intra.peff.net>
On Fri, Jan 30, 2009 at 12:47 PM, Jeff King <peff@peff.net> wrote:
> As an aside, I found some related weirdness. In my git repo, if I do
> this:
>
> $ git checkout next
> $ eg log -p
>
> I get log output, but the diff is not colorized (and I have color.diff
> set to "auto" in my ~/.gitconfig). But if I detach my HEAD and show the
> log:
>
> $ git checkout next^0
> $ eg log -p
>
> then I _do_ get color in the patch. I also get this error:
Hmm, I had never turned color on before; I guess other eg users hadn't
either. Anyway, the difference can be explained pretty easily: eg
log tries to provide user-meaningful names for how commits relate to
the active branch (like git-name-rev but implemented internally in eg
to allow the common case to be fast); if there is no active branch
there's no special naming to do so I simply run git log without
reading and modifying its output.
Essentially, the difference in coloring here is much like the
difference you see between
$ git log
$ git log | less
Whenever I try to load the output in perl, git won't show the
colorization. I guess I could manually add it when I am printing the
information, but it'd be nicer to just have git do the colorization
despite the fact that its output is not a tty. Is there an easy way
to do that (without mucking with the user's config file)?
(It looks like eg status is also affected, for similar reasons.)
> Use of uninitialized value $branch in concatenation (.) or string at
> /home/peff/eg line 2854.
> eg: command (git rev-parse refs/heads/) failed
> eg: received signal 13
>
> The error is easy to explain. The offending code is:
>
> my $branch = RepoUtil::current_branch();
> my ($ret, $revision) =
> ExecUtil::execute_captured("git rev-parse refs/heads/$branch");
Indeed, the latter two lines should have been after the if (!$branch) check.
Thanks,
Elijah
^ permalink raw reply
* Re: [ANNOUNCE] EasyGit (eg) 0.97
From: Elijah Newren @ 2009-01-30 20:22 UTC (permalink / raw)
To: Jeff King; +Cc: Mike Ralphson, Git Mailing List
In-Reply-To: <20090130200307.GA3054@coredump.intra.peff.net>
On Fri, Jan 30, 2009 at 1:03 PM, Jeff King <peff@peff.net> wrote:
> Ah, OK. I just peeked through the 'eg' source. It looks like you may
> have replicated the same bug that I just fixed in git. :)
>
> You want to make sure that "eg" is the last process to die (i.e.,
> _after_ the pager). Otherwise after it dies, less has trouble reading
> from the terminal (I don't know for sure, but I assume this has to do
> with the shell making "eg" the process group leader and magic about
> process groups and controlling terminals).
>
> I think perl may even do the wait() for you under ordinary
> circumstances. But, for example, if I kill "eg" with a signal (say, by
> hitting ^C), then it will die but the pager will live on. In git, we
> catch the signal and wait() before dying.
>
> So I don't know for sure that is your problem (it really depends on how
> much magic perl is doing behind the scenes with wait()ing on children,
> and I don't recall the exact details of that). But it is something to
> look into.
Thanks for the tips; I'll try to take a look and see what I can figure out.
Elijah
^ permalink raw reply
* Re: [ANNOUNCE] EasyGit (eg) 0.97
From: Jeff King @ 2009-01-30 20:29 UTC (permalink / raw)
To: Elijah Newren; +Cc: Mike Ralphson, Git Mailing List
In-Reply-To: <51419b2c0901301221n45cde1abw7a57a13bfa74b34@mail.gmail.com>
On Fri, Jan 30, 2009 at 01:21:00PM -0700, Elijah Newren wrote:
> Whenever I try to load the output in perl, git won't show the
> colorization. I guess I could manually add it when I am printing the
> information, but it'd be nicer to just have git do the colorization
> despite the fact that its output is not a tty. Is there an easy way
> to do that (without mucking with the user's config file)?
>
> (It looks like eg status is also affected, for similar reasons.)
If you pass --color on the command line, it is equivalent to "color =
always" (whereas the default is "auto", which turns it on only if output
is to a tty).
So you would have to read color.diff yourself and then decide whether to
add --color.
Note that in general you are playing things a bit risky with these sorts
of outputs. You are calling porcelain (like log and status) and piping
it into your program. There's no guarantee that user config might not be
affecting the results of those programs.
But I think that is sort of the nature of "eg": to be a thin wrapper
around git. So maybe it is OK for your use.
-Peff
^ permalink raw reply
* [PATCH] git-shortlog.txt: fix example about .mailmap
From: Michele Ballabio @ 2009-01-30 16:55 UTC (permalink / raw)
To: git
In the example, Joe Developer has <joe@example.com> as his email,
but in the .mailmap is <joe@random.com>. Use example.com instead.
Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
---
Documentation/git-shortlog.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-shortlog.txt b/Documentation/git-shortlog.txt
index 8f7c0e2..498bd28 100644
--- a/Documentation/git-shortlog.txt
+++ b/Documentation/git-shortlog.txt
@@ -82,7 +82,7 @@ her family name fully spelled out, a proper `.mailmap` file would look like:
# Note how we don't need an entry for <jane@laptop.(none)>, because the
# real name of that author is correct already, and coalesced directly.
Jane Doe <jane@desktop.(none)>
-Joe R. Developer <joe@random.com>
+Joe R. Developer <joe@example.com>
------------
Author
--
1.6.1.20.g0ddd
^ permalink raw reply related
* [RFC] Line diff fragments, custom colour markers and word change highlighting
From: Reece Dunn @ 2009-01-30 20:44 UTC (permalink / raw)
To: Git List
Hi,
I am using git to track various online stories and use it to keep a
history of any changes I make as I proofread them. The idea is that I
can then send this to the author for approval, so they can update the
stories their side and post updates.
At the moment, I am manually editing the output of git diff to produce
the desired output. I intend on modifying git to get it to produce the
output in a format that I am interested in so that I don't have to
edit it by hand.
The purpose of this RFC is to outline the changes I intend to make
(while still providing the existing behaviour) and see if it is useful
to go into the main git repository once I have implemented it:
(1) Line diff fragments
Taking the Lorum ipsum text as an example, if there is a typo in one
of the paragraphs then `git diff` will render the whole paragraph.
This is useful for machine processing, but not necessarily useful for
human readers. I have been cutting out everything but the paragraph
where the error is located, but a limit to X characters or word blocks
would also work. For example, showing:
$ git diff -U0 --fragment
- ... consectetur adipiscing elot. Proin interdum leo quis elit. ...
+ ... consectetur adipiscing elit. Proin interdum leo quis elit. ...
(2) Word change highlighting
Provide an option to allow the colour format to highlight just the
words that have changed and not the whole line. There have already
been some discussions on this ("git diff colorization idea"). So:
$ git diff -U0 --fragment --color-words
- ... consectetur adipiscing <red>elot</red>. Proin interdum leo quis elit. ...
+ ... consectetur adipiscing <green>elit</green>. Proin interdum leo
quis elit. ...
(3) Custom coloured diff markers
When performing a diff, you can get it to highlight the output of a
diff using terminal colour markers that will be rendered correctly if
your terminal supports processing them. This is great if you are
viewing the diff from a terminal, but if you are pasting it to another
media (forum, web page, etc) the colour information is lost.
It would be useful here to change the strings being written out to
denote colour, allowing you to generate HTML/CSS or forum/wiki markup
depending on context.
This could also help the git-web and git-gui tools that colour diff content.
I am not sure how this would work via command-line. If the output was
in a form that was easy to pipe through sed I would be happy. For
example:
$ git diff -U0 --fragment --color-words --color-markers
- ... consectetur adipiscing <red>elot</red>. Proin interdum leo quis elit. ...
+ ... consectetur adipiscing <green>elit</green>. Proin interdum leo
quis elit. ...
where <red> and the like are actually outputted and not there to
represent the terminal colour marker instruction character sequences.
Thoughts? Comments?
- Reece
^ permalink raw reply
* 'git clone' doesn't use alternates automatically?
From: James Pickens @ 2009-01-30 22:12 UTC (permalink / raw)
To: Git ML
Hi,
I have a central, shared Git repository on an NFS drive at path
$central. I have added "$central/objects" to
$central/objects/info/alternates. I see that when I clone this
repository with Git 1.6.1, the alternates file is automatically copied
to the clone, but so are all the pack files and loose objects. If I
then cd to the clone and run 'git gc', it removes the redundant local
objects.
I thought I tested this setup a few months back, and 'git clone'
automatically used the alternates file to avoid copying the redundant
objects into the clone. Has this behavior changed, or is my memory
bad?
James
^ permalink raw reply
* Re: [PATCH] builtin-blame.c: Use utf8_strwidth for author's names
From: Geoffrey Thomas @ 2009-01-30 22:22 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0901301811180.3586@pacific.mpi-cbg.de>
> Good point (even if your commit message has lines much longer than 72
> chars, ASCII ones at that).
Oops; I'll fix that.
> But how certain are you at that point that the authors are in UTF-8
> format? IOW what encoding conversions were possibly performed up to that
> point?
I don't believe there are any encoding conversions performed up to that
point. IIRC git doesn't require any encoding but encourages UTF-8; if it's
something obscure, I have no way of knowing how wide in screen columns the
author field is because I likely don't have a library for it in git at
all. I do have a utf8.c, though.
Currently, however, printf("%*.*s", width, width, author) is simply wrong,
because printf only cares about bytes, not screen columns. Do you think I
should fall back on the old behavior if i18n.commitencoding is set, or if
at least one of the author names isn't parseable as UTF-8, or something?
Or should I be doing this with iconv and assuming all commits are
encoded in the current encoding specified via $LANG or $LC_whatever?
--
Geoffrey Thomas
geofft@mit.edu
^ permalink raw reply
* Re: Git log can not show history before rename
From: Thomas Rast @ 2009-01-30 21:52 UTC (permalink / raw)
To: Santi Béjar; +Cc: Frank Li, git
In-Reply-To: <adf1fd3d0901300449x7f6a2f5bq920068b46994c92e@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 777 bytes --]
Santi Béjar wrote:
> 2009/1/30 Frank Li <lznuaa@gmail.com>:
> > Does it conflict with --parents?
> > When I use --follow and --parents together, parents can't rewrite.
> > without --follow, parent can rewrite.
>
> I think there are no obvious reasons to conflict and they could work
> together, but as Jakub just said, --follow is quite new and only works
> well with simple history and simple cases.
You might find this useful:
$ git config alias.renames
!GIT_PAGER="grep -v '^$' | sort -u" git --paginate log --follow --name-only --pretty=format:"" --
Slow and hacky, but works nice enough in practice. The intended use
case is like
$ gitk --complicated-rev-options $(git renames git-svn.perl)
--
Thomas Rast
trast@{inf,student}.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: question re dcommit problem
From: Thomas Rast @ 2009-01-30 21:43 UTC (permalink / raw)
To: Nico -telmich- Schottelius; +Cc: David Mann, git
In-Reply-To: <20090130084253.GA30046@denkbrett.schottelius.org>
[-- Attachment #1: Type: text/plain, Size: 828 bytes --]
Nico -telmich- Schottelius wrote:
> David Mann [Thu, Jan 29, 2009 at 07:14:08PM -0500]:
> > I created a git repository from my svn repository, later uploaded it to
> > GitHub, and after some branching and merging, can no longer dcommit back
> > to the svn repository. [...]
>
> Iirc git svn does not support merges. You've to use git rebase or
> update through the svn server.
It does support them on the git side. To SVN, the merge should look
like the squashed result (along the first-parent line). On your local
git end, it should rebase the merge (to allow for git-svn-id) but
preserve parents, thus keeping history.
However, it is very important that the SVN line of history is always
reachable along the first-parent line. David, did you ensure that?
--
Thomas Rast
trast@{inf,student}.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] rebase -i: correctly remember --root flag across --continue
From: Thomas Rast @ 2009-01-30 22:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin
In-Reply-To: <7vzlhd3fh7.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 323 bytes --]
Junio C Hamano wrote:
> Perhaps something like this.
> + git rev-list --topo-order --parents --pretty="tformat:%s" HEAD |
> + git name-rev --stdin --name-only --refs=refs/heads/conflict3 >out &&
Clever. I'll follow up with cleanup patches for the rest of the
test.
--
Thomas Rast
trast@{inf,student}.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH 1/2] t3412: clean up GIT_EDITOR usage
From: Thomas Rast @ 2009-01-30 22:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <200901302343.39921.trast@student.ethz.ch>
a6c7a27 (rebase -i: correctly remember --root flag across --continue,
2009-01-26) introduced a more portable GIT_EDITOR usage, but left the
old tests unchanged.
Since we never use the editor (all tests run the rebase script as
proposed by rebase -i), just disable it outright, which simplifies the
tests.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
t/t3412-rebase-root.sh | 38 +++++++++++++-------------------------
1 files changed, 13 insertions(+), 25 deletions(-)
diff --git a/t/t3412-rebase-root.sh b/t/t3412-rebase-root.sh
index 9fc528f..8a9154a 100755
--- a/t/t3412-rebase-root.sh
+++ b/t/t3412-rebase-root.sh
@@ -6,6 +6,10 @@ Tests if git rebase --root --onto <newparent> can rebase the root commit.
'
. ./test-lib.sh
+# we always run the interactive rebases unchanged, so just disable the editor
+GIT_EDITOR=:
+export GIT_EDITOR
+
test_expect_success 'prepare repository' '
test_commit 1 A &&
test_commit 2 A &&
@@ -59,7 +63,7 @@ test_expect_success 'pre-rebase got correct input (2)' '
test_expect_success 'rebase -i --root --onto <newbase>' '
git checkout -b work3 other &&
- GIT_EDITOR=: git rebase -i --root --onto master &&
+ git rebase -i --root --onto master &&
git log --pretty=tformat:"%s" > rebased3 &&
test_cmp expect rebased3
'
@@ -70,7 +74,7 @@ test_expect_success 'pre-rebase got correct input (3)' '
test_expect_success 'rebase -i --root --onto <newbase> <branch>' '
git branch work4 other &&
- GIT_EDITOR=: git rebase -i --root --onto master work4 &&
+ git rebase -i --root --onto master work4 &&
git log --pretty=tformat:"%s" > rebased4 &&
test_cmp expect rebased4
'
@@ -81,7 +85,7 @@ test_expect_success 'pre-rebase got correct input (4)' '
test_expect_success 'rebase -i -p with linear history' '
git checkout -b work5 other &&
- GIT_EDITOR=: git rebase -i -p --root --onto master &&
+ git rebase -i -p --root --onto master &&
git log --pretty=tformat:"%s" > rebased5 &&
test_cmp expect rebased5
'
@@ -111,7 +115,7 @@ EOF
test_expect_success 'rebase -i -p with merge' '
git checkout -b work6 other &&
- GIT_EDITOR=: git rebase -i -p --root --onto master &&
+ git rebase -i -p --root --onto master &&
git log --graph --topo-order --pretty=tformat:"%s" > rebased6 &&
test_cmp expect-side rebased6
'
@@ -142,7 +146,7 @@ EOF
test_expect_success 'rebase -i -p with two roots' '
git checkout -b work7 other &&
- GIT_EDITOR=: git rebase -i -p --root --onto master &&
+ git rebase -i -p --root --onto master &&
git log --graph --topo-order --pretty=tformat:"%s" > rebased7 &&
test_cmp expect-third rebased7
'
@@ -158,22 +162,14 @@ EOF
test_expect_success 'pre-rebase hook stops rebase' '
git checkout -b stops1 other &&
- (
- GIT_EDITOR=:
- export GIT_EDITOR
- test_must_fail git rebase --root --onto master
- ) &&
+ test_must_fail git rebase --root --onto master &&
test "z$(git symbolic-ref HEAD)" = zrefs/heads/stops1
test 0 = $(git rev-list other...stops1 | wc -l)
'
test_expect_success 'pre-rebase hook stops rebase -i' '
git checkout -b stops2 other &&
- (
- GIT_EDITOR=:
- export GIT_EDITOR
- test_must_fail git rebase --root --onto master
- ) &&
+ test_must_fail git rebase --root --onto master &&
test "z$(git symbolic-ref HEAD)" = zrefs/heads/stops2
test 0 = $(git rev-list other...stops2 | wc -l)
'
@@ -218,11 +214,7 @@ test_expect_success 'rebase --root with conflict (second part)' '
test_expect_success 'rebase -i --root with conflict (first part)' '
git checkout -b conflict2 other &&
- (
- GIT_EDITOR=:
- export GIT_EDITOR
- test_must_fail git rebase -i --root --onto master
- ) &&
+ test_must_fail git rebase -i --root --onto master &&
git ls-files -u | grep "B$"
'
@@ -260,11 +252,7 @@ EOF
test_expect_success 'rebase -i -p --root with conflict (first part)' '
git checkout -b conflict3 other &&
- (
- GIT_EDITOR=:
- export GIT_EDITOR
- test_must_fail git rebase -i -p --root --onto master
- ) &&
+ test_must_fail git rebase -i -p --root --onto master &&
git ls-files -u | grep "B$"
'
--
1.6.1.2.464.g6066
^ permalink raw reply related
* [PATCH 2/2] t3412: use log|name-rev instead of log --graph
From: Thomas Rast @ 2009-01-30 22:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1233355621-4783-1-git-send-email-trast@student.ethz.ch>
Replace all 'git log --graph' calls for history verification with the
combination of 'git log ...| git name-rev' first introduced by a6c7a27
(rebase -i: correctly remember --root flag across --continue,
2009-01-26). This should be less susceptible to format changes than
the --graph code.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
t/t3412-rebase-root.sh | 65 ++++++++++++++++++++++++++++-------------------
1 files changed, 39 insertions(+), 26 deletions(-)
diff --git a/t/t3412-rebase-root.sh b/t/t3412-rebase-root.sh
index 8a9154a..57a3cad 100755
--- a/t/t3412-rebase-root.sh
+++ b/t/t3412-rebase-root.sh
@@ -10,6 +10,12 @@ Tests if git rebase --root --onto <newparent> can rebase the root commit.
GIT_EDITOR=:
export GIT_EDITOR
+log_with_names () {
+ git rev-list --topo-order --parents --pretty="tformat:%s" HEAD |
+ git name-rev --stdin --name-only --refs=refs/heads/$1
+}
+
+
test_expect_success 'prepare repository' '
test_commit 1 A &&
test_commit 2 A &&
@@ -102,21 +108,25 @@ test_expect_success 'set up merge history' '
git merge side
'
-sed 's/#/ /g' > expect-side <<'EOF'
-* Merge branch 'side' into other
-|\##
-| * 5
-* | 4
-|/##
-* 3
-* 2
-* 1
+cat > expect-side <<'EOF'
+commit work6 work6~1 work6^2
+Merge branch 'side' into other
+commit work6^2 work6~2
+5
+commit work6~1 work6~2
+4
+commit work6~2 work6~3
+3
+commit work6~3 work6~4
+2
+commit work6~4
+1
EOF
test_expect_success 'rebase -i -p with merge' '
git checkout -b work6 other &&
git rebase -i -p --root --onto master &&
- git log --graph --topo-order --pretty=tformat:"%s" > rebased6 &&
+ log_with_names work6 > rebased6 &&
test_cmp expect-side rebased6
'
@@ -129,25 +139,29 @@ test_expect_success 'set up second root and merge' '
git merge third
'
-sed 's/#/ /g' > expect-third <<'EOF'
-* Merge branch 'third' into other
-|\##
-| * 6
-* | Merge branch 'side' into other
-|\ \##
-| * | 5
-* | | 4
-|/ /##
-* | 3
-|/##
-* 2
-* 1
+cat > expect-third <<'EOF'
+commit work7 work7~1 work7^2
+Merge branch 'third' into other
+commit work7^2 work7~4
+6
+commit work7~1 work7~2 work7~1^2
+Merge branch 'side' into other
+commit work7~1^2 work7~3
+5
+commit work7~2 work7~3
+4
+commit work7~3 work7~4
+3
+commit work7~4 work7~5
+2
+commit work7~5
+1
EOF
test_expect_success 'rebase -i -p with two roots' '
git checkout -b work7 other &&
git rebase -i -p --root --onto master &&
- git log --graph --topo-order --pretty=tformat:"%s" > rebased7 &&
+ log_with_names work7 > rebased7 &&
test_cmp expect-third rebased7
'
@@ -263,8 +277,7 @@ test_expect_success 'fix the conflict' '
test_expect_success 'rebase -i -p --root with conflict (second part)' '
git rebase --continue &&
- git rev-list --topo-order --parents --pretty="tformat:%s" HEAD |
- git name-rev --stdin --name-only --refs=refs/heads/conflict3 >out &&
+ log_with_names conflict3 >out &&
test_cmp expect-conflict-p out
'
--
1.6.1.2.464.g6066
^ permalink raw reply related
* Re: [PATCH v2] contrib git-resurrect: find traces of a branch name and resurrect it
From: Thomas Rast @ 2009-01-30 22:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Boyd Stephen Smith Jr., git, Johannes Schindelin
In-Reply-To: <7vwschz2dc.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 327 bytes --]
Junio C Hamano wrote:
> Thomas Rast <trast@student.ethz.ch> writes:
>
> > Add a tool 'git-resurrect.sh <branch>' that tries to find traces of
Thanks for your review. I've been busy and thus out of the loop all
week, but I'll try and make an improved version Soon(tm).
--
Thomas Rast
trast@{inf,student}.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [ANNOUNCE] EasyGit (eg) 0.97
From: Elijah Newren @ 2009-01-30 22:55 UTC (permalink / raw)
To: Jeff King; +Cc: Mike Ralphson, Git Mailing List
In-Reply-To: <20090130202917.GA3370@coredump.intra.peff.net>
On Fri, Jan 30, 2009 at 1:29 PM, Jeff King <peff@peff.net> wrote:
> If you pass --color on the command line, it is equivalent to "color =
> always" (whereas the default is "auto", which turns it on only if output
> is to a tty).
>
> So you would have to read color.diff yourself and then decide whether to
> add --color.
It looks like I can also set the environment variable GIT_PAGER_IN_USE
to achieve the same effects (and I don't even need to do so for most
commands, such as diff, just those whose output I'm parsing and
possibly tweaking).
> Note that in general you are playing things a bit risky with these sorts
> of outputs. You are calling porcelain (like log and status) and piping
> it into your program. There's no guarantee that user config might not be
> affecting the results of those programs.
>
> But I think that is sort of the nature of "eg": to be a thin wrapper
> around git. So maybe it is OK for your use.
Right, I considered switching eg to use git plumbing commands to
insulate from issues like this, but the problem is that if git output
changes then the eg output really should change too (or else I should
have a very specific reason for not changing it). This almost
certainly means that I'll have to bump the minimum git version to be
used with eg at some point, but that seemed the most reasonable path
for eg.
^ permalink raw reply
* [PATCH] contrib/difftool: add support for Kompare
From: Markus Heidelberg @ 2009-01-30 23:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
---
contrib/difftool/git-difftool-helper | 16 ++++++++++------
contrib/difftool/git-difftool.txt | 3 ++-
2 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/contrib/difftool/git-difftool-helper b/contrib/difftool/git-difftool-helper
index 0c48506..10632a3 100755
--- a/contrib/difftool/git-difftool-helper
+++ b/contrib/difftool/git-difftool-helper
@@ -1,7 +1,7 @@
#!/bin/sh
# git-difftool-helper is a GIT_EXTERNAL_DIFF-compatible diff tool launcher.
-# It supports kdiff3, tkdiff, xxdiff, meld, opendiff, emerge, ecmerge,
-# vimdiff, gvimdiff, and custom user-configurable tools.
+# It supports kdiff3, kompare, tkdiff, xxdiff, meld, opendiff,
+# emerge, ecmerge, vimdiff, gvimdiff, and custom user-configurable tools.
# This script is typically launched by using the 'git difftool'
# convenience command.
#
@@ -73,6 +73,10 @@ launch_merge_tool () {
> /dev/null 2>&1
;;
+ kompare)
+ "$merge_tool_path" "$LOCAL" "$REMOTE"
+ ;;
+
tkdiff)
"$merge_tool_path" -o "$MERGED" "$LOCAL" "$REMOTE"
;;
@@ -134,7 +138,7 @@ valid_custom_tool() {
# Built-in merge tools are always valid.
valid_tool() {
case "$1" in
- kdiff3 | tkdiff | xxdiff | meld | opendiff | emerge | vimdiff | gvimdiff | ecmerge)
+ kdiff3 | kompare | tkdiff | xxdiff | meld | opendiff | emerge | vimdiff | gvimdiff | ecmerge)
;; # happy
*)
if ! valid_custom_tool "$1"
@@ -180,14 +184,14 @@ if test -z "$merge_tool"; then
# We have a $DISPLAY so try some common UNIX merge tools
if test -n "$DISPLAY"; then
- merge_tool_candidates="kdiff3 tkdiff xxdiff meld gvimdiff"
+ merge_tool_candidates="kdiff3 kompare tkdiff xxdiff meld gvimdiff"
# If gnome then prefer meld
if test -n "$GNOME_DESKTOP_SESSION_ID"; then
merge_tool_candidates="meld $merge_tool_candidates"
fi
- # If KDE then prefer kdiff3
+ # If KDE then prefer kdiff3 or kompare
if test "$KDE_FULL_SESSION" = "true"; then
- merge_tool_candidates="kdiff3 $merge_tool_candidates"
+ merge_tool_candidates="kdiff3 kompare $merge_tool_candidates"
fi
fi
diff --git a/contrib/difftool/git-difftool.txt b/contrib/difftool/git-difftool.txt
index ca3dbd2..6e2610c 100644
--- a/contrib/difftool/git-difftool.txt
+++ b/contrib/difftool/git-difftool.txt
@@ -28,7 +28,8 @@ OPTIONS
--tool=<tool>::
Use the merge resolution program specified by <tool>.
Valid merge tools are:
- kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, ecmerge, and opendiff
+ kdiff3, kompare, tkdiff, meld, xxdiff, emerge,
+ vimdiff, gvimdiff, ecmerge, and opendiff
+
If a merge resolution program is not specified, 'git-difftool'
will use the configuration variable `merge.tool`. If the
--
1.6.1.2.256.g62566b
^ permalink raw reply related
* [PATCH 1/2] mergetool: Add a test for running mergetool in a sub-directory
From: Charles Bailey @ 2009-01-30 23:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jonas Flodén, Charles Bailey
Signed-off-by: Charles Bailey <charles@hashpling.org>
---
t/t7610-mergetool.sh | 70 ++++++++++++++++++++++++++++++++++++-------------
1 files changed, 51 insertions(+), 19 deletions(-)
diff --git a/t/t7610-mergetool.sh b/t/t7610-mergetool.sh
index edb6a57..ee8589e 100755
--- a/t/t7610-mergetool.sh
+++ b/t/t7610-mergetool.sh
@@ -9,49 +9,81 @@ Testing basic merge tool invocation'
. ./test-lib.sh
+# All the mergetool test work by checking out a temporary branch based
+# off 'branch1' and then merging in master and checking the results of
+# running mergetool
+
test_expect_success 'setup' '
echo master >file1 &&
- git add file1 &&
+ mkdir subdir &&
+ echo master sub >subdir/file3 &&
+ git add file1 subdir/file3 &&
git commit -m "added file1" &&
+
git checkout -b branch1 master &&
echo branch1 change >file1 &&
echo branch1 newfile >file2 &&
- git add file1 file2 &&
+ echo branch1 sub >subdir/file3 &&
+ git add file1 file2 subdir/file3 &&
git commit -m "branch1 changes" &&
- git checkout -b branch2 master &&
- echo branch2 change >file1 &&
- echo branch2 newfile >file2 &&
- git add file1 file2 &&
- git commit -m "branch2 changes" &&
+
git checkout master &&
echo master updated >file1 &&
echo master new >file2 &&
- git add file1 file2 &&
- git commit -m "master updates"
-'
+ echo master new sub >subdir/file3 &&
+ git add file1 file2 subdir/file3 &&
+ git commit -m "master updates" &&
-test_expect_success 'custom mergetool' '
git config merge.tool mytool &&
git config mergetool.mytool.cmd "cat \"\$REMOTE\" >\"\$MERGED\"" &&
- git config mergetool.mytool.trustExitCode true &&
- git checkout branch1 &&
+ git config mergetool.mytool.trustExitCode true
+'
+
+test_expect_success 'custom mergetool' '
+ git checkout -b test1 branch1 &&
test_must_fail git merge master >/dev/null 2>&1 &&
- ( yes "" | git mergetool file1>/dev/null 2>&1 ) &&
- ( yes "" | git mergetool file2>/dev/null 2>&1 ) &&
+ ( yes "" | git mergetool file1 >/dev/null 2>&1 ) &&
+ ( yes "" | git mergetool file2 >/dev/null 2>&1 ) &&
+ ( yes "" | git mergetool subdir/file3 >/dev/null 2>&1 ) &&
test "$(cat file1)" = "master updated" &&
test "$(cat file2)" = "master new" &&
+ test "$(cat subdir/file3)" = "master new sub" &&
git commit -m "branch1 resolved with mergetool"
'
test_expect_success 'mergetool crlf' '
git config core.autocrlf true &&
- git reset --hard HEAD^
+ git checkout -b test2 branch1
test_must_fail git merge master >/dev/null 2>&1 &&
- ( yes "" | git mergetool file1>/dev/null 2>&1 ) &&
- ( yes "" | git mergetool file2>/dev/null 2>&1 ) &&
+ ( yes "" | git mergetool file1 >/dev/null 2>&1 ) &&
+ ( yes "" | git mergetool file2 >/dev/null 2>&1 ) &&
+ ( yes "" | git mergetool subdir/file3 >/dev/null 2>&1 ) &&
test "$(printf x | cat file1 -)" = "$(printf "master updated\r\nx")" &&
test "$(printf x | cat file2 -)" = "$(printf "master new\r\nx")" &&
- git commit -m "branch1 resolved with mergetool - autocrlf"
+ test "$(printf x | cat subdir/file3 -)" = "$(printf "master new sub\r\nx")" &&
+ git commit -m "branch1 resolved with mergetool - autocrlf" &&
+ git config core.autocrlf false &&
+ git reset --hard
+'
+
+test_expect_failure 'mergetool in subdir' '
+ git checkout -b test3 branch1
+ cd subdir && (
+ test_must_fail git merge master >/dev/null 2>&1 &&
+ ( yes "" | git mergetool file3 >/dev/null 2>&1 ) &&
+ test "$(cat file3)" = "master new sub" )
'
+# We can't merge files from parent directories when running mergetool
+# from a subdir. Is this a bug?
+#
+#test_expect_failure 'mergetool in subdir' '
+# cd subdir && (
+# ( yes "" | git mergetool ../file1 >/dev/null 2>&1 ) &&
+# ( yes "" | git mergetool ../file2 >/dev/null 2>&1 ) &&
+# test "$(cat ../file1)" = "master updated" &&
+# test "$(cat ../file2)" = "master new" &&
+# git commit -m "branch1 resolved with mergetool - subdir" )
+#'
+
test_done
--
1.6.1.235.gc9d403
^ permalink raw reply related
* [PATCH 2/2] mergetool: fix running mergetool in sub-directories
From: Charles Bailey @ 2009-01-30 23:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jonas Flodén, Charles Bailey
In-Reply-To: <1233357611-31820-1-git-send-email-charles@hashpling.org>
The previous fix to mergetool to use checkout-index instead of cat-file
broke running mergetool anywhere except the root of the repository.
This fixes it by using the correct relative paths for temporary files
and index paths.
Signed-off-by: Charles Bailey <charles@hashpling.org>
---
git-mergetool.sh | 9 ++++-----
t/t7610-mergetool.sh | 2 +-
2 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/git-mergetool.sh b/git-mergetool.sh
index aefdca7..87fa88a 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -13,7 +13,6 @@ SUBDIRECTORY_OK=Yes
OPTIONS_SPEC=
. git-sh-setup
require_work_tree
-prefix=$(git rev-parse --show-prefix)
# Returns true if the mode reflects a symlink
is_symlink () {
@@ -131,7 +130,7 @@ checkout_staged_file () {
tmpfile=$(expr "$(git checkout-index --temp --stage="$1" "$2")" : '\([^ ]*\) ')
if test $? -eq 0 -a -n "$tmpfile" ; then
- mv -- "$tmpfile" "$3"
+ mv -- "$(git rev-parse --show-cdup)$tmpfile" "$3"
fi
}
@@ -161,9 +160,9 @@ merge_file () {
local_mode=`git ls-files -u -- "$MERGED" | awk '{if ($3==2) print $1;}'`
remote_mode=`git ls-files -u -- "$MERGED" | awk '{if ($3==3) print $1;}'`
- base_present && checkout_staged_file 1 "$prefix$MERGED" "$BASE"
- local_present && checkout_staged_file 2 "$prefix$MERGED" "$LOCAL"
- remote_present && checkout_staged_file 3 "$prefix$MERGED" "$REMOTE"
+ base_present && checkout_staged_file 1 "$MERGED" "$BASE"
+ local_present && checkout_staged_file 2 "$MERGED" "$LOCAL"
+ remote_present && checkout_staged_file 3 "$MERGED" "$REMOTE"
if test -z "$local_mode" -o -z "$remote_mode"; then
echo "Deleted merge conflict for '$MERGED':"
diff --git a/t/t7610-mergetool.sh b/t/t7610-mergetool.sh
index ee8589e..e768c3e 100755
--- a/t/t7610-mergetool.sh
+++ b/t/t7610-mergetool.sh
@@ -66,7 +66,7 @@ test_expect_success 'mergetool crlf' '
git reset --hard
'
-test_expect_failure 'mergetool in subdir' '
+test_expect_success 'mergetool in subdir' '
git checkout -b test3 branch1
cd subdir && (
test_must_fail git merge master >/dev/null 2>&1 &&
--
1.6.1.235.gc9d403
^ permalink raw reply related
* Re: git reset --merge misdocumented?
From: Thomas Rast @ 2009-01-30 23:20 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0901290210540.3586@pacific.mpi-cbg.de>
[-- Attachment #1: Type: text/plain, Size: 1421 bytes --]
Johannes Schindelin wrote:
> from the man page I thought that --merge would be just another way to say
> "git read-tree -u -m".
Isn't that idea from the commit message? I can't find any mention of
read-tree in next's idea of the manpage.
> In particular, the man page says _nothing_ about resetting HEAD to
> something else.
It says
--merge::
Resets the index to match the tree recorded by the named commit,
and updates the files that are different between the named commit
and the current commit in the working tree.
so while the exact way of "updating" is not specified, it does mention
that you can move between commits, and that it will do something with
the difference across the move.
The example further down really cleared up the idea for me:
Undo a merge or pull inside a dirty work tree::
+
------------
$ git pull <1>
Auto-merging nitfol
Merge made by recursive.
nitfol | 20 +++++----
...
$ git reset --merge ORIG_HEAD <2>
------------
I've never used 'read-tree -u -m' except in voodoo scripting, but I'd
have done the same with 'git stash && git reset --hard ORIG_HEAD &&
git stash pop' before. The original commit message even mentions this
equivalence.
So I'm not sure what exactly needs changing there?
--
Thomas Rast
trast@{inf,student}.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH --no-flowed] http-push: refactor request url creation
From: Tay Ray Chuan @ 2009-01-30 23:51 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano
In-Reply-To: <alpine.DEB.1.00.0901301816410.3586@pacific.mpi-cbg.de>
Hi,
On Sat, Jan 31, 2009 at 1:17 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
>> +static void append_remote_object_url(struct strbuf *buf, const char *url, const char *hex, int only_two_digit_prefix)
>
> I seem to remember that I mentioned that this line is too long.
I thought if i fixed my line wrapping then it wouldn't be a problem anymore.
I've edited the patch anyway.
--
Cheers,
Ray Chuan
^ permalink raw reply
* [PATCH] http-push: refactor request url creation
From: Tay Ray Chuan @ 2009-01-30 23:51 UTC (permalink / raw)
To: git, Junio C Hamano, Johannes Schindelin
Currently, functions that deal with objects on the remote repository
have to allocate and do strcpys to generate the URL.
This patch saves them this trouble, by providing two functions,
"append_remote_object_url" and "get_remote_object_url".
Both generate a URL, with either the object's 2-digit hex directory
(eg. /objects/a1/), or the complete object location (eg.
/objects/a1/b2).
However, they differ in that "append_remote_object_url" appends this
URL to a strbuf, while "get_remote_object_url" wraps around the former
and returns the URL directly in char*. Users usually would use
"get_remote_object_url", but may find "append_remote_object_url"
useful if they require further string operations on the URL.
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
Acked-by: Junio C Hamano <gitster@pobox.com>
---
* renamed only_two_digit_postfix in original patch to only_two_digit_prefix
* updated with Junio's changes (if (...) and fix memory leak)
* updated with Junio's double interface
* added back use of temporary string "url" in "start_fetch_loose"
* rebased and generated on master (a34a9db)
* split "append_remote_object_url" signature across 3 lines at Dscho's suggestion
http-push.c | 62 +++++++++++++++++++++++-----------------------------------
1 files changed, 25 insertions(+), 37 deletions(-)
diff --git a/http-push.c b/http-push.c
index 59037df..ba217fc 100644
--- a/http-push.c
+++ b/http-push.c
@@ -209,6 +209,22 @@ static struct curl_slist *get_dav_token_headers(struct remote_lock *lock, enum d
return dav_headers;
}
+static void append_remote_object_url(struct strbuf *buf, const char *url,
+ const char *hex,
+ int only_two_digit_prefix)
+{
+ strbuf_addf(buf, "%sobjects/%.*s/", url, 2, hex);
+ if (!only_two_digit_prefix)
+ strbuf_addf(buf, "%s", hex+2);
+}
+
+static char *get_remote_object_url(const char *url, const char *hex, int only_two_digit_prefix)
+{
+ struct strbuf buf = STRBUF_INIT;
+ append_remote_object_url(&buf, url, hex, only_two_digit_prefix);
+ return strbuf_detach(&buf, NULL);
+}
+
static void finish_request(struct transfer_request *request);
static void release_request(struct transfer_request *request);
@@ -255,7 +271,6 @@ static void start_fetch_loose(struct transfer_request *request)
char *filename;
char prevfile[PATH_MAX];
char *url;
- char *posn;
int prevlocal;
unsigned char prev_buf[PREV_BUF_SIZE];
ssize_t prev_read = 0;
@@ -305,17 +320,8 @@ static void start_fetch_loose(struct transfer_request *request)
git_SHA1_Init(&request->c);
- url = xmalloc(strlen(remote->url) + 50);
- request->url = xmalloc(strlen(remote->url) + 50);
- strcpy(url, remote->url);
- posn = url + strlen(remote->url);
- strcpy(posn, "objects/");
- posn += 8;
- memcpy(posn, hex, 2);
- posn += 2;
- *(posn++) = '/';
- strcpy(posn, hex + 2);
- strcpy(request->url, url);
+ url = get_remote_object_url(remote->url, hex, 0);
+ request->url = xstrdup(url);
/* If a previous temp file is present, process what was already
fetched. */
@@ -388,16 +394,8 @@ static void start_mkcol(struct transfer_request *request)
{
char *hex = sha1_to_hex(request->obj->sha1);
struct active_request_slot *slot;
- char *posn;
- request->url = xmalloc(strlen(remote->url) + 13);
- strcpy(request->url, remote->url);
- posn = request->url + strlen(remote->url);
- strcpy(posn, "objects/");
- posn += 8;
- memcpy(posn, hex, 2);
- posn += 2;
- strcpy(posn, "/");
+ request->url = get_remote_object_url(remote->url, hex, 1);
slot = get_active_slot();
slot->callback_func = process_response;
@@ -512,7 +510,7 @@ static void start_put(struct transfer_request *request)
{
char *hex = sha1_to_hex(request->obj->sha1);
struct active_request_slot *slot;
- char *posn;
+ struct strbuf buf = STRBUF_INIT;
enum object_type type;
char hdr[50];
void *unpacked;
@@ -551,21 +549,13 @@ static void start_put(struct transfer_request *request)
request->buffer.buf.len = stream.total_out;
- request->url = xmalloc(strlen(remote->url) +
- strlen(request->lock->token) + 51);
- strcpy(request->url, remote->url);
- posn = request->url + strlen(remote->url);
- strcpy(posn, "objects/");
- posn += 8;
- memcpy(posn, hex, 2);
- posn += 2;
- *(posn++) = '/';
- strcpy(posn, hex + 2);
- request->dest = xmalloc(strlen(request->url) + 14);
- sprintf(request->dest, "Destination: %s", request->url);
- posn += 38;
- *(posn++) = '_';
- strcpy(posn, request->lock->token);
+ strbuf_addstr(&buf, "Destination: ");
+ append_remote_object_url(&buf, remote->url, hex, 0);
+ request->dest = strbuf_detach(&buf, NULL);
+
+ append_remote_object_url(&buf, remote->url, hex, 0);
+ strbuf_addstr(&buf, request->lock->token);
+ request->url = strbuf_detach(&buf, NULL);
slot = get_active_slot();
slot->callback_func = process_response;
--
1.6.1.2.254.g2f9c7
^ permalink raw reply related
* Re: [PATCH] Don't try to reclose in command_close_bidi_pipe
From: Tay Ray Chuan @ 2009-01-31 0:03 UTC (permalink / raw)
To: Yuval Kogman; +Cc: git
In-Reply-To: <a891e1bd0901300706h4fdffe24m78c418f8c1ae7cd8@mail.gmail.com>
Hi,
On Fri, Jan 30, 2009 at 11:06 PM, Yuval Kogman <nothingmuch@woobling.org> wrote:
> Here is an example:
> http://github.com/yanick/git-cpan-patch/blob/ed67d3f86f371764935fd0da3e7f08536c95b606/git-cpan-import#L190
>
> Since git-commit-tree requires the message to be written before it can
> write the sha1 of the new commit object, the handle has to be closed
> already, which makes command_close_bidi_pipe die with an error.
> The workaround in the linked code reopens a fake handle so that
> close() will not error.
> For what it's worth, I've been poking at t/t9700/test.pl but since
> it's pretty sparse I figured I should contribute this fix
> independently.
Your usage seems to a very special case. You're closing the handle,
and then invoking the method "command_close_bidi_pipe", whose job is
to close the pipe handles passed to it (among other things). So, it
doesn't seem very good to make "command_close_bidi_pipe" to take into
account that you closed your handle independently.
Maybe you could write a pair of new functions for the commit-tree
command in the Git package, something like the
"_open_hash_and_insert_object_if_needed" and "hash_and_insert_object"
pair.
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: Bus Error- git merge
From: Brian Moran @ 2009-01-31 0:05 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git@vger.kernel.org
In-Reply-To: <alpine.DEB.1.00.0901301950100.3586@pacific.mpi-cbg.de>
With subsequent changes to the merged-to repository, the bug does not
manifest. I will attempt to reproduce when we encounter it next.
On 1/30/09 10:57 AM, "Johannes Schindelin" <Johannes.Schindelin@gmx.de>
wrote:
> Hi,
>
> On Fri, 30 Jan 2009, Brian Moran wrote:
>
>> I am getting a bus error on a git merge, including the more recent versions.
>> Following the instructions from a bug August, I got the latest sources,
>> compiled them up, and executed the merge in the debugger to repro. Here¹s
>> what I found:
>
> Is it possible that your branch has submodules?
>
^ 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