* Re: [PATCH] Re: git-svn fetch doesn't like spaces in branch names
From: Alex Riesen @ 2007-11-08 7:29 UTC (permalink / raw)
To: Michael J. Cohen; +Cc: Git Mailing List
In-Reply-To: <B28A099B-1BC8-4CED-856A-5FFD7F6711FC@mac.com>
Michael J. Cohen, Thu, Nov 08, 2007 01:53:07 +0100:
>> mini:TextMateBundles mjc$ git-svn fetch
>> Found possible branch point:
>> http://macromates.com/svn/Bundles/trunk/Tools/Dialog PlugIn =>
>> http://macromates.com/svn/Bundles/branches/Dialog PlugIn Completion Menu,
>> 8089
>> Initializing parent: Dialog PlugIn Completion Menu@8089
>> Bad URL passed to RA layer: Malformed URL for repository at
>> /opt/local/bin/git-svn line 1607
>>
>> looks like that might need to be %20 ?
>
>
> Hacky, but it works.
>
> Signed-off-by: Michael J. Cohen <mjc@cruiseplanners.com>
>
> diff --git a/git-svn.perl b/git-svn.perl
> index dd93e32..5dc3b9c 100755
> --- a/git-svn.perl
> +++ b/git-svn.perl
> @@ -1976,6 +1976,7 @@ sub find_parent_branch {
> my $r = $i->{copyfrom_rev};
> my $repos_root = $self->ra->{repos_root};
> my $url = $self->ra->{url};
> + $branch_from =~ s@([\s])@sprintf("%%%02X", ord($1))@seg;
You don't need "[" and "]".
^ permalink raw reply
* Re: [PATCH amend] git-mailsplit: with maildirs not only process cur/, but also new/
From: Alex Riesen @ 2007-11-08 7:24 UTC (permalink / raw)
To: Junio C Hamano
Cc: Gerrit Pape, Fernando J. Pereda, git, Jakub Narebski, Jeff King
In-Reply-To: <7vfxzh7ajt.fsf@gitster.siamese.dyndns.org>
Junio C Hamano, Thu, Nov 08, 2007 03:09:26 +0100:
> Gerrit Pape <pape@smarden.org> writes:
>
> > When saving patches to a maildir with e.g. mutt, the files are put into
> > the new/ subdirectory of the maildir, not cur/. This makes git-am state
> > "Nothing to do.". This patch lets git-mailsplit additional check new/
> > after reading cur/.
> >
> > This was reported by Joey Hess through
> > http://bugs.debian.org/447396
> >
> > Signed-off-by: Gerrit Pape <pape@smarden.org>
> > ---
> >
> > On Mon, Nov 05, 2007 at 01:58:50PM +0100, Jakub Narebski wrote:
> >> > + for (i = 0; i < 2; ++i) {
> >> Wouldn't it be better to use sizeof(sub)/sizeof(sub[0]) or it's macro
> >> equivalent ARRAY_SIZE(sub) instead of hardcoding 2 to avoid errors?
> > I made the array NULL-terminated.
> >
> > On Mon, Nov 05, 2007 at 04:26:24PM -0500, Jeff King wrote:
> >> Isn't the subject line now wrong?
> > Yes, thanks.
> >
> > On Mon, Nov 05, 2007 at 11:52:58PM +0100, Alex Riesen wrote:
> >> Why is missing "cur" (or "new", for that matter) a fatal error?
> >> Why is it error at all? How about just ignoring the fact?
> > As suggested by Jeff, I made it ignore the error on ENOENT.
Better.
> Looks good to me. Final acks please?
Acked-by: Alex Riesen <raa.lkml@gmail.com>
^ permalink raw reply
* Re: [PATCH v2] user-manual: add advanced topic "bisecting merges"
From: Johannes Sixt @ 2007-11-08 7:19 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: gitster, Ralf.Wildenhues, tsuna, git
In-Reply-To: <11944722214046-git-send-email-prohaska@zib.de>
Steffen Prohaska schrieb:
> +If you linearize the history by rebasing the lower branch on
> +top of the upper, instead of merging, the bug becomes much easier to
> +find and understand. Your history would instead be:
At this point I'm missing the words
The solution is ...
I.e.:
The solution is to linearize the history by rebasing the lower branch on
top of the upper, instead of merging. Now the bug becomes much easier to
find and understand. Your history would instead be:
-- Hannes
^ permalink raw reply
* [PATCH] git-sh-setup: fix parseopt `eval`.
From: Junio C Hamano @ 2007-11-08 7:09 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
The 'automagic parseopt' support corrupted non option parameters
that had IFS characters in them. The worst case can be seen
when it has a non option parameter like this:
$1=" * some string blech"
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* I had "git pull -n . to/pic-branch" in Meta/PU which was
affected by this bug, expanding the " * " bullet before the
merge message that is passed from git-pull to git-merge.
I am a bit upset because I _knew_ that the eval was wrong
when I first saw it, but somehow I forgot about it when I
made it land on 'next'. My fault.
git-sh-setup.sh | 11 ++++++-----
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/git-sh-setup.sh b/git-sh-setup.sh
index e1cf885..f1c4839 100755
--- a/git-sh-setup.sh
+++ b/git-sh-setup.sh
@@ -21,11 +21,12 @@ if test -n "$OPTIONS_SPEC"; then
exec "$0" -h
}
- parseopt_extra=
- [ -n "$OPTIONS_KEEPDASHDASH" ] &&
- parseopt_extra="$parseopt_extra --keep-dashdash"
-
- eval `echo "$OPTIONS_SPEC" | git rev-parse --parseopt $parseopt_extra -- "$@" || echo exit $?`
+ [ -n "$OPTIONS_KEEPDASHDASH" ] && parseopt_extra="--keep-dashdash"
+ parsed=$(
+ echo "$OPTIONS_SPEC" |
+ git rev-parse --parseopt $parseopt_extra -- "$@"
+ ) &&
+ eval "$parsed" || exit
else
usage() {
die "Usage: $0 $USAGE"
--
1.5.3.5.1617.g65b5b
^ permalink raw reply related
* [PATCH] Do git reset --hard HEAD when using git rebase --skip
From: Mike Hommey @ 2007-11-08 7:03 UTC (permalink / raw)
To: git; +Cc: gitster
In-Reply-To: <20071107222105.GA31666@glandium.org>
When you have a merge conflict and want to bypass the commit causing it,
you don't want to care about the dirty state of the working tree.
Also, don't git reset --hard HEAD in the rebase-skip test, so that the
lack of support for this is detected.
Signed-off-by: Mike Hommey <mh@glandium.org>
---
git-rebase.sh | 1 +
t/t3403-rebase-skip.sh | 2 --
2 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/git-rebase.sh b/git-rebase.sh
index e3ad7de..8814be9 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -158,6 +158,7 @@ do
exit
;;
--skip)
+ git reset --hard HEAD || exit $?
if test -d "$dotest"
then
git rerere clear
diff --git a/t/t3403-rebase-skip.sh b/t/t3403-rebase-skip.sh
index eab053c..becabfc 100755
--- a/t/t3403-rebase-skip.sh
+++ b/t/t3403-rebase-skip.sh
@@ -36,7 +36,6 @@ test_expect_failure 'rebase with git am -3 (default)' '
'
test_expect_success 'rebase --skip with am -3' '
- git reset --hard HEAD &&
git rebase --skip
'
test_expect_success 'checkout skip-merge' 'git checkout -f skip-merge'
@@ -44,7 +43,6 @@ test_expect_success 'checkout skip-merge' 'git checkout -f skip-merge'
test_expect_failure 'rebase with --merge' 'git rebase --merge master'
test_expect_success 'rebase --skip with --merge' '
- git reset --hard HEAD &&
git rebase --skip
'
--
1.5.3.5
^ permalink raw reply related
* Re: [PATCH v2] user-manual: add advanced topic "bisecting merges"
From: Steffen Prohaska @ 2007-11-08 6:40 UTC (permalink / raw)
To: Benoit Sigoure; +Cc: Junio C Hamano, Ralf.Wildenhues, Git Mailing List
In-Reply-To: <F783880C-A0F9-45D9-A23A-075600B31CEE@lrde.epita.fr>
On Nov 7, 2007, at 11:16 PM, Benoit Sigoure wrote:
> Hi Steffen,
>
> On Nov 7, 2007, at 10:50 PM, Steffen Prohaska wrote:
>
> Some more comments below. Sorry for not spotting these earlier.
I'll took all your suggestions except for ...
[...]
>> +later when you have a better understanding of git.
>> +
>> +[[bisect-merges]]
>> +Why bisecting merge commits can be harder than bisecting linear
>> history
>> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> ~~~
>> +The following text is based upon an email by Junio C. Hamano to
>> +the git mailing list
>> +(link:http://marc.info/?l=git&m=119403257315527&w=2[link:http://
>> marc.info/?l=git&m=119403257315527&w=2]).
>> +It was slightly adapted for this manual.
>> +
>> +Bisecting merges can be challenging due to the complexity of
>> +changes introduced at a merge. Bisecting through merges is not a
>
> s/at a merge/& point/ ?
I'll replace the first sentence with
Using gitlink:git-bisect[1] on a history with merges can be challenging.
The details are explained in the remainder of the paragraph.
[...]
>> +added a new calling site for that function at commit Y. The
>> +commits from Z leading to B all assume the old semantics of that
>> +function and the callers and the callee are consistent with each
>> +other. There is no bug at B, either.
>> +
>> +You merge to create C. There is no textual conflict with this
>> +three way merge, and the result merges cleanly. You bisect
>> +this, because you found D is bad and you know Z was good. Your
>> +bisect will find that C (merge) is broken. Understandably so,
>> +as at C, the new calling site of the function added by the lower
>> +branch is not converted to the new semantics, while all the
>> +other calling sites that already existed at Z would have been
>> +converted by the merge. The new calling site has semantic
>> +adjustment needed, but you do not know that yet. You need to
>
> s/adjustment/&s/
I'm not sure if plural is needed.
Steffen
--
Steffen Prohaska <prohaska@zib.de> <http://www.zib.de/prohaska/>
Zuse Institute Berlin, Takustraße 7, D-14195 Berlin-Dahlem, Germany
+49 (30) 841 85-337, fax -107
^ permalink raw reply
* Re: [PATCH DIFF-CLEANUP 1/2] Make the diff_options bitfields be an unsigned with explicit masks.
From: Junio C Hamano @ 2007-11-08 6:39 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <1194430832-6224-7-git-send-email-madcoder@debian.org>
Pierre Habouzit <madcoder@debian.org> writes:
> reverse_diff was a bit-value in disguise, it's merged in the flags now.
>
> Signed-off-by: Pierre Habouzit <madcoder@debian.org>
Just my first impression, as I am in the middle of unrelated
bisect. I haven't read beyond diff-lib.c changes.
> diff --git a/builtin-diff-tree.c b/builtin-diff-tree.c
> index 0b591c8..e71841a 100644
> --- a/builtin-diff-tree.c
> +++ b/builtin-diff-tree.c
> @@ -118,12 +118,12 @@ int cmd_diff_tree(int argc, const char **argv, const char *prefix)
> }
>
> if (!read_stdin)
> - return opt->diffopt.exit_with_status ?
> - opt->diffopt.has_changes: 0;
> + return DIFF_OPT_TST(&opt->diffopt, EXIT_WITH_STATUS)
> + && DIFF_OPT_TST(&opt->diffopt, HAS_CHANGES);
Had to think a bit about this, although it is correct.
> if (opt->diffopt.detect_rename)
> opt->diffopt.setup |= (DIFF_SETUP_USE_SIZE_CACHE |
> - DIFF_SETUP_USE_CACHE);
> + DIFF_SETUP_USE_CACHE);
I wonder what this is about.
> diff --git a/combine-diff.c b/combine-diff.c
> index fe5a2a1..3cab04b 100644
> --- a/combine-diff.c
> +++ b/combine-diff.c
> @@ -664,7 +664,7 @@ static void show_patch_diff(struct combine_diff_path *elem, int num_parent,
> int mode_differs = 0;
> int i, show_hunks;
> int working_tree_file = is_null_sha1(elem->sha1);
> - int abbrev = opt->full_index ? 40 : DEFAULT_ABBREV;
> + int abbrev = DIFF_OPT_TST(opt, FULL_INDEX) ? 40 : DEFAULT_ABBREV;
Indent?
> diff --git a/diff-lib.c b/diff-lib.c
> index da55713..69b5dc9 100644
> --- a/diff-lib.c
> +++ b/diff-lib.c
> @@ -188,8 +188,7 @@ static int handle_diff_files_args(struct rev_info *revs,
> else if (!strcmp(argv[1], "-n") ||
> !strcmp(argv[1], "--no-index")) {
> revs->max_count = -2;
> - revs->diffopt.exit_with_status = 1;
> - revs->diffopt.no_index = 1;
> + revs->diffopt.flags |= DIFF_OPT_EXIT_WITH_STATUS | DIFF_OPT_NO_INDEX;
> }
Now this looks harder to read that everybody else uses
DIFF_OPT_SET() for this, without DIFF_OPT_ prefix for the
bitmask names.
^ permalink raw reply
* Re: [PATCH 0/5] some shell portability fixes
From: Ralf Wildenhues @ 2007-11-08 6:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nguyen Thai Ngoc Duy, git
In-Reply-To: <7v3avhbxdq.fsf@gitster.siamese.dyndns.org>
* Junio C Hamano wrote on Wed, Nov 07, 2007 at 09:42:41PM CET:
> "Nguyen Thai Ngoc Duy" <pclouds@gmail.com> writes:
> >
> > Argh, should have made it clear, busybox sed is good enough.
>
> Thanks. And you can also happy grok Ralf's rewritten construct,
> right?
>
> That is, existing
>
> $ sed -e 's/foo/\n/' file
>
> will be rewritten by the patch [2/5] to
>
> $ sed -e 's/foo/\
> /' file
The original was something like
sed 's/[|]/\n/g'
Using instead
tr '|' '\n'
should work for the original construct, and AFAIK only /usr/ucb/tr on
Solaris fails to understand \n correctly. Would that be better for you?
Or even
tr '|' '\012'
which fails only on EBCDIC, which I don't think git targets.
I'll resend the patches tonight.
Cheers,
Ralf
^ permalink raw reply
* Re: stgit: cleaning up after using git branch delete commands
From: Karl Hasselström @ 2007-11-08 5:53 UTC (permalink / raw)
To: Jon Smirl; +Cc: Catalin Marinas, Git Mailing List
In-Reply-To: <9e4733910711070811y72f96a90i4db9acdf93aa765c@mail.gmail.com>
On 2007-11-07 11:11:42 -0500, Jon Smirl wrote:
> how about a 'stg gc' command that gets rid of all the inaccessible
> clutter?
"stg assimilate" already has the job of fixing up stuff after the user
has used git commands to move HEAD around. I think it would make sense
to teach it to do this too -- and then rename it "stg repair" or
something. That way, there's one command to fix every kind of "damage"
that git can do to stgit.
Alternatively, "stg branch --create" and "stg init" and whoever else
is bothered by the clutter could simply remove it themselves. That
would be even more user-friendly, I guess.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* [REPLACEMENT PATCH] git-checkout: Add a test case for relative paths use.
From: David Symonds @ 2007-11-08 5:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin, David Symonds
Signed-off-by: David Symonds <dsymonds@gmail.com>
---
These test cases also expose a bug in git-ls-files, where:
git-ls-files t/../
(with or without --full-name) returns no files.
t/t2008-checkout-subdir.sh | 47 ++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 47 insertions(+), 0 deletions(-)
create mode 100755 t/t2008-checkout-subdir.sh
diff --git a/t/t2008-checkout-subdir.sh b/t/t2008-checkout-subdir.sh
new file mode 100755
index 0000000..45833f3
--- /dev/null
+++ b/t/t2008-checkout-subdir.sh
@@ -0,0 +1,47 @@
+#!/bin/sh
+#
+# Copyright (c) 2007 David Symonds
+
+test_description='git checkout from subdirectories'
+
+. ./test-lib.sh
+
+test_expect_success setup '
+
+ echo base > file0 &&
+ git add file0 &&
+ mkdir dir1 &&
+ echo hello > dir1/file1 &&
+ git add dir1/file1 &&
+ test_tick &&
+ mkdir dir2 &&
+ echo bonjour > dir2/file2 &&
+ git add dir2/file2 &&
+ git commit -m "populate tree"
+
+'
+
+test_expect_success 'remove and restore with relative path' '
+
+ cd dir1 &&
+ rm ../file0 &&
+ git checkout HEAD -- ../file0 && test -f ../file0 &&
+ rm ../dir2/file2 &&
+ git checkout HEAD -- ../dir2/file2 && test -f ../dir2/file2 &&
+ rm ../file0 ./file1 &&
+ git checkout HEAD -- .. && test -f ../file0 && test -f ./file1 &&
+ rm file1 &&
+ git checkout HEAD -- ../dir1/../dir1/file1 && test -f ./file1
+
+'
+
+test_expect_failure 'checkout with relative path outside tree should fail (1)' \
+ 'git checkout HEAD - ../file0'
+
+test_expect_failure 'checkout with relative path outside tree should fail (2)' \
+ 'cd dir1 && git checkout HEAD - ./file0'
+
+test_expect_failure 'checkout with relative path outside tree should fail (2)' \
+ 'cd dir1 && git checkout HEAD - ../../file0'
+
+test_done
--
1.5.3.1
^ permalink raw reply related
* Re: [PATCH] Make git-clean a builtin
From: Shawn Bohrer @ 2007-11-08 5:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, johannes.schindelin
In-Reply-To: <7vabppbxef.fsf@gitster.siamese.dyndns.org>
On Wed, Nov 07, 2007 at 12:42:16PM -0800, Junio C Hamano wrote:
>
> Having said that, I do not particularly agree with the way the
> new implementation resolves the existing inconsistencies.
>
> Wouldn't it be better to remove "dir" when the user explicitly
> told you to clean "dir", with or without the trailing slash?
> That's what the user asked you to do, isn't it?
Yes I suppose I agree. Of course I need to spend some more time staring
at the code to figure out how to do so. Perhaps I can figure out what
is causing the original inconsistency in git-ls-files while I'm at it.
^ permalink raw reply
* Re: [PATCH] git-checkout: Add a test case for relative paths use.
From: Junio C Hamano @ 2007-11-08 5:03 UTC (permalink / raw)
To: David Symonds; +Cc: git, Johannes Schindelin
In-Reply-To: <11944932524072-git-send-email-dsymonds@gmail.com>
David Symonds <dsymonds@gmail.com> writes:
> Signed-off-by: David Symonds <dsymonds@gmail.com>
> ---
> t/t2008-checkout-subdir.sh | 36 ++++++++++++++++++++++++++++++++++++
> 1 files changed, 36 insertions(+), 0 deletions(-)
> create mode 100755 t/t2008-checkout-subdir.sh
>
> diff --git a/t/t2008-checkout-subdir.sh b/t/t2008-checkout-subdir.sh
> new file mode 100755
> index 0000000..cb9c9eb
> --- /dev/null
> +++ b/t/t2008-checkout-subdir.sh
> @@ -0,0 +1,36 @@
> +#!/bin/sh
> +#
> +# Copyright (c) 2007 David Symonds
> +
> +test_description='git checkout from subdirectories'
> +
> +. ./test-lib.sh
> +
> +test_expect_success setup '
> +
> + echo base > file0 &&
> + git add file0 &&
> + mkdir dir1 &&
> + echo hello > dir1/file1 &&
> + git add dir1/file1 &&
> + test_tick &&
> + mkdir dir2 &&
> + echo bonjour > dir2/file2 &&
> + git add dir2/file2 &&
> + git commit -m "populate tree"
> +
> +'
> +
> +test_expect_success 'remove and restore with relative path' '
> +
> + cd dir1 &&
> + rm ../file0 &&
> + git checkout HEAD -- ../file0 && test -f ../file0 &&
> + rm ../dir2/file2 &&
> + git checkout HEAD -- ../dir2/file2 && test -f ../dir2/file2 &&
> + rm ../file0 ./file1 &&
> + git checkout HEAD -- .. && test -f ../file0 && test -f ./file1
> +
> +'
This is better than not having any test, but we would also want
a negative test. Things like trying to check out "../file"
without going down into a subdirectory, check out "../../file"
in a subdirectory that is only one level deep.
^ permalink raw reply
* Re: missing object on git-gc
From: Christian Couder @ 2007-11-08 5:03 UTC (permalink / raw)
To: Yossi Leybovich; +Cc: git
In-Reply-To: <6C2C79E72C305246B504CBA17B5500C9029A3071@mtlexch01.mtl.com>
There is an entry "How to fix a broken repository?" in the Git Faq on the
wiki:
http://git.or.cz/gitwiki/GitFaq#head-ac11406480d09e2df98588e800e41b7256602074
Maybe it can help you.
The same topic has been discussed at least 3 times on the mailing list.
By the way, if you find these discussions on gmane, please tell us so that
we can add the links to the FAQ entry. (You can also add them yourself.)
Thanks,
Christian.
Le jeudi 8 novembre 2007, Yossi Leybovich a écrit :
> I am running the git-gc tool over my repository and get the following
> error:
>
> > git-gc
>
> ...
> deltifying 3308 objects...
> error: corrupt loose object '<sha1>'
> fatal: object <sha1> cannot be read .
> error: failed to run repack
>
> when sha1 is 40 bytes number
>
> Does any one know how I can solve thus issue?
>
> Thanks
> YOssi
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] git-checkout: Add a test case for relative paths use.
From: David Symonds @ 2007-11-08 3:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin, David Symonds
Signed-off-by: David Symonds <dsymonds@gmail.com>
---
t/t2008-checkout-subdir.sh | 36 ++++++++++++++++++++++++++++++++++++
1 files changed, 36 insertions(+), 0 deletions(-)
create mode 100755 t/t2008-checkout-subdir.sh
diff --git a/t/t2008-checkout-subdir.sh b/t/t2008-checkout-subdir.sh
new file mode 100755
index 0000000..cb9c9eb
--- /dev/null
+++ b/t/t2008-checkout-subdir.sh
@@ -0,0 +1,36 @@
+#!/bin/sh
+#
+# Copyright (c) 2007 David Symonds
+
+test_description='git checkout from subdirectories'
+
+. ./test-lib.sh
+
+test_expect_success setup '
+
+ echo base > file0 &&
+ git add file0 &&
+ mkdir dir1 &&
+ echo hello > dir1/file1 &&
+ git add dir1/file1 &&
+ test_tick &&
+ mkdir dir2 &&
+ echo bonjour > dir2/file2 &&
+ git add dir2/file2 &&
+ git commit -m "populate tree"
+
+'
+
+test_expect_success 'remove and restore with relative path' '
+
+ cd dir1 &&
+ rm ../file0 &&
+ git checkout HEAD -- ../file0 && test -f ../file0 &&
+ rm ../dir2/file2 &&
+ git checkout HEAD -- ../dir2/file2 && test -f ../dir2/file2 &&
+ rm ../file0 ./file1 &&
+ git checkout HEAD -- .. && test -f ../file0 && test -f ./file1
+
+'
+
+test_done
--
1.5.3.1
^ permalink raw reply related
* Re: git rebase --skip
From: Jakub Narebski @ 2007-11-08 3:31 UTC (permalink / raw)
To: git
In-Reply-To: <20071108032308.GA5638@sigill.intra.peff.net>
Jeff King wrote:
> On Wed, Nov 07, 2007 at 11:21:05PM +0100, Mike Hommey wrote:
>
>> I use git-rebase quite regularly, and I haven't used git-rebase --skip
>> after a failed merge without first resetting the working tree. I was
>> wondering if it wouldn't make sense to automatically do the reset when
>> running git-rebase --skip.
>
> I have often been annoyed by this behavior, too, and I can't think of
> any situation where you _wouldn't_ want the reset to happen. But I
> would be more comfortable hearing confirmation from others that they
> can't think of such a situation.
Perhaps "git rebase --force-skip" or "git rebase --force --skip"
would be the way to fo above...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git rebase --skip
From: Jeff King @ 2007-11-08 3:23 UTC (permalink / raw)
To: Mike Hommey; +Cc: git
In-Reply-To: <20071107222105.GA31666@glandium.org>
On Wed, Nov 07, 2007 at 11:21:05PM +0100, Mike Hommey wrote:
> I use git-rebase quite regularly, and I haven't used git-rebase --skip
> after a failed merge without first resetting the working tree. I was
> wondering if it wouldn't make sense to automatically do the reset when
> running git-rebase --skip.
I have often been annoyed by this behavior, too, and I can't think of
any situation where you _wouldn't_ want the reset to happen. But I
would be more comfortable hearing confirmation from others that they
can't think of such a situation.
-Peff
^ permalink raw reply
* Re: [PATCH] git-branch --with=commit
From: Johannes Schindelin @ 2007-11-08 3:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk5ot7aqz.fsf@gitster.siamese.dyndns.org>
Hi,
On Wed, 7 Nov 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > would it not be better to call it --containing=commit? Besides, I
> > think that the opt_parse_with_commit() function would be better named
> > opt_parse_commit() and be put into parse-options.[ch].
>
> git-describe has "--contains" so that may be a better match.
I just thought what I would understand when reading "git branch
--with=master". I would have expected that it branches off of master.
> I do not know the particular function is generic enough to be in
> parse-options.
Maybe not, you're right. And we can always come back later, and expose
the function if need be.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] git-checkout: Handle relative paths containing "..".
From: David Symonds @ 2007-11-08 2:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin, David Symonds
Based on gitte's idea.
Signed-off-by: David Symonds <dsymonds@gmail.com>
---
git-checkout.sh | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/git-checkout.sh b/git-checkout.sh
index 8993920..b2c50aa 100755
--- a/git-checkout.sh
+++ b/git-checkout.sh
@@ -134,9 +134,10 @@ Did you intend to checkout '$@' which can not be resolved as commit?"
fi
# Make sure the request is about existing paths.
- git ls-files --error-unmatch -- "$@" >/dev/null || exit
- git ls-files -- "$@" |
- git checkout-index -f -u --stdin
+ git ls-files --full-name --error-unmatch -- "$@" >/dev/null || exit
+ git ls-files --full-name -- "$@" |
+ (cd "$(git-rev-parse --show-cdup)" &&
+ git checkout-index -f -u --stdin)
# Run a post-checkout hook -- the HEAD does not change so the
# current HEAD is passed in for both args
--
1.5.3.5.1529.g69a1-dirty
^ permalink raw reply related
* Re: [PATCH amend] git-mailsplit: with maildirs not only process cur/, but also new/
From: Jeff King @ 2007-11-08 2:31 UTC (permalink / raw)
To: Junio C Hamano
Cc: Alex Riesen, Gerrit Pape, Fernando J. Pereda, git, Jakub Narebski
In-Reply-To: <7vfxzh7ajt.fsf@gitster.siamese.dyndns.org>
On Wed, Nov 07, 2007 at 06:09:26PM -0800, Junio C Hamano wrote:
> > When saving patches to a maildir with e.g. mutt, the files are put into
> > the new/ subdirectory of the maildir, not cur/. This makes git-am state
> > "Nothing to do.". This patch lets git-mailsplit additional check new/
> > after reading cur/.
>
> Looks good to me. Final acks please?
Fixed my concerns.
Acked-by: Jeff King <peff@peff.net>
-Peff
^ permalink raw reply
* Re: [PATCH amend] git-mailsplit: with maildirs not only process cur/, but also new/
From: Junio C Hamano @ 2007-11-08 2:09 UTC (permalink / raw)
To: Alex Riesen
Cc: Gerrit Pape, Fernando J. Pereda, git, Jakub Narebski, Jeff King
In-Reply-To: <20071106085418.14211.qmail@54d7c9212e25c5.315fe32.mid.smarden.org>
Gerrit Pape <pape@smarden.org> writes:
> When saving patches to a maildir with e.g. mutt, the files are put into
> the new/ subdirectory of the maildir, not cur/. This makes git-am state
> "Nothing to do.". This patch lets git-mailsplit additional check new/
> after reading cur/.
>
> This was reported by Joey Hess through
> http://bugs.debian.org/447396
>
> Signed-off-by: Gerrit Pape <pape@smarden.org>
> ---
>
> On Mon, Nov 05, 2007 at 01:58:50PM +0100, Jakub Narebski wrote:
>> > + for (i = 0; i < 2; ++i) {
>> Wouldn't it be better to use sizeof(sub)/sizeof(sub[0]) or it's macro
>> equivalent ARRAY_SIZE(sub) instead of hardcoding 2 to avoid errors?
> I made the array NULL-terminated.
>
> On Mon, Nov 05, 2007 at 04:26:24PM -0500, Jeff King wrote:
>> Isn't the subject line now wrong?
> Yes, thanks.
>
> On Mon, Nov 05, 2007 at 11:52:58PM +0100, Alex Riesen wrote:
>> Why is missing "cur" (or "new", for that matter) a fatal error?
>> Why is it error at all? How about just ignoring the fact?
> As suggested by Jeff, I made it ignore the error on ENOENT.
Looks good to me. Final acks please?
^ permalink raw reply
* Re: [PATCH] git-branch --with=commit
From: Junio C Hamano @ 2007-11-08 2:05 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0711080008050.4362@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> would it not be better to call it --containing=commit? Besides, I think
> that the opt_parse_with_commit() function would be better named
> opt_parse_commit() and be put into parse-options.[ch].
git-describe has "--contains" so that may be a better match. I
do not know the particular function is generic enough to be in
parse-options.
^ permalink raw reply
* Re: [PATCH MISC 1/1] Make gcc warning about empty if body go away.
From: Junio C Hamano @ 2007-11-08 2:01 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <1194430832-6224-2-git-send-email-madcoder@debian.org>
Pierre Habouzit <madcoder@debian.org> writes:
> diff --git a/builtin-diff.c b/builtin-diff.c
> index f77352b..80392a8 100644
> --- a/builtin-diff.c
> +++ b/builtin-diff.c
> @@ -204,7 +204,7 @@ static void refresh_index_quietly(void)
> if (write_cache(fd, active_cache, active_nr) ||
> close(fd) ||
> commit_locked_index(lock_file))
> - ; /*
> + (void)0; /*
> * silently ignore it -- we haven't mucked
> * with the real index.
> */
Wouldn't this be much easier to read, by the way?
The point is that if we touched the active_cache, we try to
write it out and make it the index file for later users to use
by calling "commit", but we do not really care about the failure
from this sequence because it is done purely as an optimization.
The original code called three functions primarily for their
side effects, which is admittedly a bad style.
builtin-diff.c | 12 +++---------
1 files changed, 3 insertions(+), 9 deletions(-)
diff --git a/builtin-diff.c b/builtin-diff.c
index f77352b..906c924 100644
--- a/builtin-diff.c
+++ b/builtin-diff.c
@@ -200,15 +200,9 @@ static void refresh_index_quietly(void)
discard_cache();
read_cache();
refresh_cache(REFRESH_QUIET|REFRESH_UNMERGED);
- if (active_cache_changed) {
- if (write_cache(fd, active_cache, active_nr) ||
- close(fd) ||
- commit_locked_index(lock_file))
- ; /*
- * silently ignore it -- we haven't mucked
- * with the real index.
- */
- }
+ if (active_cache_changed &&
+ !write_cache(fd, active_cache, active_nr) && !close(fd))
+ commit_locked_index(lock_file);
rollback_lock_file(lock_file);
}
^ permalink raw reply related
* Re: [PATCH MISC 1/1] Make gcc warning about empty if body go away.
From: Junio C Hamano @ 2007-11-08 1:52 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: gitster, git
In-Reply-To: <1194430832-6224-2-git-send-email-madcoder@debian.org>
Pierre Habouzit <madcoder@debian.org> writes:
> Signed-off-by: Pierre Habouzit <madcoder@debian.org>
> @@ -204,7 +204,7 @@ static void refresh_index_quietly(void)
> if (write_cache(fd, active_cache, active_nr) ||
> close(fd) ||
> commit_locked_index(lock_file))
> - ; /*
> + (void)0; /*
> * silently ignore it -- we haven't mucked
> * with the real index.
> */
Ok, will apply after reindenting a bit, and adding a quote to
the description that I could not parse on the first reading:
Make gcc warning about "empty if body" go away.
Thanks.
^ permalink raw reply
* Re: [PATCH 2/2] git status: show relative paths when run in a subdirectory
From: Johannes Schindelin @ 2007-11-08 1:00 UTC (permalink / raw)
To: David Symonds; +Cc: Brian Gernhardt, Jon Smirl, Git Mailing List, gitster
In-Reply-To: <ee77f5c20711071653x6a1fe8f8peb8ac2714941d2bb@mail.gmail.com>
Hi,
On Thu, 8 Nov 2007, David Symonds wrote:
> On Nov 8, 2007 11:12 AM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> >
> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> > ---
> >
> > This looks a bit ugly because quote_crlf() is now also called
> > on the untracked files, which are not NUL terminated.
> >
> > Maybe someone has an idea how to do this more elegantly.
> >
> > builtin-runstatus.c | 1 +
> > wt-status.c | 50 ++++++++++++++++++++++++++++++++++++++++++--------
> > wt-status.h | 1 +
> > 3 files changed, 44 insertions(+), 8 deletions(-)
>
> Tested, and looks good.
>
> Now that I play with it, though, it seems that a few other bits of git
> need updating to handle relative paths okay:
>
> $ cd gitweb/test
> $ rm ../../wt-status.h
> [oops, what a silly thing to do -- better checkout the latest
> revision of it]
> $ git status
> # On branch next
> # Changed but not updated:
> # (use "git add/rm <file>..." to update what will be committed)
> #
> # deleted: ../../wt-status.h
> no changes added to commit (use "git add" and/or "git commit -a")
> $ git checkout HEAD ../../wt-status.h
> fatal: git-ls-files: cannot generate relative filenames containing '..'
> [grr....]
> $ cd ../..
> $ git checkout HEAD .
> [that works]
Well, now that I did all the hard work with git-status, I leave this easy
exercise for you ;-)
Ciao,
Dscho
^ permalink raw reply
* missing object on git-gc
From: Yossi Leybovich @ 2007-11-08 0:59 UTC (permalink / raw)
To: git
In-Reply-To: <6C2C79E72C305246B504CBA17B5500C902535D9C@mtlexch01.mtl.com>
I am running the git-gc tool over my repository and get the following error:
> git-gc
...
deltifying 3308 objects...
error: corrupt loose object '<sha1>'
fatal: object <sha1> cannot be read .
error: failed to run repack
when sha1 is 40 bytes number
Does any one know how I can solve thus issue?
Thanks
YOssi
^ 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