* Re: Failed to clone http://repo.or.cz/w/msysgit.git
From: Abdelrazak Younes @ 2007-12-17 17:40 UTC (permalink / raw)
To: msysgit-/JYPxA39Uh5TLH3MbocFFw; +Cc: git-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <Pine.LNX.4.64.0712171702360.9446-OGWIkrnhIhzN0uC3ymp8PA@public.gmane.org>
Johannes Schindelin wrote:
> Hi,
>
> [please do not cull me from the Cc: list when you reply to me. This is
> like replying to me, but talking away from me (to the public).]
Sorry, I am afraid I cannot do that right now because I use the gmane
news interface and I don't have access to my smtp from here. If it is
too irritating I'll wait up until I go back home before I answer. In any
case, sorry for the inconvenience.
>
> On Mon, 17 Dec 2007, Abdelrazak Younes wrote:
>
>> Johannes Schindelin wrote:
>>> On Mon, 17 Dec 2007, Abdelrazak Younes wrote:
>>>
>>>> I am trying to clone the msysgit repository but I get this error:
>>>>
>>>> $ git clone http://repo.or.cz/w/msysgit.git
>>>> Initialized empty Git repository in d:/devel/git/msysgit/.git/
>>>> D:/program/Git/bin/git-clone: line 144: /bin/git-http-fetch: Bad file
>>>> number
>
> Okay, I get the same error here. Fishy. But then, this is not the
> correct URL either (so I think Peff's patch probably fixes it).
>
> What you tried is the gitweb URL, which explicitely says
>
> Mirror URL git://repo.or.cz/msysgit.git
>
> http://repo.or.cz/r/msysgit.git
>
> IOW replace your "/w/" by "/r/" and have fun,
Yes, it works! Thanks and sorry for the mixup, I just copied and pasted
the link without thinking.
Abdel.
^ permalink raw reply
* Question about git-svn import
From: Pascal Obry @ 2007-12-17 17:18 UTC (permalink / raw)
To: git list
Hi,
You'll find a script into this message that reproduce what I'll describe
below. Basically the Subversion repository add a given structure in the
past then rearranged to use the "standard" structure. The former
structure was:
<root>
|
| - dir1
| - dir2
The new one is:
<root>
|
|- trunk
| | - dir1
| | - dir2
|- branches
|- tags
Now I want to import this project into Git (using git-svn) as the
project won't leave Subversion for the moment. When doing:
$ git svn clone -s <repo> <git-repo>
In git-repo we get only the commits done inside <root>/trunk and not the
commits done in the former repository.
The question is what is the best way to deal with such a case with git-svn ?
Thanks.
############################ CUT HERE #############################
#!/bin/sh
REP=file://$(pwd)/repo
rm -fr repo co-repo git-repo
svnadmin create repo
svn co $REP co-repo
cd co-repo
mkdir dir
echo file1 > dir/file1
svn add dir dir/file1
svn ci -m "ci1" dir dir/file1
svn mkdir -m "create trunk" $REP/trunk
svn mkdir -m "create branches" $REP/branches
svn mkdir -m "create tags" $REP/tags
svn move -m "move dir under trunk" $REP/dir $REP/trunk/dir
svn update
sleep 2
echo file1 >> trunk/dir/file1
svn ci -m "ci2" trunk/dir/file1
sleep 2
svn update
cd ..
git svn clone -s $REP git-repo
############################ CUT HERE #############################
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
^ permalink raw reply
* Re: Failed to clone http://repo.or.cz/w/msysgit.git
From: Johannes Schindelin @ 2007-12-17 17:06 UTC (permalink / raw)
To: Abdelrazak Younes
Cc: msysgit-/JYPxA39Uh5TLH3MbocFFw, git-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <fk5u4d$j9b$1@ger.gmane.org>
Hi,
[please do not cull me from the Cc: list when you reply to me. This is
like replying to me, but talking away from me (to the public).]
On Mon, 17 Dec 2007, Abdelrazak Younes wrote:
> Johannes Schindelin wrote:
> >
> > On Mon, 17 Dec 2007, Abdelrazak Younes wrote:
> >
> > > I am trying to clone the msysgit repository but I get this error:
> > >
> > > $ git clone http://repo.or.cz/w/msysgit.git
> > > Initialized empty Git repository in d:/devel/git/msysgit/.git/
> > > D:/program/Git/bin/git-clone: line 144: /bin/git-http-fetch: Bad file
> > > number
Okay, I get the same error here. Fishy. But then, this is not the
correct URL either (so I think Peff's patch probably fixes it).
What you tried is the gitweb URL, which explicitely says
Mirror URL git://repo.or.cz/msysgit.git
http://repo.or.cz/r/msysgit.git
IOW replace your "/w/" by "/r/" and have fun,
Dscho
^ permalink raw reply
* [PATCH] rebase -p -i: handle "no changes" gracefully
From: Johannes Schindelin @ 2007-12-17 16:59 UTC (permalink / raw)
To: Pieter de Bie; +Cc: Johannes Sixt, git, gitster
In-Reply-To: <9CC305E7-3325-4D17-A43E-0A2072F52084@ai.rug.nl>
Since commit 376ccb8cbb453343998e734d8a1ce79f57a4e092, unchanged
SHA-1s are no longer mapped via $REWRITTEN. But the updating
phase was not prepared for the old head not being rewritten.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
On Mon, 17 Dec 2007, Pieter de Bie wrote:
> Ok, but what about the error in the rebase?
>
> On Dec 14, 2007, at 2:21 AM, Pieter de Bie wrote:
> > Tirana:~/git pieter$ time git rebase -p -i HEAD~100
> > cat:
> > /Users/pieter/git/.git/.dotest-merge/rewritten/1e8df762b38e01685f3aa3613e2d61f73346fcbe:
> > No such file or directory
This buglet was not caught earlier, probably because a
non-rewriting rebase is not really interesting ;-)
git-rebase--interactive.sh | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index f83e00f..cd7e43f 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -322,7 +322,12 @@ do_next () {
test -f "$DOTEST"/current-commit &&
current_commit=$(cat "$DOTEST"/current-commit) &&
git rev-parse HEAD > "$REWRITTEN"/$current_commit
- NEWHEAD=$(cat "$REWRITTEN"/$OLDHEAD)
+ if test -f "$REWRITTEN"/$OLDHEAD
+ then
+ NEWHEAD=$(cat "$REWRITTEN"/$OLDHEAD)
+ else
+ NEWHEAD=$OLDHEAD
+ fi
else
NEWHEAD=$(git rev-parse HEAD)
fi &&
--
1.5.4.rc0.59.g1d10d
^ permalink raw reply related
* Re: [PATCH] Fix config lockfile handling.
From: Kristian Høgsberg @ 2007-12-17 16:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfxy5os60.fsf@gitster.siamese.dyndns.org>
On Fri, 2007-12-14 at 13:57 -0800, Junio C Hamano wrote:
> Kristian Høgsberg <krh@redhat.com> writes:
>
> > When we commit or roll back the lock file the fd is automatically closed,
> > so don't do that again.
>
> With your change, we do not check the return status from close(2)
> anymore, which means that we may have run out of diskspace without
> noticing and renamed the incomplete file into the real place. Oops?
You're right of course. Ok, so lets just stick with the current config
file handling for 1.5.4, it's not seriously broken.
Kristian
^ permalink raw reply
* Re: add -i not able to find get_colorbool
From: Johannes Schindelin @ 2007-12-17 16:43 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20071217143100.GA21122@coredump.intra.peff.net>
Hi,
On Mon, 17 Dec 2007, Jeff King wrote:
> On Mon, Dec 17, 2007 at 02:04:21PM +0000, Johannes Schindelin wrote:
>
> > The second line of git-add--interactive reads thusly:
> >
> > use lib (split(/:/, $ENV{GITPERLLIB} ||
> > "/home/gitte/lib/perl5/site_perl/5.8.8"));
> >
> > and this puzzles me:
> >
> > $ grep -n get_colorbool /home/gitte/lib/perl5/site_perl/5.8.8/Git.pm
> > 584:=item get_colorbool ( NAME )
> > 591:sub get_colorbool {
> >
> > So it has it, but cannot locate get_colorbool?
>
> That does seem odd. Can you try running git-add--interactive in the perl
> debugger and doing this:
>
> x \&Git::get_colorbool
> x \&Git::repository
>
> It should tell you where it is getting the functions from (in the first
> case, it will presumably not find it at all, but you seem to have a
> Git::repository, so it should point to the file that has been loaded).
Good call!
main::(/home/gitte/bin/git-add--interactive:8):
8: my ($prompt_color, $header_color, $help_color, $normal_color);
DB<1> x \&Git::get_colorbool
0 CODE(0x853b25c)
-> &CODE(0x853b25c) in ???
DB<2> x \&Git::repository
0 CODE(0x833e8ac)
-> &Git::repository in
/home/gitte/lib/perl5/site_perl/5.8.8/i586-linux-thread-multi/Git.pm:145-217
So it seems that somehow on 8. Nov 10:42 Git.pm was installed into
i586-linux-thread-multi/ and is preferred over the Git.pm which was
installed on 6. Dec 12:24 into site_perl/5.8.8/.
I have no idea how that happened on Nov 8, could be that I was desperate
enough to hand-copy Git.pm there. Git.pm seems to hate me (this was not
the first time I had problems with it).
Ciao,
Dscho
^ permalink raw reply
* Re: Post-1.5.4 stuff: builtin-checkout
From: Kristian Høgsberg @ 2007-12-17 16:30 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0712151529300.5349@iabervon.org>
On Sat, 2007-12-15 at 15:44 -0500, Daniel Barkalow wrote:
> I've got my builtin-checkout implementation at:
>
> git://iabervon.org/~barkalow/git.git builtin-checkout
>
> This may be interesting to some other people at this point, despite it not
> being relevant to 1.5.4, because (a) it includes a slew of small
> preliminary patches to other stuff that might be useful for making other
> things builtin and (b) these changes reflect my debugging of my naive
> implementation of builtin-checkout, and may suggest things that might be
> wrong in existing builtins that do multiple operations in the same
> process.
Thanks, fetching it now.
Kristian
^ permalink raw reply
* Re: [PATCH] Have a flag to stop the option parsing at the first argument.
From: Pierre Habouzit @ 2007-12-17 16:29 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Wincent Colaiuta, Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <47669234.7020202@viscovery.net>
[-- Attachment #1: Type: text/plain, Size: 958 bytes --]
On Mon, Dec 17, 2007 at 03:13:56PM +0000, Johannes Sixt wrote:
> Wincent Colaiuta schrieb:
> > But leaving -p aside, will you oppose any patches that make it possible
> > for people to write stuff like:
> >
> > git init --bare
> >
> > Personally, I think this is an obvious usability improvement worth
> > striving for. Given that "git --bare init" will continue to work under
> > what I'm proposing, I really can't see any worthwhile argument against
> > it. Because we're talking about a UI improvement for newcomers at no
> > cost to old timers.
>
> Your point. I hate to have to think hard each time whether it's "git --bare
> init" or "git init --bare" and "git clone --bare" or "git --bare clone" and
> wouldn't mind if I no longer needed to.
Seconded.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFH] convert shortlog to use parse_options
From: Kristian Høgsberg @ 2007-12-17 16:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andreas Ericsson, Pierre Habouzit, Jeff King, git
In-Reply-To: <7v3au1eopr.fsf@gitster.siamese.dyndns.org>
On Sun, 2007-12-16 at 23:59 -0800, Junio C Hamano wrote:
> Andreas Ericsson <ae@op5.se> writes:
>
> > Junio C Hamano wrote:
> >
> >> ... The
> >> "must stick" restriction feels Ok on paper but in practice it looks
> >> rather draconian and very user unfriendly.
> >
> > Usually, optional arguments warrant adding a second parameter. This can
> > often even improve usability, as it's never unclear or ambiguous what's
> > happening. For the 'git tag -l' case, I'd use something like
> > 'git tag -l --match="regex"' or some such,...
>
> That is essentially arguing for POSIXly correct "do not allow optional
> option-arguments" (utility syntax guidelines #7). That position might
> be politically correct, but I am already discussing beyond that:
> usability.
>
> For "git tag -l", the fix was rather simple, as the option would either
> have taken a zero pattern (list all) or a single pattern (list matching
> this pattern), and the command itself did not take any extra arguments,
> so that was what I did in the patch. Compare your POSIXly correct
> version:
>
> git tag -l (ok)
> git tag -l pattern (not ok)
> git tag -l --match=pattern (ok)
>
> with the traditional (and fixed):
>
> git tag -l (ok)
> git tag -l pattern (ok)
> git tag -l pattern garbage (not ok)
>
> Which one is easier for the user?
git tag now lists tags by default so there's a couple of other options
to consider:
git tag (ok)
git tag --match pattern (ok)
git tag --match=pattern (ok)
git tag --match=pattern -l (ok)
git tag -l pattern (not ok)
Or we could repurpose -l as the match option:
git tag (ok)
git tag -l (not ok)
git tag -l pattern (ok)
And that was the point I was trying to make earlier with my rather
abstract sounding post about jumping through hoops. If we can't break
the options interface to make git sane, we'll be stuck with a broken
command line interface and must write complicated documents on what option
sticking is and how it works.
cheers,
Kristian
^ permalink raw reply
* Re: Solaris install error: didn't get git-init link was [Fwd: Re: The Reposithon! Take 2]
From: Jeff King @ 2007-12-17 16:07 UTC (permalink / raw)
To: Andre Noll; +Cc: Sam Vilain, Git Mailing List
In-Reply-To: <20071217151829.GP32704@skl-net.de>
On Mon, Dec 17, 2007 at 04:18:29PM +0100, Andre Noll wrote:
> > Refer attached ... 1.5.3.6 install, didn't get git-init link to git.
> > Ring any bells?
>
> /usr/sbin/install does not accept all options that git's "make install"
> is using?
/usr/sbin/install doesn't seem to work at all on Solaris. Using
/usr/ucb/install does correctly create the hardlinks.
-Peff
^ permalink raw reply
* Re: [BUG?] git rebase -i
From: Pieter de Bie @ 2007-12-17 16:04 UTC (permalink / raw)
To: Johannes Sixt, git
In-Reply-To: <47623129.2030303@viscovery.net>
Hi,
On Dec 14, 2007, at 8:30 AM, Johannes Sixt wrote:
> Pieter de Bie schrieb:
>> Another thing to note is
>> that the 1.5.4.rc0 tries to apply 215 patches, while the 1.5.3.5
>> tries
>> to apply 206 patches.
>
> This is to be expected: 1.5.3.5 counts the comment lines at the top
> of the
> action file, of which there are exactly 9, 1.5.4.rc0 does not count
> them.
>
Ok, but what about the error in the rebase?
On Dec 14, 2007, at 2:21 AM, Pieter de Bie wrote:
> Tirana:~/git pieter$ time git rebase -p -i HEAD~100
> cat: /Users/pieter/git/.git/.dotest-merge/rewritten/
> 1e8df762b38e01685f3aa3613e2d61f73346fcbe: No such file or directory
- Pieter
^ permalink raw reply
* Re: Solaris install error: didn't get git-init link was [Fwd: Re: The Reposithon! Take 2]
From: Andre Noll @ 2007-12-17 15:18 UTC (permalink / raw)
To: Sam Vilain; +Cc: Git Mailing List
In-Reply-To: <47668ABB.9000504@vilain.net>
[-- Attachment #1: Type: text/plain, Size: 296 bytes --]
On 03:42, Sam Vilain wrote:
> Refer attached ... 1.5.3.6 install, didn't get git-init link to git.
> Ring any bells?
/usr/sbin/install does not accept all options that git's "make install"
is using?
Andre
--
The only person who always got his work done by Friday was Robinson Crusoe
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: git-clone: Unobvious error messages when update-server-info has not been run
From: Sebastian Harl @ 2007-12-17 15:47 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Gerrit Pape, git
In-Reply-To: <20071217124359.GA20800@coredump.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 1274 bytes --]
Hi Jeff,
On Mon, Dec 17, 2007 at 07:43:59AM -0500, Jeff King wrote:
> On Mon, Dec 17, 2007 at 11:55:41AM +0100, Sebastian Harl wrote:
> > I was just trying to clone a repository using http but missed to run
> > git-update-server-info on the server side. git-clone aborted with the
> > following error messages:
> >
> > % git clone http://some/repo.git
> > Initialized empty Git repository in /path/repo/.git/
> > cat: /path/repo/.git/refs/remotes/origin/master: No such file or directory
> > cd: 482: can't cd to /path/repo/.git/refs/remotes/origin
> > fatal: : not a valid SHA1
> > fatal: Not a valid object name HEAD
> >
> > It's kind of hard to guess where the error comes from in this case (I blamed
> > Git at first). Is there some way to improve the error message in a case like
> > this?
>
> git-clone is supposed to detect this condition, but there was a bug in
> the error checking code. Can you confirm that this patch fixes it?
Yes, this patch seems to fix it. Thanks.
Cheers,
Sebastian
--
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/
Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Have a flag to stop the option parsing at the first argument.
From: Johannes Sixt @ 2007-12-17 15:13 UTC (permalink / raw)
To: Wincent Colaiuta
Cc: Johannes Schindelin, Pierre Habouzit, Junio C Hamano, git
In-Reply-To: <223E3B44-92DA-4861-83D6-67E56F70E784@wincent.com>
Wincent Colaiuta schrieb:
> But leaving -p aside, will you oppose any patches that make it possible
> for people to write stuff like:
>
> git init --bare
>
> Personally, I think this is an obvious usability improvement worth
> striving for. Given that "git --bare init" will continue to work under
> what I'm proposing, I really can't see any worthwhile argument against
> it. Because we're talking about a UI improvement for newcomers at no
> cost to old timers.
Your point. I hate to have to think hard each time whether it's "git --bare
init" or "git init --bare" and "git clone --bare" or "git --bare clone" and
wouldn't mind if I no longer needed to.
-- Hannes
^ permalink raw reply
* Re: Solaris install error: didn't get git-init link was [Fwd: Re: The Reposithon! Take 2]
From: Jeff King @ 2007-12-17 15:13 UTC (permalink / raw)
To: Sam Vilain; +Cc: Git Mailing List
In-Reply-To: <47668ABB.9000504@vilain.net>
On Tue, Dec 18, 2007 at 03:42:03AM +1300, Sam Vilain wrote:
> Refer attached ... 1.5.3.6 install, didn't get git-init link to git.
> Ring any bells?
I just tried it and it worked OK. Note that the hardlinks are the _last_
part of the install procedure, even after doing the perl and git-gui
subdirectories. Are we sure the "make install" actually made it to
completion?
-Peff
^ permalink raw reply
* Solaris install error: didn't get git-init link was [Fwd: Re: The Reposithon! Take 2]
From: Sam Vilain @ 2007-12-17 14:42 UTC (permalink / raw)
To: Git Mailing List
[-- Attachment #1: Type: text/plain, Size: 85 bytes --]
Refer attached ... 1.5.3.6 install, didn't get git-init link to git.
Ring any bells?
[-- Attachment #2: Re: The Reposithon! Take 2.eml --]
[-- Type: message/rfc822, Size: 3339 bytes --]
From: Andrew Dougherty <doughera@lafayette.edu>
To: "H.Merijn Brand" <h.m.brand@xs4all.nl>
Cc: perl5-porters@perl.org
Subject: Re: The Reposithon! Take 2
Date: Mon, 17 Dec 2007 09:32:39 -0500 (EST)
Message-ID: <Pine.LNX.4.64.0712170910420.22480@fractal.phys.lafayette.edu>
On Mon, 17 Dec 2007, H.Merijn Brand wrote:
> I don't say porting git to HP-UX was/is easy, but at least I got it building
> in less than four hours without having to depend on other projects. I gave
> up on SVN after three days and not having any runnable part of svn at all.
My experiences on Solaris are about equally painful, but reversed. I ended
up hand-editing svn's configure scripts to get them to work at all. It
took about a day of on-and-off effort, but it does now seem to work.
Git took about half a day to get to build and install, but alas it
doesn't seem to work:
$ git-clone git://git.utsl.gen.nz/p4-metadata
/home/doughera/git/bin/git-clone: git-init: command not found
Usage: /home/doughera/git/bin/git-clone [--template=<template_directory>] [--reference <reference-repo>] [--bare] [-l [-s]] [-q] [-u <upload-pack>] [--origin <name>] [--depth <n>] [-n] <repo> [<dir>]
$ git --version
git version 1.5.3.6
Indeed, I have no 'git-init' command anywhere to be found. I have no
idea if this is normal. It's probably something simple, but I probably
won't have time to investigate until January sometime.
Sigh.
On the other hand, I certainly agree that the discussion has been
constructive and positive. Sam's done a wonderful job working on
converting the perforce repository and sharing his work with the broader
community.
--
Andy Dougherty doughera@lafayette.edu
^ permalink raw reply
* Re: add -i not able to find get_colorbool
From: Jeff King @ 2007-12-17 14:31 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0712171400250.9446@racer.site>
On Mon, Dec 17, 2007 at 02:04:21PM +0000, Johannes Schindelin wrote:
> The second line of git-add--interactive reads thusly:
>
> use lib (split(/:/, $ENV{GITPERLLIB} ||
> "/home/gitte/lib/perl5/site_perl/5.8.8"));
>
> and this puzzles me:
>
> $ grep -n get_colorbool /home/gitte/lib/perl5/site_perl/5.8.8/Git.pm
> 584:=item get_colorbool ( NAME )
> 591:sub get_colorbool {
>
> So it has it, but cannot locate get_colorbool?
That does seem odd. Can you try running git-add--interactive in the perl
debugger and doing this:
x \&Git::get_colorbool
x \&Git::repository
It should tell you where it is getting the functions from (in the first
case, it will presumably not find it at all, but you seem to have a
Git::repository, so it should point to the file that has been loaded).
-Peff
^ permalink raw reply
* add -i not able to find get_colorbool
From: Johannes Schindelin @ 2007-12-17 14:04 UTC (permalink / raw)
To: git
Hi,
I did not use "git add -i" in something like two weeks, and now it stopped
working:
$ git add -i
Can't locate object method "get_colorbool" via package "Git" at
/home/gitte/bin/git-add--interactive line 15.
The second line of git-add--interactive reads thusly:
use lib (split(/:/, $ENV{GITPERLLIB} ||
"/home/gitte/lib/perl5/site_perl/5.8.8"));
and this puzzles me:
$ grep -n get_colorbool /home/gitte/lib/perl5/site_perl/5.8.8/Git.pm
584:=item get_colorbool ( NAME )
591:sub get_colorbool {
So it has it, but cannot locate get_colorbool?
Help,
Dscho
^ permalink raw reply
* Re: [PATCH] Have a flag to stop the option parsing at the first argument.
From: Wincent Colaiuta @ 2007-12-17 13:57 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Pierre Habouzit, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0712171328020.9446@racer.site>
El 17/12/2007, a las 14:30, Johannes Schindelin escribió:
>> But leaving -p aside, will you oppose any patches that make it
>> possible
>> for people to write stuff like:
>>
>> git init --bare
>>
>> Personally, I think this is an obvious usability improvement worth
>> striving for. Given that "git --bare init" will continue to work
>> under
>> what I'm proposing, I really can't see any worthwhile argument
>> against
>> it. Because we're talking about a UI improvement for newcomers at no
>> cost to old timers.
>
> My reasoning is like as for "-p". "--bare" is not special to
> "init". It
> makes git not guess, but work on the current directory as a bare
> repository.
Yes, I know what --bare does. It seems to me your argument is as
follows:
- "git subcommand" is actually "git" (which does setup) followed by
"git-subcommand" (which performs an action)[*]
- the newcomer should be taught this, and know which options go
between "git" and "subcommand" and which options go after
- even though there is a straightforward way to have "git subcommand
specials args" work without breaking compatibility, you oppose it on
the grounds that users should know how Git works
- the fact that CVS also has some options that go before the
subcommand makes it OK for git to do the same
- even though we could have a better UI that didn't require any of
this explanation at all, we should keep the UI we have seeing as it is
easy to explain
And possibly some combination of these two as well:
- requiring arguments to be inserted between "git" and "subcommand"
doesn't undermine the effort to make git appear like a single tool to
users
- the effort to move to dashless forms has nothing to do with
presenting git as a single tool to users
Well, I basically disagree with you on most of these points; all but
the first one(*), really. I think it's fairly clear what both you and
I think on this and I'm not very interested in debating it further; I
am more interested in hearing other people's points on this to get a
feeling for whether there is a consensus (or lack thereof).
Cheers,
Wincent
^ permalink raw reply
* [PATCH] Actually add config variable diff.external
From: Johannes Schindelin @ 2007-12-17 13:42 UTC (permalink / raw)
To: Schuberth, Sebastian; +Cc: git, gitster
In-Reply-To: <Pine.LNX.4.64.0712171220540.9446@racer.site>
We had the diff.external variable in the documentation of the config
file since its conception, but failed to respect it.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
On Mon, 17 Dec 2007, Johannes Schindelin wrote:
> Subject: [PATCH] Document diff.external and mergetool.<tool>.path
>
> There was no documentation for the config variables
> diff.external and mergetool.<tool>.path.
Heh. Missed that diff.external was actually never implemented...
Also noticed by Sebastian.
diff.c | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/diff.c b/diff.c
index 7d17754..a49c36a 100644
--- a/diff.c
+++ b/diff.c
@@ -20,6 +20,7 @@
static int diff_detect_rename_default;
static int diff_rename_limit_default = 100;
static int diff_use_color_default;
+static const char *external_diff_cmd_cfg;
int diff_auto_refresh_index = 1;
static char diff_colors[][COLOR_MAXLEN] = {
@@ -163,6 +164,10 @@ int git_diff_ui_config(const char *var, const char *value)
diff_auto_refresh_index = git_config_bool(var, value);
return 0;
}
+ if (!strcmp(var, "diff.external")) {
+ external_diff_cmd_cfg = xstrdup(value);
+ return 0;
+ }
if (!prefixcmp(var, "diff.")) {
const char *ep = strrchr(var, '.');
@@ -209,6 +214,8 @@ static const char *external_diff(void)
if (done_preparing)
return external_diff_cmd;
external_diff_cmd = getenv("GIT_EXTERNAL_DIFF");
+ if (!external_diff_cmd)
+ external_diff_cmd = external_diff_cmd_cfg;
done_preparing = 1;
return external_diff_cmd;
}
--
1.5.4.rc0.59.g1d10d
^ permalink raw reply related
* Re: [PATCH] Have a flag to stop the option parsing at the first argument.
From: Johannes Schindelin @ 2007-12-17 13:30 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Pierre Habouzit, Junio C Hamano, git
In-Reply-To: <223E3B44-92DA-4861-83D6-67E56F70E784@wincent.com>
Hi,
On Mon, 17 Dec 2007, Wincent Colaiuta wrote:
> El 17/12/2007, a las 13:55, Johannes Schindelin escribi?:
>
> > I never had any problems explaining why "-p" goes before the
> > subcommand here. Never.
>
> Would be even better if there was nothing to explain and it all just
> worked, which is what I'm proposing here. As I said, -p is the only
> special option which clashes with any non-special uses.
Even in the best of circumstances, you have to teach people a little.
> But leaving -p aside, will you oppose any patches that make it possible
> for people to write stuff like:
>
> git init --bare
>
> Personally, I think this is an obvious usability improvement worth
> striving for. Given that "git --bare init" will continue to work under
> what I'm proposing, I really can't see any worthwhile argument against
> it. Because we're talking about a UI improvement for newcomers at no
> cost to old timers.
My reasoning is like as for "-p". "--bare" is not special to "init". It
makes git not guess, but work on the current directory as a bare
repository.
In my experience, it is easier to give people a clear-cut distinction
between different concepts. Then way fewer surprises will hassle them
later.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Have a flag to stop the option parsing at the first argument.
From: Wincent Colaiuta @ 2007-12-17 13:12 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Pierre Habouzit, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0712171253290.9446@racer.site>
El 17/12/2007, a las 13:55, Johannes Schindelin escribió:
> On Mon, 17 Dec 2007, Wincent Colaiuta wrote:
>
>> El 17/12/2007, a las 13:26, Johannes Schindelin escribi?:
>>
>>> I think it is wrong to go out of our way to support "git status -
>>> p" as
>>> a synonym to "git -p status". I simply do not believe that
>>> newcomers
>>> are not intelligent enough to understand that "git -p <subcommand>"
>>> means that the output goes into their pager.
>>
>> But the point is, of all the special options, -p is the *only* that
>> can't unambiguously go after the subcommand.
>
> It should not be put after the subcommand. That's my point. Exactly
> because it is -- even conceptually -- no subcommand option.
>
> CVS has many shortcomings, but one lesson here is that people had no
> problems with "cvs -z3 update -d -P". See, the "-z3" is an option
> that
> has nothing to do with the subcommand.
>
> Exactly the same situation here. I never had any problems
> explaining why
> "-p" goes before the subcommand here. Never.
Would be even better if there was nothing to explain and it all just
worked, which is what I'm proposing here. As I said, -p is the only
special option which clashes with any non-special uses.
But leaving -p aside, will you oppose any patches that make it
possible for people to write stuff like:
git init --bare
Personally, I think this is an obvious usability improvement worth
striving for. Given that "git --bare init" will continue to work under
what I'm proposing, I really can't see any worthwhile argument against
it. Because we're talking about a UI improvement for newcomers at no
cost to old timers.
Cheers,
Wincent
^ permalink raw reply
* Re: [PATCH] Have a flag to stop the option parsing at the first argument.
From: Johannes Schindelin @ 2007-12-17 12:55 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Pierre Habouzit, Junio C Hamano, git
In-Reply-To: <26962818-F702-44D2-BD26-95D74CE21F0D@wincent.com>
Hi,
On Mon, 17 Dec 2007, Wincent Colaiuta wrote:
> El 17/12/2007, a las 13:26, Johannes Schindelin escribi?:
>
> > I think it is wrong to go out of our way to support "git status -p" as
> > a synonym to "git -p status". I simply do not believe that newcomers
> > are not intelligent enough to understand that "git -p <subcommand>"
> > means that the output goes into their pager.
>
> But the point is, of all the special options, -p is the *only* that
> can't unambiguously go after the subcommand.
It should not be put after the subcommand. That's my point. Exactly
because it is -- even conceptually -- no subcommand option.
CVS has many shortcomings, but one lesson here is that people had no
problems with "cvs -z3 update -d -P". See, the "-z3" is an option that
has nothing to do with the subcommand.
Exactly the same situation here. I never had any problems explaining why
"-p" goes before the subcommand here. Never.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Re-re-re-fix common tail optimization
From: Johannes Schindelin @ 2007-12-17 12:51 UTC (permalink / raw)
To: Johannes Sixt
Cc: Wincent Colaiuta, Jeff King, Junio C Hamano, Linus Torvalds, git
In-Reply-To: <476669A7.1050407@viscovery.net>
Hi,
On Mon, 17 Dec 2007, Johannes Sixt wrote:
> Wincent Colaiuta schrieb:
> > El 17/12/2007, a las 12:57, Johannes Schindelin escribi?:
> >
> >> Hmm. There is some chicken-and-egg problem here (I read the thread, but
> >> did not really see a problem, as I assumed that _other_ tests would
> >> assure
> >> that "git diff --no-index" works as expected).
> >>
> >> But as at least one released version of GNU diff has a pretty serious
> >> bug,
> >> I would rather not rely too much on diff. (BTW this was the reason I
> >> wanted --no-index so badly.)
> >>
> >> So yeah, the second "diff" cannot be "git diff". Maybe "cmp", but not
> >> "git diff".
> >
> > Well cmp would be fine as well, seeing all we want is a boolean "is
> > this the same or not" answer. (I'm not familiar with the GNU diff bug
> > you speak of, but was it so bad that it couldn't even get *that*
> > answer right?)
>
> Heh, there's at least one distribution out there (Suse 10.1) that comes
> with a *cmp* that doesn't get that answer right if its output is
> connected to /dev/null, which is the case when you simply 'make test'.
Yeah. That's what it was. I even posted a patch to GNU diff, only to
find out that it was already fixed in CVS. Sigh.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Have a flag to stop the option parsing at the first argument.
From: Wincent Colaiuta @ 2007-12-17 12:40 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Pierre Habouzit, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0712171223210.9446@racer.site>
El 17/12/2007, a las 13:26, Johannes Schindelin escribió:
> Hi,
>
> On Mon, 17 Dec 2007, Wincent Colaiuta wrote:
>
>> Yes, we know what it does because we know that "git ... log ..." is
>> actually two commands and each one handles one of the -p switches,
>> but
>> it is much easier to present git as a single tool to the newcomer
>> (and I
>> guess I don't need to argue that case here seeing as the decision has
>> already been taken long ago to talk using dashless forms), and it is
>> much easier to explain to a newcomer something like:
>>
>> git log --paginate -p
>>
>> Than:
>>
>> git -p log -p
>
> How about
>
> git log -p
>
> Hmm?
>
> Fact is: you make the tool easier by having sane defaults. Not by
> moving
> around command line options. The option "-p" for git is an option
> that
> holds for _all_ subcommands. That's why it belongs _before_ the
> subcommand.
>
>> But it doesn't really matter. The proposed changes allow old-timers
>> to
>> continue putting their special options between the "git" and the
>> "command". If you don't want to deprecate the -p special because of
>> the
>> confusion it might cause, I think we should at least not give it a
>> very
>> prominent place in the documentation, nor use it any examples.
>
> I think it is wrong to go out of our way to support "git status -p"
> as a
> synonym to "git -p status". I simply do not believe that newcomers
> are
> not intelligent enough to understand that "git -p <subcommand>"
> means that
> the output goes into their pager.
But the point is, of all the special options, -p is the *only* that
can't unambiguously go after the subcommand.
I'm arguing that the world would be a simpler place, friendlier to
newcomers if *all* git commands looked like "git subcommand opts...",
and at the moment -p is the only obstacle to making this so. And just
in case it's necessary to restate this, I am not proposing removing
support for the git specials subcommand opts..." form; I'm just trying
to make it so that we don't have to advertise it so prominently. This
seems to be the natural complement to the move to dashless forms.
Cheers,
Wincent
^ 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