* Re: [PATCH 13/15] t3030 (merge-recursive): use test_expect_code
From: Jonathan Nieder @ 2011-12-07 21:57 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Junio C Hamano, Git List
In-Reply-To: <1323286611-4806-14-git-send-email-artagnon@gmail.com>
Patches 9-12 look good.
Ramkumar Ramachandra wrote:
> Use test_expect_code in preference to repeatedly checking exit codes
> by hand.
[...]
> +++ b/t/t3030-merge-recursive.sh
> @@ -285,17 +285,7 @@ test_expect_success 'merge-recursive simple' '
> rm -fr [abcd] &&
> git checkout -f "$c2" &&
>
> - git merge-recursive "$c0" -- "$c2" "$c1"
> - status=$?
> - case "$status" in
> - 1)
> - : happy
> - ;;
> - *)
> - echo >&2 "why status $status!!!"
> - false
> - ;;
> - esac
> + test_expect_code 1 git merge-recursive "$c0" -- "$c2" "$c1"
Yeah, this style is kind of repetitive. Worse, if "git checkout"
fails with status 1, it would yield a false success. Thanks for
fixing it.
^ permalink raw reply
* Re: [PATCH 14/15] t1006 (cat-file): use test_cmp
From: Jonathan Nieder @ 2011-12-07 22:01 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Junio C Hamano, Git List
In-Reply-To: <1323286611-4806-15-git-send-email-artagnon@gmail.com>
Ramkumar Ramachandra wrote:
> Use test_cmp in preference to repeatedly comparing command outputs by
> hand.
>
> Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
> ---
> t/t1006-cat-file.sh | 53 +++++++++++---------------------------------------
> 1 files changed, 12 insertions(+), 41 deletions(-)
I guess test_cmp didn't exist yet when this code was written, though
that doesn't explain why "diff" or "cmp" was not used.
Doesn't this miss some other instances of the
test $expect = $actual
idiom in the same test script? What distinguishes the cases that you
fixed from the ones skipped, and is it worth an inconsistent style to
convert some without the others?
^ permalink raw reply
* Re: Odd issue - The Diffs That WILL NOT DIE.
From: Jeff King @ 2011-12-07 22:03 UTC (permalink / raw)
To: Chris Patti; +Cc: Carlos Martín Nieto, git
In-Reply-To: <CAJ8P3RCPt9Kwi1F7_TEkZQhkm1mwR_TFKhYszS5LL50kXU8oNQ@mail.gmail.com>
On Wed, Dec 07, 2011 at 11:54:26AM -0500, Chris Patti wrote:
> OK. Let me give you a very specific series of commands, sorry about
> the poor question / report (Not convinced it's a bug, probably pilot
> error?)
>
> If my understanding of the way Git works is correct, there should be
> NO pending diffs in a freshly cloned repository, yes?
Yes. It's probably a bug, perhaps related to the case-insensitive
filesystem (we've seen similar weird "phantom changes right after clone"
bugs before).
> 11:35][admin@Hiram-Abiff-2:~/src]$ rm -rf framework/
> [11:37][admin@Hiram-Abiff-2:~/src]$
> [11:44][admin@Hiram-Abiff-2:~/src]$ git clone
> ssh://git.bluestatedigital.com/home/git/framework.git
> Cloning into 'framework'...
> remote: Counting objects: 378540, done.
> remote: Compressing objects: 100% (100469/100469), done.
> remote: Total 378540 (delta 261046), reused 374685 (delta 258447)
> Receiving objects: 100% (378540/378540), 148.33 MiB | 2.08 MiB/s, done.
> Resolving deltas: 100% (261046/261046), done.
> [11:51][admin@Hiram-Abiff-2:~/src]$ cd framework/
> [11:51][admin@Hiram-Abiff-2:~/src/framework(master)]$ git diff
> diff --git a/app/modules/Core/controllers/CloudSponge.php b/app/modules/Core/con
> index 615a7b3..911d456 100644
> --- a/app/modules/Core/controllers/CloudSponge.php
> +++ b/app/modules/Core/controllers/CloudSponge.php
Are there other files in the repository that differ from this path only
in capitalization? Can you show us the output of "git ls-files"?
Is it possible to make this repo public, or at least available privately
to git developers?
You mentioned v1.7.8. Do you see the bug with other git versions? If
not, can you try bisecting?
-Peff
^ permalink raw reply
* Re: Yo dawg, I heard you like trees...
From: Jeff King @ 2011-12-07 22:12 UTC (permalink / raw)
To: Sebastian Morr; +Cc: Phil Hord, git
In-Reply-To: <20111207155411.GB2003@thinkpad>
On Wed, Dec 07, 2011 at 04:54:11PM +0100, Sebastian Morr wrote:
> > Git uses a DAG. The A stands for "acyclic". Loops are not allowed.
>
> I'm aware of that. It's acyclic by design, but is this actually enforced
> by the code? Or does it simply trust that no loops will ever occur,
> because it's so improbable?
The latter. And not just "improbable", but "so improbable that trying to
do it on purpose should still take billions of years".
Assuming sha1 isn't totally broken, of course.
> After Andrew's response I investigated a bit, and it seems I
> overvalued the attempts to "break" SHA-1. Wikipedia quotes a 2008
> attack, that can create a collision with 2^51 hash function calls.
According to wikipedia, it _may_ produce collisions in 2^51 to 2^57.
Worrisome numbers, certainly, but 2^51 is probably within our ability to
compute if a big project is undertaken. Yet to my knowledge nobody has
actually created such a collision. So the attack is still theoretical at
this point, and there's no good way to create a loop within the git DAG
(or within a tree).
-Peff
^ permalink raw reply
* Re: git auto-repack is broken...
From: Nicolas Pitre @ 2011-12-07 22:12 UTC (permalink / raw)
To: Brandon Casey
Cc: Jeff King, Junio C Hamano, Linus Torvalds,
Ævar Arnfjörð, Git Mailing List
In-Reply-To: <CA+sFfMdeVoz8XU5j4hNn1qCHHzaiDi0Bw=QbbuU3cwT9mMPZOA@mail.gmail.com>
On Sat, 3 Dec 2011, Brandon Casey wrote:
> Linus's scenario of fetching a lot of stuff that never actually makes
> it into the reflogs is still a valid problem. I'm not sure that
> people who don't know what they are doing are going to run into this
> problem though. Since he fetches a lot of stuff without ever checking
> it out or creating a branch from it, potentially many objects become
> unreferenced every time FETCH_HEAD changes.
Maybe FETCH_HEAD should have a reflog too?
Nicolas
^ permalink raw reply
* Re: [PATCH 15/15] t3040 (subprojects-basic): modernize style
From: Jonathan Nieder @ 2011-12-07 22:21 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Junio C Hamano, Git List
In-Reply-To: <1323286611-4806-16-git-send-email-artagnon@gmail.com>
Ramkumar Ramachandra wrote:
> Put the opening quote starting each test on the same line as the
> test_expect_* invocation. While at it:
[...]
> - Use <<\-EOF in preference to <<EOF to save readers the trouble of
> looking for variable interpolations.
I think you mean <<-\EOF. :)
[...]
> - Chain commands with &&. Breaks in a test assertion's && chain can
> potentially hide failures from earlier commands in the chain.
>
> - Use test_expect_code() in preference to checking the exit status of
> various statements by hand.
I guess these two are the motivation?
> Inspired-by: Jonathan Nieder <jrnieder@gmail.com>
Oh, dear.
> Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
[...]
> --- a/t/t3040-subprojects-basic.sh
> +++ b/t/t3040-subprojects-basic.sh
> @@ -3,81 +3,81 @@
> test_description='Basic subproject functionality'
> . ./test-lib.sh
>
> -test_expect_success 'Super project creation' \
> - ': >Makefile &&
> - git add Makefile &&
> - git commit -m "Superproject created"'
> -
> -
> -cat >expected <<EOF
[...]
It would be easier to read if each preimage test assertion were next to
the corresponding postimage test assertion. Does "git diff --patience"
do better?
> -test_expect_success 'Super project creation' \
> - ': >Makefile &&
> - git add Makefile &&
> - git commit -m "Superproject created"'
> -
> -
> +test_expect_success 'setup: create superproject' '
> + : >Makefile &&
> + git add Makefile &&
> + git commit -m "Superproject created"
> +'
> +
Ok, makes sense.
> -cat >expected <<EOF
> -:000000 160000 00000... A sub1
> -:000000 160000 00000... A sub2
> -EOF
> -test_expect_success 'create subprojects' \
> - 'mkdir sub1 &&
> - ( cd sub1 && git init && : >Makefile && git add * &&
> - git commit -q -m "subproject 1" ) &&
> +test_expect_success 'setup: create subprojects' '
> + mkdir sub1 &&
> + ( cd sub1 && git init && : >Makefile && git add * &&
> + git commit -q -m "subproject 1" ) &&
If cleaning up the style anyway, I would write this as
mkdir sub1 &&
(
cd sub1 &&
git init &&
>Makefile &&
git add Makefile &&
git commit -m "subproject 1"
)
Or
mkdir sub1 &&
(
cd sub1 &&
git init &&
test_commit subproject-1 Makefile
)
But leaving it alone like you did is probably better. ;-)
[...]
> - git diff-tree --abbrev=5 HEAD^ HEAD |cut -d" " -f-3,5- >current &&
> - test_cmp expected current'
> -
> -git branch save HEAD
> -
> + git diff-tree --abbrev=5 HEAD^ HEAD |cut -d" " -f-3,5- >current &&
> + git branch save HEAD &&
> + cat >expected <<-\EOF &&
> + :000000 160000 00000... A sub1
> + :000000 160000 00000... A sub2
> + EOF
> + test_cmp expected current
> +'
> +
At first I wondered if "git branch save HEAD" is logically part of the
same test. After all, it's just meant as a baseline for use by later
tests.
After thinking about it for a few seconds, though, that's exactly what
this test is about. Maybe it would have been clearer if the two setup
tests were combined into one (but please don't take this advice too
seriously; I'm just musing).
> -test_expect_success 'check if fsck ignores the subprojects' \
> - 'git fsck --full'
> +test_expect_success 'check if fsck ignores the subprojects' '
> + git fsck --full
> +'
Does this test imply that one of the subprojects is broken somehow?
> -
> -test_expect_success 'check if commit in a subproject detected' \
> - '( cd sub1 &&
> - echo "all:" >>Makefile &&
> - echo " true" >>Makefile &&
> - git commit -q -a -m "make all" ) && {
> - git diff-files --exit-code
> - test $? = 1
> - }'
> +
> +test_expect_success 'check if commit in a subproject detected' '
> + ( cd sub1 &&
> + echo "all:" >>Makefile &&
> + echo " true" >>Makefile &&
> + git commit -q -a -m "make all" ) &&
> + test_expect_code 1 git diff-files --exit-code
> +'
Nice. Style again: I'd be tempted to reformat as
(
cd sub1 &&
echo "all:" >>Makefile &&
...
) &&
test_expect_code 1 git diff-files --exit-code
to make the subshell scope a little clearer, but exercising restraint
like you did may be better.
[...]
>
> # the index must contain the object name the HEAD of the
> # subproject sub1 was at the point "save"
> -test_expect_success 'checkout in superproject' \
> - 'git checkout save &&
> - git diff-index --exit-code --raw --cached save -- sub1'
> +test_expect_success 'checkout in superproject' '
> + git checkout save &&
> + git diff-index --exit-code --raw --cached save -- sub1
> +'
Thanks much. The result really is a little easier on the eyes, and
the changes look safe.
^ permalink raw reply
* Re: Auto update submodules after merge and reset
From: Jens Lehmann @ 2011-12-07 22:23 UTC (permalink / raw)
To: Andreas T.Auer; +Cc: git
In-Reply-To: <jbnadt$hf8$1@dough.gmane.org>
Am 07.12.2011 10:07, schrieb Andreas T.Auer:
> Jens Lehmann wrote:
>
>> Am 30.11.2011 01:55, schrieb Max Krasnyansky:
>> I'm working on a patch series to teach Git to optionally update the
>> submodules work trees on checkout, reset merge and so on, but I'm not
>> there yet.
>>
>>> I'm thinking about adding a config option that would enable automatic
>>> submodule update but wanted to see if there is some fundamental reason
>>> why it would not be accepted.
> Because there is no good way to do so. It would be fine when you just track
> the submodules "read-only", but if you are actually working on submodules,
> it is a bad idea to always get a detached HEAD.
YMMV. We get along *really* well with this because all developers know that
if they want to hack on a submodule, they have to create a branch in there
first (and if they forget to do that, git status and friends will tell them).
What bugs us is that submodule HEADs don't follow what is checked out (or
merged, or reset ...) in the superproject. We had some really nasty
mismerges because of that, so we need the option to enable it.
> It is also a bad idea to
> merge or rebase on the currently checkedout branch.
As I'm no user of update=merge|rebase, I have no first hand experience on
that. But people do use those settings, no?
> Because if you are
> working on a maint branch in the submodule and then you checkout a pu branch
> in the superproject, because you have forgotten that maint branch in the
> submodule then all the proposed updates go to the maintenance branch -> bad.
Nope, checkout will fail and not do anything as it will detect changes in
the submodule to be updated by the checkout (just as it would do with a
regular file).
> So auto-update is not easy.
No, it is, and it works really well. But it might not fit your use case.
> But below I describe an idea that might solve
> these issues and help auto-udpate to work in a sane way.
>
>> I think adding something like an "submodule.autoupdate" config makes lots
>> of sense, but IMO it should affect all work tree updating porcelain
>> commands, not just merge.
>
> I was thinking about submodule integration and had the idea to bind a
> submodule to the superproject by having special references in the submodule
> like refs/super/master, refs/super/featureX... So these references are like
> tracking branches for the refs/heads/* of the superproject.
Having stuff in the submodule reference branches in the superproject
sounds upside down, as a superproject has (and should have) zero knowledge
about the superproject (as it could have many different of them).
> If you have tracking branches, the supermodule can just update the
> corresponding branch. If this branch is currently checkedout and the work
> area is clean, then the work area is updated, too. If there is currently a
> local branch or a diffent super-branch checked out then the working area
> should be considered "detached" from the superproject and not updated.
This sounds a lot like the "follow branch tip" model we discussed
recently (which could be configured via .gitmodules), but I'm not sure
you really are in the same boat here.
> With this concept you could even switch branches in the superproject and the
> attached submodules follow - still having no detached HEAD. When you want to
> do some local work on the submodule you checkout a local branch and merge
> back into the super branch later.
You lost me here. How can you merge a submodule branch into one of the
superproject?
> The head of that super branch might have
> changed by the update procedure meanwhile, but that is fine, then you just
> have a merge instead of a fast-forward.
>
> Another nice feature would be a recursive commit. So all changed index files
> in the _attached_ submodules would first be committed in their submodules
> and then the superproject commits too - all with one command. Currently it
> feels a little bit like CVS - commit one file(submodule), commit the other
> file(submodule) and then apply a label(commit the superproject) to keep the
> changes together.
>
> If the submodule is not attached the commit in the superproject can still
> detect changes that have been made to the corresponding tracking branch and
> pick these up.
>
> As a summary: Tracking submodule branches in the superproject instead of
> only the current HEAD of the submodule gives you more freedom to install
> sane auto-update procedures.
But we would want to have a deterministic update procedure, no? (And what
has more freedom than a detached HEAD? ;-)
> Even though it will raise a lot of detailed
> questions like "should the refs/super/* be pushed/pulled when syncing the
> submodule repositories".
I doubt that is a good idea, as that might conflict with the same submodule
sitting in a different superproject. But I'm interested to hear how you
want to solve that.
^ permalink raw reply
* Re: Odd issue - The Diffs That WILL NOT DIE.
From: Chris Patti @ 2011-12-07 22:24 UTC (permalink / raw)
To: Jeff King; +Cc: Carlos Martín Nieto, git
In-Reply-To: <20111207220345.GA21596@sigill.intra.peff.net>
On Wed, Dec 7, 2011 at 5:03 PM, Jeff King <peff@peff.net> wrote:
> On Wed, Dec 07, 2011 at 11:54:26AM -0500, Chris Patti wrote:
>
>> OK. Let me give you a very specific series of commands, sorry about
>> the poor question / report (Not convinced it's a bug, probably pilot
>> error?)
>>
>> If my understanding of the way Git works is correct, there should be
>> NO pending diffs in a freshly cloned repository, yes?
>
> Yes. It's probably a bug, perhaps related to the case-insensitive
> filesystem (we've seen similar weird "phantom changes right after clone"
> bugs before).
>
>> 11:35][admin@Hiram-Abiff-2:~/src]$ rm -rf framework/
>> [11:37][admin@Hiram-Abiff-2:~/src]$
>> [11:44][admin@Hiram-Abiff-2:~/src]$ git clone
>> ssh://git.bluestatedigital.com/home/git/framework.git
>> Cloning into 'framework'...
>> remote: Counting objects: 378540, done.
>> remote: Compressing objects: 100% (100469/100469), done.
>> remote: Total 378540 (delta 261046), reused 374685 (delta 258447)
>> Receiving objects: 100% (378540/378540), 148.33 MiB | 2.08 MiB/s, done.
>> Resolving deltas: 100% (261046/261046), done.
>> [11:51][admin@Hiram-Abiff-2:~/src]$ cd framework/
>> [11:51][admin@Hiram-Abiff-2:~/src/framework(master)]$ git diff
>> diff --git a/app/modules/Core/controllers/CloudSponge.php b/app/modules/Core/con
>> index 615a7b3..911d456 100644
>> --- a/app/modules/Core/controllers/CloudSponge.php
>> +++ b/app/modules/Core/controllers/CloudSponge.php
>
> Are there other files in the repository that differ from this path only
> in capitalization? Can you show us the output of "git ls-files"?
>
> Is it possible to make this repo public, or at least available privately
> to git developers?
>
> You mentioned v1.7.8. Do you see the bug with other git versions? If
> not, can you try bisecting?
>
> -Peff
Yup, you nailed it. The files in question are CloudSponge.php
(deleted) and Cloudsponge.php (still being actively maintained).
I am seeing the same behavior with 1.7.7.4 which I backrevved to
yesterday while troubleshooting this issue. Can you suggest an older
version for me to try next?
I'm not sure how I would git bisect in this case, I'd need to have all
the different git revs installed in order to do that right? (I'm
relatively new to git bisect, just figured it out the other day).
Thanks,
-Chris
--
Christopher Patti - Geek At Large | GTalk: cpatti@gmail.com | AIM:
chrisfeohpatti | P: (260) 54PATTI
"Technology challenges art, art inspires technology." - John Lasseter, Pixar
^ permalink raw reply
* Re: Odd issue - The Diffs That WILL NOT DIE.
From: Chris Patti @ 2011-12-07 22:30 UTC (permalink / raw)
To: Jeff King; +Cc: Carlos Martín Nieto, git
In-Reply-To: <CAJ8P3RB=Gj-QCe6meqXSZ7N8+PnfNxSD8omUxT6dDh00bUf0QQ@mail.gmail.com>
Actually I'm wrong on that count, but in an interesting way.
Both CloudSponge.php and Cloudsponge.php exist and are *not* deleted
in the remote repository, but on OSX only Cloudsponge.php shows up on
the filesystem, yet CloudSponge.php is being reported as modified.
Turns out two of our other developers are also seeing this behavior.
-Chris
On Wed, Dec 7, 2011 at 5:24 PM, Chris Patti <cpatti@gmail.com> wrote:
> On Wed, Dec 7, 2011 at 5:03 PM, Jeff King <peff@peff.net> wrote:
>> On Wed, Dec 07, 2011 at 11:54:26AM -0500, Chris Patti wrote:
>>
>>> OK. Let me give you a very specific series of commands, sorry about
>>> the poor question / report (Not convinced it's a bug, probably pilot
>>> error?)
>>>
>>> If my understanding of the way Git works is correct, there should be
>>> NO pending diffs in a freshly cloned repository, yes?
>>
>> Yes. It's probably a bug, perhaps related to the case-insensitive
>> filesystem (we've seen similar weird "phantom changes right after clone"
>> bugs before).
>>
>>> 11:35][admin@Hiram-Abiff-2:~/src]$ rm -rf framework/
>>> [11:37][admin@Hiram-Abiff-2:~/src]$
>>> [11:44][admin@Hiram-Abiff-2:~/src]$ git clone
>>> ssh://git.bluestatedigital.com/home/git/framework.git
>>> Cloning into 'framework'...
>>> remote: Counting objects: 378540, done.
>>> remote: Compressing objects: 100% (100469/100469), done.
>>> remote: Total 378540 (delta 261046), reused 374685 (delta 258447)
>>> Receiving objects: 100% (378540/378540), 148.33 MiB | 2.08 MiB/s, done.
>>> Resolving deltas: 100% (261046/261046), done.
>>> [11:51][admin@Hiram-Abiff-2:~/src]$ cd framework/
>>> [11:51][admin@Hiram-Abiff-2:~/src/framework(master)]$ git diff
>>> diff --git a/app/modules/Core/controllers/CloudSponge.php b/app/modules/Core/con
>>> index 615a7b3..911d456 100644
>>> --- a/app/modules/Core/controllers/CloudSponge.php
>>> +++ b/app/modules/Core/controllers/CloudSponge.php
>>
>> Are there other files in the repository that differ from this path only
>> in capitalization? Can you show us the output of "git ls-files"?
>>
>> Is it possible to make this repo public, or at least available privately
>> to git developers?
>>
>> You mentioned v1.7.8. Do you see the bug with other git versions? If
>> not, can you try bisecting?
>>
>> -Peff
>
> Yup, you nailed it. The files in question are CloudSponge.php
> (deleted) and Cloudsponge.php (still being actively maintained).
>
> I am seeing the same behavior with 1.7.7.4 which I backrevved to
> yesterday while troubleshooting this issue. Can you suggest an older
> version for me to try next?
>
> I'm not sure how I would git bisect in this case, I'd need to have all
> the different git revs installed in order to do that right? (I'm
> relatively new to git bisect, just figured it out the other day).
>
> Thanks,
> -Chris
>
> --
> Christopher Patti - Geek At Large | GTalk: cpatti@gmail.com | AIM:
> chrisfeohpatti | P: (260) 54PATTI
> "Technology challenges art, art inspires technology." - John Lasseter, Pixar
--
Christopher Patti - Geek At Large | GTalk: cpatti@gmail.com | AIM:
chrisfeohpatti | P: (260) 54PATTI
"Technology challenges art, art inspires technology." - John Lasseter, Pixar
^ permalink raw reply
* Re: Debugging git-commit slowness on a large repo
From: Joshua Redstone @ 2011-12-07 22:48 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy
Cc: Carlos Martín Nieto, Tomas Carnecky, Junio C Hamano,
git@vger.kernel.org
In-Reply-To: <CACsJy8Dbd+v+8FzvQS9a4C8DQSxQGgqQNGaLhL1cHv-yMnaCJQ@mail.gmail.com>
Hi Duy,
Thanks for the documentation link.
git ls-files shows 100k files, which matches # of files in the working
tree ('find . -type f -print | wc -l').
I added a 'git read-tree HEAD' before the git-add, and a 'git write-tree'
after the add. With that, the commit time slowed down to 8 seconds per
commit, plus 4 more seconds for the read-tree/add/write-tree ops. The
read-tree/add/write-tree each took about a second.
As an experiment, I also tried removing the 'git read-tree' and just
having the git-write-tree. That sped up commits to 0.6 seconds, but the
overall time for add/write-tree/commit was still 3 to 6 seconds.
For comparison, without the read-tree and write-tree, commits take about 1
second and add/commit in total takes about 2 seconds.
It surprises me that the presence of git read-tree or write-tree would
slow things down so much.
Josh
On 12/6/11 6:08 PM, "Nguyen Thai Ngoc Duy" <pclouds@gmail.com> wrote:
>On Wed, Dec 7, 2011 at 8:48 AM, Joshua Redstone <joshua.redstone@fb.com>
>wrote:
>> I tried doing a 'git read-tree HEAD' before each 'git add ; git commit'
>> iteration, and the time for git-commit jumped from about 1 second to
>>about
>> 8 seconds. That is a pretty dramatic slowdown. Any idea why? I wonder
>> if that's related to the overall commit slowness.
>
>How big is your working directory? "git ls-files | wc -l" should show
>it. Try "git read-tree HEAD; git add; git write-tree" and see if the
>write-tree part takes as much time as commit. write-tree is mainly
>about cache-tree generation.
>
>> @Carlos and/or @Junio, can you point me at any docs/code to understand
>> what a tree-cache is and how it differs from the index? I did a google
>> search for [git tree-cache index], but nothing popped out.
>
>Have a look at Documentation/technical/index-format.txt. Cache tree
>extension is near the end.
>--
>Duy
^ permalink raw reply
* Re: git auto-repack is broken...
From: Jeff King @ 2011-12-07 22:53 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Brandon Casey, Junio C Hamano, Linus Torvalds,
Ævar Arnfjörð, Git Mailing List
In-Reply-To: <alpine.LFD.2.02.1112071709250.2907@xanadu.home>
On Wed, Dec 07, 2011 at 05:12:14PM -0500, Nicolas Pitre wrote:
> Maybe FETCH_HEAD should have a reflog too?
That might be nice. However, there is a complication, in that FETCH_HEAD
may contain many sha1s, but each reflog entry only has room for a single
sha1 transition. You could obviously encode it as a series of reflog
entries, but then "git show FETCH_HEAD@{1}" is not very meaningful.
-Peff
^ permalink raw reply
* Re: Odd issue - The Diffs That WILL NOT DIE.
From: Carlos Martín Nieto @ 2011-12-07 22:58 UTC (permalink / raw)
To: Chris Patti; +Cc: Jeff King, git
In-Reply-To: <CAJ8P3RA48W7ZiABvjkn_KkU-JPnCnaF_X_WK0wPtToph3DGDvg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1083 bytes --]
On Wed, Dec 07, 2011 at 05:30:19PM -0500, Chris Patti wrote:
> Actually I'm wrong on that count, but in an interesting way.
>
> Both CloudSponge.php and Cloudsponge.php exist and are *not* deleted
> in the remote repository, but on OSX only Cloudsponge.php shows up on
> the filesystem, yet CloudSponge.php is being reported as modified.
>
> Turns out two of our other developers are also seeing this behavior.
HFS+ (the filesystem used by OSX) is case insensitive unless you
toggle some magic switch, so git set core.ignorecase to true on clone
(the config manpage claims its done on init or clone, in any case)
which makes it assume that Cloudsponge.php and CloudSponge.php are the
same file (which in a case-insensitive filesystem is true).
If you want to use OSX to develop this project, you'll have to either
rename one of those files or set your filesystem to be case-sensitive
(and unset core.ignorecase afterwards). From what I've heard, the OS
itself will work fine with a case-sensitive filesystem, but not all
applications might. YMMV.
cmn
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: Odd issue - The Diffs That WILL NOT DIE.
From: Jeff King @ 2011-12-07 23:03 UTC (permalink / raw)
To: Chris Patti; +Cc: Carlos Martín Nieto, git
In-Reply-To: <CAJ8P3RB=Gj-QCe6meqXSZ7N8+PnfNxSD8omUxT6dDh00bUf0QQ@mail.gmail.com>
On Wed, Dec 07, 2011 at 05:24:01PM -0500, Chris Patti wrote:
> Yup, you nailed it. The files in question are CloudSponge.php
> (deleted) and Cloudsponge.php (still being actively maintained).
> [...]
> Actually I'm wrong on that count, but in an interesting way.
>
> Both CloudSponge.php and Cloudsponge.php exist and are *not* deleted
> in the remote repository, but on OSX only Cloudsponge.php shows up on
> the filesystem, yet CloudSponge.php is being reported as modified.
>
> Turns out two of our other developers are also seeing this behavior.
OK. Then it's not a bug[1], but rather an incompatibility issue. Your
repository stores two files which differ only in case, but your
underlying case-insensitive filesystem is incapable of storing both of
them simultaneously.
There's really no way around it except to either use a case-sensitive
filesystem, rename your files (or if one if obsolete, get rid of it).
[1] Arguably git could be better at noticing and reporting this issue,
but that wouldn't change the fundamental problem.
> I am seeing the same behavior with 1.7.7.4 which I backrevved to
> yesterday while troubleshooting this issue. Can you suggest an older
> version for me to try next?
No, you'll see the same behavior in all versions of git (I was mostly
concerned that it was a regression new in v1.7.8, as I fixed some
case-sensitivity bugs recently).
> I'm not sure how I would git bisect in this case, I'd need to have all
> the different git revs installed in order to do that right? (I'm
> relatively new to git bisect, just figured it out the other day).
You can't bisect, because you don't have a version that actually worked.
But if you had, you would do it by cloning and building the git
repository itself, then starting a bisection like:
git clone git://git.kernel.org/pub/scm/git/git.git
git bisect start
git bisect bad v1.7.8
git bisect good v1.7.7.4 ;# if it had turned out to be OK
and then repeatedly build and try your test with each version of git,
until if finally narrowed it down to a single offending commit.
-Peff
^ permalink raw reply
* Re: Odd issue - The Diffs That WILL NOT DIE.
From: Jeff King @ 2011-12-07 23:06 UTC (permalink / raw)
To: Carlos Martín Nieto; +Cc: Chris Patti, git
In-Reply-To: <20111207225827.GB641@centaur.lab.cmartin.tk>
On Wed, Dec 07, 2011 at 11:58:27PM +0100, Carlos Martín Nieto wrote:
> If you want to use OSX to develop this project, you'll have to either
> rename one of those files or set your filesystem to be case-sensitive
> (and unset core.ignorecase afterwards). From what I've heard, the OS
> itself will work fine with a case-sensitive filesystem, but not all
> applications might. YMMV.
I've never done it, but my understanding is that for HFS+, going
case-sensitive is not a simple flip of a switch, but you have to
actually make a new filesystem. Given that complexity, and the fact that
some other apps might not like it, your best bet might be to create a
new case-sensitive filesystem in a loopback file, and then mount that
just for this project.
I'm not sure of the exact commands under OS X, but I'm sure some
googling could probably turn up a solution.
-Peff
^ permalink raw reply
* Re: [PATCH 1/4] test: add missing "&&" after echo command
From: Jeff King @ 2011-12-07 23:10 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Junio C Hamano, git, Vijay Lakshminarayanan, Viresh Kumar,
Shiraz HASHIM
In-Reply-To: <20111207144540.GB30157@elie.hsd1.il.comcast.net>
On Wed, Dec 07, 2011 at 08:45:40AM -0600, Jonathan Nieder wrote:
> diff --git a/t/t7501-commit.sh b/t/t7501-commit.sh
> index 3ad04363..da75abc1 100755
> --- a/t/t7501-commit.sh
> +++ b/t/t7501-commit.sh
> @@ -60,7 +60,7 @@ test_expect_success \
>
> test_expect_success \
> "next commit" \
> - "echo 'bongo bongo bongo' >file \
> + "echo 'bongo bongo bongo' >file && \
> git commit -m next -a"
Patch is obviously correct, but isn't the "\" here just superfluous and
error-prone? Maybe it should just be dropped from the new version (and
possibly from other tests in t7501).
-Peff
^ permalink raw reply
* Re: [PATCH 1/4] test: add missing "&&" after echo command
From: Jeff King @ 2011-12-07 23:11 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Junio C Hamano, git, Vijay Lakshminarayanan, Viresh Kumar,
Shiraz HASHIM
In-Reply-To: <20111207231002.GD21852@sigill.intra.peff.net>
On Wed, Dec 07, 2011 at 06:10:03PM -0500, Jeff King wrote:
> On Wed, Dec 07, 2011 at 08:45:40AM -0600, Jonathan Nieder wrote:
>
> > diff --git a/t/t7501-commit.sh b/t/t7501-commit.sh
> > index 3ad04363..da75abc1 100755
> > --- a/t/t7501-commit.sh
> > +++ b/t/t7501-commit.sh
> > @@ -60,7 +60,7 @@ test_expect_success \
> >
> > test_expect_success \
> > "next commit" \
> > - "echo 'bongo bongo bongo' >file \
> > + "echo 'bongo bongo bongo' >file && \
> > git commit -m next -a"
>
> Patch is obviously correct, but isn't the "\" here just superfluous and
> error-prone? Maybe it should just be dropped from the new version (and
> possibly from other tests in t7501).
Oh, nevermind. I just read your patch 3, which does that and much more.
I approve.
-Peff
^ permalink raw reply
* Re: git auto-repack is broken...
From: Nicolas Pitre @ 2011-12-08 0:18 UTC (permalink / raw)
To: Jeff King
Cc: Brandon Casey, Junio C Hamano, Linus Torvalds,
Ævar Arnfjörð, Git Mailing List
In-Reply-To: <20111207225318.GA21852@sigill.intra.peff.net>
On Wed, 7 Dec 2011, Jeff King wrote:
> On Wed, Dec 07, 2011 at 05:12:14PM -0500, Nicolas Pitre wrote:
>
> > Maybe FETCH_HEAD should have a reflog too?
>
> That might be nice. However, there is a complication, in that FETCH_HEAD
> may contain many sha1s, but each reflog entry only has room for a single
> sha1 transition. You could obviously encode it as a series of reflog
> entries, but then "git show FETCH_HEAD@{1}" is not very meaningful.
What does "git show FETCH_HEAD" do now? If it shows only one
(presumably the first) SHA1 then its reflog doesn't have to be smarter,
which would properly cover most cases already. I certainly never did a
multi-ref fetch myself.
Nicolas
^ permalink raw reply
* Re: git auto-repack is broken...
From: Jeff King @ 2011-12-08 0:45 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Brandon Casey, Junio C Hamano, Linus Torvalds,
Ævar Arnfjörð, Git Mailing List
In-Reply-To: <alpine.LFD.2.02.1112071912570.2907@xanadu.home>
On Wed, Dec 07, 2011 at 07:18:13PM -0500, Nicolas Pitre wrote:
> > > Maybe FETCH_HEAD should have a reflog too?
> >
> > That might be nice. However, there is a complication, in that FETCH_HEAD
> > may contain many sha1s, but each reflog entry only has room for a single
> > sha1 transition. You could obviously encode it as a series of reflog
> > entries, but then "git show FETCH_HEAD@{1}" is not very meaningful.
>
> What does "git show FETCH_HEAD" do now? If it shows only one
> (presumably the first) SHA1 then its reflog doesn't have to be
> smarter, which would properly cover most cases already.
Are you proposing that it only store the first ref in the reflog, or
that we accept that a single fetch may write lots of reflog entries?
If the former, then you are missing the expiration/connectivity
properties.
If the latter, then it is not just "we only show the first one for
FETCH_HEAD@{1}", but also "the thing that used to be FETCH_HEAD@{1} does
not graduate to FETCH_HEAD@{2}, but rather FETCH_HEAD@{n} for some
unknown n". That may be an acceptable limitation; I just wanted to
mention it in case somebody can think of some clever solution.
> I certainly never did a multi-ref fetch myself.
Not consciously, perhaps, but you do it all the time without realizing
it:
$ git clone git://git.kernel.org/pub/scm/git/git.git
$ cd git
$ git fetch -v origin
= [up to date] maint -> origin/maint
= [up to date] master -> origin/master
= [up to date] next -> origin/next
= [up to date] pu -> origin/pu
= [up to date] todo -> origin/todo
$ cat .git/FETCH_HEAD
b1af9630d758e1728fc0008b3f18d90d8f87f4c5 not-for-merge branch 'maint' of git://git.kernel.org/pub/scm/git/git
4cb5d10b14dcbe0155bed9c45ccb94e83bd4c599 branch 'master' of git://git.kernel.org/pub/scm/git/git
03e5527c5df33d4550ccc1446d861c0aa5689d58 not-for-merge branch 'next' of git://git.kernel.org/pub/scm/git/git
cc4e3f01fc6a5e09ae5bbdc464965981fae4cf39 not-for-merge branch 'pu' of git://git.kernel.org/pub/scm/git/git
7a02dba15bd28826344f9c14a5e2b5c57eeb7e50 not-for-merge branch 'todo' of git://git.kernel.org/pub/scm/git/git
-Peff
^ permalink raw reply
* Re: git auto-repack is broken...
From: Jeff King @ 2011-12-08 0:49 UTC (permalink / raw)
To: Brandon Casey
Cc: Junio C Hamano, Linus Torvalds, Ævar Arnfjörð,
Git Mailing List
In-Reply-To: <CA+sFfMdeVoz8XU5j4hNn1qCHHzaiDi0Bw=QbbuU3cwT9mMPZOA@mail.gmail.com>
On Sat, Dec 03, 2011 at 01:42:22PM -0600, Brandon Casey wrote:
> > 4. "git gc" runs "git repack -Ad", which will eject X from the pack
> > into a loose form (because it is not becoming part of the new pack
> > we are writing).
>
> Actually, it is right here when the newly loosened unreferenced
> objects will be deleted. Objects ejected from a pack _are_ given the
> timestamp of the pack they were ejected from. So, if the pack is
> older than two weeks (90 days in your example), then so will be the
> loosened objects, and git prune will delete them when called by git
> gc.
Thanks, I didn't notice that when looking at the code.
> Decreasing gc.pruneExpire as you suggested should make it much less
> likely to run into this problem.
I'd be more comfortable with that solution if we had data on what the
timestamps look like when it actually happens (e.g., an "ls -lR" listing
of a repository that in practice is wanting to auto-gc too often).
> I wonder if it is worth trying to limit how often gc --auto is run to
> not be more often than gc.pruneExpire or something. If we modified
> the timestamp that is assigned to fetched packs, maybe we could use
> the pack timestamps as an indicator of how recently git gc has run.
I'm worried you run into other corner cases, there. Like a repository
which is generating new, referenced objects at a fast rate (e.g.,
because you're importing something) should trigger auto-gc much sooner
than that, and this rule would prevent it.
-Peff
^ permalink raw reply
* Re: Debugging git-commit slowness on a large repo
From: Nguyen Thai Ngoc Duy @ 2011-12-08 1:39 UTC (permalink / raw)
To: Joshua Redstone
Cc: Carlos Martín Nieto, Tomas Carnecky, Junio C Hamano,
git@vger.kernel.org
In-Reply-To: <CB051EFC.2C795%joshua.redstone@fb.com>
On Thu, Dec 8, 2011 at 5:48 AM, Joshua Redstone <joshua.redstone@fb.com> wrote:
> Hi Duy,
> Thanks for the documentation link.
>
> git ls-files shows 100k files, which matches # of files in the working
> tree ('find . -type f -print | wc -l').
Any chance you can split it into smaller repositories, or remove files
from working directory (e.g. if you store logs, you don't have to keep
logs from all time in working directory, they can be retrieved from
history).
> I added a 'git read-tree HEAD' before the git-add, and a 'git write-tree'
> after the add. With that, the commit time slowed down to 8 seconds per
> commit, plus 4 more seconds for the read-tree/add/write-tree ops. The
> read-tree/add/write-tree each took about a second.
read-tree destroys stat info in index, refreshing 100k entries in
index in this case may take some time. Try this to see if commit time
reduces and how much time update-index takes
read-tree HEAD
update-index --refresh
add ....
write-tree
commit -q
> As an experiment, I also tried removing the 'git read-tree' and just
> having the git-write-tree. That sped up commits to 0.6 seconds, but the
> overall time for add/write-tree/commit was still 3 to 6 seconds.
overall time is not really important because we duplicate work here
(write-tree is done as part of commit again). What I'm trying to do is
to determine how much time each operation in commit may take.
--
Duy
^ permalink raw reply
* [PATCH] git-send-email: Add auto-cc to all body signatures
From: Joe Perches @ 2011-12-08 2:58 UTC (permalink / raw)
To: git; +Cc: jeffrey.t.kirsher
In-Reply-To: <1311903782.20837.42.camel@jtkirshe-mobl>
Many types of signatures are used by various projects.
The most common type is formatted:
"[some_signature_type]-by: First Last <email@domain.tld>"
e.g:
"Reported-by: First Last <email@domain.tld>" (no quotes are used)
Make git-send-email use these signatures as "CC:" entries.
Add command line option --suppress-cc=signatures to avoid
adding these entries to the cc.
Signed-off-by: Joe Perches <joe@perches.com>
Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
Documentation/git-send-email.txt | 3 ++-
git-send-email.perl | 11 ++++++-----
2 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index 327233c..17ea825 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -246,8 +246,9 @@ Automating
patch body (commit message) except for self (use 'self' for that).
- 'sob' will avoid including anyone mentioned in Signed-off-by lines except
for self (use 'self' for that).
+- 'signatures' will avoid including anyone mentioned in any "<foo>-by:" lines.
- 'cccmd' will avoid running the --cc-cmd.
-- 'body' is equivalent to 'sob' + 'bodycc'
+- 'body' is equivalent to 'sob' + 'bodycc + signatures'
- 'all' will suppress all auto cc values.
--
+
diff --git a/git-send-email.perl b/git-send-email.perl
index d491db9..fc5bf41 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -75,7 +75,7 @@ git send-email [options] <file | directory | rev-list options >
--identity <str> * Use the sendemail.<id> options.
--to-cmd <str> * Email To: via `<str> \$patch_path`
--cc-cmd <str> * Email Cc: via `<str> \$patch_path`
- --suppress-cc <str> * author, self, sob, cc, cccmd, body, bodycc, all.
+ --suppress-cc <str> * author, self, sob, cc, cccmd, body, bodycc, signatures, all.
--[no-]signed-off-by-cc * Send to Signed-off-by: addresses. Default on.
--[no-]suppress-from * Send to self. Default off.
--[no-]chain-reply-to * Chain In-Reply-To: fields. Default off.
@@ -393,13 +393,13 @@ my(%suppress_cc);
if (@suppress_cc) {
foreach my $entry (@suppress_cc) {
die "Unknown --suppress-cc field: '$entry'\n"
- unless $entry =~ /^(?:all|cccmd|cc|author|self|sob|body|bodycc)$/;
+ unless $entry =~ /^(?:all|cccmd|cc|author|self|sob|body|bodycc|signatures)$/;
$suppress_cc{$entry} = 1;
}
}
if ($suppress_cc{'all'}) {
- foreach my $entry (qw (cccmd cc author self sob body bodycc)) {
+ foreach my $entry (qw (cccmd cc author self sob body bodycc signatures)) {
$suppress_cc{$entry} = 1;
}
delete $suppress_cc{'all'};
@@ -410,7 +410,7 @@ $suppress_cc{'self'} = $suppress_from if defined $suppress_from;
$suppress_cc{'sob'} = !$signed_off_by_cc if defined $signed_off_by_cc;
if ($suppress_cc{'body'}) {
- foreach my $entry (qw (sob bodycc)) {
+ foreach my $entry (qw (sob bodycc signatures)) {
$suppress_cc{$entry} = 1;
}
delete $suppress_cc{'body'};
@@ -1276,7 +1276,7 @@ foreach my $t (@files) {
# Now parse the message body
while(<$fh>) {
$message .= $_;
- if (/^(Signed-off-by|Cc): (.*)$/i) {
+ if (/^(Signed-off-by|Cc|[a-z_-]+by): (.*)$/i) {
chomp;
my ($what, $c) = ($1, $2);
chomp $c;
@@ -1285,6 +1285,7 @@ foreach my $t (@files) {
} else {
next if $suppress_cc{'sob'} and $what =~ /Signed-off-by/i;
next if $suppress_cc{'bodycc'} and $what =~ /Cc/i;
+ next if $suppress_cc{'signatures'} and $what =~ /by$/i;
}
push @cc, $c;
printf("(body) Adding cc: %s from line '%s'\n",
--
1.7.8.dirty
^ permalink raw reply related
* Re: [PATCH] index-pack: eliminate unlimited recursion in get_delta_base()
From: Shawn Pearce @ 2011-12-08 3:02 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Junio C Hamano
In-Reply-To: <1323280223-7990-1-git-send-email-pclouds@gmail.com>
2011/12/7 Nguyễn Thái Ngọc Duy <pclouds@gmail.com>:
> Revert the order of delta applying so that by the time a delta is
> applied, its base is either non-delta or already inflated.
> get_delta_base() is still recursive, but because base's data is always
> ready, the inner get_delta_base() call never has any chance to call
> itself again.
...
> @@ -508,10 +508,25 @@ static void *get_base_data(struct base_data *c)
> {
> if (!c->data) {
> struct object_entry *obj = c->obj;
> + struct base_data **delta = NULL;
> + int delta_nr = 0, delta_alloc = 0;
>
> - if (is_delta_type(obj->type)) {
> - void *base = get_base_data(c->base);
> - void *raw = get_data_from_pack(obj);
I think you missed the critical recursion. The real work is the
recursion within find_unresolved_deltas(). This little helper
get_base_data() shouldn't be tripping over these cases unless we have
run out of delta_base_cache_limit and released objects near the base
end of the delta chain, in which case this will restore them.
Maybe this is useful on its own, but in my opinion its not an
interesting patch to consider without first fixing
find_unresolved_deltas's recursion.
^ permalink raw reply
* Re: git auto-repack is broken...
From: Nicolas Pitre @ 2011-12-08 3:35 UTC (permalink / raw)
To: Jeff King
Cc: Brandon Casey, Junio C Hamano, Linus Torvalds,
Ævar Arnfjörð, Git Mailing List
In-Reply-To: <20111208004515.GA23015@sigill.intra.peff.net>
On Wed, 7 Dec 2011, Jeff King wrote:
> On Wed, Dec 07, 2011 at 07:18:13PM -0500, Nicolas Pitre wrote:
>
> > I certainly never did a multi-ref fetch myself.
>
> Not consciously, perhaps, but you do it all the time without realizing
> it:
>
> $ git clone git://git.kernel.org/pub/scm/git/git.git
> $ cd git
> $ git fetch -v origin
> = [up to date] maint -> origin/maint
> = [up to date] master -> origin/master
> = [up to date] next -> origin/next
> = [up to date] pu -> origin/pu
> = [up to date] todo -> origin/todo
> $ cat .git/FETCH_HEAD
> b1af9630d758e1728fc0008b3f18d90d8f87f4c5 not-for-merge branch 'maint' of git://git.kernel.org/pub/scm/git/git
> 4cb5d10b14dcbe0155bed9c45ccb94e83bd4c599 branch 'master' of git://git.kernel.org/pub/scm/git/git
> 03e5527c5df33d4550ccc1446d861c0aa5689d58 not-for-merge branch 'next' of git://git.kernel.org/pub/scm/git/git
> cc4e3f01fc6a5e09ae5bbdc464965981fae4cf39 not-for-merge branch 'pu' of git://git.kernel.org/pub/scm/git/git
> 7a02dba15bd28826344f9c14a5e2b5c57eeb7e50 not-for-merge branch 'todo' of git://git.kernel.org/pub/scm/git/git
OK, nevermind. I admitedly never have been close enough to the related
code.
And I don't think this particular case is interesting anyway as the
reflogs for the various branches alre already involved. I was thinking
more about the "git fetch git://some.random.repo foobar" case where the
summary also explicitly shows:
From: git://some.random.repo
...... foobar -> FETCH_HEAD
In that case the only reference to the fetched branch is stored in
FETCH_HEAD and that is what might be worthwile for a reflog.
Nicolas
^ permalink raw reply
* Re: git auto-repack is broken...
From: Jeff King @ 2011-12-08 3:40 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Brandon Casey, Junio C Hamano, Linus Torvalds,
Ævar Arnfjörð, Git Mailing List
In-Reply-To: <alpine.LFD.2.02.1112072227510.2907@xanadu.home>
On Wed, Dec 07, 2011 at 10:35:00PM -0500, Nicolas Pitre wrote:
> And I don't think this particular case is interesting anyway as the
> reflogs for the various branches alre already involved. I was thinking
> more about the "git fetch git://some.random.repo foobar" case where the
> summary also explicitly shows:
>
> From: git://some.random.repo
> ...... foobar -> FETCH_HEAD
>
> In that case the only reference to the fetched branch is stored in
> FETCH_HEAD and that is what might be worthwile for a reflog.
I agree that is the interesting case. Perhaps we could just not bother
writing the other case into the reflog at all. So the reflog would be
sensible and contain only the set of things they had fetched or pulled
explicitly by URL. If they really want to do a multi-ref one-off fetch
from some URL, then we write multiple reflog entries. But at least the
user is very aware of what they've done, so they're not surprised by the
reflog advancing by more than 1 entry.
-Peff
^ permalink raw reply
* Re: [PATCH 07/15] t1510 (worktree): fix && chaining
From: Ramkumar Ramachandra @ 2011-12-08 4:39 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Junio C Hamano, Git List
In-Reply-To: <20111207215100.GB2911@elie.hsd1.il.comcast.net>
Hi Jonathan,
Jonathan Nieder wrote:
> [...]
> On some shells, like /usr/xpg4/bin/sh on Solaris, unset returns nonzero
> status when the variable passed was already unset. Will this work on
> such platforms, or does it need to be changed to use sane_unset?
Interesting. Thanks for catching this.
-- Ram
^ 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