* 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] Fix wrong xhtml option to highlight
From: Junio C Hamano @ 2011-01-24 22:48 UTC (permalink / raw)
To: Jochen Schmitt; +Cc: git
In-Reply-To: <1295898298-9794-1-git-send-email-Jochen@herr-schmitt.de>
Jochen Schmitt <Jochen@herr-schmitt.de> writes:
> ---
> Hallo,
>
> because I'm the maintainer of the highlight package in the
> Fedora Project I was notified, that highlight doesn't works
> properly with gitweb in BZ #672293.
>
> So I have create the following simple patch to solve the
> reported issue.
>
> Best Regards
>
> Jochen Schmitt
>
> gitweb/gitweb.perl | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 1025c2f..b662420 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 |"
> + " -xhtml --fragment --syntax $syntax |"
Curious.
Does the command take double-dash for the fragment and syntax options but
a single dash for the xhtml option? Really...
A few top hits returned by Google for "highlight manual page" tells me
otherwise.
^ permalink raw reply
* [ANNOUNCE] Git 1.7.4-rc3
From: Junio C Hamano @ 2011-01-24 22:36 UTC (permalink / raw)
To: git
A release candidate Git 1.7.4-rc3 is available at the usual places
for testing:
http://www.kernel.org/pub/software/scm/git/
git-1.7.4.rc3.tar.{gz,bz2} (source tarball)
git-htmldocs-1.7.4.rc3.tar.{gz,bz2} (preformatted docs)
git-manpages-1.7.4.rc3.tar.{gz,bz2} (preformatted docs)
The RPM binary packages for a few architectures are found in:
testing/git-*-1.7.4.rc3-1.fc13.$arch.rpm (RPM)
Except for a regression fix to keep honoring "git --work-tree=/there/ cmd"
without specifying --git-dir (Thanks Jonathan), there isn't any exciting
new thing to see here; which is exactly the way how I want an rc3 to be.
Hopefully we can tag the final by the end of the month. Everybody, thanks
in advance for testing this rc ;-).
----------------------------------------------------------------
Changes since v1.7.4-rc2 are as follows:
Alexey Shumkin (1):
userdiff: match Pascal class methods
Björn Steinbrink (1):
Correctly report corrupted objects
Erik Faye-Lund (1):
exec_cmd: remove unused extern
Johannes Sixt (2):
Fix expected values of setup tests on Windows
t/README: hint about using $(pwd) rather than $PWD in tests
Jonathan Nieder (9):
ll-merge: simplify opts == NULL case
Documentation/fast-import: capitalize beginning of sentence
remote-ext: do not segfault for blank lines
Documentation/fast-import: put explanation of M 040000 <dataref> "" in context
tests: cosmetic improvements to the repo-setup test
tests: compress the setup tests
Documentation: do not treat reset --keep as a special case
Subject: setup: officially support --work-tree without --git-dir
t1510: fix typo in the comment of a test
Junio C Hamano (2):
Documentation updates for 'GIT_WORK_TREE without GIT_DIR' historical usecase
Git 1.7.4-rc3
Ramsay Allan Jones (1):
svndump.c: Fix a printf format compiler warning
^ permalink raw reply
* Re: Why don't git-init and git-clone probe for core.ignorecase on Windows > XP?
From: Dun Peal @ 2011-01-24 21:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git ML
In-Reply-To: <7voc7s5uy3.fsf@alter.siamese.dyndns.org>
Thanks Junio, this question was due to a misunderstanding on my part:
For some reason, I thought "probe" in the man meant asking the user
whether core.ignorecase should be set. I vaguely recall there's
another (also Windows-related) setting that is interactively queried
like that.
Following your reply I tested with recent (1.7) installations of
msysgit and core.ignorecase is set automatically to true in
.git/config for newly created / cloned repo on NTFS over Windows 7.
Thanks again and sorry for the misunderstanding, D.
On Fri, Jan 7, 2011 at 2:18 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Dun Peal <dunpealer@gmail.com> writes:
>
>> The git-config manpage says about core.ignorecase:
>>
>> "The default is false, except git-clone(1) or git-init(1) will probe
>> and set core.ignorecase true if appropriate when the repository is
>> created."
>>
>> I assume this is happening when you clone or init on FAT, which is
>> explicitly mentioned earlier in that section. But apparently it
>> doesn't happen for either XP, Vista or 7. While those newer releases
>> use NTFS, which technically supports case-sensitivity, the operating
>> itself still apparently doesn't, so it would seem like git-clone and
>> git-init should probe regarding the core.ignorecase on any version of
>> Windows, no?
>
> Sorry, but it is unclear if you are complaining that core.ignorecase is
> set (but you believe it shouldn't be) or it is not set (but you believe it
> should be) on NTFS from the description.
>
> As far as I can tell from the code (I obviously only look at the plain
> vanilla git, and msysgit might have some patch to this part, I dunno. Oh
> by the way you didn't say which version you are complaining about,
> either), we do the probing on all systems (including POSIX folks with FAT
> filesystem mounted) by first creating .git/config and then checking if a
> file .git/CoNfIg which we know we never created can be accessed. If we
> can, that means the filesystem ignores case, iow, we cannot have two files
> config and CoNfIg at the same time, and set core.ignorecase to true.
>
^ permalink raw reply
* Re: First time gitr - have some questions
From: Matthieu Moy @ 2011-01-24 20:55 UTC (permalink / raw)
To: toltmanns; +Cc: git
In-Reply-To: <1295893245907-5956101.post@n2.nabble.com>
toltmanns <toltmanns@gmail.com> writes:
> First off, I may be in the wrong place, but I need a sanity check here.
>
> I've downloaded and am attempting to use the git bash app, trying to issue
> the following command and am getting fatal: Not a git repository
>
> git submodule add git@github.com:toltmanns/steal.git public/steal
> I went through directions here -
> http://www.javascriptmvc.com/docs/getstarted.html#&who=install
That page says, just above the command you're trying:
"You want to fork each project and add it as a submodule to your
project"
which you should read as
"At this point, you should have a Git project (i.e. repository) of
your own, and you can add our projects as subprojects of yours"
which probably implies that you should read some Git tutorial to learn
how to deal with your own project before trying to understand
submodules ;-).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: First time gitr - have some questions
From: Andrew Keller @ 2011-01-24 19:28 UTC (permalink / raw)
To: toltmanns; +Cc: git
In-Reply-To: <1295893245907-5956101.post@n2.nabble.com>
On Jan 24, 2011, at 1:20 PM, toltmanns wrote:
> First off, I may be in the wrong place, but I need a sanity check here.
Communication is the most efficient way to implement a sanity check.
> I've downloaded and am attempting to use the git bash app, trying to issue
> the following command and am getting fatal: Not a git repository
>
> git submodule add git@github.com:toltmanns/steal.git public/steal
I like that error because of how few scenarios can cause it. Your current working directory is not inside a repository. 'cd' into the repository and try again.
~ Andrew Keller
^ permalink raw reply
* Re: [RFC] Add bad-branch-first option for git-bisect
From: Avery Pennarun @ 2011-01-24 20:28 UTC (permalink / raw)
To: Christian Couder; +Cc: Shuang He, git, Johannes Sixt, Junio C Hamano
In-Reply-To: <AANLkTimUkv9+g_+wFcyGhwMjE9zYAKjMn32GL-WOVmoe@mail.gmail.com>
On Mon, Jan 24, 2011 at 1:53 AM, Christian Couder
<christian.couder@gmail.com> wrote:
> I am not opposed to an option to bisect on the first parents of the
> bad commit only. And after a very fast look at your patch it seems to
> be what it does. By the way Avery Pennarun's gitbuilder
> (https://github.com/apenwarr/gitbuilder) does the same thing. So I
> know some people are interested in such a feature.
Just some notes on gitbuilder's algorithm, since I haven't spent the
time to fully understand Shuang's proposal.
I do understand at least one of his concerns, that is, that people
like to do a lot of "messy" development on a branch, and when the
branch is done, merge the whole messy branch into the "mainline". The
messy branch would then have a lot of commits that break a lot of
things before fixing them again later.
In a corporate environment, this method allows people to work all day,
make frequent commits, pull from other branches at will, and never
risk their lives by doing poorly-educated rebases. It works pretty
well *until* you try to bisect, at which time all these messy commits
start to bite you.
gitbuilder's bisection is a total hack around this situation, although
it happens to work perfectly in the workflow it was designed for, thus
making me feel clever.
Basically, we push/fetch *all* the branches from *everybody* into a
single repo, and build all of them as frequently as we can. If you
think about it, if you have all the branches that someone might have
pulled/merged from, then you don't have to think of the git history as
a whole complicated DAG; you can just think of it as a whole bunch of
separate chunks of linear history. Moreover, as long as people are
careful to only pull from a branch when that branch is passing all
tests - which you can easily see by looking at the gitbuilder console
- then playing inside each of these chunks of linear history can help
you figure out where particular bugs were introduced during "messy"
branches.
It also allows you a nice separation of concerns. The owner of the
mainline branch (the "integration manager" person) only really cares
about which branch they merged that caused a problem, because that
person doesn't want to fix bugs, he/she simply wants to know who owns
the failing branch, so that person can fix *their* bug and their
branch will merge without breaking things.
So this is why gitbuilder uses "git rev-list --first-parent" during
its "fake bisection" operation: because a different person is
responsible for each "linear chunk" of history.
Note that you have to use --no-ff when merging if you want this to
work reliably. But the build manager person can just remember to do
that. Combining --no-ff and --ff-only (which sound mutually exclusive
but aren't) is a way to be extra specially sure.
Now, if you aren't using gitbuilder, what we want from "bisection" is
not quite the same, but let's imagine that you at least have a similar
setup, where people *only* ever merge into the mainline by using
--no-ff. In that case, you'd like a bisect operation that *starts* by
using --first-parent, which will tell you which merge caused the
problem. After that, you might want to bisect into the branch.
(I don't actually remember if 'git bisect' understands --first-parent
correctly. gitbuilder doesn't exactly bisect either, but that's
another story and not relevant right now.)
I can actually imagine that there are many more projects that do what
I'm talking about - "messy" branches that get broken and fixed over
time, then merge into a "clean" mainline - than projects (like the
kernel and git.git) that try to keep all branches clean at all times.
Thus, I could see some argument that a "--first-parents first"
bisection would actually help out a lot of people, and maybe even
deserves to be the default.
I don't really care though, I just use gitbuilder :)
Have fun,
Avery
^ permalink raw reply
* Re: [PATCH 2/3] git-gui: spelling fixes in russian translation
From: Alex Riesen @ 2011-01-24 20:06 UTC (permalink / raw)
To: git
Cc: Shawn O. Pearce, Pat Thoyts, Serge Ziryukin, Dmitry Potapov,
Alexander Gavrilov, Junio C Hamano
In-Reply-To: <20110117210828.GC27029@blimp.localdomain>
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?
^ permalink raw reply
* Re: [RFC] Add bad-branch-first option for git-bisect
From: Junio C Hamano @ 2011-01-24 20:04 UTC (permalink / raw)
To: Shuang He
Cc: Johannes Sixt, Christian Couder, git@vger.kernel.org,
apenwarr@gmail.com
In-Reply-To: <4D3D5CE5.4050108@intel.com>
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.
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?
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?
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.
^ permalink raw reply
* [PATCH] Fix wrong xhtml option to highlight
From: Jochen Schmitt @ 2011-01-24 19:44 UTC (permalink / raw)
To: git; +Cc: Jochen Schmitt
---
Hallo,
because I'm the maintainer of the highlight package in the
Fedora Project I was notified, that highlight doesn't works
properly with gitweb in BZ #672293.
So I have create the following simple patch to solve the
reported issue.
Best Regards
Jochen Schmitt
gitweb/gitweb.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 1025c2f..b662420 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 |"
+ " -xhtml --fragment --syntax $syntax |"
or die_error(500, "Couldn't open file or run syntax highlighter");
return $fd;
}
--
1.7.3.4
^ permalink raw reply related
* First time gitr - have some questions
From: toltmanns @ 2011-01-24 18:20 UTC (permalink / raw)
To: git
First off, I may be in the wrong place, but I need a sanity check here.
I've downloaded and am attempting to use the git bash app, trying to issue
the following command and am getting fatal: Not a git repository
git submodule add git@github.com:toltmanns/steal.git public/steal
I went through directions here -
http://www.javascriptmvc.com/docs/getstarted.html#&who=install
Made it to creating the github account and forking the codesets needed.
Am I missing something?
Thanks in advance,
Troy Oltmanns
--
View this message in context: http://git.661346.n2.nabble.com/First-time-gitr-have-some-questions-tp5956101p5956101.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: fatal: protocol error: bad line length 8205
From: Oliver Beattie @ 2011-01-24 17:49 UTC (permalink / raw)
To: git
In-Reply-To: <loom.20110124T160907-993@post.gmane.org>
Oliver Beattie <oliver <at> obeattie.com> writes:
> When I try to clone as a client, I get this error:
> fatal: protocol error: bad line length 8205
>
> Does anyone know what causes this/what I should do to fix it?
Never mind, found this was caused by a similar problem to the "bad line length
character" issue that is common.
^ permalink raw reply
* fatal: protocol error: bad line length 8205
From: Oliver Beattie @ 2011-01-24 15:11 UTC (permalink / raw)
To: git
Hi,
I am having a bit of a weird problem with a Git server of mine I am trying to
set up. I have never had
problems before which makes it even stranger.
Anyway, when I try to clone as a client, I get this error:
fatal: protocol error: bad line length 8205
Does anyone know what causes this/what I should do to fix it?
Many thanks,
Oliver Beattie
^ permalink raw reply
* merging branch
From: Mathieu Malaterre @ 2011-01-24 11:33 UTC (permalink / raw)
To: git
Hi,
I have the following branches:
$ git branch
* master
release
I have messed up my 'release' branch by manually importing file one
by one using: git checkout release && git checkout master my_file.cxx
So now I'd like to merge back release to master. I tried:
$ git checkout master && git merge -s ours release
$ git status
# On branch master
# Your branch is ahead of 'origin/master' by 27 commits.
#
nothing to commit (working directory clean)
$ git diff origin/master..master
-> return nothing
Since most of those commits will be redundant, I need to 'git pull
--rebase', right ? However I did not understand how to pass the
--interactive option to git pull --rebase to split this set of 27
commits (I'd like to discard at least one large one)
Thanks !
--
Mathieu
^ permalink raw reply
* Re: [RFC] Add bad-branch-first option for git-bisect
From: Shuang He @ 2011-01-24 11:05 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Christian Couder, git@vger.kernel.org, apenwarr@gmail.com
In-Reply-To: <4D3D5989.50903@viscovery.net>
On 2011/1/24 18:50, Johannes Sixt wrote:
> Am 1/24/2011 11:30, schrieb Shuang He:
>> 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
> Ok, so you explain what your algorithm does.
>
> But you did not illustrate your problem. The history above is ordinary,
> somewhat branchy, has *ONE* commit that introduces a regression, and *NO*
> commit that fixes the regression. But in your rationale you said something
> about "feature1 is fixed just a moment later after feature2 branch is
> created". How does this fit into the picture, where is the problem, and
> how does your algorithm solve it?
>
> -- Hannes
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
Thanks
--Shuang
Thanks
--Shuang
^ permalink raw reply
* Re: cannot fetch arm git tree
From: Russell King - ARM Linux @ 2011-01-24 10:53 UTC (permalink / raw)
To: Johannes Sixt
Cc: git, linux-arm-kernel, Jello huang, Detlef Vollmann,
Uwe Kleine-König
In-Reply-To: <4D3D2865.4020408@viscovery.net>
On Mon, Jan 24, 2011 at 08:21:09AM +0100, Johannes Sixt wrote:
> Am 1/21/2011 15:50, schrieb Russell King - ARM Linux:
> > SetEnv GIT_PROJECT_ROOT /var/www/git
> > SetEnv GIT_HTTP_EXPORT_ALL
> > ScriptAlias /git/ /usr/libexec/git-core/git-http-backend/
> >
> > Great. Deciding that it will be http://servername.example.com/git/ is
> > really damned annoying as that's traditionally where gitweb lives,
> > which requires a different script alias.
> > ...
> > I'm really not interested in working out how to bodge this into working
> > along side the existing gitweb setup by adding lots of rewrite rules,...
>
> It has been worked out for you already. It's just a single rule (although
> a bit longish). Look for 'ScriptAliasMatch' in
> http://www.kernel.org/pub/software/scm/git/docs/git-http-backend.html
Thanks, added taking two server restarts (one of them took a few minutes
for apache to restart as it was soo busy...)
I assume this also means that I need to update the URLs people are using
(as the tree wasn't exported under http://hostname.example.com/git/)?
^ permalink raw reply
* Re: [RFC] Add bad-branch-first option for git-bisect
From: Johannes Sixt @ 2011-01-24 10:50 UTC (permalink / raw)
To: Shuang He; +Cc: Christian Couder, git@vger.kernel.org, apenwarr@gmail.com
In-Reply-To: <4D3D54D3.7040801@intel.com>
Am 1/24/2011 11:30, schrieb Shuang He:
> 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
Ok, so you explain what your algorithm does.
But you did not illustrate your problem. The history above is ordinary,
somewhat branchy, has *ONE* commit that introduces a regression, and *NO*
commit that fixes the regression. But in your rationale you said something
about "feature1 is fixed just a moment later after feature2 branch is
created". How does this fit into the picture, where is the problem, and
how does your algorithm solve it?
-- Hannes
^ permalink raw reply
* Re: [RFC] Add bad-branch-first option for git-bisect
From: Shuang He @ 2011-01-24 10:30 UTC (permalink / raw)
To: Christian Couder; +Cc: git@vger.kernel.org, apenwarr@gmail.com
In-Reply-To: <AANLkTimUkv9+g_+wFcyGhwMjE9zYAKjMn32GL-WOVmoe@mail.gmail.com>
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
>> In most software development, there's one or two main branch which
>> is maintained for release, and a bunch of feature branches are created
>> for new feature development or bug fix. For the reason that sometime
>> git-bisect will locate a old culprit commit would be:
>> 1. Quality of those branches may not match the main branch,
>> some functionality are broken at first and fixed later on the feature
>> branch. If git-bisect jump to there by chance, git-bisect will only find
>> that old
>> culprit commit which only exists on that feature branch
> 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.
>> 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.
>
> And then the obvious thing to do is to decide to just start a new
> bisection like it was started the first time but with an added "git
> bisect good<merge_commit>", where<merge_commit> is the commit that
> merges the branch.
For the same reason, that we're implementing automated bisect system ,
so we want git-bisect to
be able to help with this condition also.
>> In all, we think we do not care about branches that we're not
>> currently working, unless we're sure the regression is caused by that
>> branch.
>>
>> To address those issue, we propose to add a new config option:
>> core.bisectbadbranchfirst::
>> With this algorithm, git-bisect will always try to select
>> commits
>> that on the same branch current bad commit sits. And will
>> fall back
>> to default git-bisect algorithm when bad-branch-first
>> algorithm does
>> not apply
>> +
>> This setting defaults to "false".
> I am not opposed to an option to bisect on the first parents of the
> bad commit only. And after a very fast look at your patch it seems to
> be what it does. By the way Avery Pennarun's gitbuilder
> (https://github.com/apenwarr/gitbuilder) does the same thing. So I
> know some people are interested in such a feature.
>
> But here are some suggestions/comments:
>
> - your explanations about why it could be useful should be improved,
I don't have much data to prove it. I could just say it could help if
branches are not maintained very well.
> - 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
> - before having a config option for it, why not have it first as an
> option to "git bisect start",
Agree, I have thought about it. Haven't done it yet
> - if there is a config option, then there should probably be an option
> to "git bisect start" to use the regular algorithm,
Agree
> - it seems to me that bisecting only on first parents could fail only
> if some "good" commits are not ancestors of the bad commit, and if the
> bug is fixed on a branch where such a commit is; so I don't see the
> point in defaulting to the usual algorithm in this case because in
> this case the usual algorithm just stops,
It should stop as default git-bisect do, when
There are a few cases that this algorithm will fall back to default
algorithm:
when bisect path is specified. Since --first-parent seems not
working as expected when file path is specified
when bad branch first algorithm could not find a commit to bisect
> - perhaps the message given when the first bad commit is found should
> be changed a little bit when this option is used.
Yeah, agree
> Maybe I am missing something, because as I said I didn't read your
> patch carefully, but in this case please try to give a concrete
> example.
>
> Thanks,
> Christian.
^ permalink raw reply
* Re: [RFC] Add bad-branch-first option for git-bisect
From: Christian Couder @ 2011-01-24 9:53 UTC (permalink / raw)
To: Shuang He; +Cc: git, apenwarr
In-Reply-To: <4D3CDDF9.6080405@intel.com>
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.
> In most software development, there's one or two main branch which
> is maintained for release, and a bunch of feature branches are created
> for new feature development or bug fix. For the reason that sometime
> git-bisect will locate a old culprit commit would be:
> 1. Quality of those branches may not match the main branch,
> some functionality are broken at first and fixed later on the feature
> branch. If git-bisect jump to there by chance, git-bisect will only find
> that old
> culprit commit which only exists on that feature branch
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.
> 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.
And then the obvious thing to do is to decide to just start a new
bisection like it was started the first time but with an added "git
bisect good <merge_commit>", where <merge_commit> is the commit that
merges the branch.
> In all, we think we do not care about branches that we're not
> currently working, unless we're sure the regression is caused by that
> branch.
>
> To address those issue, we propose to add a new config option:
> core.bisectbadbranchfirst::
> With this algorithm, git-bisect will always try to select
> commits
> that on the same branch current bad commit sits. And will
> fall back
> to default git-bisect algorithm when bad-branch-first
> algorithm does
> not apply
> +
> This setting defaults to "false".
I am not opposed to an option to bisect on the first parents of the
bad commit only. And after a very fast look at your patch it seems to
be what it does. By the way Avery Pennarun's gitbuilder
(https://github.com/apenwarr/gitbuilder) does the same thing. So I
know some people are interested in such a feature.
But here are some suggestions/comments:
- your explanations about why it could be useful should be improved,
- the name "bisectbadbranchfirst" seems wrong to me, because git
branches are just some special tags; "firstparentsonly" would be a
better name,
- before having a config option for it, why not have it first as an
option to "git bisect start",
- if there is a config option, then there should probably be an option
to "git bisect start" to use the regular algorithm,
- it seems to me that bisecting only on first parents could fail only
if some "good" commits are not ancestors of the bad commit, and if the
bug is fixed on a branch where such a commit is; so I don't see the
point in defaulting to the usual algorithm in this case because in
this case the usual algorithm just stops,
- perhaps the message given when the first bad commit is found should
be changed a little bit when this option is used.
Maybe I am missing something, because as I said I didn't read your
patch carefully, but in this case please try to give a concrete
example.
Thanks,
Christian.
^ permalink raw reply
* Re: [PATCH] No color diff when redirecting to file
From: Matthieu Moy @ 2011-01-24 9:38 UTC (permalink / raw)
To: Sascha Peilicke; +Cc: git
In-Reply-To: <201101240959.02852.saschpe@gmx.de>
Sascha Peilicke <saschpe@gmx.de> writes:
> try the same with
>
> git diff > foo
git diff > foo && cat foo
=> no color.
git diff --no-color > foo && cat foo
=> no color either
git diff --color=always > foo && cat foo
=> colors.
Again, just the expected behavior.
If it helps:
$ uname -a
Linux bauges 2.6.36-686 #1 SMP PREEMPT Fri Nov 5 10:35:38 CET 2010 i686 GNU/Linux
$ git --version
git version 1.7.4.rc1.17.ge7ece
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH] No color diff when redirecting to file
From: Sascha Peilicke @ 2011-01-24 8:59 UTC (permalink / raw)
To: git
In-Reply-To: <vpq39oj4jfz.fsf@bauges.imag.fr>
[-- Attachment #1: Type: Text/Plain, Size: 752 bytes --]
On Sunday 23 January 2011 18:29:52 you wrote:
> Johannes Sixt <j6t@kdbg.org> writes:
> > That said, I cannot reproduce. Perhaps your configuration says
> > color.ui=always? If so, then this is expected behavior and not a bug,
> > IMO.
>
> I think you're right.
>
> I tested this (without the patch):
>
> git diff
> => I get color, because I have color.ui = auto
>
> git diff | cat
> => I don't get color
>
> git diff --color=auto | cat
> => no color
>
> git diff --color=always | cat
> => colors, because I've asked
>
> this seems to be just the right behavior.
try the same with
git diff > foo
works when
git diff --no-color > foo
--
Mit freundlichen Grüßen,
Sascha Peilicke
http://saschpe.wordpress.com
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH] No color diff when redirecting to file
From: Sascha Peilicke @ 2011-01-24 8:56 UTC (permalink / raw)
To: git
In-Reply-To: <201101231547.18529.j6t@kdbg.org>
[-- Attachment #1: Type: text/plain, Size: 749 bytes --]
On Sunday 23 January 2011 15:47:17 you wrote:
> The subject line reads as if you want that color markup appears in a file.
>
> On Sonntag, 23. Januar 2011, Sascha Peilicke wrote:
> > Previously, when having color diffs enabled and redirecting 'git diff'
> > into a file, one ends up with a messed up file containing termcap color
> > stuff. This change disables color when diff output is redirected into a
> > file.
>
> But this description and the patch read as if you don't want it.
>
> That said, I cannot reproduce. Perhaps your configuration says
> color.ui=always? If so, then this is expected behavior and not a bug, IMO.
Nope, it's color.ui=auto
--
Mit freundlichen Grüßen,
Sascha Peilicke
http://saschpe.wordpress.com
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH 3/3] setup: always honor GIT_WORK_TREE and core.worktree
From: Jonathan Nieder @ 2011-01-24 8:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nguyen Thai Ngoc Duy, git, Maaartin
In-Reply-To: <7vipxfmb9u.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Something like this (on top of jn/setup-fixes branch queued in
> next)?
For what it's worth,
Acked-by: Jonathan Nieder <jrnieder@gmail.com>
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -317,17 +317,26 @@ false), while all other repositories are assumed to be bare (bare
> = true).
>
> core.worktree::
> - Set the path to the working tree. The value will not be
> - used in combination with repositories found automatically in
> - a .git directory (i.e. $GIT_DIR is not set).
> + Set the path to the root of the work tree.
Most manpages seem to stick to the phrase "working tree". Not sure
if that's worth worrying about --- maybe it would be good to allow or
encourage usage to drift to the term "work tree" that gets used in
many parts of the interface.
> This can be overridden by the GIT_WORK_TREE environment
> variable and the '--work-tree' command line option. It can be
> + an absolute path or a relative path to the .git directory,
> + either specified by --git-dir or GIT_DIR, or automatically
> + discovered.
Maybe:
The value can be an absolute path or relative to the path to
the .git directory, which is either specified by --git-dir or
GIT_DIR or automatically discovered.
> - an absolute path or relative path to the directory specified by
> - --git-dir or GIT_DIR.
> - Note: If --git-dir or GIT_DIR are specified but none of
> + If --git-dir or GIT_DIR are specified but none of
> --work-tree, GIT_WORK_TREE and core.worktree is specified,
> - the current working directory is regarded as the top directory
> + the current working directory is regarded as the top level
> of your working tree.
Subject-verb agreement: "--git-dir or GIT_DIR is specified" (s/are/is/)
> ++
> +Note that this variable is honored even when set in a configuration
> +file in a ".git" subdirectory of a directory, and its value differs
> +from the latter directory (e.g. "/path/to/.git/config" has
> +core.worktree set to "/different/path"), which is most likely a
> +misconfiguration.
I think it's clearer without the comma between "directory" and "and"
(otherwise, it's too easy to parse as
Note that this variable is honored even when set ....
Its value differs from the latter directory, which is most
likely a misconfiguration.
).
> + Running git commands in "/path/to" directory will
> +still use "/different/path" as the root of the work tree and can cause
> +confusion, unless you know what you are doing (e.g. you are creating a
> +read-only snapshot of the same index to a location different from the
> +repository's usual working tree).
Missing article: s,in "path/to" directory,in the "/path/to" directory,
Comma usage: s/confusion, unless/confusion unless/ to avoid misparsing
this as meaning "will use this work tree unless you know what you are
doing".
> --- a/Documentation/git.txt
> +++ b/Documentation/git.txt
> @@ -291,17 +291,12 @@ help ...`.
> path or relative path to current working directory.
>
> --work-tree=<path>::
> - Set the path to the working tree. The value will not be
> - used in combination with repositories found automatically in
> - a .git directory (i.e. $GIT_DIR is not set).
> + Set the path to the working tree. It can be an absolute path
> + or relative path to the current working directory.
s/relative path to/path relative to/
> This can also be controlled by setting the GIT_WORK_TREE
> environment variable and the core.worktree configuration
> + variable (see core.worktree in linkgit:git-config[1] for a
> + more detailed discussion).
> - variable. It can be an absolute path or relative path to
[...]
Nice.
^ permalink raw reply
* Re: cannot fetch arm git tree
From: J.H. @ 2011-01-24 7:34 UTC (permalink / raw)
To: Johannes Sixt
Cc: Russell King - ARM Linux, Detlef Vollmann, Uwe Kleine-König,
Jello huang, git, linux-arm-kernel
In-Reply-To: <4D3D2865.4020408@viscovery.net>
On 01/23/2011 11:21 PM, Johannes Sixt wrote:
> Am 1/21/2011 15:50, schrieb Russell King - ARM Linux:
>> SetEnv GIT_PROJECT_ROOT /var/www/git
>> SetEnv GIT_HTTP_EXPORT_ALL
>> ScriptAlias /git/ /usr/libexec/git-core/git-http-backend/
>>
>> Great. Deciding that it will be http://servername.example.com/git/ is
>> really damned annoying as that's traditionally where gitweb lives,
>> which requires a different script alias.
>> ...
>> I'm really not interested in working out how to bodge this into working
>> along side the existing gitweb setup by adding lots of rewrite rules,...
>
> It has been worked out for you already. It's just a single rule (although
> a bit longish). Look for 'ScriptAliasMatch' in
> http://www.kernel.org/pub/software/scm/git/docs/git-http-backend.html
I was going to say, I have both gitweb and smart http support running in
parallel, it's not terribly complicated. The way I'm doing it is a bit
older (mainly that long ScriptAliasMatch broken out more), but it's
still only 11 lines to the apache config:
# Various environment setup, should be obvious
SetEnv GIT_PROJECT_ROOT /path
SetEnv GIT_HTTP_EXPORT_ALL 1
SetEnv GIT_EXEC_PATH /usr/libexec/git-core/
# Here so that we can do straight wget fetches for the objects files,
# pack files and refs heads.
# This isn't strictly neccisary, but if it's done we can use the inbuilt
# sendfile() of apache for the sending of those files vs. funneling them
# through the CGI
AliasMatch ^/(.*/objects/[0-9a-f]{2}/[0-9a-f]{38})$ /path/$1
AliasMatch ^/(.*/objects/pack/pack-[0-9a-f]{40}.(pack|idx))$ /path/$1
AliasMatch ^/(.*/refs/heads/.*)$ /path/$1
# Meat of how to make this all work
ScriptAliasMatch "^/(.*/HEAD)$"
/usr/libexec/git-core/git-http-backend/path/$1
ScriptAliasMatch "^/(.*/info/refs)$"
/usr/libexec/git-core/git-http-backend/path/$1
ScriptAliasMatch "^/(.*/objects/info/[^/]+)$"
/usr/libexec/git-core/git-http-backend/path/$1
ScriptAliasMatch "^/pub/scm/(.*/git-upload-pack)$"
/usr/libexec/git-core/git-http-backend/path/$1
ScriptAliasMatch "^/pub/scm/(.*/git-receive-pack)$"
/usr/libexec/git-core/git-http-backend/path/$1
Just an example anyway, the paths have been shortened to fit e-mail better.
- John 'Warthog9' Hawley
^ permalink raw reply
* Re: cannot fetch arm git tree
From: Johannes Sixt @ 2011-01-24 7:21 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Detlef Vollmann, Uwe Kleine-König, Jello huang, git,
linux-arm-kernel
In-Reply-To: <20110121145025.GS13235@n2100.arm.linux.org.uk>
Am 1/21/2011 15:50, schrieb Russell King - ARM Linux:
> SetEnv GIT_PROJECT_ROOT /var/www/git
> SetEnv GIT_HTTP_EXPORT_ALL
> ScriptAlias /git/ /usr/libexec/git-core/git-http-backend/
>
> Great. Deciding that it will be http://servername.example.com/git/ is
> really damned annoying as that's traditionally where gitweb lives,
> which requires a different script alias.
> ...
> I'm really not interested in working out how to bodge this into working
> along side the existing gitweb setup by adding lots of rewrite rules,...
It has been worked out for you already. It's just a single rule (although
a bit longish). Look for 'ScriptAliasMatch' in
http://www.kernel.org/pub/software/scm/git/docs/git-http-backend.html
-- Hannes
^ 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