* Re: [PATCH 2/3] git-gui: spelling fixes in russian translation
From: Pat Thoyts @ 2011-01-24 23:31 UTC (permalink / raw)
To: Alex Riesen
Cc: git, Shawn O. Pearce, Serge Ziryukin, Dmitry Potapov,
Alexander Gavrilov, Junio C Hamano
In-Reply-To: <AANLkTinZCegWW-6uQ++uO9fGQ4SQ34=W4TJXW6ii5jXD@mail.gmail.com>
Alex Riesen <raa.lkml@gmail.com> writes:
>2011/1/17 Alex Riesen <raa.lkml@gmail.com>:
>> po/ru.po | 24 ++++++++++++------------
>> 1 files changed, 12 insertions(+), 12 deletions(-)
>>
>> diff --git a/po/ru.po b/po/ru.po
>> index c15bdfa..304bb3a 100644
>
>BTW, does anyone know what happens to git-gui development?
>In particular, the i18n patches. The old way of pushing
>to a mob branch seems to stopped working, and anyway, the
>branch is very out of date.
>
>Is git gui development stalled? Should I perhaps send the
>i18n pull request directly to Junio?
>
If you post here they'll get picked up eventually.
If you want to use the mob branch, we can use that too but you would
need to post here and to me to notify everyone.
--
Pat Thoyts http://www.patthoyts.tk/
PGP fingerprint 2C 6E 98 07 2C 59 C8 97 10 CE 11 E6 04 E0 B9 DD
^ permalink raw reply
* Re: [PATCH] git-gui: update russian translation
From: Pat Thoyts @ 2011-01-24 23:57 UTC (permalink / raw)
To: Alex Riesen
Cc: git, Shawn O. Pearce, Serge Ziryukin, Dmitry Potapov,
Alexander Gavrilov
In-Reply-To: <20110119210131.GA8184@blimp.localdomain>
Thank you for the patches. I've applied the four patches and pushed them to
http://repo.or.cz/w/git-gui.git master.
^ permalink raw reply
* Re: [PATCH 2/3] git-gui: spelling fixes in russian translation
From: Junio C Hamano @ 2011-01-25 0:24 UTC (permalink / raw)
To: Pat Thoyts
Cc: Alex Riesen, git, Shawn O. Pearce, Serge Ziryukin, Dmitry Potapov,
Alexander Gavrilov, Eric Wong, Paul Mackerras
In-Reply-To: <87wrltnakc.fsf@fox.patthoyts.tk>
Pat Thoyts <patthoyts@users.sourceforge.net> writes:
>>Is git gui development stalled? Should I perhaps send the
>>i18n pull request directly to Junio?
>
> If you post here they'll get picked up eventually.
> If you want to use the mob branch, we can use that too but you would
> need to post here and to me to notify everyone.
Oops, I probably should have pinged you (and Paulus for gitk, Eric for
git-svn) before tagging rc3 today.
If there are last-minute changes that must go to 1.7.4 final, please let
me know.
^ permalink raw reply
* Re: [PATCH] git-gui: add config value gui.diffopts for passing additional diff options
From: Pat Thoyts @ 2011-01-25 0:25 UTC (permalink / raw)
To: Tilman Vogel; +Cc: git
In-Reply-To: <1295607585-15971-1-git-send-email-tilman.vogel@web.de>
Tilman Vogel <tilman.vogel@web.de> writes:
>Signed-off-by: Tilman Vogel <tilman.vogel@web.de>
>---
> Documentation/config.txt | 4 ++++
> git-gui/git-gui.sh | 1 +
> git-gui/lib/diff.tcl | 1 +
> git-gui/lib/option.tcl | 1 +
> 4 files changed, 7 insertions(+), 0 deletions(-)
>
>diff --git a/Documentation/config.txt b/Documentation/config.txt
>index ff7c225..0ed7bcf 100644
>--- a/Documentation/config.txt
>+++ b/Documentation/config.txt
>@@ -1100,6 +1100,10 @@ gui.diffcontext::
> Specifies how many context lines should be used in calls to diff
> made by the linkgit:git-gui[1]. The default is "5".
>
>+gui.diffopts::
>+ Specifies additional parameters to pass to diff from
>+ linkgit:git-gui[1]. The default is "".
>+
> gui.encoding::
> Specifies the default encoding to use for displaying of
> file contents in linkgit:git-gui[1] and linkgit:gitk[1].
>diff --git a/git-gui/git-gui.sh b/git-gui/git-gui.sh
>index d3acf0d..2a3aed5 100755
>--- a/git-gui/git-gui.sh
>+++ b/git-gui/git-gui.sh
>@@ -823,6 +823,7 @@ set default_config(gui.fastcopyblame) false
> set default_config(gui.copyblamethreshold) 40
> set default_config(gui.blamehistoryctx) 7
> set default_config(gui.diffcontext) 5
>+set default_config(gui.diffopts) {}
> set default_config(gui.commitmsgwidth) 75
> set default_config(gui.newbranchtemplate) {}
> set default_config(gui.spellingdictionary) {}
>diff --git a/git-gui/lib/diff.tcl b/git-gui/lib/diff.tcl
>index dcf0711..de3827a 100644
>--- a/git-gui/lib/diff.tcl
>+++ b/git-gui/lib/diff.tcl
>@@ -295,6 +295,7 @@ proc start_show_diff {cont_info {add_opts {}}} {
>
> lappend cmd -p
> lappend cmd --color
>+ set cmd [concat $cmd $repo_config(gui.diffopts)]
> if {$repo_config(gui.diffcontext) >= 1} {
> lappend cmd "-U$repo_config(gui.diffcontext)"
> }
>diff --git a/git-gui/lib/option.tcl b/git-gui/lib/option.tcl
>index 3807c8d..1e5d28c 100644
>--- a/git-gui/lib/option.tcl
>+++ b/git-gui/lib/option.tcl
>@@ -153,6 +153,7 @@ proc do_options {} {
> {i-20..200 gui.copyblamethreshold {mc "Minimum Letters To Blame Copy On"}}
> {i-0..300 gui.blamehistoryctx {mc "Blame History Context Radius (days)"}}
> {i-1..99 gui.diffcontext {mc "Number of Diff Context Lines"}}
>+ {t gui.diffopts {mc "Additional Diff Parameters"}}
> {i-0..99 gui.commitmsgwidth {mc "Commit Message Text Width"}}
> {t gui.newbranchtemplate {mc "New Branch Name Template"}}
> {c gui.encoding {mc "Default File Contents Encoding"}}
This seems ok but you don't say what it is for. Why do you want to be
able to pass additional options to git diff?
I can apply this to git-gui's repository. The Documentation change will
need to be sent to git separately once this is merged from git-gui.
--
Pat Thoyts http://www.patthoyts.tk/
PGP fingerprint 2C 6E 98 07 2C 59 C8 97 10 CE 11 E6 04 E0 B9 DD
^ permalink raw reply
* Re: [PATCH] git-gui: update russian translation
From: Junio C Hamano @ 2011-01-25 0:34 UTC (permalink / raw)
To: Pat Thoyts
Cc: Alex Riesen, git, Shawn O. Pearce, Serge Ziryukin, Dmitry Potapov,
Alexander Gavrilov
In-Reply-To: <87sjwhn9c3.fsf@fox.patthoyts.tk>
Pat Thoyts <patthoyts@users.sourceforge.net> writes:
> Thank you for the patches. I've applied the four patches and pushed them to
> http://repo.or.cz/w/git-gui.git master.
I see a few changes outside po/ru.po in this update:
git-gui.sh | 26 ++-
lib/browser.tcl | 2 +-
lib/diff.tcl | 60 ++++--
po/ru.po | 623 ++++++++++++++++++++++++++++---------------------------
4 files changed, 381 insertions(+), 330 deletions(-)
Are they all good to go for 1.7.4 final? My cursory look indicates that
they are all minor bugfixes and look sane, but I rarely use git-gui
myself, so I am just double checking.
Alex Riesen (2):
git-gui: update russian translation
git-gui: update russian translation
Bert Wesarg (5):
git-gui: fix ANSI-color parsing
git-gui: respect conflict marker size
git-gui: fix browsers [Up To Parent] in sub-sub-directories.
git-gui: Fix use of renamed tag.
git-gui: Fix use of hunk tag for non-hunk content.
Serge Ziryukin (1):
git-gui: fix russian translation typos
Skip (1):
git-gui: spelling fixes in russian translation
Stefan Naewe (1):
git-gui: use --exclude-standard to check for untracked files
^ permalink raw reply
* Re: [RFC] Add bad-branch-first option for git-bisect
From: Shuang He @ 2011-01-25 3:27 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Sixt, Christian Couder, git@vger.kernel.org,
apenwarr@gmail.com
In-Reply-To: <7v8vyam5la.fsf@alter.siamese.dyndns.org>
On 2011/1/25 4:04, Junio C Hamano wrote:
> Shuang He<shuang.he@intel.com> writes:
>
>> If A is bad commit, and C fixed it, and then F is bad again,
>>
>> A -> B -> C -> D -> E -> F -> G -> H (master)
>> \ \ /
>> a -> b... c -> d -> e->f (feature 1)
>>
>> Start with H as bad commit, and D as good commit, it's possible git-bisect would jump to c, and it will lead to wrong direction
>>
>> If bad-branch-first is used, it would be:
>> 1. first round found F
>> 2. end
> It is unclear from the way you drew the picture if "F" is supposed to be a
> merge of "E" and "f", but I'd assume that it is.
Oh, I lost this mail
That graph is different from what I meant, when shown in different email
client.
It's G which is merged from e and F
> So what you are saying in 1. is "skip from H until you hit a first merge
> (without testing any intermediate commit), find F and stop to check it,
> and find that it is broken".
>
> What makes you decide "2. end"? The fact that both of its parents "E" and
> "f" are Ok? IOW, it won't be "2. end" if one of the parents of the merge
> is broken?
I think the correction above should have answer those two questions.
> What if there is _no_ merge from a side branch but there were breakages in
> A (fixed in C) and then F in your original picture, i.e.
>
> A---B---C---D---E---F---G---H (broken)
> x o x
>
> and you are hunting for the bug starting from H? How does your algorithm
> help? I grossed over the linear part by saying "skip from H until you hit
> a first merge", but in general, what is your plan to handle linear part of
> the history?
If the history is linear, the new algorithm won't help, it will just
behavior like default git-bisect algorithm.
> A totally unacceptable answer is "It does not help linear case, but it
> helps when there are merges". The a-thru-f side branch in your picture,
> or any "culprit side branch that was merged" your algorithm finds in
> general, would eventually have a linear segment, and having x-o-x in the
> history fundmentally breaks "bisect"---your band-aid will not help.
>
> The whole idea behind using "bisect" to gain efficiency in isolating the
> issue depends on "Once you see a Good commit, you do not have to search
> beyond its ancestors", as it is to look for a single breakage that
> persists to the "Bad" commit you give, and as far as "bisect" is
> concerned, the breakage at A in your example is an unrelated breakage that
> did not persist through the history to the "Bad" commit H.
In the example above (after we know G is merged from e and F),
Those commits are old bad commit: A, B, a, b, ..., c, d (but we don't
care about those old bad commits, we cared about latest bad commit that
we met which is F)
It's possible that default git-bisect would jump to these old bad
commits, and will finally find an old first bad commit
With bad-branch-first, it could help us to get away from the trouble
that old culprit commit exist on feature1 branch for a period of time
not fixed
Thanks
--Shuang
^ permalink raw reply
* Git repo on a machine with zero commits is ahead of remote by 103 commits.. !
From: Srirang Doddihal @ 2011-01-25 5:48 UTC (permalink / raw)
To: git
Hi,
I am using a simple git based deployment for my rails app and here is
my setup and current status:
1) Git repo initialized on my local development machine with a sample file.
2) Pushed to remote repo on Github.com
3) Subsequent pushes and pulls made from local development machine
4) Repository cloned on the deployed machine
5) Subsequent pulls made from the deployed machine (but no commits or
pushes are made on this machine)
Now when I run "git status" on the deployed machine it says :
# On branch master
# Your branch is ahead of 'origin/master' by 103 commits.
git pull origin master -- says it is Already up to date
git log -- appropriately shows till the latest commit
however
git log orign/master -- shows commits only till Jan 8th.
also
git rev-parse origin/master -- give different SHA1 values on my
development machine and the deployed machine.
Questions:
===========
1) Why does "git status" say that the local repo on the deployed
machine (where no commits are made) is ahead of the remote by 103
commits? (This number, 103, increases with every "git pull origin
master" and very likely the change is equal to the number of commits
pulled)
2) Why is "git log orign/master" stuck at a Jan 8th commit?
* How can I set these right?
Even with these anomalies, "git pull origin master" on the deployed
machine seems to be working just fine, in terms of the right revisions
of files being pulled in and all that.
Any help in understanding what caused these anomalies and suggestions
to fix then would be very helpful.
Kindly let me know if any more information is needed.
--
Regards,
Srirang G Doddihal
Brahmana.
The LIGHT shows the way.
The WISE see it.
The BRAVE walk it.
The PERSISTENT endure and complete it.
I want to do it all ALONE.
^ permalink raw reply
* Re: Git repo on a machine with zero commits is ahead of remote by 103 commits.. !
From: Johannes Sixt @ 2011-01-25 7:22 UTC (permalink / raw)
To: Srirang Doddihal; +Cc: git
In-Reply-To: <AANLkTikj06sjTbNd8afk9cY2=_Hy+kT+J1NCjR-fKP5J@mail.gmail.com>
Am 1/25/2011 6:48, schrieb Srirang Doddihal:
> I am using a simple git based deployment for my rails app and here is
> my setup and current status:
>
> 1) Git repo initialized on my local development machine with a sample file.
> 2) Pushed to remote repo on Github.com
> 3) Subsequent pushes and pulls made from local development machine
> 4) Repository cloned on the deployed machine
> 5) Subsequent pulls made from the deployed machine (but no commits or
> pushes are made on this machine)
>
> Now when I run "git status" on the deployed machine it says :
>
> # On branch master
> # Your branch is ahead of 'origin/master' by 103 commits.
>
> git pull origin master -- says it is Already up to date
This 'git pull' is very explicit. I.e., you specify the remote and the
branch; in this case, no remote-tracking branches, like origin/master, are
updated.
Since you cloned the repository (I assume without any special options),
you already have a configuration such that you can use this shorter command:
git pull
to merge origin's master into your local master. As a side-effect, it also
updates origin/master.
-- Hannes
^ permalink raw reply
* Re: Git repo on a machine with zero commits is ahead of remote by 103 commits.. !
From: Jay Soffian @ 2011-01-25 7:23 UTC (permalink / raw)
To: Srirang Doddihal; +Cc: git
In-Reply-To: <AANLkTikj06sjTbNd8afk9cY2=_Hy+kT+J1NCjR-fKP5J@mail.gmail.com>
On Tue, Jan 25, 2011 at 12:48 AM, Srirang Doddihal
<om.brahmana@gmail.com> wrote:
> 1) Why does "git status" say that the local repo on the deployed
> machine (where no commits are made) is ahead of the remote by 103
> commits? (This number, 103, increases with every "git pull origin
> master" and very likely the change is equal to the number of commits
> pulled)
git status is comparing refs/heads/master, aka master, to its
remote-tracking branch, refs/remotes/origin/master, aka origin/master.
master is ahead of origin/master because you've been updating the
former but not the later, with your pull invocation.
> 2) Why is "git log orign/master" stuck at a Jan 8th commit?
Because you've been saying "git pull origin master", git has been
doing the following:
- contacting origin and fetching all commits in its master not in your
local repo
- locally updating FETCH_HEAD with the results of that fetch
- performing a merge operation of FETCH_HEAD into your local master
- because you haven't made any local commits, that is a fast-forward operation
- updating your work tree
However, git is not updating your remote-tracking branch (origin/master).
> * How can I set these right?
Just do a "git pull" or "git pull origin". By not explicitly giving
pull a branch, it consults two configuration variables in your
.git/config for the currently checked out branch to figure out what
you want it to do, namely:
branch.master.remote
branch.master.merge
Also in this case, it updates the origin/master remote-tracking branch.
(I think there has been previous discussion about this behavior - it
seems broken to me that "git pull <remote> <branch>" doesn't update
the corresponding remote-tracking branch <remote>/<branch> in the case
where "git pull [<remote>]" would normally do so according to that
repo's .git/config.)
j.
^ permalink raw reply
* Re: [PATCH 2/3] git-gui: spelling fixes in russian translation
From: Alex Riesen @ 2011-01-25 7:57 UTC (permalink / raw)
To: Pat Thoyts
Cc: git, Shawn O. Pearce, Serge Ziryukin, Dmitry Potapov,
Alexander Gavrilov, Junio C Hamano
In-Reply-To: <87wrltnakc.fsf@fox.patthoyts.tk>
On Tue, Jan 25, 2011 at 00:31, Pat Thoyts
<patthoyts@users.sourceforge.net> wrote:
> Alex Riesen <raa.lkml@gmail.com> writes:
>
>>2011/1/17 Alex Riesen <raa.lkml@gmail.com>:
>>> po/ru.po | 24 ++++++++++++------------
>>> 1 files changed, 12 insertions(+), 12 deletions(-)
>>>
>>> diff --git a/po/ru.po b/po/ru.po
>>> index c15bdfa..304bb3a 100644
>>
>>BTW, does anyone know what happens to git-gui development?
>>In particular, the i18n patches. The old way of pushing
>>to a mob branch seems to stopped working, and anyway, the
>>branch is very out of date.
>>
>>Is git gui development stalled? Should I perhaps send the
>>i18n pull request directly to Junio?
>>
>
> If you post here they'll get picked up eventually.
> If you want to use the mob branch, we can use that too but you would
> need to post here and to me to notify everyone.
What's with git-gui-i18n/mob branch being out-of-date? Actually,
it seems to be abandoned, because it does have quite a bit of
changes in it which are not in git-gui/master: spanish, bulgarian,
portugese, romanian, chinese, italian, japan and greek:
$ git cherry -v git-gui-i18n/master git-gui-i18n/mob
- 0896a7856335cc934328e02b84e1e41b9db2632d Updated Hungarian
translation (e5fba18)
+ c6fb29db5a50df150280b641d3c2a6703589b529 Fixed usage of positional
parameters in it.po and ja.po
+ a1fdd910cf11837135f8b007dbb1380131f8d107 Started Romanian Translation
+ 2f27eb24bf1dfdbb14dbc44698cb07ed294a10cf Start Spanish translation
+ 4616c11423484f40361466e0f2470d6c4a29e692 More strings for Spanish
translation
+ e51f330c4c94795cb7cfd151df2f2a222bde0d66 Yet more strings translated...
+ 0947a8e1d71ff03fbc2838f4742de8aa6c971083 Translated a few more strings
- 71438168c673dd644b442a4c3f863456ddf4b13b Update french translation.
+ bb88a426e49b73c6e7f9b0c8c3be6dc1946252a7 More translated strings
for Spanish. Close to being there...
+ 1cf3364c33c57f83b214e51a3ee260334ddc7e56 Fixed usage of positional
parameters in ja.po
+ 3f4263f049b76118ce8f8f35aacc99dc2f958a82 A few more strings
+ 31da610cb074364aa8d6e32c4cf2a3b5c6d16b51 A Bulgarian translation
has been added.
+ ad8d6a97f364f4ee3082258aeddb0488652b81d2 git-gui: Update
simplified Chinese translation to POT-2008-08-02
+ 6227f5ee3c74078eec37790111242ac3856759da git-gui: Add traditional
Chinese translation
+ de6afb81c44b44722affd8f2f6aa26fece24c401 Started Portuguese translation.
+ 78ae667f948ed29dca3f7abc3ae67996a56fabf7 Cleaned header of
Portuguese translation and corrects translation of "Commit@@verb".
+ c71abd9b3de78db783e8a7af92fb75bdd57bf2a9 Clean messed up header from KBabel
+ 7b89dc573b03e26ef0b620b5f73aaf116f0eaef9 Added Greek translation & glossary
^ permalink raw reply
* The problem of Git in starting
From: peng.pang @ 2011-01-25 8:00 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 665 bytes --]
Hi , Git engineer,
Thanks for your gift of Git so much excellent .
But after I downloaded this Git-1[1].7.3.1-preview20101002.exe ,
I installed this version Git , but when I started Git->Git GUI , and
problem happened , this problem screen picture is put the attached file ,
and then can't start Git , I have to exit the Git and can't continue to do
anything in Git ..
(See attached file: 1.JPG)
This problem always happened , whatever I uninstalled Git and reinstalled
Git many times ,
Now I doubt if need to reinstalled Window XP OS .
Would you tell me how to solve this problem , and let me use Git normally
in Window XP OS ,
Thanks
Bob Pang
[-- Attachment #2: 1.JPG --]
[-- Type: image/jpeg, Size: 55747 bytes --]
^ permalink raw reply
* last commit in a directory
From: Leonid Podolny @ 2011-01-25 8:29 UTC (permalink / raw)
To: git
Hi,
I have a really simple question: how do I find a last commit for the given directory inside the repository? I want to avoid rebuilding the specific part of the project if there were no changes in it since the last build, so I need to find the sha of the last time the directory was changed.
Thanks, L.
^ permalink raw reply
* Re: last commit in a directory
From: Johannes Sixt @ 2011-01-25 8:47 UTC (permalink / raw)
To: Leonid Podolny; +Cc: git
In-Reply-To: <4D3E89FA.4080901@gmail.com>
Am 1/25/2011 9:29, schrieb Leonid Podolny:
> I have a really simple question: how do I find a last commit for the given
> directory inside the repository?
git log -1 that/directory
But if you need it in a script, this is preferable:
lastsha1=$(git rev-list -1 HEAD -- "$directory")
-- Hannes
^ permalink raw reply
* Re: last commit in a directory
From: Leonid Podolny @ 2011-01-25 8:50 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <4D3E8E0B.2090200@viscovery.net>
On 01/25/2011 10:47 AM, Johannes Sixt wrote:
> Am 1/25/2011 9:29, schrieb Leonid Podolny:
>> I have a really simple question: how do I find a last commit for the given
>> directory inside the repository?
>
> git log -1 that/directory
>
> But if you need it in a script, this is preferable:
>
> lastsha1=$(git rev-list -1 HEAD -- "$directory")
>
Thanks!
^ permalink raw reply
* Can't find the revelant commit with git-log
From: Francis Moreau @ 2011-01-25 9:01 UTC (permalink / raw)
To: git
Hello,
I'm trying to find out a commit which removed a function inside a file.
The project is the Linux kernel, and I'm trying to look for changes
which happened between v2.6.27 and v2.6.28. The changes happened in the
following file: drivers/pci/intel-iommu.c where a function has been
removed:
$ git --version
git version 1.7.4.rc3
$ cd ~/linux-2.6/drivers/pci/
$ git grep blacklist v2.6.27 -- drivers/pci/intel-iommu.c
$
No ouput... hmm, I know it's in... oh maybe the path is incorrect
$ git git grep blacklist v2.6.27 -- intel-iommu.c
v2.6.27:intel-iommu.c:static int blacklist_iommu(const struct dmi_system_id *id)
v2.6.27:intel-iommu.c: .callback = blacklist_iommu,
ah, so Git failed previously without any comments on the wrong
path... maybe it should ?
So at that point I know that in the revision v2.6.27, there's a function
called "blacklist_iommu" in drivers/pci/intel-iommu.c
Now take a look if it's still there in v2.6.28:
$ git git grep blacklist v2.6.28 -- intel-iommu.c
$
This time nothing is printed but I know that the command is correct.
So now I'm interested in looking for the commit which removed this
function. Fo this I'm trying to use git-log(1):
$ git log --full-history --follow -S'static int blacklist_iommu(const struct dmi_system_id *id)' v2.6.27..v2.6.28 -- intel-iommu.c
$ echo $?
0
I tried different options but it fails.
Also I found that passing the exact string to '-S' is annoying, are
there any way to just pass a part of the string such as
"-Sblacklist_iommu" ?
Sorry if I miss the revelant git-log's option, but there're so many...
--
Francis
^ permalink raw reply
* Re: [RFC] Add bad-branch-first option for git-bisect
From: Christian Couder @ 2011-01-25 9:20 UTC (permalink / raw)
To: Shuang He
Cc: git@vger.kernel.org, apenwarr@gmail.com, Junio C Hamano,
Johannes Sixt
In-Reply-To: <4D3D54D3.7040801@intel.com>
On Mon, Jan 24, 2011 at 11:30 AM, Shuang He <shuang.he@intel.com> wrote:
> On 2011/1/24 17:53, Christian Couder wrote:
>>
>> Hi,
>>
>> On Mon, Jan 24, 2011 at 3:03 AM, Shuang He<shuang.he@intel.com> wrote:
>>>
>>> Hi
>>> The default git-bisect algorithm will jump around the commit tree,
>>> on the purpose of taking least steps to find the first culprit commit.
>>> We may find it sometime would locate a old culprit commit that we're not
>>> concerned about anymore.
>>
>> Yes, it can be a problem.
>
> I'm honored to be given so much comment :)
> Thank you
I am honored by your interest in git bisect and the fact that you
provided a patch :-)
Thanks!
>> If the quality of these branches is too bad, I think they should not
>> have been merged in the first place.
>> If they are not merged (and not marked as good), then git bisect will
>> not look at them, since it will look only at commits that are
>> ancestors of the bad commit it is given.
>>
>> Or if one is merged but it causes too many problems, then perhaps a
>> replacement commit could be used to unmerge the branch.
>>
>> Another possibility is to have in a file a list of commits that are
>> the last commits on these branches before the merge commits, and do a:
>>
>> git bisect good $(cat good_commits_file.txt)
>>
>> at the beginning of each bisection.
>>
>> So I think the long term solution in this case is not what your are
>> suggesting.
>
> 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.
>>> 2. Some of those branches may not synchronized with main
>>> branch in time. Say feature1 is broken when feature2 branch is created,
>>> and
>>> feature1 is fixed just a moment later after feature2 branch is created,
>>> and when feature2's development is done, and developer want to merge
>>> feature2 branch back to master branch, feature2 will be firstly
>>> synchronized to master branch tip, then merge into master. For the same
>>> reason addressed in issue 1, this will also lead git-bisect into wrong
>>> direction.
>>
>> I am not sure what you mean by " feature2 will be firstly synchronized
>> to master branch tip", and I think this should mean a rebase that
>> would fix the bug if feature1 has already been merged into the master
>> branch.
>>
>> But anyway in this case, I think that git bisect will find that the
>> first bad commit is the last commit in the branch, just before it was
>> merged. And by looking at the branch graph it should be quite easy to
>> understand what happened.
Now I think I was wrong here, as git bisect will probably find that
the first commit in the branch (not the last one) is the first bad
commit.
[...]
>> - 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.
Thanks,
Christian.
^ permalink raw reply
* Confused about git filter-branch results
From: Mike Kelly @ 2011-01-25 11:48 UTC (permalink / raw)
To: git
Hi Everyone,
I was fooling around with 'git filter-branch --env-filter ...' trying to
update the timestamps on my commits (which worked), but now when I run
'git whatchanged -p master..' shows all changes to the entire project, not
the differences between my branch and the master branch.
Being a novice git user, I'm not sure how much to trust that I didn't hose
git in some really weird way, leaving it in a state where it doesn't quite
work the way it did before.
The contents of .git/refs/original/refs/heads/ shows a file with my branch
name which contains only one entry (presumably the one I updated the
timestamp on) so I feel pretty sure that only the commit I wanted to change
actually changed. However, the fact that 'git whatchanged -p' now behaves
differently makes me worry.
Nothing went wrong during my update, however, I forgot to give a range
label so it searched the entire project. In theory nothing should have
changed, but...
Ultimately, my worry is that I polluted the history which I cloned, and
pushing that would make people unhappy.
I can still get to my patches, so I can still do a fresh pull and reapply
all my changes again, as a last resort, but I'd rather not if I don't
have to.
So my questions are:
1) Is this a problem with an easy fix?
2) If not, can I back out my change?
3) Is git push --dry-run the best way to find out what I changed? Is there
a better way to see what will be pushed?
4) Is there a better way to update the timestamps of my commits so that my
patches will appear as a solid block of commits in the history (as that
is how they will be committed), not interleaved with other changes in
the past (giving the false impression that they were applied to the
master tree when they were not)?
Thanks in advance,
Mike
(:
--
--------Mike@PirateHaven.org-----------------------The_glass_is_too_big--------
^ permalink raw reply
* Re: Can't find the revelant commit with git-log
From: René Scharfe @ 2011-01-25 16:12 UTC (permalink / raw)
To: git
In-Reply-To: <m2ipxd2w78.fsf@gmail.com>
Am 25.01.2011 10:01, schrieb Francis Moreau:
> Hello,
>
> I'm trying to find out a commit which removed a function inside a file.
>
> The project is the Linux kernel, and I'm trying to look for changes
> which happened between v2.6.27 and v2.6.28. The changes happened in the
> following file: drivers/pci/intel-iommu.c where a function has been
> removed:
>
> $ git --version
> git version 1.7.4.rc3
>
> $ cd ~/linux-2.6/drivers/pci/
> $ git grep blacklist v2.6.27 -- drivers/pci/intel-iommu.c
> $
>
> No ouput... hmm, I know it's in... oh maybe the path is incorrect
>
> $ git git grep blacklist v2.6.27 -- intel-iommu.c
> v2.6.27:intel-iommu.c:static int blacklist_iommu(const struct dmi_system_id *id)
> v2.6.27:intel-iommu.c: .callback = blacklist_iommu,
>
> ah, so Git failed previously without any comments on the wrong
> path... maybe it should ?
Good idea.
> So at that point I know that in the revision v2.6.27, there's a function
> called "blacklist_iommu" in drivers/pci/intel-iommu.c
>
> Now take a look if it's still there in v2.6.28:
>
> $ git git grep blacklist v2.6.28 -- intel-iommu.c
> $
>
> This time nothing is printed but I know that the command is correct.
>
> So now I'm interested in looking for the commit which removed this
> function. Fo this I'm trying to use git-log(1):
>
> $ git log --full-history --follow -S'static int blacklist_iommu(const struct dmi_system_id *id)' v2.6.27..v2.6.28 -- intel-iommu.c
> $ echo $?
> 0
>
> I tried different options but it fails.
>
> Also I found that passing the exact string to '-S' is annoying, are
> there any way to just pass a part of the string such as
> "-Sblacklist_iommu" ?
This (-Sblacklist_iommu) works for me.
> Sorry if I miss the revelant git-log's option, but there're so many...
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?
Also interesting, and matching the above results in that we see the need for
the -m flag confirmed:
$ for merge in 057316c 6b2ada8 d847059 725c258 6e03f99
do
a=$(git show $merge | grep -c blacklist_iommu)
b=$(git show -m $merge | grep -c blacklist_iommu)
echo $merge $a $b
done
057316c 0 2
6b2ada8 0 2
d847059 0 2
725c258 0 2
6e03f99 0 2
IAW: the combined diff for the five found merges doesn't show any changes to
a line containing the string "blacklist_iommu", but the full diffs do.
Let's check for the presence of the string in the merge results and their
parents:
$ for merge in 057316c 6b2ada8 d847059 725c258 6e03f99
do
for rev in $(git show $merge | grep ^Merge:)
do
t=parent
case $rev in
Merge:)
echo
rev=$merge
t=merge
;;
esac
if git grep -q blacklist_iommu $rev -- drivers/pci/
then
echo "$t $rev: found"
else
echo "$t $rev: not found"
fi
done
done
merge 057316c: not found
parent 3e2dab9: found
parent 2515ddc: not found
merge 6b2ada8: not found
parent 278429c: not found
parent 3b7ecb5: found
parent 77af7e3: not found
parent 1516071: not found
parent 1fa63a8: not found
parent 8546232: not found
merge d847059: not found
parent 725c258: found
parent 11494547: not found
merge 725c258: found
parent 3dd392a: found
parent 72d3105: found
parent 129d6ab: not found
parent 1e19b16: found
merge 6e03f99: found
parent 9821626: not found
parent 6bfb09a: found
Hmm, seems like the function is gone since d847059. Does all of this help
you in any way?
René
^ permalink raw reply
* Re: Confused about git filter-branch results
From: Thomas Rast @ 2011-01-25 16:32 UTC (permalink / raw)
To: Mike Kelly; +Cc: git
In-Reply-To: <20110125114840.GB9367@skull.piratehaven.org>
Mike Kelly wrote:
> filter-branch
Before you read the explanations below, I recommend that you open
'gitk --all' and use it to see whether I'm right.
> I was fooling around with 'git filter-branch --env-filter ...' trying to
> update the timestamps on my commits (which worked), but now when I run
> 'git whatchanged -p master..' shows all changes to the entire project, not
> the differences between my branch and the master branch.
Most likely you filtered all commits on your branch, but not master,
so master now points to an entirely disjoint set of commits.
> Being a novice git user, I'm not sure how much to trust that I didn't hose
> git in some really weird way, leaving it in a state where it doesn't quite
> work the way it did before.
It's hopefully impossible to get git into a *inconsistent* state with
filter-branch (i.e., a state that the computer would refuse to
process), but it is indeed quite easy to get it into a state that
humans would call "a mess".
> The contents of .git/refs/original/refs/heads/ shows a file with my branch
> name which contains only one entry (presumably the one I updated the
> timestamp on) so I feel pretty sure that only the commit I wanted to change
> actually changed.
That's not how it works. A branch contains the sha1 of ("is a pointer
to") its tip commit. The refs/original/refs/heads/foo simply is the
old value of the branch, i.e., the old tip commit.
You can use it much like you could use a branch to see the difference
between them, e.g.,
gitk refs/original/refs/heads/foo...foo
but note that if the disjoint history theory above holds, this will
not be immediately obvious from the output.
> Ultimately, my worry is that I polluted the history which I cloned, and
> pushing that would make people unhappy.
Pushing that would probably make people take a proverbial LART stick
to your office.
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
and rewrite again with a range limiter, or rebase your rewritten
commits. To illustrate the rebase, assume you had history like
o---o---o---o---o---o (master)
\
*---*---* (foo)
If you really rewrote all history of foo, that means you now have
o---o---o---B---o---o (master)
\
1---2---3 (refs/heads/original/foo)
o'--o'--o'--B'--1'--2'--3' (foo)
where the ' indicates a rewritten copy of the original commit. You
need to manually determine B and B'. The former will most likely be
git merge-base master refs/heads/original/foo
The latter will be its equivalent, so you can take Bs message and
search for its subject in the history of the (rewritten) foo. Once
you know B', you can rebase the commits that were previously on foo
back to master with
git rebase --onto B B' foo
That will create another series of rewritten copies of 1', like so:
o---o---o---B---o---o (master)
|\
| 1---2---3 (refs/heads/original/foo)
|
\
1''--2''--3'' (foo)
o'--o'--o'--B'--1'--2'--3' (foo@{1})
Confused yet? :-)
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: Can't find the revelant commit with git-log
From: Francis Moreau @ 2011-01-25 17:44 UTC (permalink / raw)
To: René Scharfe; +Cc: git
In-Reply-To: <4D3EF650.20407@lsrfire.ath.cx>
René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
> Am 25.01.2011 10:01, schrieb Francis Moreau:
>>
>> The project is the Linux kernel, and I'm trying to look for changes
>> which happened between v2.6.27 and v2.6.28. The changes happened in the
>> following file: drivers/pci/intel-iommu.c where a function has been
>> removed:
>>
>> $ git --version
>> git version 1.7.4.rc3
>>
>> $ cd ~/linux-2.6/drivers/pci/
>> $ git grep blacklist v2.6.27 -- drivers/pci/intel-iommu.c
>> $
>>
>> No ouput... hmm, I know it's in... oh maybe the path is incorrect
>>
>> $ git git grep blacklist v2.6.27 -- intel-iommu.c
>> v2.6.27:intel-iommu.c:static int blacklist_iommu(const struct dmi_system_id *id)
>> v2.6.27:intel-iommu.c: .callback = blacklist_iommu,
>>
>> ah, so Git failed previously without any comments on the wrong
>> path... maybe it should ?
>
> Good idea.
>
Actually I _think_ I encoutered this behaviour for other commands as well,
like git-show or git-log, I don't remember.
>
>> So at that point I know that in the revision v2.6.27, there's a function
>> called "blacklist_iommu" in drivers/pci/intel-iommu.c
>>
>> Now take a look if it's still there in v2.6.28:
>>
>> $ git git grep blacklist v2.6.28 -- intel-iommu.c
>> $
>>
>> This time nothing is printed but I know that the command is correct.
>>
>> So now I'm interested in looking for the commit which removed this
>> function. Fo this I'm trying to use git-log(1):
>>
>> $ git log --full-history --follow -S'static int blacklist_iommu(const struct dmi_system_id *id)' v2.6.27..v2.6.28 -- intel-iommu.c
>> $ echo $?
>> 0
>>
>> I tried different options but it fails.
>>
>> Also I found that passing the exact string to '-S' is annoying, are
>> there any way to just pass a part of the string such as
>> "-Sblacklist_iommu" ?
>
> This (-Sblacklist_iommu) works for me.
>
Hmm, I thought I tried this and it didn't work, but that's obviously
wrong.
>
>> Sorry if I miss the revelant git-log's option, but there're so many...
>
> 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:
>
> $ for merge in 057316c 6b2ada8 d847059 725c258 6e03f99
> do
> a=$(git show $merge | grep -c blacklist_iommu)
> b=$(git show -m $merge | grep -c blacklist_iommu)
> echo $merge $a $b
> done
> 057316c 0 2
> 6b2ada8 0 2
> d847059 0 2
> 725c258 0 2
> 6e03f99 0 2
>
> IAW: the combined diff for the five found merges doesn't show any changes to
> a line containing the string "blacklist_iommu", but the full diffs do.
>
> Let's check for the presence of the string in the merge results and their
> parents:
>
> $ for merge in 057316c 6b2ada8 d847059 725c258 6e03f99
> do
> for rev in $(git show $merge | grep ^Merge:)
> do
> t=parent
> case $rev in
> Merge:)
> echo
> rev=$merge
> t=merge
> ;;
> esac
> if git grep -q blacklist_iommu $rev -- drivers/pci/
> then
> echo "$t $rev: found"
> else
> echo "$t $rev: not found"
> fi
> done
> done
>
> merge 057316c: not found
> parent 3e2dab9: found
> parent 2515ddc: not found
>
> merge 6b2ada8: not found
> parent 278429c: not found
> parent 3b7ecb5: found
> parent 77af7e3: not found
> parent 1516071: not found
> parent 1fa63a8: not found
> parent 8546232: not found
>
> merge d847059: not found
> parent 725c258: found
> parent 11494547: not found
>
> merge 725c258: found
> parent 3dd392a: found
> parent 72d3105: found
> parent 129d6ab: not found
> parent 1e19b16: found
>
> merge 6e03f99: found
> parent 9821626: not found
> parent 6bfb09a: found
>
> Hmm, seems like the function is gone since d847059. Does all of this help
> you in any way?
Yes it does, but one question I'm wondering is: is it possible to do
this more user friendly ? ;)
Thanks
--
Francis
^ permalink raw reply
* Re: [msysGit] Git unable to access https repositories due to curl/OpenSSL 1.0.0 handshake issues
From: Erik Faye-Lund @ 2011-01-25 19:05 UTC (permalink / raw)
To: Mika Fischer; +Cc: msysGit, Git Mailing List
In-Reply-To: <0aa77107-bb31-4f74-90e2-02ce5155b0a0@l17g2000yqe.googlegroups.com>
(CCing the mainline Git mailing list for insight)
On Tue, Jan 25, 2011 at 6:42 PM, Mika Fischer
<mika.a.fischer@googlemail.com> wrote:
> Hi,
>
> with the latest msysGit (1.7.3.1-preview20101002.exe), I cannot access
> git repositories via https, if they are served by an apache using
> OpenSSL 1.0.0
>
> The error is:
> ----
> error: error:14077458:SSL routines:SSL23_GET_SERVER_HELLO:reason(1112)
> while accessing https://server/repository/info/refs
>
> fatal: HTTP request failed
> ----
>
> An apache using OpenSSL 0.9.8 works fine.
>
> There seem to be some SSL handshake issues, when curl and apache use
> different versions of OpenSSL:
> http://bugs.gentoo.org/332661
This issue is listed as an issue with Gentoo's OpenSSL 1.0.0 builds,
and seems to be have resolved by adding back SSLv2 support.
> http://comments.gmane.org/gmane.comp.web.curl.general/11154
This seems to be an issue with Fedora's OpenSSL 1.0.0 builds.
> Any idea how to fix this? For instance, is it possible to configure
> parameters that are passed to curl (passing -3 would fix it)? I could
> also change the apache configuration if someone knows how to work
> around this issue, although I already tried playing around with the
> SSLProtocol option of Apache to no avail...
>
Git for Windows currently use OpenSSL 0.9.8k, so this sounds to me
like an issue in your server-end. Your server seems to simply be
incompatible with OpenSSL 0.9.8-clients, which is the vast majority of
SSL-clients out there.
AFAICT, Git does not run curl, but use libcurl instead. It doesn't set
CURLOPT_SSLVERSION, and Git for Windows use libcurl 7.21.1 where
either SSLv3 or TLSv1 seems to be the default. So I don't know if
there's anything we can do about this on the Git side. You could try
to set CURLOPT_SSLVERSION to work around the issue, but I don't think
this is something we'd want to do in a Git for Windows release.
But:
This issue seems like it might be related to this, which is a big issue:
http://www.openssl.org/news/secadv_20101202.txt
In other words: We should probably upgrade OpenSSL. If not, Git for
Windows will most likely be a security hole.
But we must do so while making sure we are compatible with 0.9.8. It
seems to me like either 0.9.8q or 1.0.0c and beyond fixes the
security-hole. If 1.0.x breaks 0.9.8 support (It's unclear to me if it
does or not - some sources say it does, some say it doesn't), perhaps
0.9.8q is the safest route? It's probably also the version that needs
the least amount of patching to run, as it's closer to what we're
already building. This probably means we COULD have it ready for Git
for Windows 1.7.4.
> Any help would be very much appreciated, as this makes git totally
> useless under Windows for us, as all our repositories are accessed
> through https...
As I said: I think this is a problem with your server, not Git for
Windows. But I'm far from an expert on the subject, so I could be
mistaken.
^ permalink raw reply
* Re: git filter-branch can "forget" directories on case insensitive filesystems
From: Simeon Maxein @ 2011-01-25 20:56 UTC (permalink / raw)
To: git
In-Reply-To: <AANLkTimOs9m==KaD3BNHcgkTTqNQF1yV0NLA_Ew+iS-N@mail.gmail.com>
In my opinion this is a quite serious issue, because files are lost
without any indication to the user. As of git 1.7.3.1 (tested on
Windows/NTFS with msysGit this time), the problem still exists. Please
give it a look. Fullquote of the problem description / steps to
reproduce follows.
Simeon
> When running git filter-branch on a case insensitive filesystem, the
> working tree checked out for filtering is missing a directory in my
> project. This is probably related to the problem discussed here:
> http://article.gmane.org/gmane.comp.version-control.git/154662
>
> In contrast to that report, this one affects repositories on
> case-insensitive filesystems, regardless of the setting of
> core.ignorecase.
>
> To reproduce the problem, follow the steps below. I tested them with
> git 1.7.0.4 on a laptop running Ubuntu, with the repository on a Fat32
> USB drive.
>
> mkdir gittest
> cd gittest
> git init
> mkdir testdir
> echo 'abc' >testdir/testfile
> git add testdir
> git commit -m foo
> git rm -r testdir
> mkdir testDir
> echo 'abc' >testDir/testfile
> git add testDir
> git commit -m bar
>
> Now, check out master^1 and master to ensure the commits look as
> expected. Then, run this:
>
> git filter-branch --tree-filter 'ls' master
>
> You will notice that the directory vanishes when the second commit is filtered.
>
> The problem occurs whether core.ignorecase is set to true or false. It
> doesn't occur on case sensitive filesystems.
>
> Simeon
^ permalink raw reply
* Re: git filter-branch can "forget" directories on case insensitive filesystems
From: Johannes Sixt @ 2011-01-25 21:56 UTC (permalink / raw)
To: smaxein; +Cc: git
In-Reply-To: <4D3F38E9.9060902@googlemail.com>
On Dienstag, 25. Januar 2011, Simeon Maxein wrote:
> In my opinion this is a quite serious issue, because files are lost
> without any indication to the user. As of git 1.7.3.1 (tested on
> Windows/NTFS with msysGit this time), the problem still exists. Please
> give it a look. Fullquote of the problem description / steps to
> reproduce follows.
> > mkdir testdir
> > echo 'abc' >testdir/testfile
> > git add testdir
> > git commit -m foo
> > git rm -r testdir
> > mkdir testDir
> > echo 'abc' >testDir/testfile
> > git add testDir
> > git commit -m bar
Please retry with current release condidate of 1.7.4; it has some
core.ignorecase improvements w.r.t. directories. It could well be that your
problem is fixed.
-- Hannes
^ permalink raw reply
* Re: Git repo on a machine with zero commits is ahead of remote by 103 commits.. !
From: Srirang Doddihal @ 2011-01-25 23:09 UTC (permalink / raw)
To: Jay Soffian, Johannes Sixt; +Cc: git
In-Reply-To: <AANLkTinC7yvHJj_onRRWBYaZ23Pvs0JB2DJT44Jy-JLG@mail.gmail.com>
Thank you Jay and Johannes. A 'git pull' solved the problem and I now
understand git a little better. :)
--
Regards,
Srirang G Doddihal
Brahmana.
The LIGHT shows the way.
The WISE see it.
The BRAVE walk it.
The PERSISTENT endure and complete it.
I want to do it all ALONE.
^ permalink raw reply
* Re: git filter-branch can "forget" directories on case insensitive filesystems
From: Simeon Maxein @ 2011-01-25 23:26 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <201101252256.03644.j6t@kdbg.org>
Am 25.01.2011 22:56, schrieb Johannes Sixt:
> On Dienstag, 25. Januar 2011, Simeon Maxein wrote:
>> In my opinion this is a quite serious issue, because files are lost
>> without any indication to the user. As of git 1.7.3.1 (tested on
>> Windows/NTFS with msysGit this time), the problem still exists. Please
>> give it a look. Fullquote of the problem description / steps to
>> reproduce follows.
>>> mkdir testdir
>>> echo 'abc' >testdir/testfile
>>> git add testdir
>>> git commit -m foo
>>> git rm -r testdir
>>> mkdir testDir
>>> echo 'abc' >testDir/testfile
>>> git add testDir
>>> git commit -m bar
> Please retry with current release condidate of 1.7.4; it has some
> core.ignorecase improvements w.r.t. directories. It could well be that your
> problem is fixed.
>
> -- Hannes
Thanks for the suggestion. The directory doesn't vanish anymore with
1.7.4, so a big Thank You to the developers for improving this. When
rewriting the second commit ls still prints testdir as lowercase though.
More of a nitpick, but it would still be neat to have it right.
The issue of extra files appearing during filter-branch (
http://article.gmane.org/gmane.comp.version-control.git/154662 ) is
still present.
Simeon
^ 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