* Re: ~/.git/config ?
From: Petr Baudis @ 2006-05-27 2:57 UTC (permalink / raw)
To: Pavel Roskin; +Cc: Timo Hirvonen, Anand Kumria, git
In-Reply-To: <1148697382.5599.1.camel@dv>
Dear diary, on Sat, May 27, 2006 at 04:36:22AM CEST, I got a letter
where Pavel Roskin <proski@gnu.org> said that...
> On Fri, 2006-05-26 at 18:38 +0200, Petr Baudis wrote:
> > Dear diary, on Fri, May 26, 2006 at 06:33:25PM CEST, I got a letter
> > where Timo Hirvonen <tihirvon@gmail.com> said that...
> > > I backup my $HOME using git, so there's a .git directory in ~.
> >
> > Then it should be called ~/.gitconfig. :-)
>
> No, make it .gitrc for compatibility with .cvsrc, .lynxrc and others.
~/.gitrc might get useful for actually doing what ~/.cvsrc or ~/.cgrc
does, that is providing default options for git commands. ~/.gitconfig
would just give you per-user defaults for the repository config file.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.
^ permalink raw reply
* Re: ~/.git/config ?
From: Linus Torvalds @ 2006-05-27 3:20 UTC (permalink / raw)
To: Petr Baudis; +Cc: Pavel Roskin, Timo Hirvonen, Anand Kumria, git
In-Reply-To: <20060527025750.GM11941@pasky.or.cz>
On Sat, 27 May 2006, Petr Baudis wrote:
>
> ~/.gitrc might get useful for actually doing what ~/.cvsrc or ~/.cgrc
> does, that is providing default options for git commands. ~/.gitconfig
> would just give you per-user defaults for the repository config file.
I don't think the two are necessarily any different.
I do think that
(a) we might as well use the same syntax. There's no point in having
different syntax for the files, even if they end up having slightly
different usage.
(b) a "user-wide" config file would tend to have different things in it
than a per-repository one, but some of the things it would have in it
are the things that we currently put in the per-repository one.
Notably exactly the "user.name" and "user.email" values.
(c) having a user- (and perhaps a system-) wide config file would make
some things that we do not _yet_ support in the .git/config file
format more natural, but that doesn't necessarily mean that having
them on a per-repo basis would be wrong either.
As an example of (c), let's say that somebody wants to use the CVS aliases
with git. They've used cvs for years, and as a result their brain has
atrophied, and they have a really hard time teaching their fingers to
write "git commit" when they want to write "cvs ci".
So they would do "alias cvs git" in a desperate attempt to save themselves
from CVS, and then add
[alias "co"]
cmd = commit -a
to their .gitrc file. Now, the only thing we'd need to do is to teach
"git.c" to parse that simple "alias.$1.command" variable, and that really
sounds pretty damn easy, no?
And that really does make more sense in a user-wide ".gitrc" file. But at
the same time, there's really no reason to _disallow_ it from the
repo-private .git/config file either. For example, you could do
[alias "publish"]
cmd = push public.site.com:/pub/scm/my-public-repo
and that is somethign that actually makes sense as a per-repository
command alias, so that "git publish" does the right thing for just _that_
repository.
So I would argue that yes, ".gitrc" makes sense, and no, we shouldn't have
a separate ".gitrc" and ".gitconfig", because I think what we really would
want is a way to do default .git/config entries, and that it is _also_ a
very natural way to add some things that we don't do yet.
Linus
PS. I really like my [alias "cmd"] idea. _All_ my ideas are great, of
course, but this one seems even better than some others. No?
^ permalink raw reply
* Re: ~/.git/config ?
From: Linus Torvalds @ 2006-05-27 3:36 UTC (permalink / raw)
To: Petr Baudis; +Cc: Pavel Roskin, Timo Hirvonen, Anand Kumria, git
In-Reply-To: <Pine.LNX.4.64.0605262007230.5623@g5.osdl.org>
On Fri, 26 May 2006, Linus Torvalds wrote:
>
> So they would do "alias cvs git" in a desperate attempt to save themselves
> from CVS, and then add
>
> [alias "co"]
> cmd = commit -a
That, of course, would be confusing.
It should be "ci" for commit, and "co" for "checkout".
Duh. Chalk it up to me not having used cvs in the last three or four years
or so (we used it at transmeta, although I can hope that they've since
seen the light ;).
Linus
^ permalink raw reply
* Re: ~/.git/config ?
From: Jakub Narebski @ 2006-05-27 3:40 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0605262007230.5623@g5.osdl.org>
Linus Torvalds wrote:
> PS. I really like my [alias "cmd"] idea. _All_ my ideas are great, of
> course, but this one seems even better than some others. No?
So, would we use it also for default options of commands, like
[alias "log"]
cmd = log -p -M -C
(we could implement "git whatchanges" as an alias, keeping it's man page, or
sharing it with "git log").
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: ~/.git/config ?
From: Junio C Hamano @ 2006-05-27 4:43 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0605262033560.5623@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
>> [alias "co"]
>> cmd = commit -a
>
> That, of course, would be confusing.
>
> It should be "ci" for commit, and "co" for "checkout".
>
> Duh. Chalk it up to me not having used cvs in the last three or four years
> or so (we used it at transmeta, although I can hope that they've since
> seen the light ;).
>
> Linus
You are lucky ;-).
The alias would be a nice addition -- I can get rid of the hack
I have for show-branch. We would need an argument splitter, but
that should be trivial.
^ permalink raw reply
* Re: [PATCH] Actually support embedded Qt, make configuration code more robust
From: Marco Costalba @ 2006-05-27 6:22 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <20060527022735.5879.58043.stgit@dv.roinet.com>
On 5/27/06, Pavel Roskin <proski@gnu.org> wrote:
> Add -DQWS and -fno-rtti flags for embedded Qt.
>
> Don't add X11 flags for embedded Qt and threading specific flags for
> non-multithreaded Qt.
>
> Before checking for the Qt library, make sure it actually exists in the
> Qt library path and not elsewhere.
>
Thanks, patch applied.
Please note that qgit public repository has changed. It is now
git://git.kernel.org/pub/scm/qgit/qgit.git
Marco
^ permalink raw reply
* Re: ~/.git/config ?
From: Nikolai Weibull @ 2006-05-27 8:50 UTC (permalink / raw)
To: Pavel Roskin; +Cc: Petr Baudis, Timo Hirvonen, Anand Kumria, git
In-Reply-To: <1148697382.5599.1.camel@dv>
On 5/27/06, Pavel Roskin <proski@gnu.org> wrote:
> On Fri, 2006-05-26 at 18:38 +0200, Petr Baudis wrote:
> > Dear diary, on Fri, May 26, 2006 at 06:33:25PM CEST, I got a letter
> > where Timo Hirvonen <tihirvon@gmail.com> said that...
> > > I backup my $HOME using git, so there's a .git directory in ~.
> >
> > Then it should be called ~/.gitconfig. :-)
>
> No, make it .gitrc for compatibility with .cvsrc, .lynxrc and others.
>
> I know, it's becoming a bikeshed issue :-)
I want to paint part of it as well!
Wouldn't we be futureproofing ourselves by stuffing it in a
subdirectory instead? What if we want to add more files later?
Also, can we please make sure to make the location of the file (or
directory) configurable through an environment variable, e.g.,
GIT_CONFIG, GIT_USER_CONFIG, GIT_HOME, or GIT_USER_HOME?
Peace.
nikolai
^ permalink raw reply
* Re: ~/.git/config ?
From: Timo Hirvonen @ 2006-05-27 9:09 UTC (permalink / raw)
To: Nikolai Weibull; +Cc: proski, pasky, wildfire, git
In-Reply-To: <dbfc82860605270150s5c43e32fja2e7ef934bc1ef0@mail.gmail.com>
"Nikolai Weibull" <now@bitwi.se> wrote:
> On 5/27/06, Pavel Roskin <proski@gnu.org> wrote:
> > On Fri, 2006-05-26 at 18:38 +0200, Petr Baudis wrote:
> > >
> > > Then it should be called ~/.gitconfig. :-)
> >
> > No, make it .gitrc for compatibility with .cvsrc, .lynxrc and others.
> >
> > I know, it's becoming a bikeshed issue :-)
>
> I want to paint part of it as well!
>
> Wouldn't we be futureproofing ourselves by stuffing it in a
> subdirectory instead? What if we want to add more files later?
Makes sense, we may want to put templates to ~/.gitsomething/templates/.
--
http://onion.dynserv.net/~timo/
^ permalink raw reply
* Re: ~/.git/config ?
From: Junio C Hamano @ 2006-05-27 9:11 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0605262007230.5623@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Sat, 27 May 2006, Petr Baudis wrote:
>>
>> ~/.gitrc might get useful for actually doing what ~/.cvsrc or ~/.cgrc
>> does, that is providing default options for git commands. ~/.gitconfig
>> would just give you per-user defaults for the repository config file.
>
> I don't think the two are necessarily any different.
Me neither. Default options to fall back on if repository
configuration does not specify them and when environments do not
override them -- that's exactly "per-user defaults", nothing else.
Earlier I suggested ~/.git-config, but anything other than
~/.git/config is OK. ~/.gitrc is fine. And the order suggested
by Anand sounded fine.
- use environment (if the value is obtained, stop here)
- use .git/config (if the value is obtained, stop here)
- use ~/.git-config (if the value is obtained, stop here)
- do whatever the program does by default.
> (a) we might as well use the same syntax. There's no point in having
> different syntax for the files, even if they end up having slightly
> different usage.
Absolutely.
> (b) a "user-wide" config file would tend to have different things in it
> than a per-repository one, but some of the things it would have in it
> are the things that we currently put in the per-repository one.
> Notably exactly the "user.name" and "user.email" values.
Yes. Also "preference" kind of things as opposed to "per
project policy" such as apply.whitespace.
^ permalink raw reply
* Re: git-format-patch possible regressions
From: Marco Costalba @ 2006-05-27 9:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4pzdqpit.fsf@assigned-by-dhcp.cox.net>
On 5/26/06, Junio C Hamano <junkio@cox.net> wrote:
>
> What Johannes and I were discussing was the other number -- the
> total in the series. IOW, y in "[PATCH x/y]". OTOH, the number
> used for disambiguation you care about is x, which is made
> adjustable with --start-number patch.
>
New --start-number patch says:
"Since the "a..b c..d" syntax is interpreted as "b ^a d ^c" as other
range-ish commands, if you want to format a..b and then c..d and end
up with files consecutively numbered, the second run needs to be able
to tell the command what number to start from.
This does not imply --numbered (which gives [PATCH n/m] to the subject)."
Actually it seems that --numbered is needed anyway.
$ git-format-patch HEAD^..HEAD
0000-git-format-patch-start-number-n.txt
$ git-format-patch --start-number=7 HEAD^..HEAD
0000-git-format-patch-start-number-n.txt
$ git-format-patch --numbered --start-number=7 HEAD^..HEAD
0007-git-format-patch-start-number-n.txt
But with numbered also the patch subject is changed with added [PATCH n/m] that
is not needed.
Also mutually exclusive check is not performed
git-format-patch -n -k HEAD^..HEAD
0001-git-format-patch-start-number-n.txt
This patch should fix all.
Subject: [PATCH] Let git-format-patch --start-number option to work
also without --numbered
While there also fix the check for mutually exclusive -n and -k option
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
---
builtin-log.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/builtin-log.c b/builtin-log.c
index 71f4ff9..c35733f 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -148,7 +148,7 @@ int cmd_format_patch(int argc, const cha
int nr = 0, total, i, j;
int use_stdout = 0;
int numbered = 0;
- int start_number = -1;
+ int start_number = 0;
int keep_subject = 0;
init_revisions(&rev);
@@ -201,9 +201,9 @@ int cmd_format_patch(int argc, const cha
}
argc = j;
- if (numbered && start_number < 0)
+ if (numbered && start_number == 0)
start_number = 1;
- if (numbered && keep_subject < 0)
+ if (numbered && keep_subject)
die ("-n and -k are mutually exclusive.");
argc = setup_revisions(argc, argv, &rev, "HEAD");
@@ -233,7 +233,7 @@ int cmd_format_patch(int argc, const cha
while (0 <= --nr) {
int shown;
commit = list[nr];
- rev.nr = rev.total - nr;
+ rev.nr = start_number + total - nr - 1;
if (!use_stdout)
reopen_stdout(commit, rev.nr, keep_subject);
shown = log_tree_commit(&rev, commit);
--
1.3.3.gfa0f-dirty
^ permalink raw reply related
* Re: [SCRIPT] chomp: trim trailing whitespace
From: Jan Engelhardt @ 2006-05-27 10:15 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Git Mailing List, Linux Kernel
In-Reply-To: <4477B905.9090806@garzik.org>
> Attached to this email is chomp.pl, a Perl script which removes trailing
> whitespace from several files. I've had this for years, as trailing whitespace
> is one of my pet peeves.
>
> Now that git-applymbox complains loudly whenever a patch adds trailing
> whitespace, I figured this script may be useful to others.
>
Pretty long script. How about this two-liner? It does not show 'bytes
chomped' but it also trims trailing whitespace.
#!/usr/bin/perl -i -p
s/[ \t\r\n]+$//
Jan Engelhardt
--
^ permalink raw reply
* gitview: Add key binding for F5.
From: Aneesh Kumar K.V @ 2006-05-27 10:24 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 0 bytes --]
[-- Attachment #2: 0001-gitview-Add-key-binding-for-F5.txt --]
[-- Type: text/plain, Size: 2342 bytes --]
gitview: Add key binding for F5.
F5 will now refresh the window. This is useful if you are using git bisect
and want to visualize the change.
Also update the gitview version
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
---
contrib/gitview/gitview | 17 +++++++++++++----
contrib/gitview/gitview.txt | 6 ++++--
2 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/contrib/gitview/gitview b/contrib/gitview/gitview
index 781badb..c708534 100755
--- a/contrib/gitview/gitview
+++ b/contrib/gitview/gitview
@@ -425,7 +425,7 @@ class DiffWindow:
class GitView:
""" This is the main class
"""
- version = "0.7"
+ version = "0.8"
def __init__(self, with_diff=0):
self.with_diff = with_diff
@@ -449,8 +449,17 @@ class GitView:
self.accel_group = gtk.AccelGroup()
self.window.add_accel_group(self.accel_group)
+ self.accel_group.connect_group(0xffc2, 0, gtk.ACCEL_LOCKED, self.refresh);
- self.construct()
+ self.window.add(self.construct())
+
+ def refresh(self, widget, event=None, *arguments, **keywords):
+ self.get_encoding()
+ self.get_bt_sha1()
+ Commit.children_sha1 = {}
+ self.set_branch(sys.argv[without_diff:])
+ self.window.show()
+ return True
def get_bt_sha1(self):
""" Update the bt_sha1 dictionary with the
@@ -500,9 +509,9 @@ class GitView:
menu_bar.show()
vbox.pack_start(menu_bar, expand=False, fill=True)
vbox.pack_start(paned, expand=True, fill=True)
- self.window.add(vbox)
paned.show()
vbox.show()
+ return vbox
def construct_top(self):
@@ -987,8 +996,8 @@ class GitView:
window.set_diff(commit_sha1, parent_sha1, encoding)
self.treeview.grab_focus()
+without_diff = 0
if __name__ == "__main__":
- without_diff = 0
if (len(sys.argv) > 1 ):
if (sys.argv[1] == "--without-diff"):
diff --git a/contrib/gitview/gitview.txt b/contrib/gitview/gitview.txt
index fcf759c..e3bc4f4 100644
--- a/contrib/gitview/gitview.txt
+++ b/contrib/gitview/gitview.txt
@@ -25,6 +25,9 @@ OPTIONS
<args>
All the valid option for git-rev-list(1)
+ Key Bindings:
+ F5:
+ To reread references.
EXAMPLES
------
@@ -33,6 +36,5 @@ EXAMPLES
or drivers/scsi subdirectories
gitview --since=2.weeks.ago
- Show the changes during the last two weeks
+ Show the changes during the last two weeks
-
--
1.3.3.g4d548-dirty
^ permalink raw reply related
* Re: [SCRIPT] chomp: trim trailing whitespace
From: Thomas Glanzmann @ 2006-05-27 10:24 UTC (permalink / raw)
To: Linux Kernel; +Cc: GIT, Jan Engelhardt
In-Reply-To: <Pine.LNX.4.61.0605271212210.6670@yvahk01.tjqt.qr>
Hello,
> #!/usr/bin/perl -i -p
> s/[ \t\r\n]+$//
perl -p -i -e 's/\s+$//' file1 file2 file3 ...
Thomas
^ permalink raw reply
* gitview: Move the console error messages to message dialog
From: Aneesh Kumar K.V @ 2006-05-27 10:25 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 0 bytes --]
[-- Attachment #2: 0002-gitview-Move-the-console-error-messages-to-message-dialog.txt --]
[-- Type: text/plain, Size: 1154 bytes --]
gitview: Move the console error messages to message dialog
This changes display the error/warning info using message dialog
rather than printing them using print
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
---
contrib/gitview/gitview | 9 +++++++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/contrib/gitview/gitview b/contrib/gitview/gitview
index c708534..b836047 100755
--- a/contrib/gitview/gitview
+++ b/contrib/gitview/gitview
@@ -983,10 +983,15 @@ class GitView:
try:
self.treeview.set_cursor(self.index[revid])
except KeyError:
- print "Revision %s not present in the list" % revid
+ dialog = gtk.MessageDialog(parent=None, flags=0,
+ type=gtk.MESSAGE_WARNING, buttons=gtk.BUTTONS_CLOSE,
+ message_format=None)
+ dialog.set_markup("Revision <b>%s</b> not present in the list" % revid)
# revid == 0 is the parent of the first commit
if (revid != 0 ):
- print "Try running gitview without any options"
+ dialog.format_secondary_text("Try running gitview without any options")
+ dialog.run()
+ dialog.destroy()
self.treeview.grab_focus()
--
1.3.3.g4d548-dirty
^ permalink raw reply related
* [PATCH 2/2] make init-db use GIT_TEMPLATE_DIR if --template option is not specified
From: Matthias Lederhofer @ 2006-05-27 10:25 UTC (permalink / raw)
To: git; +Cc: Matthias Lederhofer
In-Reply-To: <11487255393905-git-send-email-1>
---
f61e19360f9b5965dda1ae762ffdab8ede860430
builtin-init-db.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
f61e19360f9b5965dda1ae762ffdab8ede860430
diff --git a/builtin-init-db.c b/builtin-init-db.c
index 2a1384c..cf5bd39 100644
--- a/builtin-init-db.c
+++ b/builtin-init-db.c
@@ -253,6 +253,9 @@ int cmd_init_db(int argc, const char **a
die(init_db_usage);
}
+ if (!template_dir)
+ template_dir = getenv("GIT_TEMPLATE_DIR");
+
/*
* Set up the default .git directory contents
*/
--
1.3.3.g40505
^ permalink raw reply related
* [PATCH 1/2] add --template=<template_directory> option to git-clone
From: Matthias Lederhofer @ 2006-05-27 10:25 UTC (permalink / raw)
To: git; +Cc: Matthias Lederhofer
---
a176a8eae1d0e8e87028c4185ad5500ce2845441
Documentation/git-clone.txt | 8 ++++++--
git-clone.sh | 7 +++++--
2 files changed, 11 insertions(+), 4 deletions(-)
a176a8eae1d0e8e87028c4185ad5500ce2845441
diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index b333f51..881b464 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -9,8 +9,8 @@ git-clone - Clones a repository
SYNOPSIS
--------
[verse]
-'git-clone' [-l [-s]] [-q] [-n] [--bare] [-o <name>] [-u <upload-pack>]
- [--reference <repository>]
+'git-clone' [--template=<template_directory>] [-l [-s]] [-q] [-n] [--bare]
+ [-o <name>] [-u <upload-pack>] [--reference <repository>]
<repository> [<directory>]
DESCRIPTION
@@ -34,6 +34,10 @@ branch you are currently working on. Re
OPTIONS
-------
+--template=<template_directory>::
+ Provide the directory from which templates will be used.
+ The default template directory is `/usr/share/git-core/templates`.
+
--local::
-l::
When the repository to clone from is on a local machine,
diff --git a/git-clone.sh b/git-clone.sh
index d96894d..1c7ae12 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -9,7 +9,7 @@ # See git-sh-setup why.
unset CDPATH
usage() {
- echo >&2 "Usage: $0 [--use-separate-remote] [--reference <reference-repo>] [--bare] [-l [-s]] [-q] [-u <upload-pack>] [--origin <name>] [-n] <repo> [<dir>]"
+ echo >&2 "Usage: $0 [--template=<template_directory>] [--use-separate-remote] [--reference <reference-repo>] [--bare] [-l [-s]] [-q] [-u <upload-pack>] [--origin <name>] [-n] <repo> [<dir>]"
exit 1
}
@@ -102,6 +102,7 @@ quiet=
local=no
use_local=no
local_shared=no
+template=
no_checkout=
upload_pack=
bare=
@@ -120,6 +121,8 @@ while
*,-l|*,--l|*,--lo|*,--loc|*,--loca|*,--local) use_local=yes ;;
*,-s|*,--s|*,--sh|*,--sha|*,--shar|*,--share|*,--shared)
local_shared=yes; use_local=yes ;;
+ *,--template=*)
+ template="$1" ;;
*,-q|*,--quiet) quiet=-q ;;
*,--use-separate-remote)
use_separate_remote=t ;;
@@ -203,7 +206,7 @@ trap 'err=$?; cd ..; rm -r "$D"; exit $e
case "$bare" in
yes) GIT_DIR="$D" ;;
*) GIT_DIR="$D/.git" ;;
-esac && export GIT_DIR && git-init-db || usage
+esac && export GIT_DIR && git-init-db "$template" || usage
case "$bare" in
yes)
GIT_DIR="$D" ;;
--
1.3.3.g40505
^ permalink raw reply related
* Re: [SCRIPT] chomp: trim trailing whitespace
From: Neil Brown @ 2006-05-27 10:36 UTC (permalink / raw)
To: Thomas Glanzmann; +Cc: Linux Kernel, GIT, Jan Engelhardt
In-Reply-To: <20060527102439.GB26430@cip.informatik.uni-erlangen.de>
On Saturday May 27, sithglan@stud.uni-erlangen.de wrote:
> Hello,
>
> > #!/usr/bin/perl -i -p
> > s/[ \t\r\n]+$//
>
> perl -p -i -e 's/\s+$//' file1 file2 file3 ...
>
Uhm... have either of you actually tried those? When I tried, I lose
all the '\n' characters :-(
perl -pi -e 's/[ \t\r]+$//' *.[ch]
seems to actually work.
NeilBrown
^ permalink raw reply
* Re: [SCRIPT] chomp: trim trailing whitespace
From: Jeff Garzik @ 2006-05-27 11:32 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: Git Mailing List, Linux Kernel
In-Reply-To: <Pine.LNX.4.61.0605271212210.6670@yvahk01.tjqt.qr>
Jan Engelhardt wrote:
>> Attached to this email is chomp.pl, a Perl script which removes trailing
>> whitespace from several files. I've had this for years, as trailing whitespace
>> is one of my pet peeves.
>>
>> Now that git-applymbox complains loudly whenever a patch adds trailing
>> whitespace, I figured this script may be useful to others.
>>
>
> Pretty long script. How about this two-liner? It does not show 'bytes
> chomped' but it also trims trailing whitespace.
>
> #!/usr/bin/perl -i -p
> s/[ \t\r\n]+$//
Yes, it does, but a bit too aggressive for what we need :)
Jeff
^ permalink raw reply
* Re: [SCRIPT] chomp: trim trailing whitespace
From: Dmitry Fedorov @ 2006-05-27 11:48 UTC (permalink / raw)
To: Git Mailing List, Linux Kernel
In-Reply-To: <447838EB.9060900@garzik.org>
[-- Attachment #1: Type: text/plain, Size: 226 bytes --]
Jan Engelhardt wrote:
>> Attached to this email is chomp.pl, a Perl script which removes trailing
>> whitespace from several files. I've had this for years, as
trailing whitespace
>> is one of my pet peeves.
And my scripts.
[-- Attachment #2: find-text-files --]
[-- Type: application/octet-stream, Size: 7833 bytes --]
#!/usr/bin/perl -w
=head1 NAME
find-text-files - traverse a file tree and guess plain text files
=head1 SYNOPSIS
find-text-files [options] dir ...
=head1 DESCRIPTION
This program traverse a file tree, guess plain text files
and outputs their names to STDOUT.
=cut
require 5.004;
use strict;
use integer;
use File::Find;
use Getopt::Long;
use IPC::Open2;
sub usage {
warn "\n".join(" ", @_)."\n" if @_;
warn <<EOF;
Usage:
find-text-files [-exclude='perlre' ...] [-include='perlre' ...] \
[-total] [-excluded] [-included] [-selectors] \
dir ...
EOF
exit(1);
}
=head1 PARAMETERS
=over 4
=item dir ...
Directories list.
=back
=cut
=head1 OPTIONS
=over 4
=item -exclude='perlre' ...
Perl regular expression, case insensitive.
Matched file names excluded from output list.
=item -include='perlre' ...
Perl regular expression, case insensitive.
Matched file names included to output list.
=head2 Note
Directory part of the file name stripped before match,
'^filename\.ext$' will be matched exactly to filename.ext
with any directory prepended.
=item -total
print statistic counters to STDERR.
=item -excluded
print to STDERR what files are excluded and why.
=item -included
print to STDERR what files are included and why.
=item -selectors
Prints exclude/include regular expressions and file suffices and exits.
=back
=head1 HOW IT WORKS
Each of file names checked in that order:
* check against exclude RE; matched file excluded (see -exclude option);
if not matched, then:
* check against include RE; matched file included (see -include option);
if not matched, then:
* check against binary suffices table; matched file excluded;
if not matched, then:
* check against text suffices table; matched file included;
if not matched, then:
* checked by file(1)
All of this allows to avoid file(1)'s misdetection on some texts
and reduce time spent for file(1) calls.
=head1 NOTES
Does not follows symlinks.
Zero size files are skipped.
=cut
my $ help_option = 0;
my @ include_options;
my @ exclude_options;
my $ total_option = 0;
my $ excluded_option = 0;
my $ included_option = 0;
my $selectors_option = 0;
GetOptions(
'help' => \$ help_option,
'exclude=s' => \@ exclude_options,
'include=s' => \@ include_options,
'total' => \$ total_option,
'excluded' => \$ excluded_option,
'included' => \$ included_option,
'selectors' => \$selectors_option,
) or usage;
usage if $help_option;
my %bin_suffices;
my %txt_suffices;
BEGIN
{
map { $bin_suffices{$_} = undef }
(
'gif', 'tif', 'tiff', 'png', 'jpg', 'jpeg',
'avi', 'mpg', 'mpeg',
'o', 'obj', 'exe',
'cab', 'a', 'rar', 'arj', 'zip', 'tar', 'cpio',
'z', 'gz', 'bz', 'bz2', 'tgz', 'tbz', 'tbz2',
'iso', 'bin', 'img', 'imag', 'image',
'diff', 'patch' # diff/patch files could have EOL spaces!
);
map { $txt_suffices{$_} = undef }
(
'txt', 'text', 'html', 'htm', 'xml', 'php',
'c', 'cpp', 'c++', 'cc', 'cxx',
'h', 'hpp', 'h++', 'hh', 'hxx',
'asm', 'inc', 'mod',
'for', 'f77', 'g77',
'java', 'jav',
'bas', 'vb',
'pl', 'pm', 'pod',
'make', 'mak', 'mk',
'awk', 'sh', 'bat', 'cmd', 'rexx', 'rex',
'sql', 'def', 'man',
'cvsignore'
);
}
my $exclude_re = '(,v$)';
map { $exclude_re .= '|('.lc $_.')'; } @exclude_options;
my $include_re = '(^makefile$)';
map { $include_re .= '|('.lc $_.')'; } @include_options;
if ($selectors_option)
{
my $bin_suffices = join(" ", sort keys %bin_suffices);
my $txt_suffices = join(" ", sort keys %txt_suffices);
print STDERR "\n";
print STDERR "Exclude RE: ".$exclude_re."\n";
print STDERR "\n";
print STDERR "Include RE: ".$include_re."\n";
print STDERR "\n";
print STDERR "Exclude suffices: ".$bin_suffices."\n";
print STDERR "\n";
print STDERR "Include suffices: ".$txt_suffices."\n";
print STDERR "\n";
exit 0;
}
scalar(@ARGV) >= 1 or usage("no directory specified");
my (
$total_files_checked,
$total_files_empty,
$total_files_excluded_by_re,
$total_files_included_by_re,
$total_files_excluded_by_suffix,
$total_files_included_by_suffix,
$total_files_excluded_by_file,
$total_files_included_by_file
) = (0,0,0,0,0,0,0,0);
sub _by($$$$)
{
my ($inex_option, $inex_str, $by, $name) = @_;
printf(STDERR "%scluded by %13s: %s\n", $inex_str, $by, $name)
if $inex_option;
}
sub inby($$) { _by($included_option, 'in', $_[0], $_[1]); }
sub exby($$) { _by($excluded_option, 'ex', $_[0], $_[1]); }
local *FILE_RH;
local *FILE_WH;
my $file_pid;
$SIG{PIPE} = sub
{
close FILE_WH;
waitpid $file_pid, 0;
die "file(1) pipe broken"
};
$file_pid = open2(\*FILE_RH, \*FILE_WH, "file -n -f -" )
or die "can't fork: $!";
#+ main work
$| = 1; # STDOUT autoflush
find(\&onfile, @ARGV);
#- main work
close FILE_WH;
waitpid $file_pid, 0;
format STDERR =
Total files: checked empty
------- -------
@>>>>>> @>>>>>>
$total_files_checked, $total_files_empty
suffix re file(1)
------- ------- -------
excluded by: @>>>>>> @>>>>>> @>>>>>>
$total_files_excluded_by_suffix, $total_files_excluded_by_re, $total_files_excluded_by_file
included by: @>>>>>> @>>>>>> @>>>>>>
$total_files_included_by_suffix, $total_files_included_by_re, $total_files_included_by_file
.
write STDERR if $total_option;
exit 0;
sub onfile()
{
my $shortname = $_;
my $ fullname = "$File::Find::name";
return unless -f $shortname;
$total_files_checked++;
if ( ! -s $shortname )
{
$total_files_empty++;
return;
}
my $lcshortname = lc $shortname;
if ( $lcshortname =~ m/$exclude_re/o )
{
exby('RE', $fullname);
$total_files_excluded_by_re++;
return;
}
if ( $lcshortname =~ m/$include_re/o )
{
inby('RE', $fullname);
$total_files_included_by_re++;
}
else # check by suffix
{
my $suffix = $1 if $lcshortname =~ m/\.([^\.]+)$/;
if ( defined $suffix and length $suffix and
exists $bin_suffices{$suffix} )
{
exby('binary suffix', $fullname);
$total_files_excluded_by_suffix++;
return;
}
if ( defined $suffix and length $suffix and
exists $txt_suffices{$suffix} )
{
inby('text suffix', $fullname);
$total_files_included_by_suffix++;
}
else # check by file(1)
{
print FILE_WH $fullname."\n"
or die "bad write to file(1) pipe: $! $?";
my $fread = <FILE_RH>;
defined $fread or die "bad read from file(1) pipe: $! $?";
chomp $fread;
unless ( $fread =~ m|^(.+):\s+(.+)$| )
{
die "file(1) output does not match pattern:\n$fread\n";
}
my ($fname,$fdesc) = ($1,$2);
die "can't parse file(1) output:\n$fread\n"
if (! defined $fname) or (! defined $fdesc);
die "file name after file(1) does not match the original one:\n".
"\tbefore: $fullname\n".
"\tafter : $fname\n"
if $fname ne $fullname;
if ( $fdesc =~ m/^.* (text)|(source).*$/ )
{
inby('file(1)', $fullname);
$total_files_included_by_file++;
}
else
{
exby('file(1)', $fullname);
$total_files_excluded_by_file++;
return;
}
}
}
print $fullname . "\n";
}
=head1 AUTHOR
Dmitry Fedorov <dm.fedorov@gmail.com>
=head1 COPYRIGHT
Copyright (C) 2003 Dmitry Fedorov <dm.fedorov@gmail.com>
=head1 LICENSE
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License,
or (at your option) any later version.
=head1 DISCLAIMER
The author disclaims any responsibility for any mangling of your system
etc, that this script may cause.
=cut
[-- Attachment #3: truncate-eol-whitespace --]
[-- Type: application/octet-stream, Size: 4916 bytes --]
#!/usr/bin/perl -w
=head1 NAME
truncate-eol-whitespace - truncate white spaces at end of line.
=head1 SYNOPSIS
truncate-eol-whitespace [-total] [-truncated] [-nontruncated] [-dry-run] \
[file ...] [-f files-from]
=head1 DESCRIPTION
This program truncates extra white spaces just before end of line
in specified files. File names can be specified as parameters
and/or readed from specified file, '-' for STDIN.
=head1 EXAMPLE
Truncate all text files under DIR:
find-text-files DIR -total | truncate-eol-whitespace -total -f -
=cut
require 5.004;
use strict;
use integer;
use Getopt::Long;
sub usage {
warn "\n".join(" ", @_)."\n" if @_;
warn <<EOF;
Usage:
truncate-eol-whitespace [-total] [-truncated] [-nontruncated] [-dry-run] \
[file ...] [-f files-from]
Warning: this script truncates files! Use -dry-run for test first.
EOF
exit(1);
}
=head1 OPTIONS
=over 4
=item -total
print statistic counters to STDERR.
=item -truncated
print to STDERR what files was truncated;
=item -nontruncated
print to STDERR what files was not truncated;
=item -dry-run
Do not write files, report only
=item file ...
Files to truncate (optional)
=item -f files-from
File name with file names to truncate, one name per line.
Use '-' for STDIN.
=back
=cut
my $ help_option = 0;
my $ dry_run_option = 0;
my $ files_from_option;
my $ total_option = 0;
my $ truncated_option = 0;
my $nontruncated_option = 0;
GetOptions(
'help' => \$ help_option,
'total' => \$ total_option,
'truncated' => \$ truncated_option,
'nontruncated' => \$nontruncated_option,
'dry-run' => \$ dry_run_option,
'f=s' => \$ files_from_option,
) or usage;
usage if $help_option;
usage("no files specified")
if (! defined $files_from_option) and scalar(@ARGV) < 1;
my (
$total_files_checked,
$total_files_empty,
$total_files_truncated,
$total_files_no_chars_truncated
) = (0,0,0,0,0,0,0,0,0,0);
my ( $total_chars_readed, $total_chars_truncated ) = (0,0);
sub truncate_file($)
{
my $fname = shift;
$total_files_checked++;
if ( ! -f $fname )
{
print STDERR "is not a plain file: ".$fname."\n";
return;
}
if ( ! -s $fname )
{
print STDERR "zero size file: ".$fname."\n";
$total_files_empty++;
return;
}
local $/ = undef; # no records, slurp mode
local *IN;
open IN, "< $fname"
or die "Can't open $fname: $!";
my $file = <IN>;
defined $file or die "Can't read $fname: $!";
close IN;
my $length_before = length $file;
$total_chars_readed += $length_before;
$file =~ s/[\000-\011\013-\040]+\n/\n/mg;
my $length_after = length $file;
my $chars_truncated = $length_before - $length_after;
die "size become greater after truncating: ".$fname
if $chars_truncated < 0;
if ( $chars_truncated > 0 )
{
$total_files_truncated++;
$total_chars_truncated += $chars_truncated;
}
else
{
$total_files_no_chars_truncated++;
}
if ( $chars_truncated >0 and $truncated_option )
{
printf(STDOUT "%6u of %6u chars truncated from $fname\n",
$chars_truncated, $length_before);
}
elsif ( $chars_truncated==0 and $nontruncated_option )
{
printf(STDOUT "%-16s chars truncated from $fname\n", 'no');
}
if ( ! $dry_run_option and $chars_truncated > 0 )
{
local *OUT;
open OUT, "> $fname" or die "Can't open $fname: $!";
print OUT $file or die "Can't write $fname: $!";
close OUT or die "Error on closing $fname: $!";
}
}
#+ main work
# do process file names from the @ARGV first
truncate_file($_) while defined ($_ = shift);
if (defined $files_from_option) # do process file names from file|STDIN
{
local *IN;
open (IN, $files_from_option) or die "Can't open $files_from_option: $!";
while ( my $fname = <IN> )
{
chomp $fname;
next if length($fname) < 1; # skip empty lines
truncate_file($fname);
}
}
#- main work
format STDERR =
Total files: checked empty truncated non-truncated
------- ------- ------- -------
@>>>>>> @>>>>>> @>>>>>> @>>>>>>
$total_files_checked, $total_files_empty, $total_files_truncated, $total_files_no_chars_truncated
Total chars truncated: @>>>>>> of @<<<<<<<<<<<<<<<<<
$total_chars_truncated, $total_chars_readed
.
write STDERR if $total_option;
exit 0;
=head1 AUTHOR
Dmitry Fedorov <dm.fedorov@gmail.com>
=head1 COPYRIGHT
Copyright (C) 2003 Dmitry Fedorov <dm.fedorov@gmail.com>
=head1 LICENSE
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License,
or (at your option) any later version.
=head1 DISCLAIMER
The author disclaims any responsibility for any mangling of your system
etc, that this script may cause.
=cut
^ permalink raw reply
* remaining git-cvsimport problems: robustness when cvsps feeds strange history
From: Yann Dirson @ 2006-05-27 12:01 UTC (permalink / raw)
To: GIT list; +Cc: cvsps
Since there is quite some activity around git-cvsimport these days, I
think I'd raise a couple of issues which are still problematic.
It should at least issue a warning when cvsps feeds it with a
branchpoint that it cannot create because the base branch has not yet
been seen. I am still investigating why cvsps outputs such a buggy
patchset - it may be a cvs bug at the root, and cvsps probably did not
detect an consistency of the cvs data. While there is probably a real
bug to fix somewhere, git-cvsimport should not silently skip the
faulty patchset, especially as it will then miserably fail to import
any subsequent patch on that branch it ignored this way.
However, rerunning the script (after creating a master head by copying
heads/origin) manages to complete the import: the forgotten branch now
gets created, and all subsequent patchsets can now be imported.
I'm not sure what would be the best way to handle the issue. Maybe it
would sufficient to output a bold warning and let the user take the
necessary steps to finish the import (since this is after all a bug in
other tools, which will hopefully be fixed at some point). It could
also be useful to raise a flag when detecting that condition, and
automatically restart the import process on the first error due to
that branch not being available - otoh, that may be overkill, and
could possibly miss some other obscure cases.
As a sidenote, I'm wondering why there is no precise information on
the branchpoint in "cvsps -A". I guess the semantics are "fork a new
branch from the ancestor one" at whatever point it currently is - that
would look quite risky to me, and could be part of the reason why
cvsps did not notice the inconsistency: it just did not try to find
out where the new branch was to be grafted exactly.
======
PatchSet 1
Date: 2006/01/03 18:23:53
Author: ydirson
Branch: HEAD
Tag: (none)
Log:
Empty .cvsignore to be used as a branching base
Members:
.cvsignore:INITIAL->1.1
---------------------
PatchSet 2
Date: 2006/01/03 18:23:53
Author: ydirson
Branch: FOO_V3_0_0_HEAD
Ancestor branch: FOO_VENDOR_HEAD
Tag: (none)
Log:
file .cvsignore was added on branch FOO_V3_0_0_HEAD on 2006-05-24 07:51:07
+0000
Members:
.cvsignore:1.1->1.1.4.1(DEAD)
---------------------
PatchSet 3
Date: 2006/01/03 18:24:39
Author: ydirson
Branch: FOO_VENDOR_HEAD
Ancestor branch: HEAD
Tag: FOO_V1_1
Log:
Import de FOO 1.1
---------------------
PatchSet 20
Date: 2006/01/10 11:47:54
Author: ydirson
Branch: FOO_V3_0_0_HEAD
Tag: (none)
Log:
file script.sh was added on branch FOO_V3_0_0_HEAD on 2006-05-24 07:51:08
+0000
Members:
some/script.sh:1.1->1.1.4.1(DEAD)
===== first import
Fetching .cvsignore v 1.1
New .cvsignore: 0 bytes
Tree ID 87556a35bc2c438ede9eb2120c2cdb04baed33ae
Committing initial tree 87556a35bc2c438ede9eb2120c2cdb04baed33ae
Committed patch 1 (origin 2006-01-03 17:23:53)
Commit ID 2ddb63602915316e60b26d95414100fd80e602ef
Branch FOO_VENDOR_HEAD does not exist!
Delete .cvsignore
[...]
Tree ID ca6e986b5199b01604dfa459b6e3a2841024f11a
Parent ID 2ddb63602915316e60b26d95414100fd80e602ef
Committed patch 3 (FOO_VENDOR_HEAD 2006-01-03 17:24:39)
Commit ID 9e19f11520c89897704fff252901ff4dc5ae88ad
[...]
Committed patch 19 (origin 2006-01-10 10:47:54)
Commit ID 0c5063420b769f8db7c009843b3947350bf78eae
Switching from origin to FOO_V3_0_0_HEAD
fatal: Not a valid object name FOO_V3_0_0_HEAD
read-tree failed: 32768
===== second run
skip patchset 1: 1136309033 before 1136890074
Switching from master to FOO_V3_0_0_HEAD
Delete .cvsignore
Tree ID 38b8067e1d36ce7f45bb1121a22628927bfd2ac2
Parent ID b9cf667acd27ba7fd76a405166b355ec51261b17
Committed patch 2 (FOO_V3_0_0_HEAD 2006-01-03 17:23:53)
Commit ID 528efdac6113af50d4c14c3ccabde9661cb19359
skip patchset 3: 1136309079 before 1136312985
[...]
skip patchset 19: 1136890074 before 1136890074
Delete some/script.sh
Tree ID 38b8067e1d36ce7f45bb1121a22628927bfd2ac2
Parent ID 528efdac6113af50d4c14c3ccabde9661cb19359
Committed patch 20 (FOO_V3_0_0_HEAD 2006-01-10 10:47:54)
[...]
Committed patch 409 (origin 2006-05-24 18:59:44)
Commit ID 74a5c3b1f265f096177120166ae7da1a2cf3f64e
DONE.
=====
--
Yann Dirson <ydirson@altern.org> |
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
^ permalink raw reply
* remaining git-cvsimport problems: relying on timestamps looses patchsets
From: Yann Dirson @ 2006-05-27 12:24 UTC (permalink / raw)
To: GIT list
I use git-cvsimport daily to sync from an inernal CVS repository at
work. Occasionally (in fact, much too often ;), I notice that not all
patchsets were really imported into git (and thus I have to reimport
from scratch, update my graft file, migrate my stgit branches, which
is quite a tedious and time-consuming task).
The problem seems to stem from the fact that git-cvsimport decides
which patch to import based on commit dates, and that we cannot rely
on all machines being correctly time-synchronized.
It would seem much more reliable to keep track of the latest patchset
imported on each branch. Now, maybe this option was considered
already, and rejected for various reasons. I'd welcome any info on
this.
One such reason I can think about is that cvsps patchset numbers seem
to be currently the only way to identify a patchset, and those are not
guaranted to be stable from one cvsps release to the other - eg. I
hope the bug mentionned in previous mail there can be fixed some day,
and thus the fixed patchsets will have different numbers; or maybe
some day cvsps will deal better with the pseudo-revisions introduced
by RCS when adding a file on a branch.
So we have to be able to detect when the cvsps output has changed and
the git history is now possibly out of sync, or it would also be
possible to have a corrupted mirror of the cvs history.
For this, we would need to record some patchset information in the
imported commits - currently only the patchset number seems to make
sense, but if new cvsps releases can show the commitid's introduced in
cvs 1.12.x that would be of great help here. Then we could validate
for each patchset whether we can find a commit with its patchset
number in the git history, and do some checks to assert this commit
corresponds to the expected patchset - until we have access to the cvs
commitid's, we can check that the files changed by the commit are the
same than those in the patchset.
Does that make sense to anyone, or am I completely off-track ?
--
Yann Dirson <ydirson@altern.org> |
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
^ permalink raw reply
* Re: [SCRIPT] chomp: trim trailing whitespace
From: Jan Engelhardt @ 2006-05-27 12:42 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Git Mailing List, Linux Kernel
In-Reply-To: <447838EB.9060900@garzik.org>
>> Pretty long script. How about this two-liner? It does not show 'bytes
>> chomped' but it also trims trailing whitespace.
>>
>> #!/usr/bin/perl -i -p
>> s/[ \t\r\n]+$//
>
> Yes, it does, but a bit too aggressive for what we need :)
>
Whoops, should have been s/[ \t\r]+$//
And the CL form is
perl -i -pe '...'
Somehow, you can't group it to -ipe, but who cares.
Jan Engelhardt
--
^ permalink raw reply
* Re: ~/.git/config ?
From: Horst von Brand @ 2006-05-27 12:52 UTC (permalink / raw)
To: Linus Torvalds
Cc: Petr Baudis, Pavel Roskin, Timo Hirvonen, Anand Kumria, git
In-Reply-To: <Pine.LNX.4.64.0605262007230.5623@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> wrote:
> On Sat, 27 May 2006, Petr Baudis wrote:
> >
> > ~/.gitrc might get useful for actually doing what ~/.cvsrc or ~/.cgrc
> > does, that is providing default options for git commands. ~/.gitconfig
> > would just give you per-user defaults for the repository config file.
Yep.
[...]
> So they would do "alias cvs git" in a desperate attempt to save themselves
> from CVS, and then add
>
> [alias "co"]
> cmd = commit -a
I don't like this syntax. What other stuff (beside "cmd") would be under
"[alias "co"]? Why not simply:
[alias]
co = commit -a
publish = push public.site.com:/pub/scm/my-public-repo
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
^ permalink raw reply
* Re: [PATCH 2/2] make init-db use GIT_TEMPLATE_DIR if --template option is not specified
From: Petr Baudis @ 2006-05-27 13:25 UTC (permalink / raw)
To: Matthias Lederhofer; +Cc: git
Dear diary, on Sat, May 27, 2006 at 12:25:39PM CEST, I got a letter
where Matthias Lederhofer <matled@gmx.net> said that...
> f61e19360f9b5965dda1ae762ffdab8ede860430
> diff --git a/builtin-init-db.c b/builtin-init-db.c
> index 2a1384c..cf5bd39 100644
> --- a/builtin-init-db.c
> +++ b/builtin-init-db.c
> @@ -253,6 +253,9 @@ int cmd_init_db(int argc, const char **a
> die(init_db_usage);
> }
>
> + if (!template_dir)
> + template_dir = getenv("GIT_TEMPLATE_DIR");
> +
> /*
> * Set up the default .git directory contents
> */
Please document such changes, in the spirit of
diff --git a/Documentation/git-init-db.txt b/Documentation/git-init-db.txt
index 8a150d8..378810e 100644
--- a/Documentation/git-init-db.txt
+++ b/Documentation/git-init-db.txt
@@ -15,6 +15,8 @@ OPTIONS
-------
--template=<template_directory>::
Provide the directory from which templates will be used.
+ If not specified, the value of the `GIT_TEMPLATE_DIR` environment
+ variable is used instead.
The default template directory is `/usr/share/git-core/templates`.
--shared::
(Signed-off-by: Petr Baudis <pasky@suse.cz>, whatever...)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.
^ permalink raw reply related
* Re: remaining git-cvsimport problems: robustness when cvsps feeds strange history
From: Martin Langhoff @ 2006-05-27 15:23 UTC (permalink / raw)
To: Yann Dirson; +Cc: GIT list, cvsps
In-Reply-To: <20060527120105.GL6535@nowhere.earth>
Yann,
I want to see if we can close these gaps. Have you got a public repo
that shows this problem so can look more into it?
On 5/28/06, Yann Dirson <ydirson@altern.org> wrote:
> As a sidenote, I'm wondering why there is no precise information on
> the branchpoint in "cvsps -A". I guess the semantics are "fork a new
> branch from the ancestor one" at whatever point it currently is - that
> would look quite risky to me, and could be part of the reason why
> cvsps did not notice the inconsistency: it just did not try to find
> out where the new branch was to be grafted exactly.
It is perfectly possible for cvs to branch at a "point" that is not
really a patchset/patchlevel. Just like it is to tag something that
has never been a patchset.
It is something we currently fudge a bit (or a lot, depending on your
point of view). If the branch was made on a checkout with an
inconsistent tree, we cannot really represent that in git matching
what happened in CVS.
OTOH, the cvsps output you are showing us seems to be in the right
order... patchset 20 should go on top of patchset 3... is cvsimport
truly mishandling this?
martin
^ 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