* [PATCH] tests: sanitize more git environment variables
From: Jeff King @ 2011-01-26 20:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
These variables should generally not be set in one's
environment, but they do get set by rebase, which means
doing an interactive rebase like:
pick abcd1234 foo
exec make test
will cause false negatives in the test suite.
Signed-off-by: Jeff King <peff@peff.net>
---
t/test-lib.sh | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 42f2f14..0fdc541 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -70,6 +70,9 @@ unset GIT_NOTES_REF
unset GIT_NOTES_DISPLAY_REF
unset GIT_NOTES_REWRITE_REF
unset GIT_NOTES_REWRITE_MODE
+unset GIT_REFLOG_ACTION
+unset GIT_CHERRY_PICK_HELP
+unset GIT_QUIET
GIT_MERGE_VERBOSITY=5
export GIT_MERGE_VERBOSITY
export GIT_AUTHOR_EMAIL GIT_AUTHOR_NAME
--
1.7.0.9.7.g36b59
^ permalink raw reply related
* Re: Updating a submodule with a compatible version from another submodule version using the parent meta-repository
From: Jens Lehmann @ 2011-01-26 20:31 UTC (permalink / raw)
To: Julian Ibarz; +Cc: git
In-Reply-To: <AANLkTik-XdgGM20kFu8KZ5k9ynfNAo8fvL9t7kL_JhQg@mail.gmail.com>
Am 26.01.2011 20:48, schrieb Julian Ibarz:
> Basically my feature would work like this:
>
> in B:
> git submodule checkout some_version
>
> This will checkout B but also change A and C so that it is compatible
> with some_version of B. Basically it will find the commit in A that
> has the closest parent commit of some_version in B. When this is done
> it just does git submodule udate on other submodules.
Thanks, now I understand what you are trying to achieve.
> I see in gitk that there is a feature that has a common implementation
> for what I want to do:
>
> For every commits you can see Follows and Precedes which lists the
> closest label before this release and after. What I need is the same
> thing: instead of finding a closest labeled commit, I need to find a
> closest commit referenced by A that precedes current HEAD of B. When
> this is done I know which commit A has to be and then just have to
> call git submodule update in A (update every other submodules except
> for B).
I am not aware of something like that in current Git, But I see that
such functionality would be helpful. Care to share your implementation
idea?
^ permalink raw reply
* Re: Can't find the revelant commit with git-log
From: Francis Moreau @ 2011-01-26 19:50 UTC (permalink / raw)
To: René Scharfe; +Cc: git
In-Reply-To: <4D406A64.1000200@lsrfire.ath.cx>
René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
> Am 26.01.2011 10:01, schrieb Francis Moreau:
[...]
>> error: The following untracked working tree files would be overwritten
>> by checkout:
>> arch/x86/es7000/Makefile
>> arch/x86/es7000/es7000.h
>> arch/x86/es7000/es7000plat.c
>> drivers/pci/dma_remapping.h
>> Please move or remove them before you can switch branches.
>
> These are untracked files; your tree is not clean. Either commit them,
> stash them away or delete the files. Or make a local clone just for
> bisecting purposes.
>
Hmm, I'm wondering how those files get there...
Maybe they are some left from some git commands which failed, I dunno.
--
Francis
^ permalink raw reply
* Re: Updating a submodule with a compatible version from another submodule version using the parent meta-repository
From: Julian Ibarz @ 2011-01-26 19:48 UTC (permalink / raw)
To: Jens Lehmann; +Cc: git
In-Reply-To: <4D407875.7080607@web.de>
> Am 26.01.2011 20:10, schrieb Julian Ibarz:
>> On Wed, Jan 26, 2011 at 2:06 PM, Jens Lehmann <Jens.Lehmann@web.de> wrote:
>>> Am 26.01.2011 19:32, schrieb Julian Ibarz:
>>>> I am using git submodule in one of my professional projects and I am
>>>> facing an issue when I am using git bisect in one of the submodules.
>>>>
>>>> Basically I have a meta repository which I will call A and two
>>>> submodules B and C. Sometimes I use git bisect in B but it is
>>>> dependent on C so when I go back too much in the history of B, C needs
>>>> to change its version to a compatible one. Doing this manually is
>>>> really time consuming for me and I guess a lot of people have this
>>>> issue so I was a little bit surprise to not find easily anything on
>>>> the net that permits to do this automatically.
>>>
>>> What about bisecting in A (doing "git submodule update" after every
>>> step) to bisect to a smaller range of commits in B (which are then
>>> not dependent on your submodule C anymore and can be bisected inside
>>> B)? This of course assumes A properly records the dependencies
>>> between B and C.
>>
>> Yes but actually my real use case that made me write this mail was
>> more I have a feature done in an old branch and to try it I never to
>> revert back to this version. In this case, I have to find out the
>> corresponding good version in A and C. In this case I cannot start
>> like what you propose in A to find out the good version in B and C, I
>> already know the version I want in B.
>
> Hmm, looks like I lost you here ... you want to bisect in B although
> you know what commit you want there? Care to explain a bit more?
In B I have a feature to integrate in master branch. This feature is
in branch old_feature. But this branch is really old. To try this
feature I need to rebuild it at this version. To make the build
success I need also to revert back the submodule C because B is
dependent on it. But finding the good version of C that match
old_feature version is a pain... Is it clear?
>>>> Is there anything existing to do that and I just didn't find it yet?
>>>> If not I think I might have an implementation idea I would like to try
>>>> out.
>>>
>>> The call to "git submodule update" after each bisect step in the
>>> superproject will be obsolete as soon as the recursive checkout
>>> I am currently working on is done, but that is not here yet.
>>
>> Can you be more detailed about your recursive checkout feature? Is it
>> what I proposed?
>
> I don't think so, that will just get rid of the extra call to "git
> submodule update" when bisecting in A.
Basically my feature would work like this:
in B:
git submodule checkout some_version
This will checkout B but also change A and C so that it is compatible
with some_version of B. Basically it will find the commit in A that
has the closest parent commit of some_version in B. When this is done
it just does git submodule udate on other submodules.
I see in gitk that there is a feature that has a common implementation
for what I want to do:
For every commits you can see Follows and Precedes which lists the
closest label before this release and after. What I need is the same
thing: instead of finding a closest labeled commit, I need to find a
closest commit referenced by A that precedes current HEAD of B. When
this is done I know which commit A has to be and then just have to
call git submodule update in A (update every other submodules except
for B).
Julian
^ permalink raw reply
* Re: Updating a submodule with a compatible version from another submodule version using the parent meta-repository
From: Jens Lehmann @ 2011-01-26 19:39 UTC (permalink / raw)
To: Julian Ibarz; +Cc: git
In-Reply-To: <AANLkTinMhvBNrBMJ8vQpJdYxP_NgJU2L7JEW0KhXGjhf@mail.gmail.com>
Am 26.01.2011 20:10, schrieb Julian Ibarz:
> On Wed, Jan 26, 2011 at 2:06 PM, Jens Lehmann <Jens.Lehmann@web.de> wrote:
>> Am 26.01.2011 19:32, schrieb Julian Ibarz:
>>> I am using git submodule in one of my professional projects and I am
>>> facing an issue when I am using git bisect in one of the submodules.
>>>
>>> Basically I have a meta repository which I will call A and two
>>> submodules B and C. Sometimes I use git bisect in B but it is
>>> dependent on C so when I go back too much in the history of B, C needs
>>> to change its version to a compatible one. Doing this manually is
>>> really time consuming for me and I guess a lot of people have this
>>> issue so I was a little bit surprise to not find easily anything on
>>> the net that permits to do this automatically.
>>
>> What about bisecting in A (doing "git submodule update" after every
>> step) to bisect to a smaller range of commits in B (which are then
>> not dependent on your submodule C anymore and can be bisected inside
>> B)? This of course assumes A properly records the dependencies
>> between B and C.
>
> Yes but actually my real use case that made me write this mail was
> more I have a feature done in an old branch and to try it I never to
> revert back to this version. In this case, I have to find out the
> corresponding good version in A and C. In this case I cannot start
> like what you propose in A to find out the good version in B and C, I
> already know the version I want in B.
Hmm, looks like I lost you here ... you want to bisect in B although
you know what commit you want there? Care to explain a bit more?
>>> Is there anything existing to do that and I just didn't find it yet?
>>> If not I think I might have an implementation idea I would like to try
>>> out.
>>
>> The call to "git submodule update" after each bisect step in the
>> superproject will be obsolete as soon as the recursive checkout
>> I am currently working on is done, but that is not here yet.
>
> Can you be more detailed about your recursive checkout feature? Is it
> what I proposed?
I don't think so, that will just get rid of the extra call to "git
submodule update" when bisecting in A.
^ permalink raw reply
* Re: Updating a submodule with a compatible version from another submodule version using the parent meta-repository
From: Julian Ibarz @ 2011-01-26 19:10 UTC (permalink / raw)
To: Jens Lehmann; +Cc: git
In-Reply-To: <4D407099.4010805@web.de>
On Wed, Jan 26, 2011 at 2:06 PM, Jens Lehmann <Jens.Lehmann@web.de> wrote:
> Am 26.01.2011 19:32, schrieb Julian Ibarz:
>> I am using git submodule in one of my professional projects and I am
>> facing an issue when I am using git bisect in one of the submodules.
>>
>> Basically I have a meta repository which I will call A and two
>> submodules B and C. Sometimes I use git bisect in B but it is
>> dependent on C so when I go back too much in the history of B, C needs
>> to change its version to a compatible one. Doing this manually is
>> really time consuming for me and I guess a lot of people have this
>> issue so I was a little bit surprise to not find easily anything on
>> the net that permits to do this automatically.
>
> What about bisecting in A (doing "git submodule update" after every
> step) to bisect to a smaller range of commits in B (which are then
> not dependent on your submodule C anymore and can be bisected inside
> B)? This of course assumes A properly records the dependencies
> between B and C.
Yes but actually my real use case that made me write this mail was
more I have a feature done in an old branch and to try it I never to
revert back to this version. In this case, I have to find out the
corresponding good version in A and C. In this case I cannot start
like what you propose in A to find out the good version in B and C, I
already know the version I want in B.
>> Is there anything existing to do that and I just didn't find it yet?
>> If not I think I might have an implementation idea I would like to try
>> out.
>
> The call to "git submodule update" after each bisect step in the
> superproject will be obsolete as soon as the recursive checkout
> I am currently working on is done, but that is not here yet.
Can you be more detailed about your recursive checkout feature? Is it
what I proposed?
^ permalink raw reply
* Re: Updating a submodule with a compatible version from another submodule version using the parent meta-repository
From: Jens Lehmann @ 2011-01-26 19:06 UTC (permalink / raw)
To: Julian Ibarz; +Cc: git
In-Reply-To: <AANLkTimvNaiieEw8-Y52xxDW6DQ6b16v9azCk+BDPxhe@mail.gmail.com>
Am 26.01.2011 19:32, schrieb Julian Ibarz:
> I am using git submodule in one of my professional projects and I am
> facing an issue when I am using git bisect in one of the submodules.
>
> Basically I have a meta repository which I will call A and two
> submodules B and C. Sometimes I use git bisect in B but it is
> dependent on C so when I go back too much in the history of B, C needs
> to change its version to a compatible one. Doing this manually is
> really time consuming for me and I guess a lot of people have this
> issue so I was a little bit surprise to not find easily anything on
> the net that permits to do this automatically.
What about bisecting in A (doing "git submodule update" after every
step) to bisect to a smaller range of commits in B (which are then
not dependent on your submodule C anymore and can be bisected inside
B)? This of course assumes A properly records the dependencies
between B and C.
> Is there anything existing to do that and I just didn't find it yet?
> If not I think I might have an implementation idea I would like to try
> out.
The call to "git submodule update" after each bisect step in the
superproject will be obsolete as soon as the recursive checkout
I am currently working on is done, but that is not here yet.
^ permalink raw reply
* Re: Can't find the revelant commit with git-log
From: René Scharfe @ 2011-01-26 18:39 UTC (permalink / raw)
To: git
In-Reply-To: <m2y668yr6k.fsf@gmail.com>
Am 26.01.2011 10:01, schrieb Francis Moreau:
> René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
>
> [...]
>
>> Hmm, seems like the function is gone since d847059. Does all of this help
>> you in any way?
>
> Sigh... one more try, one more failure...
>
> This time I tried to use git-bisect(1) to see if I couldn't track the
> change more easily.
>
> So, here's what I did:
>
> $ cat ./bisect.sh
> #! /bin/sh
>
> if ! git grep -q -e blacklist_iommu -- drivers/pci/intel-iommu.c
> then
> exit 1
> fi
>
> $ git bisect start v2.6.28 v2.6.27 -- drivers/pci
> Bisecting: 70 revisions left to test after this (roughly 6 steps)
> [a0bfb673dca8a2b4324fe11e678ec6d6a9ad67e0] Merge branch 'linux-next' of
> git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6
>
> $ git bisect run ./bisect.sh
> running /dev/shm/bisect.sh
> Bisecting: 42 revisions left to test after this (roughly 5 steps)
> [0235c4fc7fc6f621dc0dd89eba102ad5aa373390] PCI PM: Introduce function
> pci_wake_from_d3
> running /dev/shm/bisect.sh
> error: The following untracked working tree files would be overwritten
> by checkout:
> arch/x86/es7000/Makefile
> arch/x86/es7000/es7000.h
> arch/x86/es7000/es7000plat.c
> drivers/pci/dma_remapping.h
> Please move or remove them before you can switch branches.
These are untracked files; your tree is not clean. Either commit them,
stash them away or delete the files. Or make a local clone just for
bisecting purposes.
> Bisecting: 18 revisions left to test after this (roughly 4 steps)
> Aborting
> bisect run failed:
> 'bisect_state bad' exited with error code 1
>
> Do you know what's going wrong ?
I tried the same and the result was:
e61d98d8dad0048619bb138b0ff996422ffae53b is the first bad commit
But this probably won't help you much, either, as it is a regular commit
which doesn't touch the function (it doesn't exist before and after it).
I can only guess that bisect gets confused by the merges just like log
(and me).
René
^ permalink raw reply
* Updating a submodule with a compatible version from another submodule version using the parent meta-repository
From: Julian Ibarz @ 2011-01-26 18:32 UTC (permalink / raw)
To: git
In-Reply-To: <AANLkTinN1XVsAZXGLqkuhysrJ8-TCtGm4pOu2RfCEVVp@mail.gmail.com>
I am using git submodule in one of my professional projects and I am
facing an issue when I am using git bisect in one of the submodules.
Basically I have a meta repository which I will call A and two
submodules B and C. Sometimes I use git bisect in B but it is
dependent on C so when I go back too much in the history of B, C needs
to change its version to a compatible one. Doing this manually is
really time consuming for me and I guess a lot of people have this
issue so I was a little bit surprise to not find easily anything on
the net that permits to do this automatically.
Is there anything existing to do that and I just didn't find it yet?
If not I think I might have an implementation idea I would like to try
out.
Thanks for your time,
Julian Ibarz
^ permalink raw reply
* Re: Can't find the revelant commit with git-log
From: René Scharfe @ 2011-01-26 18:11 UTC (permalink / raw)
To: git; +Cc: Johannes Sixt
In-Reply-To: <m239og12pe.fsf@gmail.com>
Am 26.01.2011 09:36, schrieb Francis Moreau:
> Francis Moreau <francis.moro@gmail.com> writes:
>
>> René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
>>
>>> Try -m (show full diff for merge commits), as the change you're looking
>>> for seems to have been introduced by a merge, not a regular commit.
>>>
>>> $ opts="--stat -Sblacklist_iommu -m --oneline"
>>> $ revs="v2.6.27..v2.6.28"
>>>
>>> $ git log $opts $revs -- drivers/pci/intel-iommu.c
>>>
>>> This returns nothing. Hmm. Let's try this instead:
>>>
>>> $ git log $opts $revs -- drivers/pci/
>>> 057316c (from 3e2dab9) Merge branch 'linus' into test
>>> drivers/pci/intel-iommu.c | 307 ++++++++++++++++++++------------------------
>>> 1 files changed, 140 insertions(+), 167 deletions(-)
>>> 6b2ada8 (from 3b7ecb5) Merge branches 'core/softlockup', 'core/softirq', 'core/resources', 'core/printk' and 'core/misc' into core-v28-for-linus
>>> drivers/pci/intel-iommu.c | 187 ++++++--------------------------------------
>>> 1 files changed, 26 insertions(+), 161 deletions(-)
>>> d847059 (from 725c258) Merge branch 'x86/apic' into x86-v28-for-linus-phase4-B
>>> drivers/pci/intel-iommu.c | 185 ++++++---------------------------------------
>>> 1 files changed, 25 insertions(+), 160 deletions(-)
>>> 725c258 (from 129d6ab) Merge branches 'core/iommu', 'x86/amd-iommu' and 'x86/iommu' into x86-v28-for-linus-phase3-B
>>> drivers/pci/intel-iommu.c | 25 ++++++++++++++++++++++++-
>>> 1 files changed, 24 insertions(+), 1 deletions(-)
>>> 6e03f99 (from 9821626) Merge branch 'linus' into x86/iommu
>>> drivers/pci/intel-iommu.c | 23 +++++++++++++++++++++++
>>> 1 files changed, 23 insertions(+), 0 deletions(-)
>>>
>>> Strange, why did we need to remove the last path component to get these
>>> results which say that exactly the file we previously specified was changed?
>>
>> ah... I think I've been hit by this, since I tried '-m' too but see
>> nothing and was not smart enough to remove the filename from the path.
>>
>>> Also interesting, and matching the above results in that we see the need for
>>> the -m flag confirmed:
>
> BTW, couldn't '-m' automatically set when '-S' is given ?
I can't see a connection between the two options. Merges are ignored by
default (without -m) because they shouldn't contain any changes that
aren't already present in one of the merged branches (by convention),
and diffs with a single parent are easier to read. This is true with or
without -S.
So far we have two action items, I think:
- Make git grep report non-matching path specs (new feature).
- Find out why removing the last path component made a
difference in the case above (looks like a bug, but I don't
understand what's going on).
Taking into account what Johannes said regarding the disappearance of
the function during a merge instead of as part of a regular commit, I
don't think these changes would help you much with your use case,
though. You would still be looking at a complicated net of commits,
with the action happening in non-obvious places (merges).
Perhaps --graph can help a bit, see for yourself:
$ git log --graph -Sblacklist_iommu -m --oneline \
v2.6.27..v2.6.28 -- drivers/pci/
If you start at v.2.6.26 instead -- e.g. to catch the commit that
introduced the function -- then the graph gets a lot more colourful and
too complicated, at least for me, though.
René
^ permalink raw reply
* Re: git: patch does not apply
From: Junio C Hamano @ 2011-01-26 17:43 UTC (permalink / raw)
To: Dmitri Pissarenko; +Cc: git
In-Reply-To: <AANLkTi=ujfX53PXsfQXKf+1d5WQP=zMtzhKG-PSzT2_s@mail.gmail.com>
Dmitri Pissarenko <dmitri.pissarenko@gmail.com> writes:
> When I try to apply it, I get following message:
>
> $ git apply --check my_pcc_branch.patch
> warning: src/main/java/.../AbstractedPanel.java has type 100644, expected 100755
Whoever prepared the patch started off of the version of the file with
executable bit dropped, while you still have a version with executable
bit. This is a warning and is not a cause for the patch not applying.
> error: patch failed: src/main/java/.../AbstractedPanel.java:13
> error: src/main/java/.../AbstractedPanel.java: patch does not apply
The tool looked at around line 13 of the APanel.java file because the
input, my_pcc_branch.patch, wanted to change things around there, but
couldn't find corresponding preimage.
> What does it mean?
That is what it means.
> How can I fix this problem?
Look at the patch (find lines that perhaps begin with "@@ -13,something"
after "diff --git a/...APanel.java b/...APanel.java" appears), look at the
APanel.java file at around line 13, and see how they differ. Discern what
the patch wanted to do, and make a corresponding edit to ...APanel.java
file.
^ permalink raw reply
* Re: Fwd: Git and Large Binaries: A Proposed Solution
From: Joey Hess @ 2011-01-26 17:42 UTC (permalink / raw)
To: Scott Chacon; +Cc: git list
In-Reply-To: <AANLkTimE+s81Xbj4snNX0WWxG8x=qSwaQWfK+08+1Zy+@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 881 bytes --]
Scott Chacon wrote:
> Sorry to come in a bit late to this, but in addition to git-annex, I
> wrote something called 'git-media' a long time ago that works in a
> similar manner to what you both are discussing.
Huh, if I had known about that I might not have written git-annex.
Although probably I would have still, I needed a more distributed
approach to storing data than git-media seems to support, and the
ability to partially check out only some files.
> > git config --global filter.huge.clean huge-clean %f
>
> This is amazing. I absolutely did not know you could do this, and it
> would make parts of git-media way better if I re-implemented it using
> this. Thanks for pointing this out.
Yeah, that's great, it should allow a smart clean filter to not waste
time reprocessing a known large file on every git status/git commit.
--
see shy jo
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* [PATCH] Pass "-O xhtml" param to highlight instead of "-xhtml"
From: Adam Tkac @ 2011-01-26 17:11 UTC (permalink / raw)
To: git; +Cc: gitster
[-- Attachment #1: Type: text/plain, Size: 265 bytes --]
Hello,
attached patch fixes the gitweb.perl script. Current highlight utility
doesn't recognize --xhtml parameter, it recognizes only "-O xhtml" parameter.
Reference: https://bugzilla.redhat.com/show_bug.cgi?id=672293
Regards, Adam
--
Adam Tkac, Red Hat, Inc.
[-- Attachment #2: 0001-Pass-O-xhtml-parameter-instead-of-xhtml-to-hightligh.patch --]
[-- Type: text/plain, Size: 930 bytes --]
>From ec8043a730c165d8b438ccaba7c3cf5dc5fa65bc Mon Sep 17 00:00:00 2001
From: Adam Tkac <atkac@redhat.com>
Date: Wed, 26 Jan 2011 17:46:29 +0100
Subject: [PATCH] Pass "-O xhtml" parameter instead of "--xhtml" to hightlight in gitweb.
Signed-off-by: Jochen Schmitt <jochen@herr-schmitt.de>
Signed-off-by: Adam Tkac <atkac@redhat.com>
---
gitweb/gitweb.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 1025c2f..88556f4 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -3468,7 +3468,7 @@ sub run_highlighter {
close $fd;
open $fd, quote_command(git_cmd(), "cat-file", "blob", $hash)." | ".
quote_command($highlight_bin).
- " --xhtml --fragment --syntax $syntax |"
+ " -O xhtml --fragment --syntax $syntax |"
or die_error(500, "Couldn't open file or run syntax highlighter");
return $fd;
}
--
1.7.3.5
^ permalink raw reply related
* Re: Fwd: Git and Large Binaries: A Proposed Solution
From: Eric Montellese @ 2011-01-26 16:23 UTC (permalink / raw)
To: Scott Chacon; +Cc: Pete Wyckoff, Jeff King, git list
In-Reply-To: <AANLkTimE+s81Xbj4snNX0WWxG8x=qSwaQWfK+08+1Zy+@mail.gmail.com>
Good stuff!
So, it seems like there are at least a few decent ways to work around
the git binaries problem -- but my question is, will something like
this become part of mainline git? (and how is such a decision made
and by whom?)
It does seem that there is a real need for a solution like this, and a
lot of the core code to handle it has already been written (perhaps
even by multiple folks); it's just in need (as Peff said) of a
polished and configurable script. If one were to exist, would it
become part of mainline git?
Thanks,
Eric
On Tue, Jan 25, 2011 at 10:42 PM, Scott Chacon <schacon@gmail.com> wrote:
> Hey,
>
> Sorry to come in a bit late to this, but in addition to git-annex, I
> wrote something called 'git-media' a long time ago that works in a
> similar manner to what you both are discussing.
>
> Much like what peff was talking about, it uses the smudge and clean
> filters to automatically redirect content into a .git/media directory
> instead of into Git itself while keeping the SHA in Git. One of the
> cool thing is that it can use S3, scp or a local directory to transfer
> the big files to and from.
>
> Check it out if interested:
>
> https://github.com/schacon/git-media
>
> On Sun, Jan 23, 2011 at 6:14 AM, Pete Wyckoff <pw@padd.com> wrote:
>> peff@peff.net wrote on Fri, 21 Jan 2011 17:24 -0500:
>>
>> Just a quick aside. Since (a2b665d, 2011-01-05) you can provide
>> the filename as an argument to the filter script:
>>
>> git config --global filter.huge.clean huge-clean %f
>>
>
> This is amazing. I absolutely did not know you could do this, and it
> would make parts of git-media way better if I re-implemented it using
> this. Thanks for pointing this out.
>
> Scott
>
^ permalink raw reply
* Re: [msysGit] Git unable to access https repositories due to curl/OpenSSL 1.0.0 handshake issues
From: Mika Fischer @ 2011-01-26 15:13 UTC (permalink / raw)
To: Daniel Stenberg; +Cc: kusmabite, msysGit, Git Mailing List
In-Reply-To: <alpine.DEB.2.00.1101261422550.20831@tvnag.unkk.fr>
On Wed, Jan 26, 2011 at 14:29, Daniel Stenberg <daniel@haxx.se> wrote:
> 3. I tried getting a file through this using curl 7.21.2 and my current dev
> version of 7.21.4-DEV (see below for full details). Both managed to get it
> fine.
Same here. curl can fetch fine from the openssl mini-httpd
> From this, I conclude that there's some additional factors necessary to make
> this problem trigger. Can you figure out what?
So to recap, we have the following situation:
curl/openssl 0.9.8k <-> apache/openssl 0.9.8k -> works
curl/openssl 1.0.0 <-> apache/openssl 0.9.8k -> works
curl/openssl 0.9.8k <-> apache/openssl 1.0.0 -> error
openssl 0.9.8k <-> apache/openssl 1.0.0 -> works
curl/openssl 0.9.8k <-> openssl 1.0.0 -> works
openssl 0.9.8k <-> openssl 1.0.0 -> works
I'm not sure what to take away from this. Maybe it's a problem that is
partly caused by both apache and curl?
Do you know how I could debug this? I won't have much time during the
day but I can test things in the evenings...
Just FYI: To get something running, I downgraded our apache server to
the OpenSuSE 11.2 packages. Now it works again fine, with the same
configuration as before...
The failing curl -V on OpenSuSE 11.2
curl 7.19.6 (x86_64-unknown-linux-gnu) libcurl/7.19.6 OpenSSL/0.9.8k
zlib/1.2.3 libidn/1.10
Protocols: tftp ftp telnet dict ldap http file https ftps
Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz
curl -V on the problematic apache host running OpenSuSE 11.3
curl 7.20.1 (x86_64-unknown-linux-gnu) libcurl/7.20.1 OpenSSL/1.0.0
zlib/1.2.3 libidn/1.15 libssh2/1.2.2_DEV
Protocols: dict file ftp ftps http https imap imaps ldap pop3 pop3s
rtsp scp sftp smtp smtps telnet tftp
Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz
Best,
Mika
^ permalink raw reply
* Re: Git unable to access https repositories due to curl/OpenSSL 1.0.0 handshake issues
From: Erik Faye-Lund @ 2011-01-26 14:29 UTC (permalink / raw)
To: Daniel Stenberg; +Cc: Mika Fischer, msysGit, Git Mailing List
In-Reply-To: <alpine.DEB.2.00.1101261422550.20831@tvnag.unkk.fr>
On Wed, Jan 26, 2011 at 2:29 PM, Daniel Stenberg <daniel@haxx.se> wrote:
> On Wed, 26 Jan 2011, Mika Fischer wrote:
>
>> But I noticed that the same problem occurs on OpenSuSE 11.2. So I compiled
>> the latest version of curl on OpenSuSE 11.2 and the problem is still
>> present...
>
> Sorry, but I can't repeat this problem. I tried this:
>
> 1. I got OpenSSL 1.0.0c, built it and installed it.
>
> 2. I started OpenSSL's little HTTPS server with this version:
>
> $ openssl s_server -HTTP -cert [PEM]
>
> (I verified, and this binary uses the lib statically so there's no funny lib
> path issues here.)
>
> 3. I tried getting a file through this using curl 7.21.2 and my current dev
> version of 7.21.4-DEV (see below for full details). Both managed to get it
> fine.
>
> From this, I conclude that there's some additional factors necessary to make
> this problem trigger. Can you figure out what?
>
> The full curl -V outputs from my two test versions:
>
> curl 7.21.2 (i486-pc-linux-gnu) libcurl/7.21.2 OpenSSL/0.9.8o zlib/1.2.3.4
> libidn/1.18 libssh2/1.2.6
> Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3
> pop3s rtsp scp sftp smtp smtps telnet tftp
> Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz
>
> curl 7.21.4-DEV (i686-pc-linux-gnu) libcurl/7.21.4-DEV OpenSSL/1.0.0c
> zlib/1.2.3.4 c-ares/1.7.5-DEV libidn/1.18 libssh2/1.2.8_DEV librtmp/2.2e
> Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3
> pop3s rtmp rtsp scp sftp smtp smtps telnet tftp
> Features: AsynchDNS Debug TrackMemory GSS-Negotiate IDN IPv6 Largefile NTLM
> SSL libz
>
Here's the output from Git for Windows' curl -V:
$ curl -V
curl 7.21.1 (i686-pc-mingw32) libcurl/7.21.1 OpenSSL/0.9.8k zlib/1.2.3
Protocols: dict file ftp ftps http https imap imaps ldap ldaps pop3
pop3s rtsp smtp smtps telnet tftp
Features: Largefile NTLM SSL SSPI libz
^ permalink raw reply
* Re: [msysGit] Git unable to access https repositories due to curl/OpenSSL 1.0.0 handshake issues
From: Daniel Stenberg @ 2011-01-26 13:29 UTC (permalink / raw)
To: Mika Fischer; +Cc: kusmabite, msysGit, Git Mailing List
In-Reply-To: <AANLkTimJznExH8N9fcgSC88HOPfaFDF7jFMTZUJauL9+@mail.gmail.com>
On Wed, 26 Jan 2011, Mika Fischer wrote:
> But I noticed that the same problem occurs on OpenSuSE 11.2. So I compiled
> the latest version of curl on OpenSuSE 11.2 and the problem is still
> present...
Sorry, but I can't repeat this problem. I tried this:
1. I got OpenSSL 1.0.0c, built it and installed it.
2. I started OpenSSL's little HTTPS server with this version:
$ openssl s_server -HTTP -cert [PEM]
(I verified, and this binary uses the lib statically so there's no funny lib
path issues here.)
3. I tried getting a file through this using curl 7.21.2 and my current dev
version of 7.21.4-DEV (see below for full details). Both managed to get it
fine.
>From this, I conclude that there's some additional factors necessary to make
this problem trigger. Can you figure out what?
The full curl -V outputs from my two test versions:
curl 7.21.2 (i486-pc-linux-gnu) libcurl/7.21.2 OpenSSL/0.9.8o zlib/1.2.3.4
libidn/1.18 libssh2/1.2.6
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3
pop3s rtsp scp sftp smtp smtps telnet tftp
Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz
curl 7.21.4-DEV (i686-pc-linux-gnu) libcurl/7.21.4-DEV OpenSSL/1.0.0c
zlib/1.2.3.4 c-ares/1.7.5-DEV libidn/1.18 libssh2/1.2.8_DEV librtmp/2.2e
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3
pop3s rtmp rtsp scp sftp smtp smtps telnet tftp
Features: AsynchDNS Debug TrackMemory GSS-Negotiate IDN IPv6 Largefile NTLM
SSL libz
--
/ daniel.haxx.se
^ permalink raw reply
* git: patch does not apply
From: Dmitri Pissarenko @ 2011-01-26 12:41 UTC (permalink / raw)
To: git
Hello!
I have a certain patch called my_pcc_branch.patch.
When I try to apply it, I get following message:
$ git apply --check my_pcc_branch.patch
warning: src/main/java/.../AbstractedPanel.java has type 100644, expected 100755
error: patch failed: src/main/java/.../AbstractedPanel.java:13
error: src/main/java/.../AbstractedPanel.java: patch does not apply
What does it mean?
How can I fix this problem?
Notes:
1) I posted this question on StackOverflow and tried out several
things suggested there.
http://stackoverflow.com/questions/4770177/git-patch-does-not-apply
However, I don't have a working solution yet.
2) I'm using git 1.7.3.1.mysgit.0 under Windows 7. The author of the
patch uses Windows XP.
Thanks in advance
Dmitri
^ permalink raw reply
* Re: Confused about git filter-branch results
From: Mike Kelly @ 2011-01-26 11:18 UTC (permalink / raw)
To: Thomas Rast; +Cc: git
In-Reply-To: <201101251732.40811.trast@student.ethz.ch>
On Tue, Jan 25, 2011 at 05:32:40PM +0100, Thomas Rast wrote:
> Before you read the explanations below, I recommend that you open
> 'gitk --all' and use it to see whether I'm right.
>
This was really useful for finding my problem.
> Most likely you filtered all commits on your branch, but not master,
> so master now points to an entirely disjoint set of commits.
>
Almost exactly correct. The tree branched off at a really early point in
development.
> Assuming my "disjoint history" theory is correct, you should either
> discard your rewrite along the lines of
>
> git branch -f foo refs/original/refs/heads/foo
>
Done. This cleaned up the mess.
> Confused yet? :-)
>
Not at all, I found your explanation to be clear and straight forward.
Thank you.
At first I was grumbling to myself about git filter-branch rewriting every
commit, but then I remembered that there were a few messages on stderr
complaining that some commits were not in the correct encoding. I guess
that the tool decided to rewrite these commits for me (without asking),
thus causing a fork. Sorry for not mentioning these error messages before,
I forgot about them in the ensuing panic.
I just want to give a shout-out to all the git developers, I've used RCS,
CVS, and SVN in the past, and they all had different ways of making life
miserable. Git is the first tool which I felt was working with me, not
against me. Keep up the good work!
Anyway, I'm back in business and have by branch under control again.
Thanks again,
Mike
(:
--
--------Mike@PirateHaven.org-----------------------The_glass_is_too_big--------
^ permalink raw reply
* Re: Can't find the revelant commit with git-log
From: Johannes Sixt @ 2011-01-26 10:44 UTC (permalink / raw)
To: git, Francis Moreau; +Cc: René Scharfe
In-Reply-To: <m239og12pe.fsf@gmail.com>
Please don't set Mail-Followup-To; it's disliked on this list.
Am 1/26/2011 9:36, schrieb Francis Moreau:
> I tried to reproduce something similar but with a far more simple repo:
>
>
> <v2.6.28> 1.f o
> |
> 1.e o (merge)
> | \
> 1.d o o 2.c (merge)
> | | \
> 1.c o o o 3.a "Remove blacklist_iommu()"
> | | /
> | o 2.a
> | /
> 1.b o
> |
> <v2.6.27> 1.a o "Introduce blacklist_iommu()"
> |
> o Init
>
> Basically this repo 3 branches: master, 2, 3. Master branch introduces
> the "blacklist_iommu()" function with commit 1.a, and branch "3" removes
> it at commit 3.a.
> ...
> So in this case there's no need to pass the '-m' flag and git-log(1), by
> default walks through all the commits:
To reproduce the real history, you have to modify your example in three ways:
1. 2.a must be forked off of Init, not 1.b; i.e., this commit does not
contain "blacklist_iommu".
2. Drop the side branch that removes the word. (Drop at least the commit.)
3. The merge 1.e (which resembles d847059) must be modified such that it
takes the contents of 2.c rather than 1.d.
IOW, "blacklist_iommu" is not removed explicitly by a commit, but rather
by a merge of one branch that has it and another one that doesn't have it.
Look closely at d847059: The commit message hints at a conflict in
intel_iommu.c, and Ingo resolved the conflict by taking the contents of
the file of one branch, namely the branch that does *not* contain
"blacklist_iommu", ignoring entirely what happend on the other branch
(that had added "blacklist_iommu" somewhere at or before v2.6.27).
-- Hannes
^ permalink raw reply
* Re: [RFC] Add bad-branch-first option for git-bisect
From: Shuang He @ 2011-01-26 10:40 UTC (permalink / raw)
To: Christian Couder
Cc: git@vger.kernel.org, apenwarr@gmail.com, Junio C Hamano,
Johannes Sixt
In-Reply-To: <AANLkTi=T+oapfn1CTu_smU1P+JEraihE4BUKJcB=uBHw@mail.gmail.com>
On 2011/1/26 17:44, Christian Couder wrote:
> On Wed, Jan 26, 2011 at 8:22 AM, Shuang He<shuang.he@intel.com> wrote:
>> On 2011/1/25 17:20, Christian Couder wrote:
>>>> Yeah, I agree that the issue I addressed above will not be a problem if
>>>> all
>>>> those branches are maintained very well.
>>>> Actually we've implemented a automated bisect system for Intel Linux
>>>> Graphics Driver Project, and so we'd like the system
>>>> helps us to locate issue in an more automatic way when branches are not
>>>> maintained as good as expected.
>>> I think there is always a price to pay when you bisect if the branches
>>> are not well maintained.
>>> Maybe your algorithm could help in some cases, but my opinion is that
>>> there will probably still be many problems and a human will often have
>>> to take a look.
>>>
>> Yes, I agree. What we trying to do is just make the machine to do more help
>> for human.
> Yeah, this is the way to go. And by the way I am happy to know that
> you have implemented an automated bisect system. That's great and I
> hope it already helps.
>
>>>>> - the name "bisectbadbranchfirst" seems wrong to me, because git
>>>>> branches are just some special tags; "firstparentsonly" would be a
>>>>> better name,
>>>> It's recursively applying bad branch first algorithm, not just constantly
>>>> stick to first parent.
>>>> Given this condition:
>>>> A -> B -> C -> D -> E -> F -> G -> H (master)
>>>> \ a -> b -> c -> d -> e / (feature 1)
>>>> \ x -> y -> z/ (feature 2)
>>>> start with H as bad commit, and A as good commit, if y is the target bad
>>>> commit. bad-branch-first algorithm will do it like this:
>>>> 1. In first round stick to master branch, so it will locate G as first
>>>> bad commit
>>>> 2. In second round stick to feature1 branch, then it will locate d as
>>>> first bad commit
>>>> 3. In third round stick to feature2 branch, then it will finally
>>>> locate y
>>>> as first bad commit
>>>> So you could see, it's always sticking to branch where current bad commit
>>>> sit
>>> I see. It is interesting, but why not develop a "firstparentsonly"
>>> algorithm first?
>>>
>>> As Avery explains in his email, it is already interesting to have a
>>> "firstparentsonly" algorithm because some people are only interested
>>> to know from which branch the bug comes from.
>>> When they know that, they can just contact the relevant people and be
>>> done with it.
>>>
>>> And when we have a "firstparentsonly" algorithm, then your algorithm
>>> could be just a script that repeatedly uses git bisect with the
>>> "firstparentsonly" algorithm. And this script might be integrated in
>>> the "contrib" directory if it not considered important to be
>>> integrated as an algorithm into git bisect.
>> Sorry to reply so late, since I was on a long journey home for Chinese New
>> Year vacation ;)
> No problem. I am not in a hurry at all. In fact I don't have much time
> these days so I reply very late too.
>
>> I agree that's also an good option.
>> Is it acceptable to add option to git-bisect stuff, so user could choose
>> which algorithm to use at every step at will.
> Are you sure it is needed to be able to change the algorithm at every step?
I don't think it's needed, it would just give user more control over the
algorithm.
> This means that you would like a new "git bisect strategy<strategy>"
> subcommand ?
>
> First I thought that we could just add a "--strategy<strategy>"
> option to "git bisect start".
> But anyway, I think it should be easy to add afterward, and it can be
> done in a separated patch that can be discussed on its own.
Yeah, agree. We could discuss this later
>> And we have tested previous attached patch with t6002-rev-list-bisect.sh and
>> t6030-bisect-porcelain.sh, and we get:
>> with bad-branch-first disabled (which is the default setting):
>> t6002-rev-list-bisect.sh: # passed all 45 test(s)
>> t6030-bisect-porcelain.sh: # passed all 40 test(s)
>> and with bad-branch-first enabled:
>> t6002-rev-list-bisect.sh: # passed all 45 test(s)
>> t6030-bisect-porcelain.sh: # failed 5 among 40 test(s), and I have
>> spent some time digging into those failures ,and it seems they're all false
>> negative since they're using hard-coded bisect path to validate specific
>> case
> Yes, there are some hard coded commits that depend on the algorithm.
> Anyway I did not look in depth at your patch yet, and as I said it
> would be better if you could split it into a patch series where a
> "firstparentsonly" algorithm is implemented first.
> This way it will be easier to review, and we can start to integrate
> some non controversial features, and then discuss the other ones on
> their own merit.
>
> Thanks in advance,
> Christian.
Thanks for the good suggestion, I'll start the work soon.
Thanks
--Shuang
^ permalink raw reply
* Is there a specific reason that git gui does not respect comment lines added by a git hook?
From: Wilbert van Dolleweerd @ 2011-01-26 10:14 UTC (permalink / raw)
To: Git ML
Hello,
I've written a prepare-commit-msg hook that maps Team Foundation
Server workitem ID's to a Git commit message. (When committing, a
picklist appears. Users can select one or more workitems and the
workitems are added to the commit message using a specific format.
Later on, we use git log --grep to search for specific commits
belonging to a workitem).
I'm using comments in the commit message to give additional
information to the user. For example, when the Team Foundation Server
is not available, I add the following comment to the top of the commit
message.
# Warning: could not access Team Foundation Server at <servername>.
Check your configuration or manually enter your workitem.
Because the line starts with a # sign, it is not added to the actual
commit message...when using git commit. If I use git gui, the above
comment appears in the git gui interface but *is* actually added to
the git commit message when committing.
Is there a specific reason that git gui is actually adding lines
starting with a # sign? I was expecting it to ignore those lines.
--
Kind regards,
Wilbert van Dolleweerd
Blog: http://walkingthestack.wordpress.com/
Twitter: http://www.twitter.com/wvandolleweerd
^ permalink raw reply
* Re: [msysGit] Git unable to access https repositories due to curl/OpenSSL 1.0.0 handshake issues
From: Mika Fischer @ 2011-01-26 10:04 UTC (permalink / raw)
To: Daniel Stenberg; +Cc: kusmabite, msysGit, Git Mailing List
In-Reply-To: <alpine.DEB.2.00.1101261056570.5603@tvnag.unkk.fr>
On Wed, Jan 26, 2011 at 10:57, Daniel Stenberg <daniel@haxx.se> wrote:
> Are these clean builds of libcurl and OpenSSL from source?
I just compiled libcurl against the OpenSSL library of OpenSuSE 11.2 (0.9.8k).
If you want me to test other combinations/versions etc. just let me know.
> I'll try to look into this.
Thanks a lot!
Best,
Mika
^ permalink raw reply
* Re: [msysGit] Git unable to access https repositories due to curl/OpenSSL 1.0.0 handshake issues
From: Daniel Stenberg @ 2011-01-26 9:57 UTC (permalink / raw)
To: Mika Fischer; +Cc: kusmabite, msysGit, Git Mailing List
In-Reply-To: <AANLkTimJznExH8N9fcgSC88HOPfaFDF7jFMTZUJauL9+@mail.gmail.com>
On Wed, 26 Jan 2011, Mika Fischer wrote:
>> I'll see if I can get a more current version of curl to compile under
>> Windows.
>
> I did not manage to do do this.
>
> But I noticed that the same problem occurs on OpenSuSE 11.2. So I compiled
> the latest version of curl on OpenSuSE 11.2 and the problem is still
> present...
Are these clean builds of libcurl and OpenSSL from source?
I'll try to look into this.
--
/ daniel.haxx.se
^ permalink raw reply
* Re: [msysGit] Git unable to access https repositories due to curl/OpenSSL 1.0.0 handshake issues
From: Mika Fischer @ 2011-01-26 9:54 UTC (permalink / raw)
To: kusmabite; +Cc: msysGit, Git Mailing List
In-Reply-To: <AANLkTinGLMcRJ9EuZY_k4GoKyg+r7hxcgnq3z0=qOemA@mail.gmail.com>
On Wed, Jan 26, 2011 at 10:15, Mika Fischer
<mika.a.fischer@googlemail.com> wrote:
> I'll see if I can get a more current version of curl to compile under Windows.
I did not manage to do do this.
But I noticed that the same problem occurs on OpenSuSE 11.2. So I
compiled the latest version of curl on OpenSuSE 11.2 and the problem
is still present...
Best,
Mika
^ 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