* Re: [PATCH] Don't rely on unspecified behavior
From: Johannes Schindelin @ 2007-07-28 20:17 UTC (permalink / raw)
To: Thomas Schwinge; +Cc: git
In-Reply-To: <20070728194306.GA32203@fencepost.gnu.org>
Hi,
On Sat, 28 Jul 2007, Thomas Schwinge wrote:
> On Sat, Jul 28, 2007 at 08:30:07PM +0100, Johannes Schindelin wrote:
> > On Sat, 28 Jul 2007, Thomas Schwinge wrote:
> > > Calling access(p, m) with p == NULL is not specified, so don't do that. On
> > > GNU/Hurd systems doing so will result in a SIGSEGV.
> > >
> > > Signed-off-by: Thomas Schwinge <tschwinge@gnu.org>
> > > ---
> >
> > Isn't this the same patch as you sent before?
>
> As I wrote in <20070728182542.GA22651@fencepost.gnu.org>: ``I noticed
> that the patch I sent was prepared for an old version of the file. I'll
> send an updated patch that applies to the current revision.''
Ah.
> > > + if (excludes_file != NULL && !access(excludes_file, R_OK))
> >
> > We usually omit the "!= NULL"; see the other source code in git.git.
>
> Okay, so I should sent a thusly modified version to get it applied?
I don't think that is necessary; a small change like this is usually fixed
by Junio with --amend.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Don't rely on unspecified behavior
From: Johannes Schindelin @ 2007-07-28 20:16 UTC (permalink / raw)
To: Thomas Glanzmann; +Cc: GIT
In-Reply-To: <20070728193402.GE23337@cip.informatik.uni-erlangen.de>
Hi,
On Sat, 28 Jul 2007, Thomas Glanzmann wrote:
> > Isn't this the same patch as you sent before?
>
> > > @@ -74,7 +74,7 @@ static void fill_directory(struct dir_struct *dir, const char **pathspec)
> > > @@ -60,7 +60,7 @@ static void fill_directory(struct dir_struct *dir, const char **pathspec,
> ~~~~~ ~~~~~ ~
>
> The offset of the diff has changed. Not that git couldn't sort it out by
> itself. And the function had one or more parameters less.
Ah. Thanks for the explanation.
Ciao,
Dscho
^ permalink raw reply
* Re: ru.po updated
From: Johannes Schindelin @ 2007-07-28 20:15 UTC (permalink / raw)
To: Irina Riesen; +Cc: git
In-Reply-To: <7a842a5a0707281225m6c3cfdc3r4cd5a2476364d508@mail.gmail.com>
Hi,
On Sat, 28 Jul 2007, Irina Riesen wrote:
> I've just updated the russian translation of git-gui
> and pushed it into mob branch.
I've already seen it, and pushed it to the master branch. Thanks!
Ciao,
Dscho
^ permalink raw reply
* Re: suggestion for git rebase -i
From: Johannes Schindelin @ 2007-07-28 20:09 UTC (permalink / raw)
To: Seth Falcon; +Cc: git
In-Reply-To: <m2vec4seyf.fsf@ziti.fhcrc.org>
Hi,
On Sat, 28 Jul 2007, Seth Falcon wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> > Why? This is an implementation detail, and should not concern the
> > user.
>
> In the context of an existing editing session, the name of the tempfile
> is visible and relevant to the user (not just an implementation detail).
> For example, the tempfile name is useful when multi-tasking and one
> needs to get back to the buffer. As another reply pointed out, the name
> could also be used for editor mode customization.
Okay, fair enough. But since you want that feature, you get to do the
patch. Hint: it is just one line that has to be changed.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Add a --user option to git-config
From: Johannes Schindelin @ 2007-07-28 20:04 UTC (permalink / raw)
To: Ramsay Jones; +Cc: Junio C Hamano, GIT Mailing-list
In-Reply-To: <46AB7041.8070605@ramsay1.demon.co.uk>
Hi,
On Sat, 28 Jul 2007, Ramsay Jones wrote:
>
> At present, the --global option is something of a misnomer, so
> we introduce the --user option as a synonym, with the intention
> of removing the old option in the future.
Ack for the intention, except for "removing the old option in the future".
We do not need to advertise it, but breaking existing functionality, which
might be used by scripts and aliases is bad.
Ciao,
Dscho
^ permalink raw reply
* Re: git-svn rebase screwing up commit messages
From: Robin Rosenberg @ 2007-07-28 19:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sean, Benoit SIGOURE, git
In-Reply-To: <7vk5skps1g.fsf@assigned-by-dhcp.cox.net>
lördag 28 juli 2007 skrev Junio C Hamano:
> Sean <seanlkml@sympatico.ca> writes:
>
> >> Having said all that, so that the readers understand the
> >> background, here is a not-so-heavily-tested patch, which might
> >> help. It passes all the test suite as before, but that tells
> >> how existing git-svn tests do not test many things.
> >>
> >> I am not considering this for inclusion right now, by the way.
> >
> > FWIW your patch fixed my test case here.
>
> Actually the patched behaviour actively encourages a bad (not in
> the sense that those oneline tools will not work well, but in
> the sense that these messages are reader unfriendly) practice; I
> do not think what the patch did deserves to be called "fixed".
git-svn should not enforce git conventions when managing commits
intended for svn. Those commits should obviously follow the conventions
for the target (svn) repo.
-- robin
^ permalink raw reply
* Re: [PATCH] Don't rely on unspecified behavior
From: Thomas Schwinge @ 2007-07-28 19:43 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0707282028130.14781@racer.site>
[-- Attachment #1: Type: text/plain, Size: 838 bytes --]
Hello!
On Sat, Jul 28, 2007 at 08:30:07PM +0100, Johannes Schindelin wrote:
> On Sat, 28 Jul 2007, Thomas Schwinge wrote:
> > Calling access(p, m) with p == NULL is not specified, so don't do that. On
> > GNU/Hurd systems doing so will result in a SIGSEGV.
> >
> > Signed-off-by: Thomas Schwinge <tschwinge@gnu.org>
> > ---
>
> Isn't this the same patch as you sent before?
As I wrote in <20070728182542.GA22651@fencepost.gnu.org>: ``I noticed
that the patch I sent was prepared for an old version of the file. I'll
send an updated patch that applies to the current revision.''
> > + if (excludes_file != NULL && !access(excludes_file, R_OK))
>
> We usually omit the "!= NULL"; see the other source code in git.git.
Okay, so I should sent a thusly modified version to get it applied?
Regards,
Thomas
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: [PATCH 3/8] Clean up work-tree handling
From: Johannes Schindelin @ 2007-07-28 19:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, matled
In-Reply-To: <7vd4ycsrrt.fsf@assigned-by-dhcp.cox.net>
Hi,
On Sat, 28 Jul 2007, Junio C Hamano wrote:
> Outside of a work tree, I think the only two semi-sensible behaviours
> exist. Either tell the user that we cannot understand what "." should
> mean in that context and error out (IOW, "Not inside a work tree"), or
> assume that the user meant "from the top". So in such a case, if we do
> not want to error out to make things more "convenient", one possibility
> would be:
>
> * give empty as prefix;
>
> * give absolute or cwd relative path to the work tree for cdup
> (it would not be a sequence of ../ anyway in this case).
I am happy that you agree with the way I implemented it...
> I think this is in line with the traditional behaviour when GIT_DIR is
> explicitly given. We assume the cwd is the toplevel, and return empty
> prefix and empty cdup.
Yes, I want that behaviour.
> Having said that, I am not convinced that "assume toplevel outside of a
> work tree" is a win for the end users. If the command errors out with a
> message telling the user that relative path does not make sense from
> outside a work tree, the user would understand. If the command does not
> error out but always works relative to the toplevel without explanation,
> it might confuse the user more until the he realizes "assume toplevel
> outside of a work tree" is the rule that is applying to his case.
There are two reasons against that...
- it is really convenient to be able to say "git add .vimrc" (think Martin
Krafft's desired setup). Let's just put some uppercase warning at the
side of --work-tree in git-init.txt to tell the user about the
behaviour.
- the implementation of "you are not in the worktree" would not be
elegant: "git log" should succeed, "git log dir/file" should not.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Don't rely on unspecified behavior
From: Thomas Glanzmann @ 2007-07-28 19:34 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: GIT
In-Reply-To: <Pine.LNX.4.64.0707282028130.14781@racer.site>
Hello Dscho,
> Isn't this the same patch as you sent before?
> > @@ -74,7 +74,7 @@ static void fill_directory(struct dir_struct *dir, const char **pathspec)
> > @@ -60,7 +60,7 @@ static void fill_directory(struct dir_struct *dir, const char **pathspec,
~~~~~ ~~~~~ ~
The offset of the diff has changed. Not that git couldn't sort it out by
itself. And the function had one or more parameters less.
Thomas
^ permalink raw reply
* Re: [PATCH] Don't rely on unspecified behavior
From: Johannes Schindelin @ 2007-07-28 19:30 UTC (permalink / raw)
To: Thomas Schwinge; +Cc: git
In-Reply-To: <11856471952272-git-send-email-tschwinge@gnu.org>
Hi,
On Sat, 28 Jul 2007, Thomas Schwinge wrote:
> Calling access(p, m) with p == NULL is not specified, so don't do that. On
> GNU/Hurd systems doing so will result in a SIGSEGV.
>
> Signed-off-by: Thomas Schwinge <tschwinge@gnu.org>
> ---
Isn't this the same patch as you sent before?
> builtin-add.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/builtin-add.c b/builtin-add.c
> index 7345479..de5c108 100644
> --- a/builtin-add.c
> +++ b/builtin-add.c
> @@ -60,7 +60,7 @@ static void fill_directory(struct dir_struct *dir, const char **pathspec,
> path = git_path("info/exclude");
> if (!access(path, R_OK))
> add_excludes_from_file(dir, path);
> - if (!access(excludes_file, R_OK))
> + if (excludes_file != NULL && !access(excludes_file, R_OK))
We usually omit the "!= NULL"; see the other source code in git.git.
Ciao,
Dscho
^ permalink raw reply
* ru.po updated
From: Irina Riesen @ 2007-07-28 19:25 UTC (permalink / raw)
To: git
I've just updated the russian translation of git-gui
and pushed it into mob branch.
Enjoy,
Irina Riesen
^ permalink raw reply
* [PATCH v3] gitk: let you easily specify lines of context in diff view
From: Steffen Prohaska @ 2007-07-28 19:18 UTC (permalink / raw)
To: paulus; +Cc: git, Steffen Prohaska
In-Reply-To: <11855366703782-git-send-email-prohaska@zib.de>
More lines of context sometimes help to better understand a diff.
This patch introduces a text field above the box displaying the
blobdiffs. You can type in the number of lines of context that
you wish to view. The number of lines of context is initially
always set to 3.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
gitk | 41 +++++++++++++++++++++++++++++++++++++++--
1 files changed, 39 insertions(+), 2 deletions(-)
rebased to the current master.
Steffen
diff --git a/gitk b/gitk
index f74ce51..670a162 100755
--- a/gitk
+++ b/gitk
@@ -517,6 +517,7 @@ proc makewindow {} {
global textfont mainfont uifont tabstop
global findtype findtypemenu findloc findstring fstring geometry
global entries sha1entry sha1string sha1but
+ global diffcontextstring diffcontext
global maincursor textcursor curtextcursor
global rowctxmenu fakerowmenu mergemax wrapcomment
global highlight_files gdttype
@@ -731,7 +732,16 @@ proc makewindow {} {
-command changediffdisp -variable diffelide -value {0 1}
radiobutton .bleft.mid.new -text "New version" \
-command changediffdisp -variable diffelide -value {1 0}
- pack .bleft.mid.diff .bleft.mid.old .bleft.mid.new -side left
+ label .bleft.mid.labeldiffcontext -text " Lines of context: " \
+ -font $uifont
+ spinbox .bleft.mid.diffcontext -width 5 -font $textfont \
+ -from 1 -increment 1 -to 10000000 \
+ -validate all -validatecommand "diffcontextvalidate %P" \
+ -textvariable diffcontextstring
+ .bleft.mid.diffcontext set $diffcontext
+ trace add variable diffcontextstring write diffcontextchange
+ lappend entries .bleft.mid.diffcontext
+ pack .bleft.mid.diff .bleft.mid.old .bleft.mid.new .bleft.mid.labeldiffcontext .bleft.mid.diffcontext -side left
set ctext .bleft.ctext
text $ctext -background $bgcolor -foreground $fgcolor \
-tabs "[expr {$tabstop * $charspc}]" \
@@ -4985,12 +4995,37 @@ proc gettreediffline {gdtf ids} {
return 0
}
+# empty strings or integers accepted
+proc diffcontextvalidate {v} {
+ if {[string length $v] == 0} {
+ return 1
+ }
+ if {[string is integer $v]} {
+ if {$v > 0} {
+ return 1
+ }
+ }
+ return 0
+}
+
+proc diffcontextchange {n1 n2 op} {
+ global diffcontextstring diffcontext
+
+ if {[string is integer $diffcontextstring]} {
+ if {$diffcontextstring > 0} {
+ set diffcontext $diffcontextstring
+ reselectline
+ }
+ }
+}
+
proc getblobdiffs {ids} {
global diffopts blobdifffd diffids env
global diffinhdr treediffs
+ global diffcontext
set env(GIT_DIFF_OPTS) $diffopts
- if {[catch {set bdf [open [diffcmd $ids {-p -C --no-commit-id}] r]} err]} {
+ if {[catch {set bdf [open [diffcmd $ids "-p -C --no-commit-id -U$diffcontext"] r]} err]} {
puts "error getting diffs: $err"
return
}
@@ -7646,6 +7681,8 @@ set markingmatches 0
set optim_delay 16
+set diffcontext 3
+
set nextviewnum 1
set curview 0
set selectedview 0
--
1.5.3.rc3.45.g4c741
^ permalink raw reply related
* [PATCH] Don't rely on unspecified behavior
From: Thomas Schwinge @ 2007-07-28 18:26 UTC (permalink / raw)
To: git; +Cc: Thomas Schwinge
In-Reply-To: <20070728173948.GD23337@cip.informatik.uni-erlangen.de>
Calling access(p, m) with p == NULL is not specified, so don't do that. On
GNU/Hurd systems doing so will result in a SIGSEGV.
Signed-off-by: Thomas Schwinge <tschwinge@gnu.org>
---
builtin-add.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-add.c b/builtin-add.c
index 7345479..de5c108 100644
--- a/builtin-add.c
+++ b/builtin-add.c
@@ -60,7 +60,7 @@ static void fill_directory(struct dir_struct *dir, const char **pathspec,
path = git_path("info/exclude");
if (!access(path, R_OK))
add_excludes_from_file(dir, path);
- if (!access(excludes_file, R_OK))
+ if (excludes_file != NULL && !access(excludes_file, R_OK))
add_excludes_from_file(dir, excludes_file);
}
--
1.5.3.rc3.26.g6c58-dirty
^ permalink raw reply related
* Re: [PATCH] Don't rely on unspecified behavior
From: Thomas Schwinge @ 2007-07-28 18:25 UTC (permalink / raw)
To: Thomas Glanzmann; +Cc: git, Michael Gernoth
In-Reply-To: <20070728173948.GD23337@cip.informatik.uni-erlangen.de>
[-- Attachment #1: Type: text/plain, Size: 1038 bytes --]
Hello!
On Sat, Jul 28, 2007 at 07:39:48PM +0200, Thomas Glanzmann wrote:
> > Calling access(p, m) with p == NULL is not specified, so don't do
> > that. On GNU/Hurd systems doing so will result in an SIGSEGV.
>
> a friend of mine choked on this one when tried git for the second time
> (the first time "git-repack -a -d -f" screwed his repository after the
> initial checkout. This is fixed for a long time). Lucky me that he had
> his libusbdriver in LD_PRELOAD which could not handle the NULL argument.
> And I always thought libc would make the check before it does the system
> call or does GNU/hurts not use the gnu libc?
GNU/Hurd systems do (obviously ;-) use the GNU libc. The glibc
maintainer Roland McGrath explicitly told me that ``access (NULL, m)''
shall not be caught as it is not specified and thus must not be invoked
like this.
I noticed that the patch I sent was prepared for an old version of the
file. I'll send an updated patch that applies to the current revision.
Regards,
Thomas
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: git diff with add/modified codes
From: Jon Smirl @ 2007-07-28 18:07 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <f8fn72$l30$1@sea.gmane.org>
On 7/28/07, Jakub Narebski <jnareb@gmail.com> wrote:
> Jeff King wrote:
>
> > On Fri, Jul 27, 2007 at 08:17:54PM -0400, Jon Smirl wrote:
> >
> >> That's not what I want. I'm looking a report that indicates new files
> >> vs modified ones in a single list. These old patches I am working with
> >> often create 100 files and modify another 200.
> >>
> >> Adding a code like (Added (A), Copied (C), Deleted (D), Modified (M),
> >> Renamed (R)) to --stat would be perfect.
> >
> > How about --name-status?
>
> Or -r --name-status?
-r is not in the git diff doc but it is used in the examples.
http://www.kernel.org/pub/software/scm/git/docs/git-diff.html
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH] Make verify-tag a builtin.
From: Carlos Rica @ 2007-07-28 18:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin
In-Reply-To: <7vtzrpwo44.fsf@assigned-by-dhcp.cox.net>
Your explanation about the I/O in parallel sounds much better to me,
now I understand, thank you Junio.
2007/7/27, Junio C Hamano <gitster@pobox.com>:
> What is happening is:
>
> 1. Your process prepares the whole thing in vtag-tmp, to hand
> to gpg;
>
> 2. You make a pipe and start gpg with the above file telling it
> "here is a detached signature file, the payload will be fed
> through your stdin";
>
> 3-a. You feed the payload to the pipe, expecting gpg to read it.
>
> 3-b. gpg reads the detached signature file, finds no signature in
> the vtag-tmp file because the tag in question is not signed,
> and exits without reading a single byte from the pipe;
>
> Now, 3-a and 3-b run in parallel. If 3-a is scheduled before
> 3-b happens, because payload is very often much smaller than the
> in-kernel pipe buffer, your write(2) succeeds before gpg gives up
> and exits without reading from the pipe. If 3-b is scheduled
> before 3-a, then gpg exits and when 3-a gets around to write(2)
> to the pipe, write notices that there is nobody on the other end
> of the pipe, and you get SIGPIPE.
^ permalink raw reply
* Re: [PATCH] Don't rely on unspecified behavior
From: Thomas Glanzmann @ 2007-07-28 17:39 UTC (permalink / raw)
To: Thomas Schwinge; +Cc: git, Michael Gernoth
In-Reply-To: <11856407791617-git-send-email-tschwinge@gnu.org>
Hello,
> Calling access(p, m) with p == NULL is not specified, so don't do
> that. On GNU/Hurd systems doing so will result in an SIGSEGV.
a friend of mine choked on this one when tried git for the second time
(the first time "git-repack -a -d -f" screwed his repository after the
initial checkout. This is fixed for a long time). Lucky me that he had
his libusbdriver in LD_PRELOAD which could not handle the NULL argument.
And I always thought libc would make the check before it does the system
call or does GNU/hurts not use the gnu libc?
Thomas
^ permalink raw reply
* [PATCH] Add a --user option to git-config
From: Ramsay Jones @ 2007-07-28 16:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: GIT Mailing-list
At present, the --global option is something of a misnomer, so
we introduce the --user option as a synonym, with the intention
of removing the old option in the future.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
---
I have recently had the need to create a ~/.gitconfig file for the
first time and I was reminded of this patch. Maybe it's just me who
thinks that --global is odd ... ;-) Particularly since the system
config file was added.
Actually my config editor of choice is vim, so this is not a high
priority for me.
[This is against 1.5.2, but will hopefully not be too difficult to
forward to current git]
ATB,
Ramsay Jones
Documentation/git-config.txt | 30 +++++++++++++++---------------
Documentation/git-repo-config.txt | 2 +-
Documentation/tutorial.txt | 4 ++--
Documentation/user-manual.txt | 2 +-
builtin-config.c | 5 +++--
contrib/completion/git-completion.bash | 2 +-
ident.c | 2 +-
7 files changed, 24 insertions(+), 23 deletions(-)
diff --git a/Documentation/git-config.txt b/Documentation/git-config.txt
index 280ef20..26138c4 100644
--- a/Documentation/git-config.txt
+++ b/Documentation/git-config.txt
@@ -3,22 +3,22 @@ git-config(1)
NAME
----
-git-config - Get and set repository or global options
+git-config - Get and set repository, user or system-wide options
SYNOPSIS
--------
[verse]
-'git-config' [--system | --global] [type] name [value [value_regex]]
-'git-config' [--system | --global] [type] --add name value
-'git-config' [--system | --global] [type] --replace-all name [value [value_regex]]
-'git-config' [--system | --global] [type] --get name [value_regex]
-'git-config' [--system | --global] [type] --get-all name [value_regex]
-'git-config' [--system | --global] [type] --unset name [value_regex]
-'git-config' [--system | --global] [type] --unset-all name [value_regex]
-'git-config' [--system | --global] [type] --rename-section old_name new_name
-'git-config' [--system | --global] [type] --remove-section name
-'git-config' [--system | --global] -l | --list
+'git-config' [--system | --user] [type] name [value [value_regex]]
+'git-config' [--system | --user] [type] --add name value
+'git-config' [--system | --user] [type] --replace-all name [value [value_regex]]
+'git-config' [--system | --user] [type] --get name [value_regex]
+'git-config' [--system | --user] [type] --get-all name [value_regex]
+'git-config' [--system | --user] [type] --unset name [value_regex]
+'git-config' [--system | --user] [type] --unset-all name [value_regex]
+'git-config' [--system | --user] [type] --rename-section old_name new_name
+'git-config' [--system | --user] [type] --remove-section name
+'git-config' [--system | --user] -l | --list
DESCRIPTION
-----------
@@ -47,7 +47,7 @@ This command will fail if:
. the section or key is invalid,
. you try to unset an option which does not exist,
. you try to unset/set an option for which multiple lines match, or
-. you use --global option without $HOME being properly set.
+. you use --user option without $HOME being properly set.
OPTIONS
@@ -73,8 +73,8 @@ OPTIONS
--get-regexp::
Like --get-all, but interprets the name as a regular expression.
---global::
- Use global ~/.gitconfig file rather than the repository .git/config.
+--user::
+ Use per user ~/.gitconfig file rather than the repository .git/config.
--system::
Use system-wide $(prefix)/etc/gitconfig rather than the repository
@@ -110,7 +110,7 @@ ENVIRONMENT
GIT_CONFIG::
Take the configuration from the given file instead of .git/config.
- Using the "--global" option forces this to ~/.gitconfig.
+ Using the "--user" option forces this to ~/.gitconfig.
GIT_CONFIG_LOCAL::
Currently the same as $GIT_CONFIG; when Git will support global
diff --git a/Documentation/git-repo-config.txt b/Documentation/git-repo-config.txt
index 2deba31..8eec3cd 100644
--- a/Documentation/git-repo-config.txt
+++ b/Documentation/git-repo-config.txt
@@ -3,7 +3,7 @@ git-repo-config(1)
NAME
----
-git-repo-config - Get and set repository or global options
+git-repo-config - Get and set repository, user or system-wide options
SYNOPSIS
diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt
index f55d408..a401638 100644
--- a/Documentation/tutorial.txt
+++ b/Documentation/tutorial.txt
@@ -20,8 +20,8 @@ public email address before doing any operation. The easiest
way to do so is:
------------------------------------------------
-$ git config --global user.name "Your Name Comes Here"
-$ git config --global user.email you@yourdomain.example.com
+$ git config --user user.name "Your Name Comes Here"
+$ git config --user user.email you@yourdomain.example.com
------------------------------------------------
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 52247aa..105e362 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1147,7 +1147,7 @@ The file specified by the `core.excludesfile` config directive:::
more information on configuration options). This config directive
can be set in the per-repo `.git/config` file, in which case the
exclude patterns will apply to that repo only. Alternatively, you
- can set the directive in the global `~/.gitconfig` file to apply
+ can set the directive in the per-user `~/.gitconfig` file to apply
the exclude pattern to all your git repos. As with the above
`.git/info/exclude` (and, indeed, with git config directives in
general), this directive does not follow push/pull/clone, but remain
diff --git a/builtin-config.c b/builtin-config.c
index b2515f7..1850d9d 100644
--- a/builtin-config.c
+++ b/builtin-config.c
@@ -2,7 +2,7 @@
#include "cache.h"
static const char git_config_set_usage[] =
-"git-config [ --global | --system ] [ --bool | --int ] [--get | --get-all | --get-regexp | --replace-all | --add | --unset | --unset-all] name [value [value_regex]] | --rename-section old_name new_name | --remove-section name | --list";
+"git-config [ --user | --system ] [ --bool | --int ] [--get | --get-all | --get-regexp | --replace-all | --add | --unset | --unset-all] name [value [value_regex]] | --rename-section old_name new_name | --remove-section name | --list";
static char *key;
static regex_t *key_regexp;
@@ -143,7 +143,8 @@ int cmd_config(int argc, const char **argv, const char *prefix)
type = T_BOOL;
else if (!strcmp(argv[1], "--list") || !strcmp(argv[1], "-l"))
return git_config(show_all_config);
- else if (!strcmp(argv[1], "--global")) {
+ else if (!strcmp(argv[1], "--user") ||
+ !strcmp(argv[1], "--global")) {
char *home = getenv("HOME");
if (home) {
char *user_config = xstrdup(mkpath("%s/.gitconfig", home));
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 46356e8..cb5a457 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -745,7 +745,7 @@ _git_config ()
case "$cur" in
--*)
__gitcomp "
- --global --list --replace-all
+ --user --list --replace-all
--get --get-all --get-regexp
--add --unset --unset-all
"
diff --git a/ident.c b/ident.c
index 69a04b8..21dca3a 100644
--- a/ident.c
+++ b/ident.c
@@ -182,7 +182,7 @@ static const char *env_hint =
" git config user.name \"Your Name\"\n"
"\n"
"To set the identity in this repository.\n"
-"Add --global to set your account\'s default\n"
+"Add --user to set your account\'s default\n"
"\n";
const char *fmt_ident(const char *name, const char *email,
--
1.5.2
^ permalink raw reply related
* Re: git-svn rebase screwing up commit messages
From: Benoit SIGOURE @ 2007-07-28 17:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vodhwptba.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 1655 bytes --]
On Jul 28, 2007, at 3:10 PM, Junio C Hamano wrote:
> Sean <seanlkml@sympatico.ca> writes:
>
>>> Do you mean by "my commits in Git" a commit you created with git
>>> in your git repository?
>>
>> Tested this here (rc3.24.g83b3d) and can confirm the reported
>> problem.
>> After making a commit in git and then running "git svn rebase" to
>> receive updates from the svn repo, the rebased commit has a borked
>> description (multi-lined commit message appears all on one line).
>
> In short, your original commit log message is broken.
>
> The recommended convention for commit messages is to start it
> with a single line that describes what it does, followed by a
> blank line (i.e. the first paragraph consists of a single line),
> followed by a longer explanation of why the change brought by
> the commit is a good thing.
>
Hi people,
thanks for the quick and complete replies. As a user, I do not
expect git-rebase to change my commit message. I was aware of this
convention in Git, but it looks like it's more than just a
convention. This trap should either be fixed (your patch works for
me) or it should be clearly stated in the documentation that commit
messages must really be formatted according to the convention.
Personally I expected Git to keep the 1st line of my commit message
as the "short version" (which is what git log and the like do ATM)
and although I don't leave a blank line between the 1st line and the
rest of the message, the 1st line is always the sentence that can be
used as a short version of the commit message.
Cheers,
--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]
^ permalink raw reply
* [PATCH] Don't rely on unspecified behavior
From: Thomas Schwinge @ 2007-07-28 16:39 UTC (permalink / raw)
To: git; +Cc: Thomas Schwinge
In-Reply-To: <11856407793933-git-send-email-tschwinge@gnu.org>
Calling access(p, m) with p == NULL is not specified, so don't do that. On
GNU/Hurd systems doing so will result in an SIGSEGV.
Signed-off-by: Thomas Schwinge <tschwinge@gnu.org>
---
builtin-add.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-add.c b/builtin-add.c
index 5e6748f..c13c738 100644
--- a/builtin-add.c
+++ b/builtin-add.c
@@ -74,7 +74,7 @@ static void fill_directory(struct dir_struct *dir, const char **pathspec)
path = git_path("info/exclude");
if (!access(path, R_OK))
add_excludes_from_file(dir, path);
- if (!access(excludes_file, R_OK))
+ if (excludes_file != NULL && !access(excludes_file, R_OK))
add_excludes_from_file(dir, excludes_file);
/*
--
1.5.3.rc3.26.g6c58-dirty
^ permalink raw reply related
* [PATCH] Support building on GNU/Hurd
From: Thomas Schwinge @ 2007-07-28 16:39 UTC (permalink / raw)
To: git; +Cc: Thomas Schwinge
GNU/Hurd systems don't have strlcpy either.
Signed-off-by: Thomas Schwinge <tschwinge@gnu.org>
---
Makefile | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index 2fea115..8d9a01b 100644
--- a/Makefile
+++ b/Makefile
@@ -458,6 +458,10 @@ ifeq ($(uname_S),AIX)
NO_STRLCPY = YesPlease
NEEDS_LIBICONV=YesPlease
endif
+ifeq ($(uname_S),GNU)
+ # GNU/Hurd
+ NO_STRLCPY=YesPlease
+endif
ifeq ($(uname_S),IRIX64)
NO_IPV6=YesPlease
NO_SETENV=YesPlease
--
1.5.3.rc3.26.g6c58-dirty
^ permalink raw reply related
* Re: suggestion for git rebase -i
From: Seth Falcon @ 2007-07-28 15:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Seth Falcon, git
In-Reply-To: <Pine.LNX.4.64.0707280941380.14781@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Why? This is an implementation detail, and should not concern the
> user.
In the context of an existing editing session, the name of the
tempfile is visible and relevant to the user (not just an
implementation detail). For example, the tempfile name is useful when
multi-tasking and one needs to get back to the buffer. As another
reply pointed out, the name could also be used for editor mode
customization.
So. When editing a commit message, the buffer is named
COMMIT_EDITMSG. When editing a rebase -i buffer it is named todo. Is
this a real problem? Of course not. But I think a slightly more
descriptive name makes sense -- especially if other commands gain
interactive modes and a user might have a number of them going at once
(in different repos, e.g.).
+ seth
^ permalink raw reply
* Re: git diff with add/modified codes
From: Jakub Narebski @ 2007-07-28 15:26 UTC (permalink / raw)
To: git
In-Reply-To: <20070728043901.GB11916@coredump.intra.peff.net>
Jeff King wrote:
> On Fri, Jul 27, 2007 at 08:17:54PM -0400, Jon Smirl wrote:
>
>> That's not what I want. I'm looking a report that indicates new files
>> vs modified ones in a single list. These old patches I am working with
>> often create 100 files and modify another 200.
>>
>> Adding a code like (Added (A), Copied (C), Deleted (D), Modified (M),
>> Renamed (R)) to --stat would be perfect.
>
> How about --name-status?
Or -r --name-status?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git-svn rebase screwing up commit messages
From: Jakub Narebski @ 2007-07-28 14:32 UTC (permalink / raw)
To: git
In-Reply-To: <7vk5skps1g.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Sean <seanlkml@sympatico.ca> writes:
>
>>> Having said all that, so that the readers understand the
>>> background, here is a not-so-heavily-tested patch, which might
>>> help. It passes all the test suite as before, but that tells
>>> how existing git-svn tests do not test many things.
>>>
>>> I am not considering this for inclusion right now, by the way.
>>
>> FWIW your patch fixed my test case here.
>
> Actually the patched behaviour actively encourages a bad (not in
> the sense that those oneline tools will not work well, but in
> the sense that these messages are reader unfriendly) practice; I
> do not think what the patch did deserves to be called "fixed".
>
> And that is one of the reasons, other than that we are in -rc
> freeze that we do not add anything but unarguable fixes, that I
> am not considering the patch for inclusion right now.
I think that git should not enforce this policy. Think import
and exchange with foreign SCMs which do not follow this, argueably
very reasonable, one-line summary policy.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] gitweb: Simplify 'opt' parameter validation, add "no merges" feeds
From: Jakub Narebski @ 2007-07-28 14:27 UTC (permalink / raw)
To: git; +Cc: Luben Tuikov, Petr Baudis, Jakub Narebski
Simplify and make more readable validation of 'opt' (extra options)
parameter, using exists($hash{key}) instead of grepping keys of a hash
for value.
Move 'opt' parameter to be the last (for now) in the URL.
Make use of '--no-merges' extra option ('opt') by adding "no merges"
RSS and Atom feeds to the HTML header. Note that alternate format
links in the RSS and Atom views do not use '--no-merges' option yet!
Adds tests for the 'opt' parameter to t9500-gitweb-standalone-no-errors.sh
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
This patch could (and probablu should) be split into four separate
patches: simplify 'opt' parameter validation, move 'opt' parameter
to be last in the generated URL, add tests for 'opt' parameter, and
add an example of using 'opt' parameter in the form of feeds without
merges. But I wanted to avoid generating micro-commits.
This patch is based on 'master'.
gitweb/gitweb.perl | 17 ++++++++++++-----
t/t9500-gitweb-standalone-no-errors.sh | 28 ++++++++++++++++++++++++++++
2 files changed, 40 insertions(+), 5 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index b381692..668be42 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -436,12 +436,11 @@ my %allowed_options = (
our @extra_options = $cgi->param('opt');
if (defined @extra_options) {
- foreach(@extra_options)
- {
- if (not grep(/^$_$/, keys %allowed_options)) {
+ foreach my $opt (@extra_options) {
+ if (not exists $allowed_options{$opt}) {
die_error(undef, "Invalid option parameter");
}
- if (not grep(/^$action$/, @{$allowed_options{$_}})) {
+ if (not grep(/^$action$/, @{$allowed_options{$opt}})) {
die_error(undef, "Invalid option parameter for this action");
}
}
@@ -598,7 +597,6 @@ sub href(%) {
action => "a",
file_name => "f",
file_parent => "fp",
- extra_options => "opt",
hash => "h",
hash_parent => "hp",
hash_base => "hb",
@@ -608,6 +606,7 @@ sub href(%) {
searchtext => "s",
searchtype => "st",
snapshot_format => "sf",
+ extra_options => "opt",
);
my %mapping = @mapping;
@@ -2267,9 +2266,17 @@ EOF
printf('<link rel="alternate" title="%s log RSS feed" '.
'href="%s" type="application/rss+xml" />'."\n",
esc_param($project), href(action=>"rss"));
+ printf('<link rel="alternate" title="%s log RSS feed (no merges)" '.
+ 'href="%s" type="application/rss+xml" />'."\n",
+ esc_param($project), href(action=>"rss",
+ extra_options=>"--no-merges"));
printf('<link rel="alternate" title="%s log Atom feed" '.
'href="%s" type="application/atom+xml" />'."\n",
esc_param($project), href(action=>"atom"));
+ printf('<link rel="alternate" title="%s log Atom feed (no merges)" '.
+ 'href="%s" type="application/atom+xml" />'."\n",
+ esc_param($project), href(action=>"atom",
+ extra_options=>"--no-merges"));
} else {
printf('<link rel="alternate" title="%s projects list" '.
'href="%s" type="text/plain; charset=utf-8"/>'."\n",
diff --git a/t/t9500-gitweb-standalone-no-errors.sh b/t/t9500-gitweb-standalone-no-errors.sh
index d948724..fa32598 100755
--- a/t/t9500-gitweb-standalone-no-errors.sh
+++ b/t/t9500-gitweb-standalone-no-errors.sh
@@ -521,4 +521,32 @@ test_expect_success \
'gitweb_run "p=.git;a=log"'
test_debug 'cat gitweb.log'
+# ----------------------------------------------------------------------
+# extra options
+
+test_expect_success \
+ 'opt: log --no-merges' \
+ 'gitweb_run "p=.git;a=log;opt=--no-merges"'
+test_debug 'cat gitweb.log'
+
+test_expect_success \
+ 'opt: atom --no-merges' \
+ 'gitweb_run "p=.git;a=log;opt=--no-merges"'
+test_debug 'cat gitweb.log'
+
+test_expect_success \
+ 'opt: "file" history --no-merges' \
+ 'gitweb_run "p=.git;a=history;f=file;opt=--no-merges"'
+test_debug 'cat gitweb.log'
+
+test_expect_success \
+ 'opt: log --no-such-option (invalid option)' \
+ 'gitweb_run "p=.git;a=log;opt=--no-such-option"'
+test_debug 'cat gitweb.log'
+
+test_expect_success \
+ 'opt: tree --no-merges (invalid option for action)' \
+ 'gitweb_run "p=.git;a=tree;opt=--no-merges"'
+test_debug 'cat gitweb.log'
+
test_done
--
1.5.2.4
^ 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