* [PATCH] git rev-parse: Fix --show-cdup inside symlinked directory
From: Petr Baudis @ 2008-07-15 14:59 UTC (permalink / raw)
To: gitster; +Cc: git
In-Reply-To: <1216131208.19334.171.camel@gemini>
Consider the scenario when someone makes a symlink into a working tree
subdirectory at an unrelated place, then attempts to work inside the
symlinked directory. The scenario is a bit unwieldly, but most of
the Git will handle it fine - except git rev-parse --show-cdup. That
will output a sequence of ../ which will work wrong inside the symlink
using shell cd builtin.
This patch changes --show-cdup to always show absolute workdir path
instead. I think this should hopefully cause no compatibility problems;
the testsuite is passing fine, at least. The patch also adds
a --show-cdup check and this particular scenartio to the t1500 test.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
Documentation/git-rev-parse.txt | 4 ++--
builtin-rev-parse.c | 15 +++++----------
t/t1500-rev-parse.sh | 18 ++++++++++++++++--
3 files changed, 23 insertions(+), 14 deletions(-)
diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt
index 088f971..4c289d0 100644
--- a/Documentation/git-rev-parse.txt
+++ b/Documentation/git-rev-parse.txt
@@ -103,8 +103,8 @@ OPTIONS
--show-cdup::
When the command is invoked from a subdirectory, show the
- path of the top-level directory relative to the current
- directory (typically a sequence of "../", or an empty string).
+ path of the top-level directory, or an empty string if the
+ current directory is the top-level directory.
--git-dir::
Show `$GIT_DIR` if defined else show the path to the .git directory.
diff --git a/builtin-rev-parse.c b/builtin-rev-parse.c
index a7860ed..011d16c 100644
--- a/builtin-rev-parse.c
+++ b/builtin-rev-parse.c
@@ -500,22 +500,17 @@ int cmd_rev_parse(int argc, const char **argv, const char *prefix)
continue;
}
if (!strcmp(arg, "--show-cdup")) {
- const char *pfx = prefix;
- if (!is_inside_work_tree()) {
+ if (prefix) {
+ /* We are not at the top level yet */
const char *work_tree =
get_git_work_tree();
if (work_tree)
printf("%s\n", work_tree);
continue;
+ } else {
+ /* Backwards compatibility */
+ putchar('\n');
}
- while (pfx) {
- pfx = strchr(pfx, '/');
- if (pfx) {
- pfx++;
- printf("../");
- }
- }
- putchar('\n');
continue;
}
if (!strcmp(arg, "--git-dir")) {
diff --git a/t/t1500-rev-parse.sh b/t/t1500-rev-parse.sh
index 85da4ca..2f0bf15 100755
--- a/t/t1500-rev-parse.sh
+++ b/t/t1500-rev-parse.sh
@@ -26,9 +26,14 @@ test_rev_parse() {
"test '$1' = \"\$(git rev-parse --show-prefix)\""
shift
[ $# -eq 0 ] && return
+
+ test_expect_success "$name: cdup" \
+ "test '$1' = \"\$(git rev-parse --show-cdup)\""
+ shift
+ [ $# -eq 0 ] && return
}
-# label is-bare is-inside-git is-inside-work prefix
+# label is-bare is-inside-git is-inside-work prefix cdup
test_rev_parse toplevel false false true ''
@@ -38,11 +43,20 @@ cd objects || exit 1
test_rev_parse .git/objects/ false true false ''
cd ../.. || exit 1
+basedir=$(pwd)
mkdir -p sub/dir || exit 1
cd sub/dir || exit 1
-test_rev_parse subdirectory false false true sub/dir/
+test_rev_parse subdirectory false false true sub/dir/ "$basedir"
cd ../.. || exit 1
+# Scenario: Working within a subdirectory symlinked out of the working tree
+mkdir -p maindir || exit 1
+(mv .git maindir && mkdir -p maindir/sub2 && ln -s maindir/sub2 .) || exit 1
+cd sub2 || exit 1
+test_rev_parse 'symlinked subdirectory' false false true sub2/ "$basedir"/maindir
+cd .. || exit 1
+(rm sub2 && mv maindir/.git . && rm -r maindir) || exit 1
+
git config core.bare true
test_rev_parse 'core.bare = true' true false false
^ permalink raw reply related
* Re: git config oddity
From: Johannes Schindelin @ 2008-07-15 15:02 UTC (permalink / raw)
To: sverre; +Cc: Git Mailinglist
In-Reply-To: <bd6139dc0807150744l78eb8d54ld167d3a9a5a600f@mail.gmail.com>
Hi,
On Tue, 15 Jul 2008, Sverre Rabbelier wrote:
> I noticed today that when unsetting the last value in a group git
> config leaves the empty group header.
That is on purpose. As .git/config was always meant as a user-editable
file, you can put comments into that section. Or comment out some values.
So "git config" does not remove the section, even if no variable is there
at the moment.
It is somewhat unfortunate that setting a variable does not find the
section; the reason is that it sees sections only when a variable is set
(to avoid having to do the parsing itself).
Hth,
Dscho
^ permalink raw reply
* Re: Closing the merge window for 1.6.0
From: Dmitry Potapov @ 2008-07-15 15:06 UTC (permalink / raw)
To: Petr Baudis
Cc: Junio C Hamano, Nicolas Pitre, Gerrit Pape, Johannes Schindelin,
git
In-Reply-To: <20080715092023.GO10151@machine.or.cz>
On Tue, Jul 15, 2008 at 11:20:23AM +0200, Petr Baudis wrote:
>
> (iii) Most importantly, this is not about waiting another few
> years for Debian to catch up, since the next stable release
> should really be upcoming rather soon:
>
> http://debian-community.org/LennyReleaseSchedule/
Even if Lenny will be released right on the scheduler (which I seriously
doubt), Etch will be around for another year. In fact, the last release
of oldstable (sarge) happened on April 12 this year. Thus delaying of
indexversion=2 does not help much here. Anyone who is more or less
seriously about using Git grabs it from backports. The downside of
delaying is that any incompatible changes are much less welcome by users
during minor releases than major ones. People tend to read release notes
during major releases more carefully and think whether they prefer new
features or backward compatibility. This choice will not be the same for
anyone, but changing default settings on the major release is much more
appropriate than during minor ones.
>
> (iv) These problems do not concern people who are currently
> _actively_ _working_ with Git; these people hopefully do not
> use 1.4 willingly and already use Git from backports.org.
> This is about user experience for casual users who are quite
> possibly interested only in read-only tracking of upstream
> using Git - these people will likely use default Debian Git
> version and that is okay, because frankly, for them, the
> 1.5 improvements do not really matter much. This is also
> large class of prospective future real Git users and we might
> not want to ruin Git's reputation in their eyes.
I disagree. It is not Git does not support the old format, but it
switches on the new one as default on the next major release, which
is a sensible thing to do. Those repos that think that access for
Git 1.4 users is important for them can set indexformat=1. As to
prospective future real Git users, anyone who is trying to use Git
1.4 is going to hit by many usability issues that were resolved in
1.5; and there is no community support for Git 1.4 either -- you can
ask about any problem with Git 1.4 on this list, and the only answer
you'll get is that you should upgrade your Git. So, there is no way
for newcommers to start using Git 1.4 and be satisfied with it.
Finally, 18 months since 1.4.4 may not appear as a long time ago for
other projects that are being developed for many years, but for Git,
which was only 21 months when Git 1.4.4 was released, 18 months is
really very *long* time ago.
Dmitry
^ permalink raw reply
* Re: [PATCH] git rev-parse: Fix --show-cdup inside symlinked directory
From: Johannes Schindelin @ 2008-07-15 15:19 UTC (permalink / raw)
To: Petr Baudis; +Cc: gitster, git
In-Reply-To: <20080715145920.13529.25603.stgit@localhost>
Hi,
On Tue, 15 Jul 2008, Petr Baudis wrote:
> Consider the scenario when someone makes a symlink into a working tree
> subdirectory at an unrelated place, then attempts to work inside the
> symlinked directory. The scenario is a bit unwieldly, but most of
> the Git will handle it fine - except git rev-parse --show-cdup. That
> will output a sequence of ../ which will work wrong inside the symlink
> using shell cd builtin.
Short version: do not use symlinks in the working directory, if you do not
want to track the _symlink_.
Long version: there are a lot of problems with that, and --show-cdup is
the least of the problems. A checkout, for example, is able to kill the
symlink and check out a fresh copy of the subdirectory.
AFAICT this is a concious decision: If you want to track a symlink, track
a symlink, but if you want to track a subdirectory, you will have to track
a subdirectory, and it cannot be a symlink.
> This patch changes --show-cdup to always show absolute workdir path
> instead. I think this should hopefully cause no compatibility problems;
> the testsuite is passing fine, at least.
See the thread where I proposed a change like this, back with the infamous
worktree desaster, and Junio NACKed; or the thread where Linus rightfully
insists that git_dir should be relative if possible, for performance
reasons.
Hth,
Dscho
^ permalink raw reply
* Re: [PATCH 0/6] archive: refactor and cleanup
From: Junio C Hamano @ 2008-07-15 15:21 UTC (permalink / raw)
To: René Scharfe; +Cc: git
In-Reply-To: <487C568F.6030705@lsrfire.ath.cx>
René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
> Lea Wiemann schrieb:
> ...
>> Feel free to ping me on IRC (lea_w in #git) if you need help.
>
> I've slacked long enough to become a complete noob again. Oh, well.
Lol ;-)
The series looks good. Thanks.
^ permalink raw reply
* Re: [PATCH] git-rebase.sh: Display error output from git-checkout when detaching HEAD fails.
From: Junio C Hamano @ 2008-07-15 15:22 UTC (permalink / raw)
To: Rob Shearman; +Cc: git
In-Reply-To: <1096648c0807141257i76f70322p5a16c86c1c826a66@mail.gmail.com>
"Rob Shearman" <robertshearman@gmail.com> writes:
> 2008/7/11 Junio C Hamano <gitster@pobox.com>:
> ...
>> I think this very much is done deliberately by somebody who knows the
>> shell to discard everything.
>
> Why wasn't "git checkout "$onto^0" &> /dev/null" used then? Then only
> reason I can come up with would be portability,...
Yes, we are quite old fashioned when it comes to shell scripting.
>> ... Perhaps you can replace the line with
>>
>> git checkout -q "$onto^0"
>>
>> and be done with it. I haven't tested it, though.
>
> I just tested it and it solves the original issue whilst not
> displaying unnecessary messages during a rebase. For reference, the
> attached script reproduces the issue that I was trying to solve.
>
> Should I resend the patch (like the following) now that it is
> effectively completely your work?
Your choice.
The issues you might want to consider when making that choice are:
- Resending something that is trivial may seem waste of time on your
part;
- Bringing the issue up is more than half of solving it, and you deserve
the credit. By resending with a clear commit log message you assure
this;
- I am handling many patches for git.git that are readily applicable
immediately after I read them in my mbox, while creating a commit out
of this discussion is something I need to "work on". When I get around
to do some git work tonight, I may not even recall this dialogue, and
the solution may be forgotten.
- I am lazy and may forget to pass --author="Rob Shearman <your@email>"
even if I remember this conversation and when I make a commit myself;
I just made a commit out of this discussion before I forget, so no need to
resend for this one, but in general I'd appreciate a resend in general ;-)
-- >8 --
From: Junio C Hamano <gitster@pobox.com>
Date: Mon, 14 Jul 2008 14:05:35 -0700
Subject: [PATCH] git-rebase: report checkout failure
When detaching the HEAD to the base commit, the "git checkout" command
could fail if, for example, upstream contains a file that would overrwrite
a local, untracked file. Unconditionally discarding the standard error
stream was done to squelch the progress and notices back when checkout
did not have -q option, but there is no reason to keep doing it anymore.
Noticed by Robert Shearman.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
git-rebase.sh | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/git-rebase.sh b/git-rebase.sh
index e2d85ee..7825f88 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -376,9 +376,7 @@ fi
# Detach HEAD and reset the tree
echo "First, rewinding head to replay your work on top of it..."
-git checkout "$onto^0" >/dev/null 2>&1 ||
- die "could not detach HEAD"
-# git reset --hard "$onto^0"
+git checkout -q "$onto^0" || die "could not detach HEAD"
# If the $onto is a proper descendant of the tip of the branch, then
# we just fast forwarded.
--
1.5.6.3.473.gc658e
^ permalink raw reply related
* Re: Closing the merge window for 1.6.0
From: Johannes Schindelin @ 2008-07-15 15:27 UTC (permalink / raw)
To: Dmitry Potapov
Cc: Petr Baudis, Junio C Hamano, Nicolas Pitre, Gerrit Pape, git
In-Reply-To: <20080715150626.GA2925@dpotapov.dyndns.org>
Hi,
On Tue, 15 Jul 2008, Dmitry Potapov wrote:
> Those repos that think that access for Git 1.4 users is important for
> them can set indexformat=1.
Unfortunately, you place quite a high maintenance burden on the repository
maintainers here.
>From the time balance sheet, it does not look good at all: a few minutes
for Junio to change and commit, up to a few hours (because they missed it
in the release notes) for probably more than hundred repository
maintainers that are not subscribed to the Git mailing list.
And I absolutely agree with Pasky that this does _nothing_ in the vague
direction of wielding a reputation of being easy to use.
Sure, we can make it easy on ourselves. And it is just as easy to make it
hard on others. If you're okay with that, I am not.
Ciao,
Dscho
^ permalink raw reply
* Re: git config oddity
From: Sverre Rabbelier @ 2008-07-15 15:29 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailinglist
In-Reply-To: <alpine.DEB.1.00.0807151600170.8950@racer>
On Tue, Jul 15, 2008 at 5:02 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
>> I noticed today that when unsetting the last value in a group git
>> config leaves the empty group header.
>
> That is on purpose. As .git/config was always meant as a user-editable
> file, you can put comments into that section. Or comment out some values.
Ok, this makes sense :). I agree that I would be unhappily surprised
if I found that git removed a section that I had put some comments in
when I unset a variable.
> It is somewhat unfortunate that setting a variable does not find the
> section; the reason is that it sees sections only when a variable is set
> (to avoid having to do the parsing itself).
Ah, unfortunate indeed. I'm not sure I understand why it does not see
the existing header? I had a look at config.c but I couldn't really
make out why it doesn't. Would it be difficult to add that?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: git config oddity
From: Johannes Schindelin @ 2008-07-15 15:33 UTC (permalink / raw)
To: sverre; +Cc: Git Mailinglist
In-Reply-To: <bd6139dc0807150829n2b3c88d7p18c203e93cd4e0c1@mail.gmail.com>
Hi,
On Tue, 15 Jul 2008, Sverre Rabbelier wrote:
> On Tue, Jul 15, 2008 at 5:02 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
>
> > It is somewhat unfortunate that setting a variable does not find the
> > section; the reason is that it sees sections only when a variable is
> > set (to avoid having to do the parsing itself).
>
> Ah, unfortunate indeed. I'm not sure I understand why it does not see
> the existing header? I had a look at config.c but I couldn't really make
> out why it doesn't.
The config writing uses the config parser to determine where the locations
of the config variables (and therefore, sections) are by using the parser,
and remembering the position in the file.
> Would it be difficult to add that?
Yes.
Ciao,
Dscho
^ permalink raw reply
* Re: git config oddity
From: Sverre Rabbelier @ 2008-07-15 15:35 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailinglist
In-Reply-To: <alpine.DEB.1.00.0807151631520.8950@racer>
On Tue, Jul 15, 2008 at 5:33 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> The config writing uses the config parser to determine where the locations
> of the config variables (and therefore, sections) are by using the parser,
> and remembering the position in the file.
Ok, thanks for the explanation, I'll add a workaround in my code.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* --username wrong or ignored for git-svn
From: Stephen Sinclair @ 2008-07-15 15:37 UTC (permalink / raw)
To: Git Mailing List
Hello,
Just now I attempted to commit some changes that a coworker had made
to our subversion repository using git-svn. Since it was his work, we
attempted to commit it using his username, though it was done in a git
repository that I'd previously used with my username. So I did:
git-svn dcommit --username <name>
But it ignored --username and the commit is now attributed to me.
Is it because I'd previously done dcommit in my own username?
There was no warning that it wouldn't do what I expected.
Admittedly it's was a weird thing to have him make a change in my
local repository but we didn't think it would be a problem if we
carefully used --username.
thanks,
Steve
^ permalink raw reply
* Re: [PATCH] git rev-parse: Fix --show-cdup inside symlinked directory
From: Petr Baudis @ 2008-07-15 15:40 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: gitster, git, yves.orton
In-Reply-To: <alpine.DEB.1.00.0807151614510.8950@racer>
Hi,
On Tue, Jul 15, 2008 at 04:19:30PM +0100, Johannes Schindelin wrote:
> On Tue, 15 Jul 2008, Petr Baudis wrote:
>
> > Consider the scenario when someone makes a symlink into a working tree
> > subdirectory at an unrelated place, then attempts to work inside the
> > symlinked directory. The scenario is a bit unwieldly, but most of
> > the Git will handle it fine - except git rev-parse --show-cdup. That
> > will output a sequence of ../ which will work wrong inside the symlink
> > using shell cd builtin.
>
> Short version: do not use symlinks in the working directory, if you do not
> want to track the _symlink_.
>
> Long version: there are a lot of problems with that, and --show-cdup is
> the least of the problems. A checkout, for example, is able to kill the
> symlink and check out a fresh copy of the subdirectory.
>
> AFAICT this is a concious decision: If you want to track a symlink, track
> a symlink, but if you want to track a subdirectory, you will have to track
> a subdirectory, and it cannot be a symlink.
no, no, this is for the scenario other way around: you have a normal
subdirectory in the working tree, and point a symlink _at_ it from
$somewhere_else. Then you try to work in $somewhere_else/symlink.
> > This patch changes --show-cdup to always show absolute workdir path
> > instead. I think this should hopefully cause no compatibility problems;
> > the testsuite is passing fine, at least.
>
> See the thread where I proposed a change like this, back with the infamous
> worktree desaster, and Junio NACKed; or the thread where Linus rightfully
> insists that git_dir should be relative if possible, for performance
> reasons.
I see, <7vk5sly3h9.fsf@assigned-by-dhcp.cox.net>. But noone was aware
of this possible user case. Performance reasons sound reasonable, though
I'm not really sure if for cdup in particular this ever matters.
P.S.: Either way, there is a possible workaround to tell git about the
working directory manually using git --work-tree=... that I missed to
mention on IRC, Yves.
--
Petr "Pasky" Baudis
GNU, n. An animal of South Africa, which in its domesticated state
resembles a horse, a buffalo and a stag. In its wild condition it is
something like a thunderbolt, an earthquake and a cyclone. -- A. Pierce
^ permalink raw reply
* Re: Closing the merge window for 1.6.0
From: Avery Pennarun @ 2008-07-15 15:51 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Dmitry Potapov, Petr Baudis, Junio C Hamano, Nicolas Pitre,
Gerrit Pape, git
In-Reply-To: <alpine.DEB.1.00.0807151623120.8950@racer>
On 7/15/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Tue, 15 Jul 2008, Dmitry Potapov wrote:
> > Those repos that think that access for Git 1.4 users is important for
> > them can set indexformat=1.
>
> Unfortunately, you place quite a high maintenance burden on the repository
> maintainers here.
>
> From the time balance sheet, it does not look good at all: a few minutes
> for Junio to change and commit, up to a few hours (because they missed it
> in the release notes) for probably more than hundred repository
> maintainers that are not subscribed to the Git mailing list.
To take this in a slightly different direction, what exactly is the
benefit of the new feature? Apparently my git doesn't have it enabled
by default, and git works fine for me. Am I missing out on something
that I should feel inferior about if my non-debian-etch running
friends(*) found out about it? :)
Have fun,
Avery
(*) Actually I compile my own git from source anyway. I never want to
live without "git rebase -i" and "git add -p" ever again. Life is too
short! :)
^ permalink raw reply
* Re: Increased maintainer work during Summer of Code
From: Junio C Hamano @ 2008-07-15 15:52 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Christian Couder, Daniel Barkalow, Johannes Schindelin, J.H.,
Sam Vilain, git
In-Reply-To: <20080715060427.GB3337@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Junio, I know you have been working extra hard lately with the
> merge of builtin merge, and now gitweb and the sequencer are also
> being looked at in much greater detail.
I do not currently perceive much problem. If they are being looked at in
much greater detail, that is good.
> What can we do to smooth out this workload better? Its awesome
> that we were so fortunate to get these great students this year,
> and have so much contributed in so little time, but we also do
> not want to see maintainer burn-out. We also want to avoid a
> huge backlog of patches.
For GSoC participants, it might be of utmost importance that their patches
are looked at, reviewed and integrated. To me, there is no reason to give
any preferential treatment for GSoC students. Students may need to learn
how to cope with busy, overloaded, and/or grumpy maintainer. It is a
necessary skill to work effectively in an open source project they need to
acquire.
When there are more urgent issues than their projects, patches from GSoC
students may drop through the crack in the floor just like any other
submitters', and more importantly, the urgency is determined solely by
judging how important the issue is for git.git project, not GSoC. Usually
when patches are dropped, its the original submitters job to remind,
resend, or make it easier for the maintainer to take any corrective
measure (e.g. host her own tree to be pulled from) --- GSoC students
should learn to do the same, and their mentors would help them with this.
The community has matured to the point that there are a few areas with
trustworthy area experts, and I do not have to look at certain patches
very deeply myself. To name only a few, I just apply patches to git-svn
that are either from Eric or acked by him without looking at them (I may
spot obvious typos by accident and fix them up, though); patches to
"archive" from René are the same way.
People can help widen areas that are covered like so. I admit that I am
hesitant to let go of certain areas, e.g. sha1_file.c layer, even though I
know Nico and you are as competent and knowledgeable in that area as I am
if not more, simply because such a very core part of the system really
matters. I expect there will always be areas in which I have to look at
all changes for my own peace of mind, but even in these areas I do not
have to be the only person to look at and review the patches.
^ permalink raw reply
* Re: Closing the merge window for 1.6.0
From: Nicolas Pitre @ 2008-07-15 16:26 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Dmitry Potapov, Petr Baudis, Junio C Hamano, Gerrit Pape, git
In-Reply-To: <alpine.DEB.1.00.0807151623120.8950@racer>
On Tue, 15 Jul 2008, Johannes Schindelin wrote:
> And I absolutely agree with Pasky that this does _nothing_ in the vague
> direction of wielding a reputation of being easy to use.
Staying with git versions prior 1.5 isn't either. In fact, git had a
much harder time with its usability reputation in those days. In other
words, if some user of Debian is rebutted by the upgrade path for a later
git version, then the awkwardness of git 1.4.4 UI will be even worse.
Anyway this is all hand waving until someone can come with some evidence
that git 1.4.4 is actually used by a significant amount of people, and
that those people depend on dumb transfer protocols.
Nicolas
^ permalink raw reply
* Re: [PATCH] git rev-parse: Fix --show-cdup inside symlinked directory
From: Yves Orton @ 2008-07-15 16:41 UTC (permalink / raw)
To: Petr Baudis; +Cc: Johannes Schindelin, gitster, git
In-Reply-To: <20080715154036.GR10151@machine.or.cz>
On Tue, 2008-07-15 at 17:40 +0200, Petr Baudis wrote:
> no, no, this is for the scenario other way around: you have a normal
> subdirectory in the working tree, and point a symlink _at_ it from
> $somewhere_else. Then you try to work in $somewhere_else/symlink.
Yes correct. We have a number of different repositories like so:
banana.git/apps
banana.git/lib
orange.git/config
kiwi.git/refdata
and its convenient for many of our existing apps to be able to symlink
them all together into a common tree
joined/apps -> banana.git/apps
joined/lib -> banana.git/lib
joined/config -> orange.git/config
joined/refdata -> kiwi.git/refdata
this way for instance we can swap bits around easily on the fly and say,
restart a webserver or whatever.
Currently we can do this and all our other stuff works, and you
can /mostly/ work with git from the "joined" tree, with the exception of
git pull --rebase and apparently anything else that relies on
--show-cdup
> > > This patch changes --show-cdup to always show absolute workdir path
> > > instead. I think this should hopefully cause no compatibility problems;
> > > the testsuite is passing fine, at least.
> >
> > See the thread where I proposed a change like this, back with the infamous
> > worktree desaster, and Junio NACKed; or the thread where Linus rightfully
> > insists that git_dir should be relative if possible, for performance
> > reasons.
>
> I see, <7vk5sly3h9.fsf@assigned-by-dhcp.cox.net>. But noone was aware
> of this possible user case. Performance reasons sound reasonable, though
> I'm not really sure if for cdup in particular this ever matters.
Would it be so bad to detect if the show-cdup actually resolves to the
right place, and if it doesnt go absolute?
>
> P.S.: Either way, there is a possible workaround to tell git about the
> working directory manually using git --work-tree=... that I missed to
> mention on IRC, Yves.
Hmm, am i using it wrong then?
[dmq@somewhere apps]$ git-rev-parse --git-dir
/home/dmq/git_tree/main/.git
[dmq@somewhere apps]$ git --work-tree="$(git-rev-parse --git-dir)" pull
--rebase
/usr/bin/git-sh-setup: line 139: cd: .git: No such file or directory
Unable to determine absolute path of git directory
cheers,
yves
ps: not on list, please cc me on replies (sorry for the hassle)
^ permalink raw reply
* Re: Closing the merge window for 1.6.0
From: Sverre Rabbelier @ 2008-07-15 16:46 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Johannes Schindelin, Dmitry Potapov, Petr Baudis, Junio C Hamano,
Gerrit Pape, git
In-Reply-To: <alpine.LFD.1.10.0807151213000.12484@xanadu.home>
On Tue, Jul 15, 2008 at 6:26 PM, Nicolas Pitre <nico@cam.org> wrote:
> Anyway this is all hand waving until someone can come with some evidence
> that git 1.4.4 is actually used by a significant amount of people, and
> that those people depend on dumb transfer protocols.
Can't we add a msg to 1.4.4.x when it finds pack version 2 to upgrade
to 1.5.x? Gets rid of the problem all together while still giving the
user a reasonable message when it finds a repo version 2.
Hey, here's an idea, can't we have 1.4.4.x just give that msg for everything?
$cat git
#!/bin/sh
echo "Please upgrade to 1.5.x, version 1.4.x is no longer supported
nor should you even want to use it </cluebat>"
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Geoffrey Irving @ 2008-07-15 16:48 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0807151117450.3487@eeepc-johanness>
On Tue, Jul 15, 2008 at 2:22 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Mon, 14 Jul 2008, Geoffrey Irving wrote:
>
>> The problem (beyond the basic problem of me not having tried running the
>> tests) is that the current caching code isn't taking into account the
>> changing values of diff_options. t6007 computes a patch-id for a commit
>> with one value of options.paths, and then tries to compute a _different_
>> patch-id for the same commit using a different value of options.paths.
>>
>> Here are a few different ways of fixing this:
>>
>> 1. Modify commit_patch_id in patch-ids.c to compute a sha1 of the
>> diff_options structure and xor it with the commit sha1 to get a truly
>> unique hash of the input. This means the optimization can be safely
>> applied for all patch-id computations regardless of the diff_options.
>> I can add a diff_options_sha1 function in diff.[ch] to compute the
>> checksum.
>>
>> 2. Restrict commit_patch_id in patch-ids.c to apply the optimization
>> only if options.nr_paths is zero, and perhaps a few other conditions.
>> This is rather fragile, since it would mean that the cache would
>> break if someone decided to change the default diff options.
>
> Funnily, (2) contradicts (1). The patch id is _different_ when you have
> nr_paths > 0. At least in the general case.
>
> So what you propose in (1) will not work, unless you also hash the path
> names (in the correct order, otherwise you'll end up with two hashes).
The sha1 would include paths, of course, since it's part of diff_options.
> OTOH I would be really surprised if you needed --cherry-pick with paths
> and/or diff options more than once for the same commits. So the caching
> does not make sense to begin with (especially since we do not have a
> proper way of gc'ing it, right?).
>
> So I'd suggest saving diff_opts before the command line parsing, and
> disable the cache when it is different _and/or_ (||) nr_paths.
I'll attach the patch to the other thread.
Geoffrey
^ permalink raw reply
* [PATCH] cherry: cache patch-ids to avoid repeating work
From: Geoffrey Irving @ 2008-07-15 16:57 UTC (permalink / raw)
To: Junio C Hamano, git@vger.kernel.org; +Cc: Johannes Schindelin
In-Reply-To: <7f9d599f0807122014y5190463j62d106a01bf31c86@mail.gmail.com>
Add cached-sha-map.[ch] implementing a persistent hash map from sha1 to
sha1. The map is read with mmap, and completely rewritten if any entries
change. It would be good to add incremental update to handle the usual case
where only a few entries change.
This structure is used by patch-ids.c to cache the mapping from commit to
patch-id into $GIT_DIR/patch-id-cache. In the one case I've tested so far,
this speeds up the second invocation of git-cherry by two orders of
magnitude. The caching can be disabled by setting cherry.cachepatchids to
false. Only patch-ids with default diff options are cached.
Original code cannibalized from Johannes Schindelin's notes-index structure.
Signed-off-by: Geoffrey Irving <irving@naml.us>
---
Here's a version of the patch fixing the test breakage. Only
patch-ids.c differs from the previous version.
Documentation/config.txt | 5 +
Makefile | 2 +
builtin-log.c | 12 ++
cached-sha1-map.c | 293 ++++++++++++++++++++++++++++++++++++++++++++++
cached-sha1-map.h | 45 +++++++
patch-ids.c | 40 ++++++-
patch-ids.h | 2 +
7 files changed, 398 insertions(+), 1 deletions(-)
create mode 100644 cached-sha1-map.c
create mode 100644 cached-sha1-map.h
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 838794d..02b8113 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -468,6 +468,11 @@ browser.<tool>.path::
browse HTML help (see '-w' option in linkgit:git-help[1]) or a
working repository in gitweb (see linkgit:git-instaweb[1]).
+cherry.cachepatchids::
+ If true, linkgit:git-cherry will store a cache of computed patch-ids
+ in $GIT_DIR/patch-id-cache in order to make repeated invocations faster.
+ Defaults to true.
+
clean.requireForce::
A boolean to make git-clean do nothing unless given -f
or -n. Defaults to true.
diff --git a/Makefile b/Makefile
index 4796565..f7360e1 100644
--- a/Makefile
+++ b/Makefile
@@ -356,6 +356,7 @@ LIB_H += pack-refs.h
LIB_H += pack-revindex.h
LIB_H += parse-options.h
LIB_H += patch-ids.h
+LIB_H += cached-sha1-map.h
LIB_H += path-list.h
LIB_H += pkt-line.h
LIB_H += progress.h
@@ -436,6 +437,7 @@ LIB_OBJS += pager.o
LIB_OBJS += parse-options.o
LIB_OBJS += patch-delta.o
LIB_OBJS += patch-ids.o
+LIB_OBJS += cached-sha1-map.o
LIB_OBJS += path-list.o
LIB_OBJS += path.o
LIB_OBJS += pkt-line.o
diff --git a/builtin-log.c b/builtin-log.c
index 430d876..fbfefbd 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -1081,6 +1081,16 @@ static int add_pending_commit(const char *arg,
struct rev_info *revs, int flags)
return -1;
}
+static int git_cherry_config(const char *var, const char *value, void *cb)
+{
+ if (!strcmp(var, "cherry.cachepatchids")) {
+ cache_patch_ids = git_config_bool(var, value);
+ return 0;
+ }
+
+ return 0;
+}
+
static const char cherry_usage[] =
"git-cherry [-v] <upstream> [<head>] [<limit>]";
int cmd_cherry(int argc, const char **argv, const char *prefix)
@@ -1094,6 +1104,8 @@ int cmd_cherry(int argc, const char **argv,
const char *prefix)
const char *limit = NULL;
int verbose = 0;
+ git_config(git_cherry_config, NULL);
+
if (argc > 1 && !strcmp(argv[1], "-v")) {
verbose = 1;
argc--;
diff --git a/cached-sha1-map.c b/cached-sha1-map.c
new file mode 100644
index 0000000..9cf7252
--- /dev/null
+++ b/cached-sha1-map.c
@@ -0,0 +1,293 @@
+#include "cached-sha1-map.h"
+
+union cached_sha1_map_header {
+ struct {
+ char signature[4]; /* CS1M */
+ uint32_t version;
+ uint32_t count;
+ uint32_t size;
+ uint32_t pad; /* pad to 20 bytes */
+ } u;
+ /* pad header out to 40 bytes. As a consistency
+ * check, pad.value stores the sha1 of pad.key. */
+ struct cached_sha1_entry pad;
+};
+
+static const char *signature = "CS1M";
+static const uint32_t version = 1;
+
+static int init_empty_map(struct cached_sha1_map *cache, uint32_t size)
+{
+ cache->count = 0;
+ cache->size = size;
+ cache->initialized = 1;
+ cache->mmapped = 0;
+ cache->dirty = 1;
+
+ cache->entries = calloc(size, sizeof(struct cached_sha1_entry));
+ if (!cache->entries) {
+ warning("failed to allocate empty map of size %"PRIu32" for %s",
+ size, git_path(cache->filename));
+ cache->size = 0;
+ cache->dirty = 0;
+ return -1;
+ }
+ return 0;
+}
+
+static int grow_map(struct cached_sha1_map *cache)
+{
+ struct cached_sha1_map new_cache;
+ uint32_t i;
+
+ if (cache->size * 2 == 0) {
+ warning("%s overflowed, so resetting to empty",
+ git_path(cache->filename));
+ return init_empty_map(cache, 64);
+ }
+
+ /* allocate cache with twice the size */
+ new_cache.filename = cache->filename;
+ if (init_empty_map(&new_cache, cache->size * 2)) {
+ warning("failed to grow %s to size %"PRIu32,
+ git_path(cache->filename), cache->size * 2);
+ return init_empty_map(cache, 64);
+ }
+
+ /* reinsert all entries */
+ for (i = 0; i < cache->size; i++)
+ if (!is_null_sha1(cache->entries[i].key))
+ set_cached_sha1_entry(&new_cache,
+ cache->entries[i].key, cache->entries[i].value);
+ /* finish */
+ free_cached_sha1_map(cache);
+ *cache = new_cache;
+ return 0;
+}
+
+/* Any errors that occur result in the cache being initialized to empty */
+static int init_cached_sha1_map(struct cached_sha1_map *cache)
+{
+ int fd;
+ union cached_sha1_map_header header;
+ const char *filename;
+ size_t map_size;
+ SHA_CTX ctx;
+
+ if (cache->initialized)
+ return cache->size ? 0 : -1;
+
+ filename = git_path(cache->filename);
+ fd = open(filename, O_RDONLY);
+ if (fd < 0) {
+ if (errno != ENOENT)
+ warning("failed to read '%s': %s", filename,
+ strerror(errno));
+ goto empty;
+ }
+
+ if (read_in_full(fd, &header, sizeof(header)) != sizeof(header)) {
+ warning("cannot read %s header", filename);
+ goto empty;
+ }
+
+ if (memcmp(header.u.signature, signature, 4)) {
+ warning("%s has invalid header", filename);
+ goto empty;
+ }
+
+ if (ntohl(header.u.version) != version) {
+ warning("%s has unrecognized version %"PRIu32, filename,
+ ntohl(header.u.version));
+ goto empty;
+ }
+
+ cache->count = ntohl(header.u.count);
+ cache->size = ntohl(header.u.size);
+
+ if (cache->size & (cache->size-1)) {
+ warning("%s is corrupt: size %"PRIu32" is not a power of two",
+ filename, cache->size);
+ goto empty;
+ }
+
+ if (cache->count >= cache->size) {
+ warning("%s is corrupt: count %"PRIu32" >= size %"PRIu32,
+ filename, cache->count, cache->size);
+ goto empty;
+ }
+
+ SHA1_Init(&ctx);
+ SHA1_Update(&ctx, header.pad.key, 20);
+ SHA1_Final(header.pad.key, &ctx); /* reuse pad.key to store its sha1 */
+ if (hashcmp(header.pad.key, header.pad.value)) {
+ warning("%s header has invalid sha1", filename);
+ goto empty;
+ }
+
+ cache->dirty = 0;
+ cache->initialized = 1;
+ cache->mmapped = 1;
+
+ /* mmap entire file so that file / memory blocks are aligned */
+ map_size = sizeof(struct cached_sha1_entry) * (cache->size + 1);
+ cache->entries = mmap(NULL, map_size,
+ PROT_READ | PROT_WRITE, MAP_PRIVATE, fd, 0);
+ if (cache->entries == MAP_FAILED) {
+ /* this is just a cache, so don't free pack memory and retry */
+ warning("%s mmap failed: %s", filename, strerror(errno));
+ goto empty;
+ }
+ cache->entries += 1; /* skip header */
+ return 0;
+
+empty:
+ if (fd >= 0)
+ close(fd);
+ return init_empty_map(cache, 64);
+}
+
+int write_cached_sha1_map(struct cached_sha1_map *cache)
+{
+ union cached_sha1_map_header header;
+ struct lock_file update_lock;
+ int fd;
+ size_t map_size;
+ const char *filename;
+ SHA_CTX ctx;
+
+ if (!cache->initialized || !cache->dirty)
+ return 0;
+
+ filename = git_path(cache->filename);
+ fd = hold_lock_file_for_update(&update_lock, filename, 0);
+
+ if (fd < 0)
+ {
+ warning("could not construct %s", filename);
+ return -1;
+ }
+
+ /* initialize header */
+ memcpy(header.u.signature, signature, 4);
+ header.u.version = htonl(version);
+ header.u.count = htonl(cache->count);
+ header.u.size = htonl(cache->size);
+ header.u.pad = 0; /* make header deterministic */
+
+ /* compute header sha1 */
+ SHA1_Init(&ctx);
+ SHA1_Update(&ctx, header.pad.key, 20);
+ SHA1_Final(header.pad.value, &ctx);
+
+ map_size = sizeof(struct cached_sha1_entry) * cache->size;
+ if (write_in_full(fd, &header, sizeof(header)) != sizeof(header)
+ || write_in_full(fd, cache->entries, map_size) != map_size)
+ {
+ warning("could not write %s", filename);
+ return -1;
+ }
+
+ if (commit_lock_file(&update_lock) < 0)
+ {
+ warning("could not write %s", filename);
+ return -1;
+ }
+
+ cache->dirty = 0;
+ return 0;
+}
+
+void free_cached_sha1_map(struct cached_sha1_map *cache)
+{
+ if (!cache->initialized)
+ return;
+
+ if (cache->mmapped)
+ munmap(cache->entries - 1,
+ sizeof(struct cached_sha1_entry) * (cache->size + 1));
+ else
+ free(cache->entries);
+}
+
+/* The fact that size is a power of two means count-1 <= INT32_MAX, so it
+ * is safe to return signed integers here. */
+static int32_t get_hash_index(const unsigned char *sha1)
+{
+ /* this is alignment safe since 40 is a multiple of 4 */
+ return ntohl(*(uint32_t*)sha1);
+}
+
+/*
+ * Returns the index if the entry exists, and the complemented index of
+ * the next free entry otherwise. If the hash is full, returns the
+ * complement of a nonfree entry and sets count = size (this happens
+ * only if the file is corrupt).
+ */
+static int32_t find_helper(struct cached_sha1_map *cache,
+ const unsigned char *key)
+{
+ int32_t i, mask, full;
+
+ mask = cache->size - 1;
+ i = get_hash_index(key) & mask;
+ full = (i-1) & mask;
+
+ for (; ; i = (i+1) & mask) {
+ if (!hashcmp(key, cache->entries[i].key))
+ return i;
+ else if (is_null_sha1(cache->entries[i].key) || i == full)
+ return ~i;
+ if (i == full) {
+ cache->count = cache->size; /* fix count */
+ return ~1;
+ }
+ }
+}
+
+int get_cached_sha1_entry(struct cached_sha1_map *cache,
+ const unsigned char *key, unsigned char *value)
+{
+ int32_t i;
+
+ if (init_cached_sha1_map(cache))
+ return -1;
+
+ i = find_helper(cache, key);
+ if(i < 0)
+ return -1;
+
+ /* entry found, return value */
+ hashcpy(value, cache->entries[i].value);
+ return 0;
+}
+
+int set_cached_sha1_entry(struct cached_sha1_map *cache,
+ const unsigned char *key, const unsigned char *value)
+{
+ int32_t i;
+ struct cached_sha1_entry *entry;
+
+ if (init_cached_sha1_map(cache))
+ return -1;
+
+ i = find_helper(cache, key);
+
+ if (i < 0) { /* write new entry */
+ entry = cache->entries + ~i;
+ hashcpy(entry->key, key);
+ hashcpy(entry->value, value);
+ cache->count++;
+ cache->dirty = 1;
+ } else { /* overwrite existing entry */
+ entry = cache->entries + i;
+ if (hashcmp(value, entry->value)) {
+ hashcpy(entry->value, value);
+ cache->dirty = 1;
+ }
+ }
+
+ if (cache->count >= cache->size/4*3)
+ return grow_map(cache);
+ return 0;
+}
diff --git a/cached-sha1-map.h b/cached-sha1-map.h
new file mode 100644
index 0000000..296c17c
--- /dev/null
+++ b/cached-sha1-map.h
@@ -0,0 +1,45 @@
+#ifndef CACHED_SHA1_MAP_H
+#define CACHED_SHA1_MAP_H
+
+#include "cache.h"
+
+/*
+ * A cached-sha1-map is a file storing a hash map from sha1 to sha1.
+ *
+ * The file is mmap'ed, updated in memory during operation, and flushed
+ * back to disk when freed. Currently the entire file is rewritten for
+ * any change. This could be a significant bottleneck for common uses,
+ * so it would be good to fix this later if possible.
+ *
+ * The performance of a hash map depends highly on a good hashing
+ * algorithm, to avoid collisions. Lucky us! SHA-1 is a pretty good
+ * hashing algorithm.
+ */
+
+struct cached_sha1_entry {
+ unsigned char key[20];
+ unsigned char value[20];
+};
+
+struct cached_sha1_map {
+ const char *filename; /* relative to GIT_DIR */
+
+ /* rest is for internal use */
+ uint32_t count, size;
+ unsigned int initialized : 1;
+ unsigned int dirty : 1;
+ unsigned int mmapped : 1;
+ struct cached_sha1_entry *entries; /* pointer to mmap'ed memory + 1 */
+};
+
+extern int get_cached_sha1_entry(struct cached_sha1_map *cache,
+ const unsigned char *key,unsigned char *value);
+
+extern int set_cached_sha1_entry(struct cached_sha1_map *cache,
+ const unsigned char *key, const unsigned char *value);
+
+extern int write_cached_sha1_map(struct cached_sha1_map *cache);
+
+extern void free_cached_sha1_map(struct cached_sha1_map *cache);
+
+#endif
diff --git a/patch-ids.c b/patch-ids.c
index 3be5d31..5ba12fb 100644
--- a/patch-ids.c
+++ b/patch-ids.c
@@ -2,17 +2,49 @@
#include "diff.h"
#include "commit.h"
#include "patch-ids.h"
+#include "cached-sha1-map.h"
+
+int cache_patch_ids = 1;
+static struct cached_sha1_map patch_id_cache;
+
+static struct diff_options default_options;
+#define IGNORED_DIFF_OPTS (DIFF_OPT_HAS_CHANGES | DIFF_OPT_CHECK_FAILED)
static int commit_patch_id(struct commit *commit, struct diff_options *options,
unsigned char *sha1)
{
+ int use_cache = 0;
+ int ret;
+
+ /* only cache if diff options are defaults */
+ if (cache_patch_ids) {
+ default_options.found_changes = options->found_changes;
+ default_options.flags = (options->flags & IGNORED_DIFF_OPTS)
+ | (default_options.flags & ~IGNORED_DIFF_OPTS);
+ use_cache = !memcmp(options, &default_options,
+ sizeof(struct diff_options));
+ }
+
+ /* pull patch-id out of the cache if possible */
+ patch_id_cache.filename = "patch-id-cache";
+ if (use_cache && !get_cached_sha1_entry(&patch_id_cache,
+ commit->object.sha1, sha1))
+ return 0;
+
if (commit->parents)
diff_tree_sha1(commit->parents->item->object.sha1,
commit->object.sha1, "", options);
else
diff_root_tree_sha1(commit->object.sha1, "", options);
diffcore_std(options);
- return diff_flush_patch_id(options, sha1);
+ ret = diff_flush_patch_id(options, sha1);
+ if (ret)
+ return ret;
+
+ /* record commit, patch-id pair in cache */
+ if (use_cache)
+ set_cached_sha1_entry(&patch_id_cache, commit->object.sha1, sha1);
+ return 0;
}
static uint32_t take2(const unsigned char *id)
@@ -124,6 +156,7 @@ int init_patch_ids(struct patch_ids *ids)
DIFF_OPT_SET(&ids->diffopts, RECURSIVE);
if (diff_setup_done(&ids->diffopts) < 0)
return error("diff_setup_done failed");
+ default_options = ids->diffopts; /* remember defaults */
return 0;
}
@@ -136,6 +169,11 @@ int free_patch_ids(struct patch_ids *ids)
next = patches->next;
free(patches);
}
+
+ /* write cached patch-ids and ignore any errors that arise
+ * (e.g. if the repository is write protected) */
+ if (cache_patch_ids)
+ write_cached_sha1_map(&patch_id_cache);
return 0;
}
diff --git a/patch-ids.h b/patch-ids.h
index c8c7ca1..c0ebdc1 100644
--- a/patch-ids.h
+++ b/patch-ids.h
@@ -18,4 +18,6 @@ int free_patch_ids(struct patch_ids *);
struct patch_id *add_commit_patch_id(struct commit *, struct patch_ids *);
struct patch_id *has_commit_patch_id(struct commit *, struct patch_ids *);
+extern int cache_patch_ids;
+
#endif /* PATCH_IDS_H */
--
1.5.6.2.256.g3ef05.dirty
^ permalink raw reply related
* Re: [PATCH] git rev-parse: Fix --show-cdup inside symlinked directory
From: Yves Orton @ 2008-07-15 16:58 UTC (permalink / raw)
To: Petr Baudis; +Cc: Johannes Schindelin, gitster, git
In-Reply-To: <1216140100.19334.189.camel@gemini>
On Tue, 2008-07-15 at 18:41 +0200, Yves Orton wrote:
> On Tue, 2008-07-15 at 17:40 +0200, Petr Baudis wrote:
> >
> > P.S.: Either way, there is a possible workaround to tell git about the
> > working directory manually using git --work-tree=... that I missed to
> > mention on IRC, Yves.
>
> Hmm, am i using it wrong then?
>
> [dmq@somewhere apps]$ git-rev-parse --git-dir
> /home/dmq/git_tree/main/.git
> [dmq@somewhere apps]$ git --work-tree="$(git-rev-parse --git-dir)" pull
> --rebase
> /usr/bin/git-sh-setup: line 139: cd: .git: No such file or directory
> Unable to determine absolute path of git directory
Hmm, realizing that was the workdir it wanted i tried it like so:
[dmq@somewhere apps]$ git --work-tree="$(git-rev-parse --git-dir)/.."
pull --rebase
/usr/bin/git-sh-setup: line 139: cd: /home/dmq/git_tree/main/apps/.git:
No such file or directory
Unable to determine absolute path of git directory
Yet:
[dmq@somewhere apps]$ git-rev-parse --git-dir
/home/dmq/git_tree/main/.git
is correct.
> cheers,
> yves
> ps: not on list, please cc me on replies (sorry for the hassle)
>
^ permalink raw reply
* Re: Closing the merge window for 1.6.0
From: Dmitry Potapov @ 2008-07-15 17:04 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Petr Baudis, Junio C Hamano, Nicolas Pitre, Gerrit Pape, git
In-Reply-To: <alpine.DEB.1.00.0807151623120.8950@racer>
On Tue, Jul 15, 2008 at 04:27:02PM +0100, Johannes Schindelin wrote:
>
> >From the time balance sheet, it does not look good at all: a few minutes
> for Junio to change and commit, up to a few hours (because they missed it
> in the release notes) for probably more than hundred repository
> maintainers that are not subscribed to the Git mailing list.
If you just grab sources and never read release notes, there is nothing
that can help you. If Git 1.6.0 is not the right moment to do these
changes then Git 1.6.1 is neither, regardless whether Debian will
release Lenny by that time or not. People do not upgrade their distro in
the day of release. Some upgraded to Etch not so long ago. So, should we
wait for another year till 1.7.0?
>
> And I absolutely agree with Pasky that this does _nothing_ in the vague
> direction of wielding a reputation of being easy to use.
I don't think Git 1.4 is easy to use. If you want Git that is easy to
use install Git 1.5.x. And, it is *much* easier to install Git from
backports then to deal with usability issues of Git 1.4 and the lack
of community support. So, I don't see how this change may hurt.
>
> Sure, we can make it easy on ourselves. And it is just as easy to make it
> hard on others. If you're okay with that, I am not.
It has *nothing* to do with making easy on ourselves and hard on others.
The question here is what is the appropriate time to change these default
settings, and I believe that *major* releases are the appropriate time
while minor ones are not.
Dmitry
^ permalink raw reply
* Re: Closing the merge window for 1.6.0
From: Petr Baudis @ 2008-07-15 17:28 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Johannes Schindelin, Dmitry Potapov, Junio C Hamano, Gerrit Pape,
git
In-Reply-To: <alpine.LFD.1.10.0807151213000.12484@xanadu.home>
On Tue, Jul 15, 2008 at 12:26:48PM -0400, Nicolas Pitre wrote:
> Anyway this is all hand waving until someone can come with some evidence
> that git 1.4.4 is actually used by a significant amount of people, and
> that those people depend on dumb transfer protocols.
That will be hard to produce. :-) _My_ personal story is that I have
Git-1.4.4.4 installed system-wide on repo.or.cz and follow git#next
locally, and quite panicked when I was inspecting some repositories
as root (using the system-wide Git) and these error messages popped up.
This may become a similar experience for others on multi-user systems
where people want to share work but don't realize that one of them has
Git installed locally and the other one doesn't. We can save them the
head-slapping and a bit of wasted life.
Out of interest, I did a simple statistics of HTTP user agents on
repo.or.cz; the dumb access does not seem very widely used overally,
it turns out. The stats begin at 19/May/2008:10:54:32 +0200. Here is the
breakdown, counting unique clients only:
# zgrep '"GET /r/.*/info/packs' /var/log/apache2/repo-access.log* | egrep -v bot\|slurp\|Gecko\|Opera |
cut -d " " -f 1,12- | sed 's/\.g[a-f0-9]*\(\.dirty\)*"/"/' | sort -u |
cut -d ' ' -f 2 | sort | uniq -c | sort -rn | head -n 50
1501 "git/1.5.4.3" <- Ubuntu Hardy (heh.. is just that it?)
278 "git/1.5.5.1" <- RHEL5 (ditto)
151 "git/1.5.2.5" <- Ubuntu Gutsy
133 "git/1.5.5.3" <- ? (maybe Gentoo ~x86 for some time)
125 "git/1.5.4.5" <- OpenSUSE 11.0, FC9, Gentoo x86, Dapper backports
104 "git/1.5.6" <- Debian Lenny
94 "git/1.5.5"
66 "git/1.5.3.7"
63 "git/1.5.5.4"
63 "git/1.5.5.1015"
55 "git/1.5.2.4" <- OpenSUSE 10.3
51 "Mozilla/4.0 (compatible;)" <- huh?
42 "git/1.5.3.8"
37 "git/1.5.5.GIT"
37 "git/1.5.3.5.2229"
34 "git/1.5.6.1"
33 "git/1.5.3.6" <- Feisty backports
31 "git/1.5.4.1"
30 "git/1.5.6.2"
20 "git/1.5.6.GIT"
18 "git/1.5.3"
17 "git/1.5.2.2"
17 "git/1.4.4.4"
15 "git/1.5.6.1.1071"
14 "git/1.5.3.3"
13 "git/1.5.4.4"
13 "git/1.5.4"
11 "git/1.5.6.1062"
11 "git/1.5.5.2"
10 "git/1.5.5.1.316"
(I also got two 1.4.4.2 (feisty?) fetches from one client. No older
Git versions.)
So wrt. keeping backwards compatibility, this is not _very_ convincing,
I admit. ;-)
--
Petr "Pasky" Baudis
GNU, n. An animal of South Africa, which in its domesticated state
resembles a horse, a buffalo and a stag. In its wild condition it is
something like a thunderbolt, an earthquake and a cyclone. -- A. Pierce
^ permalink raw reply
* Re: [PATCH] Only use GIT_CONFIG in "git config", not other programs
From: Sverre Rabbelier @ 2008-07-15 17:56 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, git, Johannes Schindelin
In-Reply-To: <alpine.LNX.1.00.0806300328380.19665@iabervon.org>
On Mon, Jun 30, 2008 at 9:37 AM, Daniel Barkalow <barkalow@iabervon.org> wrote:
> @@ -611,31 +613,28 @@ int git_config(config_fn_t fn, void *data)
> {
> int ret = 0;
> char *repo_config = NULL;
> - const char *home = NULL, *filename;
> + const char *home = NULL;
>
> /* $GIT_CONFIG makes git read _only_ the given config file,
> * $GIT_CONFIG_LOCAL will make it process it in addition to the
> * global config file, the same way it would the per-repository
> * config file otherwise. */
I noticed today while looking at config.c (because of the 'git config
oddity' thread) that this reference to GIT_CONFIG_LOCAL was not
removed? On latest next:
$ grep GIT_CONFIG_LOCAL *
config.c: * $GIT_CONFIG_LOCAL will make it process it in addition to the
git-svn: my $file = $ENV{GIT_CONFIG} || $ENV{GIT_CONFIG_LOCAL} ||
git-svn.perl: my $file = $ENV{GIT_CONFIG} || $ENV{GIT_CONFIG_LOCAL} ||
I doubt that this stray comment will hurt anyone, but it's probably
nicer not to let cruft like this accumulate, I think?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH] Documentation/git-submodule.txt: Add Description section
From: Heikki Orsila @ 2008-07-15 18:37 UTC (permalink / raw)
To: Petr Baudis; +Cc: gitster, git
In-Reply-To: <20080715102119.26321.78530.stgit@localhost>
On Tue, Jul 15, 2008 at 12:22:07PM +0200, Petr Baudis wrote:
> +Submodules are a special kind of tree entries which do not refer to a blob or
> +a directory, but to a particular tree in another repository (living at a given
> +URL).
Better to say what a submodule is, rather than what it isn't:
"Submodules are a special kind of tree entries which refer to a
particular tree in another repository ..."
Also, I think you should make the following explicit:
"A submodule is visible as subdirectory in the working directory.
However, the submodule is not part of the main repository.
This is a differene to "remotes". In remotes only the contents of
other repositories is tracked, but their content is not visible in the
working directory."
--
Heikki Orsila
heikki.orsila@iki.fi
http://www.iki.fi/shd
^ permalink raw reply
* Re: [PATCH v2] index-pack: Honor core.deltaBaseCacheLimit when resolving deltas
From: Junio C Hamano @ 2008-07-15 18:48 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Nicolas Pitre, Stephan Hennig, Andreas Ericsson
In-Reply-To: <20080715044534.GA2794@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Version 2 plugs the case Nico noticed, where the patch was causing
> the exact behavior it was trying to prevent while recovering from
> what it did to avoid the excessive memory usage in the first place.
Thanks both; it makes sense.
^ 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