* Re: [PATCH] xdiff-interface.c (buffer_is_binary): Remove buffer size limitation
From: Linus Torvalds @ 2007-12-04 0:00 UTC (permalink / raw)
To: Dmitry V. Levin; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <20071203215007.GA14697@basalt.office.altlinux.org>
On Tue, 4 Dec 2007, Dmitry V. Levin wrote:
>
> Average file size in the linux-2.6.23.9 kernel tree is 10944 bytes,
Don't do "average" sizes. That's an almost totally meaningless number.
"Average" makes sense if you have some kind of gaussian distribution or
similar. File sizes tend to be exponential distributions, and what makes
much more sense is to look at the median. That doesn't show the effect of
a few larger files, and also gives you a much better "half the files are
smaller than x" idea.
And the median filesize for the kernel is just a few bytes over 4k.
Of the 23,000+ files in the current kernel, about 15,500 are less than
8kB. And 17,179 are smaller than the 10944 bytes you mention.
I'd argue that 8kB (or even 4kB) is probably a good number for things like
that: it catches the bulk of all files in their entirety, but it *avoids*
spending tons of time on the (few) really large files.
Linus
^ permalink raw reply
* Re: What's in git-gui.git
From: Miklos Vajna @ 2007-12-04 0:29 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20071203041010.GT14735@spearce.org>
[-- Attachment #1: Type: text/plain, Size: 693 bytes --]
On Sun, Dec 02, 2007 at 11:10:10PM -0500, "Shawn O. Pearce" <spearce@spearce.org> wrote:
> The following changes since gitgui-0.9.0 are now in my git-gui
> master branch. I'm considering tagging a 0.9.1 release next week.
The following changes since commit 6f4ec3aa29450f4fa5af3cd8f6593d46d80aa909:
Christian Stimming (1):
Update German translation. 100% completed.
are available in the git repository at:
git://repo.or.cz/git-gui/git-gui-i18n.git mob
Miklos Vajna (1):
Update Hungarian translation. 100% completed.
po/hu.po | 682 +++++++++++++++++++++++++++++++++-----------------------------
1 files changed, 362 insertions(+), 320 deletions(-)
thanks,
- VMiklos
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: v1.5.4 plans
From: Russell @ 2007-12-04 0:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk5nwu51x.fsf@gitster.siamese.dyndns.org>
On Dec 3, 2007 7:04 AM, Junio C Hamano <gitster@pobox.com> wrote:
> * We have already removed svnimport without giving a deprecation notice
> in the release notes of the previous feature release, which was bad.
> Maybe the users will forgive us. Maybe not.
Ah, that explains that. I was in the middle of importing the open2x
project into a git repo. It's a large tree which looks like it
includes several copies of linux 2.4, and importing is taking several
days. Occasionally the svn connection times out or something, and I
just restart it and it continues. In the middle of that I built and
installed git 1.5.3.7 and was surprised when git-svnimport wasn't
there the next time I tried to restart it. Back to 1.5.3.6 for now.
I see there's a thread about using a git-svnimport tree with git-svn,
so I'll do that.
Oh, and you're forgiven. :)
--
Virus found in this message.
^ permalink raw reply
* Re: [PATCH] xdiff-interface.c (buffer_is_binary): Remove buffer size limitation
From: Johannes Schindelin @ 2007-12-04 1:00 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Dmitry V. Levin, Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.LFD.0.9999.0712031559480.8458@woody.linux-foundation.org>
Hi,
On Mon, 3 Dec 2007, Linus Torvalds wrote:
> On Tue, 4 Dec 2007, Dmitry V. Levin wrote:
> >
> > Average file size in the linux-2.6.23.9 kernel tree is 10944 bytes,
>
> Don't do "average" sizes. That's an almost totally meaningless number.
>
> "Average" makes sense if you have some kind of gaussian distribution or
> similar.
To enhance on that: Gaussian is symmetric, which cannot be the proper
distribution for anything that is non-negative.
I see so many mis-applications of statistics/probability theory in my day
job that I cannot resist pointing people to the Poisson distribution here
(in whose context "average" actually makes kind of sense).
But back to the problem: if you have a truly binary file, then _every_
byte (absent further information, of course) has a probability of 1/256 of
being 0.
Which means that if a file is binary, but is unusual enough to have that
property only for half of the first 8192 bytes, you get a probability of
1 - 1 / 256^4096 = 1 - 1 / 2 ^ 32768 that the current test succeeds.
I fail to see how this test can possibly fail for the average case.
So if it fails only for special cases, we are probably (in the common, not
the mathematical, sense) better off asking those people encountering them
to add git-attributes for the files.
IMHO that is not asking for too much.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] install-sh from automake does not like -m without delimiting space
From: Junio C Hamano @ 2007-12-04 1:02 UTC (permalink / raw)
To: Robert Schiele; +Cc: git, spearce
In-Reply-To: <20071201170540.GS11347@schiele.dyndns.org>
Robert Schiele <rschiele@gmail.com> writes:
> The install-sh script as shipped with automake requires a space between
> the -m switch and its argument. Since this is also the regular way of
> doing it with other install implementations this change inserts the
> missing space in all makefiles.
I do not think this is risky, so I'll take it but please yell if it
breaks some existing setups.
I'll ask Shawn to do that part separately.
Thanks.
^ permalink raw reply
* Re: [PATCH] hg-to-git: do not include the branch name as the first line of commit msg
From: Junio C Hamano @ 2007-12-04 1:20 UTC (permalink / raw)
To: Mark Drago; +Cc: stelian, gitster, git
In-Reply-To: <4751A036.1080209@gmail.com>
Mark Drago <markdrago@gmail.com> writes:
> Signed-off-by: Mark Drago <markdrago@gmail.com>
> ---
> contrib/hg-to-git/hg-to-git.py | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/contrib/hg-to-git/hg-to-git.py b/contrib/hg-to-git/hg-to-git.py
> index 7a1c3e4..6bff49b 100755
> --- a/contrib/hg-to-git/hg-to-git.py
> +++ b/contrib/hg-to-git/hg-to-git.py
> @@ -158,7 +158,7 @@ for cset in range(int(tip) + 1):
> mparent = None
>
> (fdcomment, filecomment) = tempfile.mkstemp()
> - csetcomment = os.popen('hg log -r %d -v | grep -v ^changeset: | grep -v ^parent: | grep -v ^user: | grep -v ^date | grep -v ^files: | grep -v ^description: | grep -v ^tag:' % cset).read().strip()
> + csetcomment = os.popen('hg log -r %d -v | grep -v ^changeset: | grep -v ^parent: | grep -v ^user: | grep -v ^date | grep -v ^files: | grep -v ^description: | grep -v ^tag: | grep -v ^branch:' % cset).read().strip()
> os.write(fdcomment, csetcomment)
> os.close(fdcomment)
Isn't this one of the ugliest lines in the whole git.git project, I have
to wonder?
I also wonder missing colon after "date" is a bug from the original
version, and assuming that it is, how about doing something less error
prone like this?
def included(line):
keywords = ('changeset', 'parent', 'user', 'date', 'files',
'description', 'tag', 'branch')
for kw in keywords:
if line.startswith(kw + ':'):
return 0
return 1
hglog = os.popen('hg log -r %d -v' % cset).read();
csetcomment = '\n'.join(filter(included, hglog.split('\n'))).strip()
If you are excluding _all_ of the <word>: header lines, the "included"
function may have to become cleverer but much simpler by doing something
like:
import re
header_re = re.compile(r'^\w+:')
def included(line):
return not header_re.match(line)
^ permalink raw reply
* [PATCH] t9600: require cvsps 2.1 to perform tests
From: Jeff King @ 2007-12-04 1:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: gitzilla, Johannes Schindelin, git
In-Reply-To: <7vir3fe54c.fsf@gitster.siamese.dyndns.org>
git-cvsimport won't run at all with less than cvsps 2.1, because it
lacks the -A flag. But there's no point in preventing people who have an
old cvsps from running the full testsuite.
Tested-by: A Large Angry SCM <gitzilla@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
---
On Mon, Dec 03, 2007 at 03:21:55PM -0800, Junio C Hamano wrote:
> Jeff, would you want to further amend the patch to use "say" as Hannes
> suggested to make it look nicer?
Here it is.
t/t9600-cvsimport.sh | 20 ++++++++++++++++++--
1 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/t/t9600-cvsimport.sh b/t/t9600-cvsimport.sh
index 08f0f2a..7706430 100755
--- a/t/t9600-cvsimport.sh
+++ b/t/t9600-cvsimport.sh
@@ -3,13 +3,29 @@
test_description='git-cvsimport basic tests'
. ./test-lib.sh
-if ! ( type cvs && type cvsps ) >/dev/null 2>&1
+if ! type cvs >/dev/null 2>&1
then
- test_expect_success 'skipping cvsimport tests, cvs/cvsps not found' ''
+ say 'skipping cvsimport tests, cvs not found'
test_done
exit
fi
+cvsps_version=`cvsps -h 2>&1 | sed -ne 's/cvsps version //p'`
+case "$cvsps_version" in
+2.1)
+ ;;
+'')
+ say 'skipping cvsimport tests, cvsps not found'
+ test_done
+ exit
+ ;;
+*)
+ say 'skipping cvsimport tests, cvsps too old'
+ test_done
+ exit
+ ;;
+esac
+
CVSROOT=$(pwd)/cvsroot
export CVSROOT
# for clean cvsps cache
--
1.5.3.7.2070.g88cf2-dirty
^ permalink raw reply related
* Re: [PATCH] Make Git accept absolute path names for files within the work tree
From: Jeff King @ 2007-12-04 1:43 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Junio C Hamano, Anatol Pomozov, git, Linus Torvalds
In-Reply-To: <200712032153.31322.robin.rosenberg.lists@dewire.com>
On Mon, Dec 03, 2007 at 09:53:30PM +0100, Robin Rosenberg wrote:
> code did not pass). Like Linus, this code does not resolve symlinks,
> but I forgot to state that it is by design. It solves my problem and
By design meaning "I didn't feel like implemening it because I do not
personally care" or "I have some reason not to resolve symlinks"?
-Peff
^ permalink raw reply
* Re: [PATCH] install-sh from automake does not like -m without delimiting space
From: Shawn O. Pearce @ 2007-12-04 1:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Robert Schiele, git
In-Reply-To: <7v1wa3e0h9.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> Robert Schiele <rschiele@gmail.com> writes:
> > The install-sh script as shipped with automake requires a space between
> > the -m switch and its argument. Since this is also the regular way of
> > doing it with other install implementations this change inserts the
> > missing space in all makefiles.
...
> I'll ask Shawn to do that part separately.
The git-gui portion is already in my master branch. See the
"What's in git-gui.git" I sent out last evening.
--
Shawn.
^ permalink raw reply
* Re: [PATCH v4] Allow update hooks to update refs on their own.
From: Shawn O. Pearce @ 2007-12-04 1:51 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Steven Grimm, git, Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0712031146520.27959@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Sun, 2 Dec 2007, Shawn O. Pearce wrote:
>
> > Steven Grimm <koreth@midwinter.com> wrote:
> > > This is useful in cases where a hook needs to modify an incoming commit
> > > in some way, e.g., fixing whitespace errors, adding an annotation to
> > > the commit message, noting the location of output from a profiling tool,
> > > or committing to an svn repository using git-svn.
> > ...
> > > +/* Update hook exit code: hook has updated ref on its own */
> > > +#define EXIT_CODE_REF_UPDATED 100
> >
> > Hmm. I would actually rather move the ref locking to before we run
> > the update hook, so the ref is locked *while* the hook executes.
>
> Would that not mean that you cannot use update-ref to update the ref,
> since that wants to use the same lock?
You failed to quote the part of my email where I talked about how
we set an evironment variable to pass a hint to lockfile.c running
within the git-update-ref subprocess to instruct it to perform a
different style of locking, one that would work as a "recursive"
lock.
Such a recursive lock could be useful for a whole lot more than just
the update hook. But it would at least allow the update hook to
use git-update-ref to safely change the ref, without receive-pack
losing its own lock on the ref.
--
Shawn.
^ permalink raw reply
* Re: [PATCH v4] Allow update hooks to update refs on their own.
From: Shawn O. Pearce @ 2007-12-04 1:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Steven Grimm, git
In-Reply-To: <7vmyssqrhk.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
>
> > This probably requires exporting the name of the ref we currently
> > have locked in an environment variable (and teach lockfile.c it)
> > so we can effectively do recursive locking. That way the update
> > hook can still use git-update-ref to change the ref safely.
>
> Heh, I like that, although I suspect getting this right would mean the
> topic should be post 1.5.4 (which I do not mind).
Yea, most likely.
Also I won't have any time in the near future to work on this
implementation myself. I threw the idea out there in case someone
else can find the time. I'm willing to do the work myself as I think
its the right approach to use here for this update hook change, but
I just don't see myself getting to it anytime before say Christmas...
Its slightly more involved then what Steven originally proposed,
but I think it solves the problem better and gives us more room
for future improvements where we may want/need something such as
a recursive ref locking.
--
Shawn.
^ permalink raw reply
* [BUG] Pulling tags no longer works in 1.5.3.4...
From: Jeff Garzik @ 2007-12-04 2:00 UTC (permalink / raw)
To: Git Mailing List
Using package git-core-1.5.3.3-3.fc7, I can do the following with kernel
git trees:
1) git-clone --reference linux-2.6 linux-2.6 tmp-2.6
2) time passes (days or weeks)
3) cd tmp-2.6
git pull ../linux-2.6
git pull --tags ../linux-2.6
Result: works as expected.
Using package git-core-1.5.3.4-1.fc8, step #3 breaks:
[jgarzik@pretzel misc-2.6]$ git pull --tags ../linux-2.6/
You asked me to pull without telling me which branch you
want to merge with, and 'branch.master.merge' in
your configuration file does not tell me either. Please
name which branch you want to merge on the command line and
try again (e.g. 'git pull <repository> <refspec>').
See git-pull(1) for details on the refspec.
If you often merge with the same branch, you may want to
configure the following variables in your configuration
file:
branch.master.remote = <nickname>
branch.master.merge = <remote-ref>
remote.<nickname>.url = <url>
remote.<nickname>.fetch = <refspec>
See git-config(1) for details.
^ permalink raw reply
* Re: [PATCH] Reorder msgfmt command-line arguments.
From: Shawn O. Pearce @ 2007-12-04 2:07 UTC (permalink / raw)
To: brian m. carlson; +Cc: Johannes Schindelin, git
In-Reply-To: <20071203170402.GA13712@crustytoothpaste.ath.cx>
"brian m. carlson" <sandals@crustytoothpaste.ath.cx> wrote:
> On Mon, Dec 03, 2007 at 10:35:33AM +0000, Johannes Schindelin wrote:
> >On Mon, 3 Dec 2007, brian m. carlson wrote:
> >
> >>Any program using getopt or getopt_long will stop processing options
> >>once a non-option argument has been encountered, if POSIXLY_CORRECT is
> >>set.
...
> >Besides, you probably want to send this as a git-gui patch: based on
> >git-gui.git, not git.git, and Cc'ed to Shawn Pearce.
>
> Thanks. Will do.
Don't bother. I already did the necesary work to apply this patch
to the git-gui.git tree. It was small, obviously correct, and easy
to fix up to make it apply to git-gui.git. Its already pushed out
in my master branch and will be in gitgui-0.9.1.
--
Shawn.
^ permalink raw reply
* Re: [PATCH v4] Allow update hooks to update refs on their own.
From: Johannes Schindelin @ 2007-12-04 2:12 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Steven Grimm, git, Junio C Hamano
In-Reply-To: <20071204015108.GV14735@spearce.org>
Hi,
On Mon, 3 Dec 2007, Shawn O. Pearce wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > On Sun, 2 Dec 2007, Shawn O. Pearce wrote:
> >
> > > Steven Grimm <koreth@midwinter.com> wrote:
> > > > This is useful in cases where a hook needs to modify an incoming commit
> > > > in some way, e.g., fixing whitespace errors, adding an annotation to
> > > > the commit message, noting the location of output from a profiling tool,
> > > > or committing to an svn repository using git-svn.
> > > ...
> > > > +/* Update hook exit code: hook has updated ref on its own */
> > > > +#define EXIT_CODE_REF_UPDATED 100
> > >
> > > Hmm. I would actually rather move the ref locking to before we run
> > > the update hook, so the ref is locked *while* the hook executes.
> >
> > Would that not mean that you cannot use update-ref to update the ref,
> > since that wants to use the same lock?
>
> You failed to quote the part of my email where I talked about how
> we set an evironment variable to pass a hint to lockfile.c running
> within the git-update-ref subprocess to instruct it to perform a
> different style of locking, one that would work as a "recursive"
> lock.
>
> Such a recursive lock could be useful for a whole lot more than just
> the update hook. But it would at least allow the update hook to
> use git-update-ref to safely change the ref, without receive-pack
> losing its own lock on the ref.
Indeed, I even failed to read it fully ;-)
What do you propose, though? <filename>.lock.<n>?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Make Git accept absolute path names for files within the work tree
From: Johannes Schindelin @ 2007-12-04 2:17 UTC (permalink / raw)
To: Jeff King
Cc: Robin Rosenberg, Junio C Hamano, Anatol Pomozov, git,
Linus Torvalds
In-Reply-To: <20071204014326.GA21358@coredump.intra.peff.net>
Hi,
On Mon, 3 Dec 2007, Jeff King wrote:
> On Mon, Dec 03, 2007 at 09:53:30PM +0100, Robin Rosenberg wrote:
>
> > code did not pass). Like Linus, this code does not resolve symlinks,
> > but I forgot to state that it is by design. It solves my problem and
>
> By design meaning "I didn't feel like implemening it because I do not
> personally care" or "I have some reason not to resolve symlinks"?
IMHO those symlinks would be a nice thing in some corner cases, but
penalise the common case. So I tend to believe the latter. (See also
Linus' message why he talks about his preference for the die() code path.)
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH v4] Allow update hooks to update refs on their own.
From: Shawn O. Pearce @ 2007-12-04 2:20 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Steven Grimm, git, Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0712040211270.27959@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Mon, 3 Dec 2007, Shawn O. Pearce wrote:
> > You failed to quote the part of my email where I talked about how
> > we set an evironment variable to pass a hint to lockfile.c running
> > within the git-update-ref subprocess to instruct it to perform a
> > different style of locking, one that would work as a "recursive"
> > lock.
> >
> > Such a recursive lock could be useful for a whole lot more than just
> > the update hook. But it would at least allow the update hook to
> > use git-update-ref to safely change the ref, without receive-pack
> > losing its own lock on the ref.
>
> Indeed, I even failed to read it fully ;-)
>
> What do you propose, though? <filename>.lock.<n>?
Sure. :-)
I was also hand-waving. Hoping someone else would fill in the
magic details.
Actually <n> wouldn't be so bad. We could do something like:
GIT_INHERITED_LOCKS="<ref> <depth> <ref> <depth> ..."
where <ref> is a ref name (which cannot contain spaces, even though
some people seem to forget that rule) and <depth> is the number
of times it has been locked already. <depth> of 0 is the current
".lock" file. So the first lock taken out by receive-pack would
be setting:
GIT_INHERITED_LOCKS="refs/heads/master 0"
and another lock on the same ref by a subprocess would then update
it to:
GIT_INHERITED_LOCKS="refs/heads/master 1"
etc...
</hand-waving>
--
Shawn.
^ permalink raw reply
* Re: [BUG] Pulling tags no longer works in 1.5.3.4...
From: Johannes Schindelin @ 2007-12-04 2:21 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Git Mailing List
In-Reply-To: <4754B4AF.8070408@garzik.org>
Hi,
On Mon, 3 Dec 2007, Jeff Garzik wrote:
> Using package git-core-1.5.3.3-3.fc7, I can do the following with kernel git
> trees:
>
> 1) git-clone --reference linux-2.6 linux-2.6 tmp-2.6
>
> 2) time passes (days or weeks)
>
> 3) cd tmp-2.6
> git pull ../linux-2.6
> git pull --tags ../linux-2.6
>
> Result: works as expected.
>
>
>
> Using package git-core-1.5.3.4-1.fc8, step #3 breaks:
>
> [jgarzik@pretzel misc-2.6]$ git pull --tags ../linux-2.6/
> You asked me to pull without telling me which branch you
> want to merge with, and 'branch.master.merge' in
> your configuration file does not tell me either. Please
> name which branch you want to merge on the command line and
> try again (e.g. 'git pull <repository> <refspec>').
> See git-pull(1) for details on the refspec.
Oops.
As a workaround, please do "git fetch --tags ../linux-2.6 && git pull
../linux-2.6/" until it is fixed.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH v4] Allow update hooks to update refs on their own.
From: Johannes Schindelin @ 2007-12-04 2:25 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Steven Grimm, git, Junio C Hamano
In-Reply-To: <20071204022020.GA14735@spearce.org>
Hi,
On Mon, 3 Dec 2007, Shawn O. Pearce wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > On Mon, 3 Dec 2007, Shawn O. Pearce wrote:
> > > You failed to quote the part of my email where I talked about how
> > > we set an evironment variable to pass a hint to lockfile.c running
> > > within the git-update-ref subprocess to instruct it to perform a
> > > different style of locking, one that would work as a "recursive"
> > > lock.
> > >
> > > Such a recursive lock could be useful for a whole lot more than just
> > > the update hook. But it would at least allow the update hook to
> > > use git-update-ref to safely change the ref, without receive-pack
> > > losing its own lock on the ref.
> >
> > Indeed, I even failed to read it fully ;-)
> >
> > What do you propose, though? <filename>.lock.<n>?
>
> Sure. :-)
>
> I was also hand-waving. Hoping someone else would fill in the
> magic details.
>
> Actually <n> wouldn't be so bad. We could do something like:
>
> GIT_INHERITED_LOCKS="<ref> <depth> <ref> <depth> ..."
I am somewhat wary of using environment variables in that context, since
the variables could leak to subprocesses, or (even worse), they could be
set inadvertently by the user or other scripts.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH v4] Allow update hooks to update refs on their own.
From: Steven Grimm @ 2007-12-04 2:33 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Shawn O. Pearce, git, Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0712040224080.27959@racer.site>
On Dec 3, 2007, at 6:25 PM, Johannes Schindelin wrote:
> I am somewhat wary of using environment variables in that context,
> since
> the variables could leak to subprocesses, or (even worse), they
> could be
> set inadvertently by the user or other scripts.
Agreed on the inadvertent setting, but isn't leaking to subprocesses
the whole point of the exercise here?
-Steve
^ permalink raw reply
* Re: [BUG] Pulling tags no longer works in 1.5.3.4...
From: Jeff King @ 2007-12-04 2:33 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Git Mailing List
In-Reply-To: <4754B4AF.8070408@garzik.org>
On Mon, Dec 03, 2007 at 09:00:15PM -0500, Jeff Garzik wrote:
> Using package git-core-1.5.3.3-3.fc7, I can do the following with kernel git
> trees:
>
> 1) git-clone --reference linux-2.6 linux-2.6 tmp-2.6
>
> 2) time passes (days or weeks)
>
> 3) cd tmp-2.6
> git pull ../linux-2.6
> git pull --tags ../linux-2.6
>
> Result: works as expected.
Hrm, when I try to reproduce using v1.5.3.3, I get the "Warning: No
merge candidate found..." message. Between 1.5.3.3 and 1.5.3.4, this
message got a bit longer and the exit code was fixed to indicate an
error. Were you perhaps just missing the warning message, since no error
was signaled?
At any rate, I think what you really want in step 3 is
git fetch --tags ../linux-2.6
since you just want to grab the tags, and not merge anything (remember
that pull is fetch+merge -- you are only interesting in the fetching
side effect). You could also do this:
git pull --tags ../linux-2.6 master
In general, "git pull --tags" without a branch to pull doesn't make much
sense. What happens is that the "--tags" tells the fetch part of the
pull operation to just grab the tags. Then the merge part of the pull
operation looks in what has just been fetched for something merge-able.
And of course there isn't anything, since all you fetched were tags.
-Peff
^ permalink raw reply
* Re: [PATCH v4] Allow update hooks to update refs on their own.
From: Shawn O. Pearce @ 2007-12-04 2:34 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Steven Grimm, git, Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0712040224080.27959@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Mon, 3 Dec 2007, Shawn O. Pearce wrote:
> > Actually <n> wouldn't be so bad. We could do something like:
> >
> > GIT_INHERITED_LOCKS="<ref> <depth> <ref> <depth> ..."
>
> I am somewhat wary of using environment variables in that context, since
> the variables could leak to subprocesses, or (even worse), they could be
> set inadvertently by the user or other scripts.
Sure. But as bad as it is, its still more secure than the
"repository of record" that my day-job uses for its source code
tree (no, it doesn't use Git, and I wish it was as good as Visual
Source Suck). </bad-joke>
I'd suggest also using something like getppid() to check the pid
against a pid in the env, and *gasp* maybe do a SHA-1 hash in there
or something to make it challening enough to fake that the average
user won't set it unless they really understand what they are doing.
--
Shawn.
^ permalink raw reply
* git-add--interactive works only in top level
From: Reid Barton @ 2007-12-04 3:19 UTC (permalink / raw)
To: git
When the working directory is not the top of the working tree, git-
add--interactive fails silently and confusingly. In this example,
the working tree is rooted at ~/sandbox/foo and ~/sandbox/foo/bar/x
is a file that's been edited.
rwbarton@homothety:~/sandbox/foo/bar$ git-add--interactive
staged unstaged path
1: unchanged +1/-0 bar/x
*** Commands ***
1: status 2: update 3: revert 4: add untracked
5: patch 6: diff 7: quit 8: help
What now> 5
staged unstaged path
1: unchanged +1/-0 bar/x
Patch update> 1
*** Commands ***
1: status 2: update 3: revert 4: add untracked
5: patch 6: diff 7: quit 8: help
What now>
Rather than returning to the main menu, git-add--interactive should
have showed me a list of chunks. It seems that the list of files is
relative to the working tree root (which is sensible) but when git-
add--interactive invokes git-diff-files it does not take this into
account. Perhaps git-diff-files should also complain when invoked as
git-diff-files -- non-existent-file-name
so it wouldn't have taken me half an hour to track this down.
Regards,
Reid Barton
^ permalink raw reply
* Re: Fix UTF Encoding issue
From: Ismail Dönmez @ 2007-12-04 4:12 UTC (permalink / raw)
To: Jakub Narebski
Cc: Benjamin Close, Martin Koegler, Junio C Hamano,
Alexandre Julliard, git
In-Reply-To: <200712040037.37204.jnareb@gmail.com>
Tuesday 04 December 2007 Tarihinde 01:37:35 yazmıştı:
> On Tue, 4 Dec 2007, Benjamin Close wrote:
> > On Tue, Dec 04, 2007 at 12:20:26AM +0200, Ismail Donmez wrote:
> > > Can you try the attached patch?
> >
> > I confirm that the patch corrects the problem.
> >
> > Without it I get the Cannot decode string error. With it gitweb
> > displays correctly.
>
> But the patch _avoids_ issue (des not convert owner to utf8), rather
> than solving it, if I understand it correctly. What if gecos is in
> utf-8?
Indeed its a workaround but UTF-8 username is correctly displayed in gitweb so
my understanding was gecos field is already UTF-8.
--
Never learn by your mistakes, if you do you may never dare to try again.
^ permalink raw reply
* Re: [PATCH] t9600: require cvsps 2.1 to perform tests
From: Junio C Hamano @ 2007-12-04 5:37 UTC (permalink / raw)
To: Jeff King; +Cc: gitzilla, Johannes Schindelin, git
In-Reply-To: <20071204014145.GA20145@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> +cvsps_version=`cvsps -h 2>&1 | sed -ne 's/cvsps version //p'`
> +case "$cvsps_version" in
> +2.1)
> + ;;
> +'')
> + say 'skipping cvsimport tests, cvsps not found'
> + test_done
> + exit
> + ;;
> +*)
> + say 'skipping cvsimport tests, cvsps too old'
> + test_done
> + exit
> + ;;
> +esac
> +
I wonder if it is better to grep for ' [-A] ' instead, like:
cvsps_supports_A=$(cvsps -h 2>&1 | sed -ne '/\[-A\]/p')
case "$cvsps_supports_A" in
'')
say 'skipping cvsimport tests, lacking cvsps that supports -A option'
test_done
exit
esac
^ permalink raw reply
* [PATCH] Documentation: add a new man page for "git-help" and -i|--info option.
From: Christian Couder @ 2007-12-04 5:44 UTC (permalink / raw)
To: Junio Hamano; +Cc: git
Option -i|--info for "git-help" is documented only in the new
"git-help.txt" man page, but this new man page is referenced
from the "--help" option documentation in the "git.txt" man page.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Documentation/git-help.txt | 53 ++++++++++++++++++++++++++++++++++++++++++++
Documentation/git.txt | 11 ++++++--
2 files changed, 61 insertions(+), 3 deletions(-)
create mode 100644 Documentation/git-help.txt
This is a first documentation patch in my git-help
improvement series.
diff --git a/Documentation/git-help.txt b/Documentation/git-help.txt
new file mode 100644
index 0000000..232daae
--- /dev/null
+++ b/Documentation/git-help.txt
@@ -0,0 +1,53 @@
+git-help(1)
+======
+
+NAME
+----
+git-help - display help information about git
+
+SYNOPSIS
+--------
+'git help' [-a|--all|-i|--info] [COMMAND]
+
+DESCRIPTION
+-----------
+
+With no options and no COMMAND given, the synopsis of the 'git'
+command and a list of the most commonly used git commands are printed
+on the standard output.
+
+If the option '--all' or '-a' is given, then all available commands are
+printed on the standard output.
+
+If a git command is named, a manual page for that command is brought
+up. The 'man' program is used by default for this purpose, but this
+can be overriden by other options.
+
+Note that 'git --help ...' is identical as 'git help ...' because the
+former is internally converted into the latter.
+
+OPTIONS
+-------
+-a|--all::
+
+ Prints all the available commands on the standard output. This
+ option superseeds any other option.
+
+-i|--info::
+ Use the 'info' program to display the manual page, instead of
+ the 'man' program that is used by default.
+
+Author
+------
+Written by Junio C Hamano <gitster@pobox.com> and the git-list
+<git@vger.kernel.org>.
+
+Documentation
+-------------
+Initial documentation was part of the gitlink:git[7] man page.
+Christian Couder <chriscool@tuxfamily.org> extracted and rewrote it a
+little. Maintenance is done by the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 5460201..f8d1eef 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -100,9 +100,14 @@ OPTIONS
--help::
Prints the synopsis and a list of the most commonly used
- commands. If a git command is named this option will bring up
- the man-page for that command. If the option '--all' or '-a' is
- given then all available commands are printed.
+ commands. If the option '--all' or '-a' is given then all
+ available commands are printed. If a git command is named this
+ option will bring up the manual page for that command.
+
+ Other options are available to control how the manual page is
+ displayed. See gitlink:git-help[1] for more information,
+ because 'git --help ...' is converted internally into 'git
+ help ...'.
--exec-path::
Path to wherever your core git programs are installed.
--
1.5.3.6.1993.g154f-dirty
^ permalink raw reply related
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