* Re: [PATCH] Add 'git-p4 commit' as an alias for 'git-p4 submit'
From: Simon Hausmann @ 2007-10-09 19:08 UTC (permalink / raw)
To: Marius Storm-Olsen; +Cc: git
In-Reply-To: <1191939369-18811-1-git-send-email-marius@trolltech.com>
[-- Attachment #1: Type: text/plain, Size: 316 bytes --]
On Tuesday 09 October 2007 16:16:09 Marius Storm-Olsen wrote:
> 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>
Acked-By: Simon Hausmann <simon@lst.de>
Simon
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Fixed crash in fetching remote tags when there is not tags.
From: Alex Riesen @ 2007-10-09 18:20 UTC (permalink / raw)
To: Väinö Järvelä; +Cc: git, Junio C Hamano
In-Reply-To: <81553116-3A4F-4526-A772-9A43C53D3E22@pp.inet.fi>
Väinö Järvelä, Tue, Oct 09, 2007 12:52:01 +0200:
> Hi,
>
> These patches should have been numbered, sorry, The test patch was
> supposed be number 1 of 2.
>
> The patches were done on top of next. The fix should be checked, as
> it's mostly a quick fix to get it to work, probably not the correct
> way to fix that bug, or is it?
Your test does not crash on my system and your fix is obviously bogus.
Just take a look at the only call site of the tail_link_ref: ret
cannot be NULL. alloc_ref will crash in memset, if this were the case.
If you can reproduce the crash reliably, try compiling git with -g and
run it in your test with valgrind or gdb (assuming these are available
to you).
^ permalink raw reply
* GNU-style ChangeLog merge driver for Git (was: Re: git: avoiding merges, rebasing)
From: Benoit SIGOURE @ 2007-10-09 18:19 UTC (permalink / raw)
To: Bruno Haible; +Cc: bug-gnulib, git list
In-Reply-To: <200710091403.26047.bruno@clisp.org>
[-- Attachment #1: Type: text/plain, Size: 3366 bytes --]
On Oct 9, 2007, at 2:03 PM, Bruno Haible wrote:
> Hello Benoit,
>
> Thanks for working on this. But this merge driver has a few major
> nits.
>
>
> 1) While my ChangeLog file was locally unmodified but some pulled
> in commits
> should modify it, "git pull" stopped and said:
>
> ChangeLog: needs update
> fatal: Entry 'ChangeLog' not uptodate. Cannot merge.
>
> [I cannot swear on this, because I did not do a "git status" before
> the
> "git pull", but this is in a directory where I usually have no
> pending diffs.]
I'll check but I'm afraid that Git bails out before actually trying
the merge driver.
>
> The ChangeLog in question is the one from gnulib
> (git clone git://git.sv.gnu.org/gnulib).
>
>
> 2) This "merge driver" did much more than sorting in a merge: it
> sorted the
> entire file! In doing so,
> - It changed the order of ChangeLog entries in a way that does
> not represent
> the historical commit order.
> - For ChangeLog entries with multiple contributors, it shuffled
> around these
> extra contributors to other ChangeLog entries.
> - Near the end of the file, it made a change that I cannot explain.
>
> Find attached a context diff of all the bad changes that it did.
>
Yes, it's pretty stupid, I hacked this in a hurry. I'll try to
improve it so that it doesn't have these undesired side-effects.
>
> In my opinion, a merge driver should not do changes to the file except
> in the range of lines where the conflict occurred. For a ChangeLog
> driver,
> all uncommitted entries should be collected at the top of the file,
> because
> 1. ChangeLogs are kept in the order of historical commit in the
> central
> repository,
> 2. other developers always look at the top of the ChangeLog; if a
> ChangeLog
> entries is inserted second or third after some already present
> entries,
> the danger is too high that the change gets unnoticed.
>
> So "git-merge-changelog OLD CURRENT OTHERS" should IMO do the
> following:
> 1) Collect the changes between OLD and HEAD (I don't know if that
> is CURRENT
> or OTHERS?), in two categories:
> - added entries,
> - changed and removed entries.
> 2) Back out the added entries, keeping only the changed and removed
> entries
> as modifications.
> 3) Do a normal merge between this and the pulled in remote branch
> (I don't
> know if that is OTHERS or CURRENT?). If that merge gives a
> conflict,
> bail out.
> 4) Insert the added entries at the top, in the same order as they were
> originally (no sorting).
>
> Bruno
> <git-merge-changelog-blunder>
OK I'll try to rework the driver so that it implements this. It will
take some time though, I'm quite busy these days.
Akim Demaille would also like it to squash the commits added by the
merge (the new commits in OTHERS):
YYYY-MM-DD Author <who@where.com>
Merge whatever:
YYYY-MM-DD Someone Else <foo@bar.com>
Some change.
* FileChanged.c: Whatever.
YYYY-MM-DD Who Cares <who@cares.com>
Some other change.
* OtherFile.c: Do it.
I thought this was mandated by the GNU Coding Standards but I
checked, it doesn't say anything about merges. Would this sort of
strategy be useful to you? Should it be default (or enabled by some
--squash option)?
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
* Re: Merge problems with git-mingw
From: Linus Torvalds @ 2007-10-09 18:09 UTC (permalink / raw)
To: Johannes Sixt
Cc: Steffen Prohaska, Peter Karlsson, Git Mailing List,
Johannes Schindelin
In-Reply-To: <470BB44B.3030500@viscovery.net>
On Tue, 9 Oct 2007, Johannes Sixt wrote:
>
> + extern const char *quote_arg(const char *arg);
> + argv[0] = quote_arg(git_command);
Extern declarations inside a local scope will not work on more modern gcc
versions. Don't do it. Do proper prototyping in proper scope.
Linus
^ permalink raw reply
* Re: git: avoiding merges, rebasing
From: Benoit SIGOURE @ 2007-10-09 18:06 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git list
In-Reply-To: <Pine.LNX.4.64.0710091141440.4174@racer.site>
[-- Attachment #1: Type: text/plain, Size: 681 bytes --]
On Oct 9, 2007, at 12:43 PM, Johannes Schindelin wrote:
> Hi,
>
> On Mon, 8 Oct 2007, Benoit SIGOURE wrote:
>
>> [as usual, I forgot the attachment...]
>
> Two comments:
>
> - by not inlining you made it hard to review your script. Therefore I
> will not do it.
:|
>
> - Try to avoid naming the script git-merge-*; these scripts/
> programs are
> merge _strategies_, not merge _drivers_ (and yes, we already have
> two
> programs violating this rule -- merge-base and merge-file -- but
> that
> does not mean that you are free to add to the pile).
I'm open to better suggestions.
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
* Re: Merge problems with git-mingw
From: Johannes Sixt @ 2007-10-09 17:03 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Peter Karlsson, Git Mailing List, Johannes Schindelin
In-Reply-To: <BA71DD45-9226-4661-9C92-60EEEA8638D0@zib.de>
Steffen Prohaska schrieb:
>
> On Oct 9, 2007, at 11:03 AM, Johannes Sixt wrote:
>
>> Peter Karlsson schrieb:
>>> C:\Program Files\Git\bin>git var -l
>>> usage: git-var [-l | <variable>]
>>> C:\Program Files\Git\bin>git-var -l
>>> fatal: Not a git repository
>>> C:\Program Files\Git\bin>git --version
>>> git version 1.5.3.mingw.1
>>
>> For the time being, install this beast in a path without blanks.
>>
>> This needs fixing, appearently. :(
>
> I have the printf 'callstack' below from the v1.5.3.mingw.1 version
> (9c792c5)
> Apparently spawnve, which is called in compat/mingw.c, corrupts argv.
Thank you. Here is a quick-fix.
-- Hannes
diff --git a/compat/mingw.c b/compat/mingw.c
index 8bb0dba..361216f 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -303,7 +303,7 @@ void openlog(const char *ident, int option,
{
}
-static const char *quote_arg(const char *arg)
+const char *quote_arg(const char *arg)
{
/* count chars to quote */
int len = 0, n = 0;
diff --git a/exec_cmd.c b/exec_cmd.c
index bad4843..7ab5a0f 100644
--- a/exec_cmd.c
+++ b/exec_cmd.c
@@ -129,7 +129,8 @@ int execv_git_cmd(const char **argv)
*/
tmp = argv[0];
- argv[0] = git_command;
+ extern const char *quote_arg(const char *arg);
+ argv[0] = quote_arg(git_command);
trace_argv_printf(argv, -1, "trace: exec:");
^ permalink raw reply related
* [take 2] Clean up "git log" format with DIFF_FORMAT_NO_OUTPUT
From: Linus Torvalds @ 2007-10-09 16:35 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano
In-Reply-To: <alpine.LFD.0.999.0710081353290.4964@woody.linux-foundation.org>
Clean up "git log" format with DIFF_FORMAT_NO_OUTPUT
This fixes an unnecessary empty line that we add to the log message when
we generate diffs, but don't actually end up printing any due to having
DIFF_FORMAT_NO_OUTPUT set.
This can happen with pickaxe or with rename following. The reason is that
we normally add an empty line between the commit and the diff, but we do
that even for the case where we've then suppressed the actual printing of
the diff.
This also updates a couple of tests that assumed the extraneous empty
line would exist at the end of output.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
---
This is a resend of the original patch, with just the changes to the tests
added to make it pass them all. Both of the tests actually got cleaner, I
think (ie one had the sed script blindly just delete the last line in
order to match it up with the known input, for example).
Linus
log-tree.c | 3 ++-
t/t3900-i18n-commit.sh | 2 +-
t/t4013/diff.log_-SF_master | 1 -
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/log-tree.c b/log-tree.c
index 2319154..62edd34 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -304,7 +304,8 @@ int log_tree_diff_flush(struct rev_info *opt)
* output for readability.
*/
show_log(opt, opt->diffopt.msg_sep);
- if (opt->verbose_header &&
+ if ((opt->diffopt.output_format & ~DIFF_FORMAT_NO_OUTPUT) &&
+ opt->verbose_header &&
opt->commit_format != CMIT_FMT_ONELINE) {
int pch = DIFF_FORMAT_DIFFSTAT | DIFF_FORMAT_PATCH;
if ((pch & opt->diffopt.output_format) == pch)
diff --git a/t/t3900-i18n-commit.sh b/t/t3900-i18n-commit.sh
index fcbabe8..94b1c24 100755
--- a/t/t3900-i18n-commit.sh
+++ b/t/t3900-i18n-commit.sh
@@ -8,7 +8,7 @@ test_description='commit and log output encodings'
. ./test-lib.sh
compare_with () {
- git show -s $1 | sed -e '1,/^$/d' -e 's/^ //' -e '$d' >current &&
+ git show -s $1 | sed -e '1,/^$/d' -e 's/^ //' >current &&
git diff current "$2"
}
diff --git a/t/t4013/diff.log_-SF_master b/t/t4013/diff.log_-SF_master
index 6162ed2..c1599f2 100644
--- a/t/t4013/diff.log_-SF_master
+++ b/t/t4013/diff.log_-SF_master
@@ -4,5 +4,4 @@ Author: A U Thor <author@example.com>
Date: Mon Jun 26 00:02:00 2006 +0000
Third
-
$
^ permalink raw reply related
* Re: Merge problems with git-mingw
From: Steffen Prohaska @ 2007-10-09 16:33 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Peter Karlsson, Git Mailing List, Johannes Schindelin
In-Reply-To: <470B43D2.6090307@viscovery.net>
On Oct 9, 2007, at 11:03 AM, Johannes Sixt wrote:
> Peter Karlsson schrieb:
>> C:\Program Files\Git\bin>git var -l
>> usage: git-var [-l | <variable>]
>> C:\Program Files\Git\bin>git-var -l
>> fatal: Not a git repository
>> C:\Program Files\Git\bin>git --version
>> git version 1.5.3.mingw.1
>
> For the time being, install this beast in a path without blanks.
>
> This needs fixing, appearently. :(
I have the printf 'callstack' below from the v1.5.3.mingw.1 version
(9c792c5)
Apparently spawnve, which is called in compat/mingw.c, corrupts argv.
I have no idea how to continue debugging. Maybe some one else can
take over.
Steffen
$ git var GIT_COMMITTER_IDENT
argv at git.c:429
3
C:\Program Files (x86)\Git\bin\git.exe
var
C:/Program Files (x86)/Git/bin/git-var
GIT_COMMITTER_IDENT
argv at compat/mingw.c:301
C:/Program Files (x86)/Git/bin/git-var
GIT_COMMITTER_IDENT
(null)
argv at var.c:54
4
C:/Program
Files
(x86)/Git/bin/git-var
GIT_COMMITTER_IDENT
usage: git-var [-l | <variable>]
^ permalink raw reply
* [PATCH] Minor usage update in setgitperms.perl
From: Josh England @ 2007-10-09 16:04 UTC (permalink / raw)
To: git; +Cc: Josh England
Signed-off-by: Josh England <jjengla@sandia.gov>
---
contrib/hooks/setgitperms.perl | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/contrib/hooks/setgitperms.perl b/contrib/hooks/setgitperms.perl
index 5e3b89d..bd48e27 100644
--- a/contrib/hooks/setgitperms.perl
+++ b/contrib/hooks/setgitperms.perl
@@ -8,13 +8,14 @@
# To save permissions/ownership data, place this script in your .git/hooks
# directory and enable a `pre-commit` hook with the following lines:
# #!/bin/sh
-# . git-sh-setup
+# SUBDIRECTORY_OK=1 . git-sh-setup
# $GIT_DIR/hooks/setgitperms.perl -r
#
# To restore permissions/ownership data, place this script in your .git/hooks
-# directory and enable a `post-merge` hook with the following lines:
+# directory and enable a `post-merge` and `post-checkout` hook with the
+# following lines:
# #!/bin/sh
-# . git-sh-setup
+# SUBDIRECTORY_OK=1 . git-sh-setup
# $GIT_DIR/hooks/setgitperms.perl -w
#
use strict;
--
1.5.3.2.111.g5166-dirty
^ permalink raw reply related
* Re: Adding color to git-add--interactive
From: Wincent Colaiuta @ 2007-10-09 14:44 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jonathan del Strother, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0710091503460.4174@racer.site>
El 9/10/2007, a las 16:04, Johannes Schindelin escribió:
> 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.
Why so combative, Johannes? I merely answered one of Jonathan's
questions. Nobody has proffered any "excuses".
And in any case, you're exaggerating. Jonathan said that he's already
invested time in trying to get it working, most certainly more time
than it has taken he, you or I, to write the emails in this thread,
and he's gotten as far as his Perl knowledge permits him.
Cheers,
Wincent
^ permalink raw reply
* [PATCH] Support cvs via git-shell
From: Johannes Schindelin @ 2007-10-09 14:33 UTC (permalink / raw)
To: gitster, hjemli; +Cc: Jan Wielemaker, Git Mailing List
In-Reply-To: <200710051453.47622.wielemak@science.uva.nl>
This adds cvs support to the git-shell; You can now give new users
a restricted git-shell and they still can commit via git's cvs
emulator.
Note that either the gecos information must be accurate, or you must
provide a $HOME/.gitconfig with the appropriate user credentials.
Since the git-shell is too restricted to allow the user to do it
(on purpose!), it is up to the administrator to take care of that.
Based on an idea by Jan Wielemaker.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Since Jan seems to be too busy to do it (in contrast to everybody
else), I ended up implementing my advices myself. At least that
way, I can take the credit, too, since not many things are left
from the original patch.
shell.c | 27 ++++++++++++++++++++++++++-
1 files changed, 26 insertions(+), 1 deletions(-)
diff --git a/shell.c b/shell.c
index c983fc7..cfe372b 100644
--- a/shell.c
+++ b/shell.c
@@ -1,6 +1,7 @@
#include "cache.h"
#include "quote.h"
#include "exec_cmd.h"
+#include "strbuf.h"
static int do_generic_cmd(const char *me, char *arg)
{
@@ -18,12 +19,34 @@ static int do_generic_cmd(const char *me, char *arg)
return execv_git_cmd(my_argv);
}
+static int do_cvs_cmd(const char *me, char *arg)
+{
+ const char *cvsserver_argv[3] = {
+ "cvsserver", "server", NULL
+ };
+ const char *oldpath = getenv("PATH");
+ struct strbuf newpath = STRBUF_INIT;
+
+ if (!arg || strcmp(arg, "server"))
+ die("git-cvsserver only handles server: %s", arg);
+
+ strbuf_addstr(&newpath, git_exec_path());
+ strbuf_addch(&newpath, ':');
+ strbuf_addstr(&newpath, oldpath);
+
+ setenv("PATH", strbuf_detach(&newpath, NULL), 1);
+
+ return execv_git_cmd(cvsserver_argv);
+}
+
+
static struct commands {
const char *name;
int (*exec)(const char *me, char *arg);
} cmd_list[] = {
{ "git-receive-pack", do_generic_cmd },
{ "git-upload-pack", do_generic_cmd },
+ { "cvs", do_cvs_cmd },
{ NULL },
};
@@ -32,8 +55,10 @@ int main(int argc, char **argv)
char *prog;
struct commands *cmd;
+ if (argc == 2 && !strcmp(argv[1], "cvs server"))
+ argv--;
/* We want to see "-c cmd args", and nothing else */
- if (argc != 3 || strcmp(argv[1], "-c"))
+ else if (argc != 3 || strcmp(argv[1], "-c"))
die("What do you think I am? A shell?");
prog = argv[2];
--
1.5.3.4.1169.g5fb8d
^ permalink raw reply related
* Re: [PATCH] rebase -i: use diff plumbing instead of porcelain
From: Johannes Sixt @ 2007-10-09 14:26 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0710091353140.4174@racer.site>
Johannes Schindelin schrieb:
> 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.
Thanks a lot! That works much better.
-- Hannes
^ permalink raw reply
* Re: [PATCH] mergetool: add support for ECMerge
From: Alan Hadsell @ 2007-10-09 14:21 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Johannes Schindelin, Git Mailing List, Theodore Tso
In-Reply-To: <236E44B5-361E-4CE3-8C3D-BDAD0569642E@zib.de>
Steffen Prohaska writes:
> 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.
>From their FAQ:
Does WinMerge support merging three files? Sometimes it is called
3-way merge, where one file is ancestor. This would be useful for
version control!
Unfortunately not. We acknowledge it would be good feature but have no
plans to implement it in near future. This can be somewhat worked
around by using two WinMerge instances. (One developer has begun
preliminary work on this feature, but it is not yet available, even in
experimental releases.)
^ 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
* 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
* 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: [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: 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: 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: [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: 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] 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: 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
* 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] 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
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