* Re: 'git diff' in rebase--interactive
From: Johannes Sixt @ 2007-10-09 12:35 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0710091319400.4174@racer.site>
Johannes Schindelin schrieb:
> On Tue, 9 Oct 2007, Johannes Sixt wrote:
>
>> I wonder for what reason rebase--interactive generates a patch using
>> 'git diff' in the make_patch function. Is this an artefact?
>
> It was an explicit request by people who use git-rebase regularly, and
> missed being able to see the patch in --interactive.
Can we generate the patch with plumbing, diff-{files,index,tree}? They
by-pass any diff drivers.
>> I'd like to get rid of this use of 'git diff' because it invokes
>> external diff drivers, which is totally unwanted if the driver is
>> interactive - like the 'windiff' thing that I posted a week ago.
>
> So you do not want to be able to run git-rebase (without -i)?
It wouldn't work anyway in my use-case (versioned Word documents), but
rebase -m and rebase -i could run without manual intervention as long as
there are no content merges.
In this particular case, I only wanted to amend the message of a commit 3
steps down in the history, and I had not expected any diff drivers to be
fired up.
-- Hannes
^ permalink raw reply
* Re: [PATCH] mergetool: support absolute paths to tools by git config merge.<tool>path
From: Johannes Schindelin @ 2007-10-09 12:35 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Theodore Ts'o, git
In-Reply-To: <11918785613855-git-send-email-prohaska@zib.de>
Hi,
On Mon, 8 Oct 2007, Steffen Prohaska wrote:
> This commit adds a mechanism to provide absolute paths to the
> commands called by 'git mergetool'. A path can be specified
> in the configuation variable merge.<toolname>path.
Would it not be more in line with all other config variables if it was
written merge.<toolname>.path? (Indeed, I thought your subject line
contained a typo when I read it first.)
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] mergetool: add support for ECMerge
From: Johannes Schindelin @ 2007-10-09 12:37 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Theodore Tso, git
In-Reply-To: <1C50C046-3D61-4D55-8D38-B2D563C1FF2A@zib.de>
Hi,
On Tue, 9 Oct 2007, Steffen Prohaska wrote:
> I work on the msysgit project and I'd like to have mergetool available
> before I advertise git on Windows. It makes merging so much easier ;)
I would _hate_ to rely on a closed source program (in addition to Windows
itself) in msysGit.
And it seems that you cannot even get ECMerge for free in general.
What does TortoiseCVS use?
Ciao,
Dscho
^ permalink raw reply
* Re: [msysGit] Re: [PATCH] git-gui: offer a list of recent repositories on startup
From: Steffen Prohaska @ 2007-10-09 12:42 UTC (permalink / raw)
To: Johannes Schindelin, Shawn O. Pearce; +Cc: Git Mailing List, msysGit
In-Reply-To: <Pine.LNX.4.64.0710091240540.4174@racer.site>
On Oct 9, 2007, at 1:43 PM, Johannes Schindelin wrote:
> On Mon, 8 Oct 2007, Steffen Prohaska wrote:
>
>> commit a483fdd562d6c44d68a998224e0bbb17933b624a
>> Author: Steffen Prohaska <prohaska@zib.de>
>> Date: Mon Oct 8 08:25:47 2007 +0200
>>
>> git-gui: offer a list of recent repositories on startup
>
> May I suggest not putting this list into ~/.gitconfig, but rather
> ~/.gitguirc? It is not really a user-specific git configuration...
git-gui already stores other options as global variables gui.*.
(see git-gui/lib/option.tcl). I just added gui.recentrepo. The
list of recent repos should go to wherever git-gui stores its options.
Right now this is in ~/.gitconfig, if I understand correctly. Shawn?
Steffen
^ permalink raw reply
* [PATCH] git-config: handle --file option with relative pathname properly
From: Gerrit Pape @ 2007-10-09 12:49 UTC (permalink / raw)
To: Junio C Hamano, git
When calling git-config not from the top level directory of a repository,
it changes directory before trying to open the config file specified
through the --file option, which then fails if the config file was
specified by a relative pathname. This patch adjusts the pathname to
the config file if applicable.
The problem was noticed by Joey Hess, reported through
http://bugs.debian.org/445208
Signed-off-by: Gerrit Pape <pape@smarden.org>
---
builtin-config.c | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/builtin-config.c b/builtin-config.c
index 0a605e0..c2708ba 100644
--- a/builtin-config.c
+++ b/builtin-config.c
@@ -165,7 +165,7 @@ int cmd_config(int argc, const char **argv, const char *prefix)
{
int nongit = 0;
char* value;
- setup_git_directory_gently(&nongit);
+ const char *name = setup_git_directory_gently(&nongit);
while (1 < argc) {
if (!strcmp(argv[1], "--int"))
@@ -189,7 +189,11 @@ int cmd_config(int argc, const char **argv, const char *prefix)
else if (!strcmp(argv[1], "--file") || !strcmp(argv[1], "-f")) {
if (argc < 3)
usage(git_config_set_usage);
- setenv(CONFIG_ENVIRONMENT, argv[2], 1);
+ if (argv[2][0] == '/')
+ name = argv[2];
+ else
+ name = name ? prefix_filename(name, strlen(name), argv[2]) : argv[2];
+ setenv(CONFIG_ENVIRONMENT, name, 1);
argc--;
argv++;
}
--
1.5.3.4
^ permalink raw reply related
* Re: [PATCH] mergetool: add support for ECMerge
From: Steffen Prohaska @ 2007-10-09 12:49 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Theodore Tso, git
In-Reply-To: <Pine.LNX.4.64.0710091335580.4174@racer.site>
On Oct 9, 2007, at 2:37 PM, Johannes Schindelin wrote:
> On Tue, 9 Oct 2007, Steffen Prohaska wrote:
>
>> I work on the msysgit project and I'd like to have mergetool
>> available
>> before I advertise git on Windows. It makes merging so much easier ;)
>
> I would _hate_ to rely on a closed source program (in addition to
> Windows
> itself) in msysGit.
It's only an option. You can also choose kdiff3 if you like, or
vimdiff or
emacs merge. But personally, I prefer ECMerge because is seems to
support
a faster and safer workflow (at least for me).
Before submitted this patch I thought about a general mechanism to
easily
specify any tool that supports command line argument. But just adding
them
tool by tool as needed looks easier to me, and hopefully to the user. We
can include the correct command line in git-mergetool and only require
the location of the program from the user.
> And it seems that you cannot even get ECMerge for free in general.
True. But does it matter? I can't get Windows for free and git runs
on it.
> What does TortoiseCVS use?
Don't know.
Steffen
^ permalink raw reply
* [PATCH] git-config: respect other options after -l, most notably --file
From: Gerrit Pape @ 2007-10-09 12:50 UTC (permalink / raw)
To: Junio C Hamano, git
When git-commit is seeing the -l|--list option, it stops reading the
following command line options. So although they should be the same,
the following commands act differently:
git config --file ../repo2/.git/config -l
git config -l --file ../repo2/.git/config
This patch delays the 'list all variables' to after the command line
options have been processed.
The problem was noticed by Joey Hess, reported through
http://bugs.debian.org/445208
Signed-off-by: Gerrit Pape <pape@smarden.org>
---
builtin-config.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/builtin-config.c b/builtin-config.c
index c2708ba..1bb0ebb 100644
--- a/builtin-config.c
+++ b/builtin-config.c
@@ -8,6 +8,7 @@ static char *key;
static regex_t *key_regexp;
static regex_t *regexp;
static int show_keys;
+static int show_all;
static int use_key_regexp;
static int do_all;
static int do_not_match;
@@ -173,7 +174,7 @@ int cmd_config(int argc, const char **argv, const char *prefix)
else if (!strcmp(argv[1], "--bool"))
type = T_BOOL;
else if (!strcmp(argv[1], "--list") || !strcmp(argv[1], "-l"))
- return git_config(show_all_config);
+ show_all = 1;
else if (!strcmp(argv[1], "--global")) {
char *home = getenv("HOME");
if (home) {
@@ -234,6 +235,8 @@ int cmd_config(int argc, const char **argv, const char *prefix)
argv++;
}
+ if (show_all)
+ return git_config(show_all_config);
switch (argc) {
case 2:
return get_value(argv[1], NULL);
--
1.5.3.4
^ permalink raw reply related
* [PATCH] git-config: print error message if the config file cannot be read
From: Gerrit Pape @ 2007-10-09 12:51 UTC (permalink / raw)
To: Junio C Hamano, git
Instead of simply exiting with 255, print an error message including
the reason why the config file cannot be opened or read.
The problem was noticed by Joey Hess, reported through
http://bugs.debian.org/445208
Signed-off-by: Gerrit Pape <pape@smarden.org>
---
builtin-config.c | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/builtin-config.c b/builtin-config.c
index 1bb0ebb..750a403 100644
--- a/builtin-config.c
+++ b/builtin-config.c
@@ -235,8 +235,12 @@ int cmd_config(int argc, const char **argv, const char *prefix)
argv++;
}
- if (show_all)
- return git_config(show_all_config);
+ if (show_all) {
+ if (git_config(show_all_config) == -1)
+ die("unable to read config file %s: %s",
+ getenv(CONFIG_ENVIRONMENT), strerror(errno));
+ return 0;
+ }
switch (argc) {
case 2:
return get_value(argv[1], NULL);
--
1.5.3.4
^ permalink raw reply related
* [PATCH] t5403-post-checkout-hook.sh: make test operands posix
From: Gerrit Pape @ 2007-10-09 12:51 UTC (permalink / raw)
To: Junio C Hamano, git
Signed-off-by: Gerrit Pape <pape@smarden.org>
---
t/t5403-post-checkout-hook.sh | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/t/t5403-post-checkout-hook.sh b/t/t5403-post-checkout-hook.sh
index 487abf3..823239a 100755
--- a/t/t5403-post-checkout-hook.sh
+++ b/t/t5403-post-checkout-hook.sh
@@ -39,7 +39,7 @@ test_expect_success 'post-checkout receives the right arguments with HEAD unchan
old=$(awk "{print \$1}" clone1/.git/post-checkout.args) &&
new=$(awk "{print \$2}" clone1/.git/post-checkout.args) &&
flag=$(awk "{print \$3}" clone1/.git/post-checkout.args) &&
- test $old = $new -a $flag == 1
+ test $old = $new -a $flag = 1
'
test_expect_success 'post-checkout runs as expected ' '
@@ -52,7 +52,7 @@ test_expect_success 'post-checkout args are correct with git checkout -b ' '
old=$(awk "{print \$1}" clone1/.git/post-checkout.args) &&
new=$(awk "{print \$2}" clone1/.git/post-checkout.args) &&
flag=$(awk "{print \$3}" clone1/.git/post-checkout.args) &&
- test $old = $new -a $flag == 1
+ test $old = $new -a $flag = 1
'
test_expect_success 'post-checkout receives the right args with HEAD changed ' '
@@ -60,7 +60,7 @@ test_expect_success 'post-checkout receives the right args with HEAD changed ' '
old=$(awk "{print \$1}" clone2/.git/post-checkout.args) &&
new=$(awk "{print \$2}" clone2/.git/post-checkout.args) &&
flag=$(awk "{print \$3}" clone2/.git/post-checkout.args) &&
- test $old != $new -a $flag == 1
+ test $old != $new -a $flag = 1
'
test_expect_success 'post-checkout receives the right args when not switching branches ' '
@@ -68,7 +68,7 @@ test_expect_success 'post-checkout receives the right args when not switching br
old=$(awk "{print \$1}" clone2/.git/post-checkout.args) &&
new=$(awk "{print \$2}" clone2/.git/post-checkout.args) &&
flag=$(awk "{print \$3}" clone2/.git/post-checkout.args) &&
- test $old == $new -a $flag == 0
+ test $old = $new -a $flag = 0
'
test_done
--
1.5.3.4
^ permalink raw reply related
* Re: Problem with git-cvsimport
From: Jan Wielemaker @ 2007-10-09 12:47 UTC (permalink / raw)
To: Thomas Pasch; +Cc: git
In-Reply-To: <470B491F.9020306@jentro.com>
On Tuesday 09 October 2007 11:25, Thomas Pasch wrote:
> Hello,
>
> using git-cvsimport (1.5.3.4), it dies with
>
> Update
> guidance-common/src/java/com/jentro/manager/guidance/common/servlet/IconSer
>vlet.java: 2104 bytes
> Tree ID 01cb84cbee2e70a712459be6601b993603eed5bd
> Parent ID dcd8dc76f4638d1994165070c9813202992d546a
> Committed patch 3775 (bmw +0000 2004-10-14 11:10:43)
> Commit ID 53c68066f71651b057884e1101cda3967070724d
> Fetching
> guidance-common/src/java/com/jentro/manager/guidance/common/serverapi/Guida
>nceException.java v 1.14.4.2
> Update
> guidance-common/src/java/com/jentro/manager/guidance/common/serverapi/Guida
>nceException.java: 3718 bytes
> Tree ID 886268190ac2cb28b5f1e6cdb309054bcb8fa38e
> Parent ID 53c68066f71651b057884e1101cda3967070724d
> Merge parent branch: master
> fatal: Not a valid object name master
> Use of uninitialized value in chomp at /usr/bin/git-cvsimport line 766.
> Use of uninitialized value in pattern match (m//) at
> /usr/bin/git-cvsimport line 527.
> Use of uninitialized value in concatenation (.) or string at
> /usr/bin/git-cvsimport line 767.
> Cannot get commit id ():
>
> What can I do to avoid this problem?
I've had some similar problem. I've converted two big old repositories by
first converting to SVN using:
cvs2svn -s myrepo-svn /path/to/cvsmodule
git-svnimport -i -u -C /path/to-git file://myrepo-svn
Worked like a charm
Cheers --- Jan
^ permalink raw reply
* [PATCH] rebase -i: use diff plumbing instead of porcelain
From: Johannes Schindelin @ 2007-10-09 12:59 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Git Mailing List
In-Reply-To: <470B7581.3030301@viscovery.net>
When diff drivers are installed, calling "git diff <tree1>..<tree2>"
calls those drivers. This borks the patch generation of rebase -i.
So use "git diff-tree -p" instead, which does not call diff drivers.
Noticed by Johannes Sixt.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
On Tue, 9 Oct 2007, Johannes Sixt wrote:
> Johannes Schindelin schrieb:
> > On Tue, 9 Oct 2007, Johannes Sixt wrote:
> >
> > > I wonder for what reason rebase--interactive generates a
> > > patch using 'git diff' in the make_patch function. Is this
> > > an artefact?
> >
> > It was an explicit request by people who use git-rebase
> > regularly, and missed being able to see the patch in
> > --interactive.
>
> Can we generate the patch with plumbing,
> diff-{files,index,tree}? They by-pass any diff drivers.
Here you are.
git-rebase--interactive.sh | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 050140d..df4cedb 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -80,7 +80,7 @@ mark_action_done () {
make_patch () {
parent_sha1=$(git rev-parse --verify "$1"^) ||
die "Cannot get patch for $1^"
- git diff "$parent_sha1".."$1" > "$DOTEST"/patch
+ git diff-tree -p "$parent_sha1".."$1" > "$DOTEST"/patch
test -f "$DOTEST"/message ||
git cat-file commit "$1" | sed "1,/^$/d" > "$DOTEST"/message
test -f "$DOTEST"/author-script ||
@@ -325,7 +325,7 @@ do_next () {
;;
esac && {
test ! -f "$DOTEST"/verbose ||
- git diff --stat $(cat "$DOTEST"/head)..HEAD
+ git diff-tree --stat $(cat "$DOTEST"/head)..HEAD
} &&
rm -rf "$DOTEST" &&
git gc --auto &&
--
1.5.3.4.1169.g5fb8d
^ permalink raw reply related
* Re: [PATCH] mergetool: add support for ECMerge
From: Alan Hadsell @ 2007-10-09 13:03 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Steffen Prohaska, Theodore Tso, git
In-Reply-To: <Pine.LNX.4.64.0710091335580.4174@racer.site>
On 10/9/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> What does TortoiseCVS use?
They don't actually include it in the package, but they recommend
WinMerge http://winmerge.org/, which is free (GPL).
--
Alan Hadsell
^ permalink raw reply
* public repository
From: Pierre Habouzit @ 2007-10-09 13:04 UTC (permalink / raw)
To: Git ML
[-- Attachment #1: Type: text/plain, Size: 903 bytes --]
Under popular demand^W^W^Wbecause Jonas asked for my parse_options
work, I've put my git topic branches on a public repository on
git://git.madism.org/git.git.
master/next are my known positions of master and next at the time I
pushed last. ph/* are topic branches I work on, they should be either
bsaed on master or next (hence are rebased until merged into git.git or
dropped).
Right now, there is ph/strbuf with the 1+2 series that generated this
heated discussion before. There is also ph/parseopt: a 10+ series
featuring krh parse_options, with some rework on my end to support more
features, and I migrate a dozen of builtins to use them (in this topic
branch, `git rm -rf ...` works !)
Cheers,
--
·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: [PATCH] t5403-post-checkout-hook.sh: make test operands posix
From: Lars Hjemli @ 2007-10-09 13:05 UTC (permalink / raw)
To: Gerrit Pape; +Cc: git
In-Reply-To: <20071009125130.1343.qmail@bcafc83cd51c05.315fe32.mid.smarden.org>
On 10/9/07, Gerrit Pape <pape@smarden.org> wrote:
> t/t5403-post-checkout-hook.sh | 8 ++++----
> 1 files changed, 4 insertions(+), 4 deletions(-)
An identical patch has already been posted:
http://article.gmane.org/gmane.comp.version-control.git/59952
--
larsh
^ permalink raw reply
* Adding color to git-add--interactive
From: Jonathan del Strother @ 2007-10-09 13:06 UTC (permalink / raw)
To: Git Mailing List
I find git-add--interactive incredibly awkward to use, mostly due to
the lack of visual differentiation as you type in a sequence of
commands. For example, when stepping through hunks to patch, every
time it shows a new hunk I have to carefully scan up the screen to
find where the hunk starts, before I can actually start reading what's
contained in that hunk.
For me at least, adding color would make the interactive mode far more
readable. I hacked in basic color support (just coloring PROMPT &
HEADER in list_and_choose, and the "Stage this hunk?" prompt) - which
helped a lot - but then reached the limits of my perl knowledge. For
instance, I can't see a sensible way of reusing git-svn's
log_use_color function without importing the entire file, and I can't
figure out how you'd go about diff-coloring the hunks. Is anyone with
more perl knowledge than me interested in taking this on?
Or am I alone in finding interactive mode basically unreadable?
Jon
^ permalink raw reply
* Re: [PATCH] git-config: handle --file option with relative pathname properly
From: Johannes Schindelin @ 2007-10-09 13:14 UTC (permalink / raw)
To: Gerrit Pape; +Cc: Junio C Hamano, git
In-Reply-To: <20071009124932.1184.qmail@395d4a80f3eafd.315fe32.mid.smarden.org>
Hi,
On Tue, 9 Oct 2007, Gerrit Pape wrote:
> @@ -189,7 +189,11 @@ int cmd_config(int argc, const char **argv, const char *prefix)
> else if (!strcmp(argv[1], "--file") || !strcmp(argv[1], "-f")) {
> if (argc < 3)
> usage(git_config_set_usage);
> - setenv(CONFIG_ENVIRONMENT, argv[2], 1);
> + if (argv[2][0] == '/')
Please use is_absolute_path() instead.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] mergetool: add support for ECMerge
From: Steffen Prohaska @ 2007-10-09 13:17 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List, Theodore Tso, Alan Hadsell
In-Reply-To: <2b3a6fcd0710090603l3c3578caq3bfa6a1b8ec583f@mail.gmail.com>
On Oct 9, 2007, at 3:03 PM, Alan Hadsell wrote:
> On 10/9/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
>> What does TortoiseCVS use?
>
> They don't actually include it in the package, but they recommend
> WinMerge http://winmerge.org/, which is free (GPL).
WinMerge doesn't support 3-way merges. At least I cannot find any
indication for 3-way in the manual [1] and the comparison at [2] also
tells that WinMerge doesn't support 3-way.
Steffen
[1] http://winmerge.org/2.6/manual/CompareFiles.html
[2] http://en.wikipedia.org/wiki/Comparison_of_file_comparison_tools
^ permalink raw reply
* Re: [PATCH] git-config: respect other options after -l, most notably --file
From: Johannes Schindelin @ 2007-10-09 13:15 UTC (permalink / raw)
To: Gerrit Pape; +Cc: Junio C Hamano, git
In-Reply-To: <20071009125024.1259.qmail@d8e601127fe8d0.315fe32.mid.smarden.org>
Hi,
On Tue, 9 Oct 2007, Gerrit Pape wrote:
> @@ -234,6 +235,8 @@ int cmd_config(int argc, const char **argv, const char *prefix)
> argv++;
> }
>
> + if (show_all)
> + return git_config(show_all_config);
> switch (argc) {
> case 2:
> return get_value(argv[1], NULL);
Shouldn't this somehow check if argc == 1 when show_all is set, and die
otherwise?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-config: print error message if the config file cannot be read
From: Johannes Schindelin @ 2007-10-09 13:16 UTC (permalink / raw)
To: Gerrit Pape; +Cc: Junio C Hamano, git
In-Reply-To: <20071009125102.1305.qmail@054bd0fc8effa5.315fe32.mid.smarden.org>
Hi,
On Tue, 9 Oct 2007, Gerrit Pape wrote:
> + if (git_config(show_all_config) == -1)
I'd rather check for < 0, just for future proofing.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-config: handle --file option with relative pathname properly
From: Johannes Sixt @ 2007-10-09 13:20 UTC (permalink / raw)
To: Gerrit Pape; +Cc: Junio C Hamano, git
In-Reply-To: <20071009124932.1184.qmail@395d4a80f3eafd.315fe32.mid.smarden.org>
Gerrit Pape schrieb:
> @@ -189,7 +189,11 @@ int cmd_config(int argc, const char **argv, const char *prefix)
> else if (!strcmp(argv[1], "--file") || !strcmp(argv[1], "-f")) {
> if (argc < 3)
> usage(git_config_set_usage);
> - setenv(CONFIG_ENVIRONMENT, argv[2], 1);
> + if (argv[2][0] == '/')
Please use is_absolute_path() here.
> + name = argv[2];
> + else
> + name = name ? prefix_filename(name, strlen(name), argv[2]) : argv[2];
Can't you avoid this ternary here? There's already an 'if' with the same
'else' branch.
> + setenv(CONFIG_ENVIRONMENT, name, 1);
> argc--;
> argv++;
> }
-- Hannes
^ permalink raw reply
* Re: Problem with git-cvsimport
From: Gerald (Jerry) Carter @ 2007-10-09 13:21 UTC (permalink / raw)
To: Thomas Pasch; +Cc: Jan Wielemaker, git
In-Reply-To: <200710091447.50501.wielemak@science.uva.nl>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jan Wielemaker wrote:
> I've had some similar problem. I've converted two big old
> repositories by first converting to SVN using:
>
> cvs2svn -s myrepo-svn /path/to/cvsmodule
> git-svnimport -i -u -C /path/to-git file://myrepo-svn
I would actually plug using cvs2svn to convert directly to git.
See this thread for Michael's original announcement.
http://marc.info/?l=git&m=118592701426175&w=2
I'm in the process of drafting Samba's own git repos from
the CVS and SVN history (http://gitweb.samba.org/).
cheers, jerry
=====================================================================
Samba ------- http://www.samba.org
Centeris ----------- http://www.centeris.com
"What man is a man who does not make the world better?" --Balian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHC4BJIR7qMdg1EfYRAlQ4AKDctlXFv0kcT51sA6P99qjVrPJ+MgCfWkCB
wPSf6l06UIlz0HERasHbryg=
=zSSf
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH] git-config: print error message if the config file cannot be read
From: Johannes Sixt @ 2007-10-09 13:30 UTC (permalink / raw)
To: Gerrit Pape; +Cc: Junio C Hamano, git
In-Reply-To: <20071009125102.1305.qmail@054bd0fc8effa5.315fe32.mid.smarden.org>
Gerrit Pape schrieb:
> @@ -235,8 +235,12 @@ int cmd_config(int argc, const char **argv, const char *prefix)
> argv++;
> }
>
> - if (show_all)
> - return git_config(show_all_config);
> + if (show_all) {
> + if (git_config(show_all_config) == -1)
> + die("unable to read config file %s: %s",
> + getenv(CONFIG_ENVIRONMENT), strerror(errno));
I don't think that this works well: If there are no config files at all,
then we don't want to see an error - just as if the config file were empty.
Also, I don't think that errno is reliable at this point.
You probably want to see an error message *only* if you have supplied a file
name with --file.
-- Hannes
^ permalink raw reply
* Re: Adding color to git-add--interactive
From: Wincent Colaiuta @ 2007-10-09 13:31 UTC (permalink / raw)
To: Jonathan del Strother; +Cc: Git Mailing List
In-Reply-To: <91EBB71E-BB4E-4089-8C33-6B0C4A61223A@steelskies.com>
El 9/10/2007, a las 15:06, Jonathan del Strother escribió:
> Or am I alone in finding interactive mode basically unreadable?
I don't think you're alone. Compared with the nice colorized output
from things like git-status, git-log, git-diff and friends, the
output of "git-add --interactive" is decidedly hard to read.
Cheers,
Wincent
^ permalink raw reply
* Re: Adding color to git-add--interactive
From: Johannes Schindelin @ 2007-10-09 14:04 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Jonathan del Strother, Git Mailing List
In-Reply-To: <A59A0321-9E29-4857-AF03-E6226C45E87C@wincent.com>
Hi,
On Tue, 9 Oct 2007, Wincent Colaiuta wrote:
> El 9/10/2007, a las 15:06, Jonathan del Strother escribi?:
>
> > Or am I alone in finding interactive mode basically unreadable?
>
> I don't think you're alone. Compared with the nice colorized output from
> things like git-status, git-log, git-diff and friends, the output of
> "git-add --interactive" is decidedly hard to read.
And since git-add--interactive is still a script, there is no excuse:
providing a patch should take the same time and amount of work as
complaining about the lack of colour.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Add 'git-p4 commit' as an alias for 'git-p4 submit'
From: Marius Storm-Olsen @ 2007-10-09 14:16 UTC (permalink / raw)
To: git; +Cc: simon, Marius Storm-Olsen
Given that git uses 'commit', git-p4's 'sumbit' was a bit confusing at times;
often making me do 'git submit' and 'git-p4 commit' instead.
Signed-off-by: Marius Storm-Olsen <marius@trolltech.com>
---
contrib/fast-import/git-p4 | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index 557649a..52cd2a4 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -1651,6 +1651,7 @@ def printUsage(commands):
commands = {
"debug" : P4Debug,
"submit" : P4Submit,
+ "commit" : P4Submit,
"sync" : P4Sync,
"rebase" : P4Rebase,
"clone" : P4Clone,
--
1.5.3.4.1155.gfe96ee-dirty
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox