* Re: [PATCH] Support output ISO 8601 format dates
From: Robin Rosenberg @ 2007-07-15 23:19 UTC (permalink / raw)
To: Jan Hudec; +Cc: junkio, git
In-Reply-To: <20070715212359.GB18293@efreet.light.src>
From 59eafc201aec3be121b33c2ecf16c70cc3521e92 Mon Sep 17 00:00:00 2001
From: Robin Rosenberg <robin.rosenberg@dewire.com>
Date: Mon, 16 Jul 2007 01:05:19 +0200
Subject: [PATCH] Support output ISO 8601 format dates
Support output of full ISO 8601 style dates in e.g. git log
and other places that use interpolation for formatting.
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
Documentation/pretty-formats.txt | 2 ++
cache.h | 2 +-
commit.c | 6 +++++-
date.c | 9 +++++++++
4 files changed, 17 insertions(+), 2 deletions(-)
söndag 15 juli 2007 skrev Jan Hudec:
> Hello,
>
> On Fri, Jul 13, 2007 at 22:22:58 +0200, Robin Rosenberg wrote:
> > + else if (mode == DATE_ISO8601)
> > + sprintf(timebuf, "%04d-%02d-%02d %02d:%02d:%02d %+05d",
> > + tm->tm_year + 1900,
> > + tm->tm_mon + 1,
> > + tm->tm_mday,
> > + tm->tm_hour, tm->tm_min, tm->tm_sec,
> > + tz);
>
> I apologise for nitpicking, but ISO 8601 (and RFC 3339) says separator between
> date and time is 'T' and there is no separator between time and timezone. So
> this should be
>
> + sprintf(timebuf, "%04d-%02d-%02dT%02d:%02d:%02d%+05d",
Note that my reference is to ISO 8601, not RFC 3339. Hower I interpret "NOTE By mutual
agreement of the partners in information interchange, the character [T] may be omitted in
applications where there is no risk of confusing a date and time of day representation with
others defined in this International Standard" (ISO 8601:2004 4.3.2) as space being
allowed here instead of 'T'.
By "mutual agreement" I mean that I tell you what it looks like and you agree :)
I agree with you about the space before timezone though. I'll go.
> for 100% conformance to the standard. RFC 3339 explicitely mentions using
> space instead of 'T' as separator as allowed, but does not seem to mention
> space before time zone. There may be applications that would stop at such
> space and assume no timezone information.
>
> Furthermore RFC 3339 seems to require colon in the timezone, so it would be:
>
> + sprintf(timebuf, "%04d-%02d-%02dT%02d:%02d:%02d%+03d:%02d",
> + tm->tm_year + 1900,
> + tm->tm_mon + 1,
> + tm->tm_mday,
> + tm->tm_hour, tm->tm_min, tm->tm_sec,
> + tz / 100, abs(tz % 100));
>
> ISO 8601 makes separators optional, so simple 4-digit timezone is OK.
For the sake of consequence I should use the extended format for all parts and not mix
basic and extended formats.
Updated patch follows that formats dates as "2006-08-17 20:59:46+05:30"
-- robin
diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
index d922e8e..1296b31 100644
--- a/Documentation/pretty-formats.txt
+++ b/Documentation/pretty-formats.txt
@@ -106,12 +106,14 @@ The placeholders are:
- '%aD': author date, RFC2822 style
- '%ar': author date, relative
- '%at': author date, UNIX timestamp
+- '%ai': author date, ISO 8601 format
- '%cn': committer name
- '%ce': committer email
- '%cd': committer date
- '%cD': committer date, RFC2822 style
- '%cr': committer date, relative
- '%ct': committer date, UNIX timestamp
+- '%ci': committer date, ISO 8601 format
- '%e': encoding
- '%s': subject
- '%b': body
diff --git a/cache.h b/cache.h
index 5dff2f1..3dc0def 100644
--- a/cache.h
+++ b/cache.h
@@ -389,7 +389,7 @@ extern void *read_object_with_reference(const unsigned char *sha1,
unsigned long *size,
unsigned char *sha1_ret);
-enum date_mode { DATE_NORMAL = 0, DATE_RELATIVE, DATE_SHORT, DATE_LOCAL };
+enum date_mode { DATE_NORMAL = 0, DATE_RELATIVE, DATE_SHORT, DATE_LOCAL, DATE_ISO8601 };
const char *show_date(unsigned long time, int timezone, enum date_mode mode);
const char *show_rfc2822_date(unsigned long time, int timezone);
int parse_date(const char *date, char *buf, int bufsize);
diff --git a/commit.c b/commit.c
index 5632e32..68df3b4 100644
--- a/commit.c
+++ b/commit.c
@@ -773,6 +773,7 @@ static void fill_person(struct interp *table, const char *msg, int len)
interp_set_entry(table, 2, show_date(date, tz, 0));
interp_set_entry(table, 3, show_rfc2822_date(date, tz));
interp_set_entry(table, 4, show_date(date, tz, 1));
+ interp_set_entry(table, 6, show_date(date, tz, DATE_ISO8601));
}
static long format_commit_message(const struct commit *commit,
@@ -791,12 +792,14 @@ static long format_commit_message(const struct commit *commit,
{ "%aD" }, /* author date, RFC2822 style */
{ "%ar" }, /* author date, relative */
{ "%at" }, /* author date, UNIX timestamp */
+ { "%ai" }, /* author date, ISO 8601 */
{ "%cn" }, /* committer name */
{ "%ce" }, /* committer email */
{ "%cd" }, /* committer date */
{ "%cD" }, /* committer date, RFC2822 style */
{ "%cr" }, /* committer date, relative */
{ "%ct" }, /* committer date, UNIX timestamp */
+ { "%ci" }, /* committer date, ISO 8601 */
{ "%e" }, /* encoding */
{ "%s" }, /* subject */
{ "%b" }, /* body */
@@ -813,10 +816,11 @@ static long format_commit_message(const struct commit *commit,
IPARENTS, IPARENTS_ABBREV,
IAUTHOR_NAME, IAUTHOR_EMAIL,
IAUTHOR_DATE, IAUTHOR_DATE_RFC2822, IAUTHOR_DATE_RELATIVE,
- IAUTHOR_TIMESTAMP,
+ IAUTHOR_TIMESTAMP, IAUTHOR_ISO8601,
ICOMMITTER_NAME, ICOMMITTER_EMAIL,
ICOMMITTER_DATE, ICOMMITTER_DATE_RFC2822,
ICOMMITTER_DATE_RELATIVE, ICOMMITTER_TIMESTAMP,
+ ICOMMITTER_ISO8601,
IENCODING,
ISUBJECT,
IBODY,
diff --git a/date.c b/date.c
index 4690371..c96100e 100644
--- a/date.c
+++ b/date.c
@@ -137,7 +137,15 @@ const char *show_date(unsigned long time, int tz, enum date_mode mode)
if (mode == DATE_SHORT)
sprintf(timebuf, "%04d-%02d-%02d", tm->tm_year + 1900,
tm->tm_mon + 1, tm->tm_mday);
+ else if (mode == DATE_ISO8601)
+ sprintf(timebuf, "%04d-%02d-%02d %02d:%02d:%02d%+03d:%02d",
+ tm->tm_year + 1900,
+ tm->tm_mon + 1,
+ tm->tm_mday,
+ tm->tm_hour, tm->tm_min, tm->tm_sec,
+ tz/100,
+ abs(tz%100)
+ );
else
sprintf(timebuf, "%.3s %.3s %d %02d:%02d:%02d %d%c%+05d",
weekday_names[tm->tm_wday],
--
1.5.2.3
^ permalink raw reply related
* Re: CVS -> SVN -> Git
From: Scott Lamb @ 2007-07-15 23:09 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Martin Langhoff, Julian Phillips, git, dev
In-Reply-To: <4699034A.9090603@alum.mit.edu>
Michael Haggerty wrote:
> One quick-and-dirty idea that I had was to have cvs2svn output
> information compatible with cvsps's output, as I believe that several
> tools rely on cvsps to do the dirty work and so could perhaps be
> persuaded to use cvs2svn out of the box.
I think this would be an excellent approach. The interface between
cvs->X (cvsps), Y->git (git-fastimport), and cvs->git glue
(git-cvsimport) is a great idea for troubleshooting and for code sharing
with other converters. (Shawn O. Pearce's attitude is a great example of
this - he can maintain the part he cares about and several converters
benefit even though he's never used them.)
However, I was unhappy to see that cvsps doesn't reuse any cvs2svn code
or unit tests. I remember seeing a lot of those hairy cases on the
Subversion list long ago, so a CVS converter without those tests seems
untrustworthy. If I maintained an important CVS repository I wanted to
convert to git accurately, I would use cvs2svn.py+git-svnimport over
git-cvsimport any day.
They both seem much better than something like Tailor, though. I've
discovered several things that made me realize going through working
copies is error-prone (as well as slow).
>> Does cvs2svn handle incremental imports, remembering any "guesses"
>> taken earlier? Last time I looked at it, it had far better logic than
>> cvsps, but it didn't do incremental imports, and repeated imports done
>> at different times would "guess" different branching points for new
>> branches, so it _really_ didn't support incrementals
>
> That's correct; cvs2svn does not support incremental conversion at all
> (at least not yet).
That's an important feature for me. I'm using git-cvsimport to track
other people's CVS repositories. Initial import is SLOW and
resource-intensive on the network, client, and server, so I couldn't
switch to anything that didn't support incremental use.
Best regards,
Scott
--
Scott Lamb <http://www.slamb.org/>
^ permalink raw reply
* Re: [PATCH 0/4] Move git-p4import into contrib directory.
From: Junio C Hamano @ 2007-07-15 22:37 UTC (permalink / raw)
To: Sean; +Cc: git
In-Reply-To: <20070715154804.2877361d.seanlkml@sympatico.ca>
Sean <seanlkml@sympatico.ca> writes:
> Having caught up on some list emails, it appears that Git now has a
> much better option for importing from Perforce in the git-p4 front
> end to fast-import.
>
> Is there anyone out there actually even using git-p4import? It was
> written for a very specific case, by a git wannabe hacker who had
> never used Perforce before, and not intended for inclusion in Git
> proper...
>
> My guess is that it could be removed outright without pain to anyone,
> but as a first step, it could be moved into contrib for 1.5.3.
Well, I am all for reducing the code base all the time ;-).
^ permalink raw reply
* Re: finding the right remote branch for a commit
From: Matthias Lederhofer @ 2007-07-15 22:33 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0707112226170.4516@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> In practice, and I consider these all bugs, it does not work:
>
> - you have to say
>
> $ git --work-tree=$HOME --bare init
>
> which is a bit counterintuitive. After all, it is _not_ a bare
> repository. The whole purpose of worktree, as far as I understand, is
> to have a _detached_ repository, which would otherwise be called bare.
Use
$ git --work-tree "$HOME" --git-dir . init
instead.
IMHO the --bare flag did not make much sense before the introduction
of GIT_WORK_TREE and doesn't after, at least not with the meaning it
has: why should 'git --bare' mean to use the repository from cwd?
Ok, git --bare implies that you cannot use a working tree because
you're at the top of the git repository directory which may not be
used as working tree.
Now bare only means that some protection mechanisms are disabled and
some default values change (i.e. overwrite HEAD, enable/disable
reflogs by default). So maybe the name bare itself is a bit
counterintuitive now.
> - $ git status
>
> does not do what you would expect: it fails, telling you that it needs a
> work tree, of all things. You can say (tongue-in-cheek)
>
> $ (export GIT_DIR="$(pwd)" && cd "$(git config core.worktree)" &&
> git status)
>
> So, git knows about the location of the working tree, but just ignores
> that.
>
> - In the case that you forget to set GIT_DIR, you better not have any
> .git/ repository in $HOME/ or $HOME/gits/, because it will pick up that
> instead! Even if you are _inside_ a detached git directory!
>
> So you better not try some games like this in a subdirectory of your
> local git.git repository. It is a fine way to get completely confused.
> And certainly do _not_ do something like "git reset --hard <branch>"
> there.
>
> - Of course, it would be nice if something like that worked:
>
> $ cd $HOME/gits/vim.git
> $ git add $HOME/.vimrc
>
> But it does not work, because it wants to _be_ in the work tree. Of
> course, you have to specify the GIT_DIR again, because the working tree
> does not know about the location of the repository, but vice versa.
Up to now you are supposed to be in the working tree all the time when
using it. Therefore I'd call these feature requests rather than bugs :)
For git status it should be quite easy to add a special case to change
to the top of the working tree as long as no paths are used as
parameters.
When paths are used (either with git status or git add) you'd have to
translate the specified path to a path relative to the working tree.
This should be possible with chdir, getcwd and prefixcmp. If this
gets implemented for git status/git add it should probably get
implemented for all commands for which it makes sense. I think this
would be nice to have but I'm not sure how complicated this is to
implement.
^ permalink raw reply
* Re: question about git-submodule
From: VMiklos @ 2007-07-15 22:29 UTC (permalink / raw)
To: skimo; +Cc: Alex Riesen, git
In-Reply-To: <20070715214530.GK999MdfPADPa@greensroom.kotnet.org>
[-- Attachment #1: Type: text/plain, Size: 805 bytes --]
Hello,
Na Sun, Jul 15, 2007 at 11:45:30PM +0200, Sven Verdoolaege <skimo@kotnet.org> pisal(a):
> You should do a git submodule init first.
nice, now it works :)
then my question would be if the following workflow is possible or not:
1) you told me how to do the following:
a) somebody updates libfoo
b) a dev of main pulls libfoo, commits something like:
diff --git a/libfoo b/libfoo
index 07ceadb..459b61f 160000
--- a/libfoo
+++ b/libfoo
@@ -1 +1 @@
-Subproject commit 07ceadb17ca73636b0d96cb91688baecb1763d9b
+Subproject commit 459b61fa4bba78a6e6542b8fcc0fd8f320eafa8c
c) users have to "git pull; git submodule update" and they'll be happy
2) is it possible to do this without step b)?
i mean adding something like: "Subproject commit HEAD" or "Subproject
commit mybranch"
thanks,
- VMiklos
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply related
* Re: [PATCH] Support output ISO 8601 format dates
From: Junio C Hamano @ 2007-07-15 22:14 UTC (permalink / raw)
To: Jan Hudec; +Cc: Robin Rosenberg, junkio, git
In-Reply-To: <20070715212359.GB18293@efreet.light.src>
Jan Hudec <bulb@ucw.cz> writes:
> I apologise for nitpicking, but ISO 8601 (and RFC 3339) says separator between
> date and time is 'T' and there is no separator between time and timezone. So
> this should be
> ...
> ISO 8601 makes separators optional, so simple 4-digit timezone is OK.
My reading of 8601 was that it is allowed to drop [T] as long as
it is clear from the context by agreement between the parties
involved, although I admit the only copy I have handy is JIS
X0301 (2002), which is matching Japanese industrial standard
that consists of translation of ISO 8601 (2000) plus Japanese
"emperor's era" extensions.
^ permalink raw reply
* Re: Questions about git-fast-import for cvs2svn
From: Robin Rosenberg @ 2007-07-15 21:56 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Shawn O. Pearce, git
In-Reply-To: <469A2B1D.2040107@alum.mit.edu>
söndag 15 juli 2007 skrev Michael Haggerty:
> b. CVS tag/branch creation events do not even include a username.
> Any suggestions for what to use here?
The CVSROOT/history file contains the user name and timestamp of the tag
creation. CVS can be told not to update the file. It is appended to by default.
-- robin
^ permalink raw reply
* Re: [PATCH 0/4] Move git-p4import into contrib directory.
From: Scott Lamb @ 2007-07-15 21:53 UTC (permalink / raw)
To: Sean; +Cc: git
In-Reply-To: <20070715154804.2877361d.seanlkml@sympatico.ca>
Sean wrote:
> Hi Junio,
>
> Having caught up on some list emails, it appears that Git now has a
> much better option for importing from Perforce in the git-p4 front
> end to fast-import.
>
> Is there anyone out there actually even using git-p4import? It was
> written for a very specific case, by a git wannabe hacker who had
> never used Perforce before, and not intended for inclusion in Git
> proper...
>
> My guess is that it could be removed outright without pain to anyone,
> but as a first step, it could be moved into contrib for 1.5.3.
I vote for removing it immediately. It has serious bugs - e.g.,
incremental mode is totally broken. I sent in a patch a month ago to fix
this particular bug, which remains unapplied. Now that git-p4 has made
it into git.git, I don't think anyone - myself included - is interested
in creating or merging git-p4import.py fixes. Keeping git-p4import.py in
this broken state just wastes the time of anyone unlucky enough to see
it first.
Best regards,
Scott
--
Scott Lamb <http://www.slamb.org/>
^ permalink raw reply
* Re: question about git-submodule
From: Sven Verdoolaege @ 2007-07-15 21:45 UTC (permalink / raw)
To: VMiklos; +Cc: Alex Riesen, git
In-Reply-To: <20070715154028.GI7106@genesis.frugalware.org>
On Sun, Jul 15, 2007 at 05:40:28PM +0200, VMiklos wrote:
> vmiklos@vmobile:~/git/test/client2/main$ git submodule update
You should do a git submodule init first.
skimo
^ permalink raw reply
* [StGIT PATCH] Revert 'Disallow non-patch args to "stg show" (gna #8453).'
From: Yann Dirson @ 2007-07-15 21:32 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
This patch has a lot of side-effects that will break people's
expectations. There is much more that just this to do if we want to
sanitize patch/commit/range addressing on the command-line, so that
will wait till after 0.13.
Signed-off-by: Yann Dirson <ydirson@altern.org>
---
stgit/commands/show.py | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/stgit/commands/show.py b/stgit/commands/show.py
index 2b22744..45ca253 100644
--- a/stgit/commands/show.py
+++ b/stgit/commands/show.py
@@ -55,7 +55,12 @@ def func(parser, options, args):
elif len(args) == 0:
patches = ['HEAD']
else:
- patches = parse_patches(args, applied + unapplied +\
+ if len(args) == 1 and args[0].find('..') == -1 \
+ and not crt_series.patch_exists(args[0]):
+ # it might be just a commit id
+ patches = args
+ else:
+ patches = parse_patches(args, applied + unapplied +\
crt_series.get_hidden(), len(applied))
if options.diff_opts:
^ permalink raw reply related
* git-config: replaces ~/.gitconfig symlink with real file
From: Bradford Smith @ 2007-07-15 21:27 UTC (permalink / raw)
To: git
Since the number of dot-files and dot-directories that I have in my
home directory these days is somewhat overwhelming, I like to keep
those I directly edit all together in an ~/etc directory so I can
easily back them up and/or copy them in bulk to new accounts. So,
several of my home dot-files are just symlinks to something in ~/etc,
including ~/.gitconfig.
However, when I tried running 'git-config --global color.diff auto'
today, it removed my symlink and replaced it with a real file. This
left me briefly a bit confused when the changes I had made didn't show
up in ~/etc/gitconfig, but git-config reported them anyway.
If I were to fix this, I'd be tempted to use realpath(3) to follow the
symlink, but I don't think it's very reliably available
cross-platform. Certainly, it isn't used anywhere in the current git
code. Can anyone suggest a more portable fix?
Thanks,
Bradford
^ permalink raw reply
* Re: Confusing language in man page
From: Satyam Sharma @ 2007-07-15 21:25 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20070715094038.GE2568@steel.home>
On 7/15/07, Alex Riesen <raa.lkml@gmail.com> wrote:
> Satyam Sharma, Sat, Jul 14, 2007 22:27:52 +0200:
Ok, the first two were silly questions I got answered as I got to
know more about git automatically :-)
> > * On my system, doing:
> >
> > $ git diff
> >
> > with no outstanding changes in my current working tree produces some
> > bogus newlines, throwing the prompt to the bottom of the xterm window.
> > This sounds like weird / undesirable behaviour and I have a feeling must
> > already be fixed in latest git (?)
>
> It is not git. It is the program less which git uses. The problem is
> known to the author of less.
As for this one, I sent out a mail to bug-less@ just in case -- it's a weird
and annoying thing.
Thanks!
^ permalink raw reply
* Re: [PATCH] Support output ISO 8601 format dates
From: Jan Hudec @ 2007-07-15 21:23 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: junkio, git
In-Reply-To: <20070713202258.14107.18196.stgit@lathund.dewire.com>
[-- Attachment #1: Type: text/plain, Size: 1218 bytes --]
Hello,
On Fri, Jul 13, 2007 at 22:22:58 +0200, Robin Rosenberg wrote:
> + else if (mode == DATE_ISO8601)
> + sprintf(timebuf, "%04d-%02d-%02d %02d:%02d:%02d %+05d",
> + tm->tm_year + 1900,
> + tm->tm_mon + 1,
> + tm->tm_mday,
> + tm->tm_hour, tm->tm_min, tm->tm_sec,
> + tz);
I apologise for nitpicking, but ISO 8601 (and RFC 3339) says separator between
date and time is 'T' and there is no separator between time and timezone. So
this should be
+ sprintf(timebuf, "%04d-%02d-%02dT%02d:%02d:%02d%+05d",
for 100% conformance to the standard. RFC 3339 explicitely mentions using
space instead of 'T' as separator as allowed, but does not seem to mention
space before time zone. There may be applications that would stop at such
space and assume no timezone information.
Furthermore RFC 3339 seems to require colon in the timezone, so it would be:
+ sprintf(timebuf, "%04d-%02d-%02dT%02d:%02d:%02d%+03d:%02d",
+ tm->tm_year + 1900,
+ tm->tm_mon + 1,
+ tm->tm_mday,
+ tm->tm_hour, tm->tm_min, tm->tm_sec,
+ tz / 100, abs(tz % 100));
ISO 8601 makes separators optional, so simple 4-digit timezone is OK.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH 4/4] Update 1.5.3 release notes: git-p4import has been deprecated
From: Sean @ 2007-07-15 19:53 UTC (permalink / raw)
To: git
In-Reply-To: <20070715154804.2877361d.seanlkml@sympatico.ca>
Signed-off-by: Sean Estabrooks <seanlkml@sympatico.ca>
---
Documentation/RelNotes-1.5.3.txt | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/Documentation/RelNotes-1.5.3.txt b/Documentation/RelNotes-1.5.3.txt
index e2e809e..00b2b93 100644
--- a/Documentation/RelNotes-1.5.3.txt
+++ b/Documentation/RelNotes-1.5.3.txt
@@ -172,6 +172,11 @@ Updates since v1.5.2
concatenate them into a single line and treat the result as
"oneline".
+ - "git p4import" has been demoted to contrib status. For
+ a superior option, checkout the git-p4 front end to
+ git-fast-import (also in contrib). The man page and p4
+ rpm have been removed as well.
+
* Builds
- old-style function definitions (most notably, a function
--
1.5.3.rc0.826.gc301a3
^ permalink raw reply related
* [PATCH 3/4] Demote git-p4import to contrib status.
From: Sean @ 2007-07-15 19:52 UTC (permalink / raw)
To: git
In-Reply-To: <20070715154804.2877361d.seanlkml@sympatico.ca>
Move git-p4import.py and Documentation/git-p4import.txt into
a contrib/p4import directory. Add a README there directing
people to contrib/fast-import/git-p4 as a better alternative.
Signed-off-by: Sean Estabrooks <seanlkml@sympatico.ca>
---
contrib/p4import/README | 1 +
.../p4import/git-p4import.py | 0
.../p4import}/git-p4import.txt | 0
3 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 contrib/p4import/README
rename git-p4import.py => contrib/p4import/git-p4import.py (100%)
rename {Documentation => contrib/p4import}/git-p4import.txt (100%)
diff --git a/contrib/p4import/README b/contrib/p4import/README
new file mode 100644
index 0000000..b9892b6
--- /dev/null
+++ b/contrib/p4import/README
@@ -0,0 +1 @@
+Please see contrib/fast-import/git-p4 for a better Perforce importer.
diff --git a/git-p4import.py b/contrib/p4import/git-p4import.py
similarity index 100%
rename from git-p4import.py
rename to contrib/p4import/git-p4import.py
diff --git a/Documentation/git-p4import.txt b/contrib/p4import/git-p4import.txt
similarity index 100%
rename from Documentation/git-p4import.txt
rename to contrib/p4import/git-p4import.txt
--
1.5.3.rc0.826.gc301a3
^ permalink raw reply related
* [PATCH 2/4] Remove p4 rpm from git.spec.in.
From: Sean @ 2007-07-15 19:51 UTC (permalink / raw)
To: git
In-Reply-To: <20070715154804.2877361d.seanlkml@sympatico.ca>
Signed-off-by: Sean Estabrooks <seanlkml@sympatico.ca>
---
git.spec.in | 29 +++++++++--------------------
1 files changed, 9 insertions(+), 20 deletions(-)
NOTE: Unfortunately i have no way to test this here, anyone?
diff --git a/git.spec.in b/git.spec.in
index 27182ba..fe7b3d8 100644
--- a/git.spec.in
+++ b/git.spec.in
@@ -12,7 +12,7 @@ URL: http://kernel.org/pub/software/scm/git/
Source: http://kernel.org/pub/software/scm/git/%{name}-%{version}.tar.gz
BuildRequires: zlib-devel >= 1.2, openssl-devel, curl-devel, expat-devel %{!?_without_docs:, xmlto, asciidoc > 6.0.3}
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
-Requires: git-core, git-svn, git-cvs, git-arch, git-email, gitk, git-gui, git-p4, perl-Git
+Requires: git-core, git-svn, git-cvs, git-arch, git-email, gitk, git-gui, perl-Git
%description
Git is a fast, scalable, distributed revision control system with an
@@ -53,13 +53,6 @@ Requires: git-core = %{version}-%{release}, tla
%description arch
Git tools for importing Arch repositories.
-%package p4
-Summary: Git tools for importing Perforce repositories
-Group: Development/Tools
-Requires: git-core = %{version}-%{release}, python
-%description p4
-Git tools for importing Perforce repositories.
-
%package email
Summary: Git tools for sending email
Group: Development/Tools
@@ -95,14 +88,14 @@ Perl interface to Git
%setup -q
%build
-make %{_smp_mflags} CFLAGS="$RPM_OPT_FLAGS" WITH_P4IMPORT=YesPlease \
+make %{_smp_mflags} CFLAGS="$RPM_OPT_FLAGS" \
ETC_GITCONFIG=/etc/gitconfig \
- prefix=%{_prefix} PYTHON_PATH=%{python_path} all %{!?_without_docs: doc}
+ prefix=%{_prefix} all %{!?_without_docs: doc}
%install
rm -rf $RPM_BUILD_ROOT
make %{_smp_mflags} CFLAGS="$RPM_OPT_FLAGS" DESTDIR=$RPM_BUILD_ROOT \
- WITH_P4IMPORT=YesPlease prefix=%{_prefix} mandir=%{_mandir} \
+ prefix=%{_prefix} mandir=%{_mandir} \
ETC_GITCONFIG=/etc/gitconfig \
PYTHON_PATH=%{python_path} \
INSTALLDIRS=vendor install %{!?_without_docs: install-doc}
@@ -110,10 +103,10 @@ find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} ';'
find $RPM_BUILD_ROOT -type f -name '*.bs' -empty -exec rm -f {} ';'
find $RPM_BUILD_ROOT -type f -name perllocal.pod -exec rm -f {} ';'
-(find $RPM_BUILD_ROOT%{_bindir} -type f | grep -vE "p4import|archimport|svn|cvs|email|gitk|git-gui|git-citool" | sed -e s@^$RPM_BUILD_ROOT@@) > bin-man-doc-files
+(find $RPM_BUILD_ROOT%{_bindir} -type f | grep -vE "archimport|svn|cvs|email|gitk|git-gui|git-citool" | sed -e s@^$RPM_BUILD_ROOT@@) > bin-man-doc-files
(find $RPM_BUILD_ROOT%{perl_vendorlib} -type f | sed -e s@^$RPM_BUILD_ROOT@@) >> perl-files
%if %{!?_without_docs:1}0
-(find $RPM_BUILD_ROOT%{_mandir} $RPM_BUILD_ROOT/Documentation -type f | grep -vE "p4import|archimport|svn|git-cvs|email|gitk|git-gui|git-citool" | sed -e s@^$RPM_BUILD_ROOT@@ -e 's/$/*/' ) >> bin-man-doc-files
+(find $RPM_BUILD_ROOT%{_mandir} $RPM_BUILD_ROOT/Documentation -type f | grep -vE "archimport|svn|git-cvs|email|gitk|git-gui|git-citool" | sed -e s@^$RPM_BUILD_ROOT@@ -e 's/$/*/' ) >> bin-man-doc-files
%else
rm -rf $RPM_BUILD_ROOT%{_mandir}
%endif
@@ -145,13 +138,6 @@ rm -rf $RPM_BUILD_ROOT
%{!?_without_docs: %{_mandir}/man1/git-archimport.1*}
%{!?_without_docs: %doc Documentation/git-archimport.html }
-%files p4
-%defattr(-,root,root)
-%doc Documentation/git-p4import.txt
-%{_bindir}/git-p4import
-%{!?_without_docs: %{_mandir}/man1/git-p4import.1*}
-%{!?_without_docs: %doc Documentation/git-p4import.html }
-
%files email
%defattr(-,root,root)
%doc Documentation/*email*.txt
@@ -187,6 +173,9 @@ rm -rf $RPM_BUILD_ROOT
%{!?_without_docs: %doc Documentation/technical}
%changelog
+* Sun Jul 15 2007 Sean Estabrooks <seanlkml@sympatico.ca>
+- Removed p4import.
+
* Tue Jun 26 2007 Quy Tonthat <qtonthat@gmail.com>
- Fixed problems looking for wrong manpages.
--
1.5.3.rc0.826.gc301a3
On Sun, 15 Jul 2007 15:48:04 -0400
Sean <seanlkml@sympatico.ca> wrote:
> Hi Junio,
>
> Having caught up on some list emails, it appears that Git now has a
> much better option for importing from Perforce in the git-p4 front
> end to fast-import.
>
> Is there anyone out there actually even using git-p4import? It was
> written for a very specific case, by a git wannabe hacker who had
> never used Perforce before, and not intended for inclusion in Git
> proper...
>
> My guess is that it could be removed outright without pain to anyone,
> but as a first step, it could be moved into contrib for 1.5.3.
>
> Sean
>
^ permalink raw reply related
* [PATCH 1/4] Remove "WITH_P4IMPORT" knob from the Makefile
From: Sean @ 2007-07-15 19:49 UTC (permalink / raw)
To: Sean; +Cc: git
In-Reply-To: <20070715154804.2877361d.seanlkml@sympatico.ca>
Signed-off-by: Sean Estabrooks <seanlkml@sympatico.ca>
---
Makefile | 26 --------------------------
1 files changed, 0 insertions(+), 26 deletions(-)
diff --git a/Makefile b/Makefile
index 5b30e5c..cc18bf4 100644
--- a/Makefile
+++ b/Makefile
@@ -112,8 +112,6 @@ all::
# Define NO_PERL_MAKEMAKER if you cannot use Makefiles generated by perl's
# MakeMaker (e.g. using ActiveState under Cygwin).
#
-# Define WITH_P4IMPORT to build and install Python git-p4import script.
-#
# Define NO_TCLTK if you do not want Tcl/Tk GUI.
#
# The TCL_PATH variable governs the location of the Tcl interpreter
@@ -222,20 +220,9 @@ SCRIPT_PERL = \
git-svnimport.perl git-cvsexportcommit.perl \
git-send-email.perl git-svn.perl
-SCRIPT_PYTHON = \
- git-p4import.py
-
-ifdef WITH_P4IMPORT
SCRIPTS = $(patsubst %.sh,%,$(SCRIPT_SH)) \
$(patsubst %.perl,%,$(SCRIPT_PERL)) \
- $(patsubst %.py,%,$(SCRIPT_PYTHON)) \
git-status git-instaweb
-else
-SCRIPTS = $(patsubst %.sh,%,$(SCRIPT_SH)) \
- $(patsubst %.perl,%,$(SCRIPT_PERL)) \
- git-status git-instaweb
-endif
-
# ... and all the rest that could be moved out of bindir to gitexecdir
PROGRAMS = \
@@ -285,9 +272,6 @@ endif
ifndef PERL_PATH
PERL_PATH = /usr/bin/perl
endif
-ifndef PYTHON_PATH
- PYTHON_PATH = /usr/local/bin/python
-endif
export PERL_PATH
@@ -710,7 +694,6 @@ prefix_SQ = $(subst ','\'',$(prefix))
SHELL_PATH_SQ = $(subst ','\'',$(SHELL_PATH))
PERL_PATH_SQ = $(subst ','\'',$(PERL_PATH))
-PYTHON_PATH_SQ = $(subst ','\'',$(PYTHON_PATH))
TCLTK_PATH_SQ = $(subst ','\'',$(TCLTK_PATH))
LIBS = $(GITLIBS) $(EXTLIBS)
@@ -782,15 +765,6 @@ $(patsubst %.sh,%,$(SCRIPT_SH)) : % : %.sh
$(patsubst %.perl,%,$(SCRIPT_PERL)): perl/perl.mak
-$(patsubst %.py,%,$(SCRIPT_PYTHON)) : % : %.py
- rm -f $@ $@+
- sed -e '1s|#!.*/python|#!$(PYTHON_PATH_SQ)|' \
- -e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
- -e 's/@@NO_CURL@@/$(NO_CURL)/g' \
- $@.py >$@+
- chmod +x $@+
- mv $@+ $@
-
perl/perl.mak: GIT-CFLAGS
$(QUIET_SUBDIR0)perl $(QUIET_SUBDIR1) PERL_PATH='$(PERL_PATH_SQ)' prefix='$(prefix_SQ)' $(@F)
--
1.5.3.rc0.826.gc301a3
^ permalink raw reply related
* [PATCH 0/4] Move git-p4import into contrib directory.
From: Sean @ 2007-07-15 19:48 UTC (permalink / raw)
To: git
Hi Junio,
Having caught up on some list emails, it appears that Git now has a
much better option for importing from Perforce in the git-p4 front
end to fast-import.
Is there anyone out there actually even using git-p4import? It was
written for a very specific case, by a git wannabe hacker who had
never used Perforce before, and not intended for inclusion in Git
proper...
My guess is that it could be removed outright without pain to anyone,
but as a first step, it could be moved into contrib for 1.5.3.
Sean
^ permalink raw reply
* Re: Questions about git-fast-import for cvs2svn
From: Steffen Prohaska @ 2007-07-15 18:58 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Sean, Shawn Pearce, Git Mailing List
In-Reply-To: <F06A5876-BA2A-4172-B2D1-BBCFF92C83EF@zib.de>
On Jul 15, 2007, at 8:51 PM, Steffen Prohaska wrote:
> I'm not sure if merges help to solve the situation described by
> Michael.
> From my understanding the situation is more like starting a branch and
> later 'cherry-picking' commits from various other branches at
> different
> times. Michael describes a situation where a branch would need to
> start
> from multiple commits. I think this is different from merging.
[ Hmm.. should have checked my email another time
to avoid the race condition with Linus ...]
Steffen
^ permalink raw reply
* Re: Questions about git-fast-import for cvs2svn
From: Junio C Hamano @ 2007-07-15 18:55 UTC (permalink / raw)
To: Sean; +Cc: Michael Haggerty, Shawn O. Pearce, git
In-Reply-To: <20070715120149.3271b736.seanlkml@sympatico.ca>
Sean <seanlkml@sympatico.ca> writes:
> Will take a stab at answering your questions...
>
>> 1. Is it a problem to create blobs that are never referenced? The
>> easiest point to create blobs is when the RCS files are originally
>> parsed, but later we discard some CVS revisions, meaning that the
>> corresponding blobs would never be needed. Would this be a problem?
>
> Not a problem. Running "git gc" later will cleanup any unused objects.
>
>> 2. It appears that author/committer require an email address. How
>> important is a valid email address here?
>
> It's not necessary for the operation of Git itself; it's up to you to
> decide how important the information is to your project. You should
> be able to set an empty email address for author or committer in
> git fast-import as "name <>".
Don't do this; git-cvsimport and git-svn uses "name <name>"
which is a saner compromise. This way, you can add .mailmap to
help later "git shortlog" to map using "<name>" part to more
human friendly name. Mapping at conversion time would also be
good and git-cvsimport knows about it (I do not know about
git-svn).
>> b. CVS tag/branch creation events do not even include a username.
>> Any suggestions for what to use here?
>
> Perhaps just use your own username or one specifically created to
> run the conversion process.
I'd suggest to take the person and time information from the
commit that is tagged; that way you can keep the conversion
stable (iow, two conversoin runs using the same input data would
produce identical result).
In git we do not record "branch creation event". Also you can
use lightweight tags which does not have its own data -- which
means you do not have to come up with "the person who made the
tag".
>> 3. I expect we should set 'committer' to the value determined from CVS
>> and leave 'author' unused. But I suppose another possibility would be
>> to set the 'committer' to 'cvs2svn' and the 'author' to the original CVS
>> author. Which one makes sense?
I would set both to "name <name>" from CVS information.
^ permalink raw reply
* Re: Questions about git-fast-import for cvs2svn
From: Steffen Prohaska @ 2007-07-15 18:51 UTC (permalink / raw)
To: Michael Haggerty, Sean; +Cc: Shawn Pearce, Git Mailing List
In-Reply-To: <20070715120149.3271b736.seanlkml@sympatico.ca>
On Jul 15, 2007, at 6:01 PM, Sean wrote:
> On Sun, 15 Jul 2007 16:11:41 +0200
> Michael Haggerty <mhagger@alum.mit.edu> wrote:
>
> [...]
>
>> 3. I expect we should set 'committer' to the value determined from
>> CVS
>> and leave 'author' unused. But I suppose another possibility
>> would be
>> to set the 'committer' to 'cvs2svn' and the 'author' to the
>> original CVS
>> author. Which one makes sense?
>
> Another option is to just allow Git to set author and committer to the
> same value. As noted in the man page: "If author is omitted then
> fast-import will automatically use the committer's information for
> the author portion of the commit".
I expect that committer and author would both be set to the value
determined from CVS. CVS doesn't differentiate and I think the
most reasonable assumption in many CVS settings is that the one
who committed a change is the original author.
>> 4. It appears that a commit can only have a single 'from', which I
>> suppose means that files can only be added to one branch from a
>> single
>> source branch/revision in a single commit. But CVS branches and tags
>> can include files from multiple source branches and/or revisions.
>> What
>> would be the most git-like way to handle this situation? Should the
>> branch be created in one commit, then have files from other sources
>> added to it in other commits? Or should (is this even possible?) all
>> files be added to the branch in a single commit, using multiple
>> "merge"
>> sources?
This is really a hard question, which I feel unable to answer.
My feeling is that you would not be able to construct a git
history where branches would need multiple 'froms'. git always
tracks the complete state of all files in the project. So
you can only branch all files at once or no file at all.
It's really hard to say how the situation you described can
be handled.
However, I have a related comment.
Well maintained CVS branches shouldn't suffer from this problem. In
our repository we typically set a tag topic-split on the CVS trunk
and create the branch topic-branch from this tag. Note, some time may
pass before we commit the first change to topic-branch. I'd expect that
a CVS to git importer should handle this situation perfectly. I'd expect
that the git tag topic-split would be set to the last commit common
to the git branch representing the CVS trunk and the git branch
representing the CVS topic-branch. git-cvsimport fails to do so if
the timing of the first commit to the CVS topic-branch is wrong.
To be honest, we have messy branches as well that start off in an
uncontrolled way. But I'd care less about them than about the well
maintained branches.
Michael,
what do you think. Would cvs2svn perfectly handle the well-formed
CVS branches I described?
I already would be very happy if the well-formed branches can be
imported to git and any malformed branch would be reported.
Maybe a second step could be to import malformed branches nonetheless,
perhaps in a non-standard way and give a hint what the difficulty was.
A human may have a chance to fix it using git tools, such as
git-filter-branch or similar.
> Git supports the ability to merge from multiple branches at once
> (known
> as an octopus merge). So it's possible to start a new branch, drawing
> in files from more than one source branch in a single commit. As i
> understand it, fast-import allows only a single "from" line for a
> commit,
> but allows multiple "merge" lines for additional parentage info.
>
> [...]
I'm not sure if merges help to solve the situation described by Michael.
From my understanding the situation is more like starting a branch and
later 'cherry-picking' commits from various other branches at different
times. Michael describes a situation where a branch would need to start
from multiple commits. I think this is different from merging.
I propose not to create any merge commits during import from CVS to git.
CVS doesn't track merges and therefore I'd expect that the history
created
in git during import should form a tree (without merges). If you have
a custom way to detect merges for a specific CVS repository (e.g. by
parsing
CVS commit messages) you can use a grafts file to add them to git later.
Steffen
^ permalink raw reply
* Re: [PATCH] Add --show-size to git log to print message size
From: Marco Costalba @ 2007-07-15 18:45 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Alex Riesen, Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.LFD.0.999.0707151110520.20061@woody.linux-foundation.org>
On 7/15/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> So you could actually make the parsing really strict, and look for the
> sequence
>
> '\n\0commit '
>
> and that's a very trustworthy delimeter.
>
Thanks to you and Sean for the hint, anyhow I would wish the message
size patch applied if it is possible and there are no drawbacks. Tool
that parses git-log output would benefit form that and the impact (in
code lines) is very low and also does not change anything if not
activated.
Thanks
Marco
^ permalink raw reply
* Re: Questions about git-fast-import for cvs2svn
From: Linus Torvalds @ 2007-07-15 18:43 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Shawn O. Pearce, git
In-Reply-To: <469A2B1D.2040107@alum.mit.edu>
On Sun, 15 Jul 2007, Michael Haggerty wrote:
>
> 1. Is it a problem to create blobs that are never referenced? The
> easiest point to create blobs is when the RCS files are originally
> parsed, but later we discard some CVS revisions, meaning that the
> corresponding blobs would never be needed. Would this be a problem?
No, don't worry about it. The resulting intermediate pack-file may be
unnecessarily big, but you'd want to do a "git gc" to re-pack everything
afterwards *anyway*, since the pack-files git-fast-import generates are
generally not all that optimall, and that will also prune any unreferenced
blobs.
> 2. It appears that author/committer require an email address. How
> important is a valid email address here?
Git itself doesn't really care, and many CVS conversions have just
converted the username into "user <user>", but from a QoI standpoint it's
much nicer if you at least were to allow the kind of conversion that
allows user-name to be associated with an email.
Maybe git-fast-import could be taught to do the kind of user name
conversion that we already do for CVS imports.. Shawn?
> a. CVS commits include a username but not an email address. If an
> email address is really required, then I suppose the person doing the
> conversion would have to supply a lookup table mapping username -> email
> address.
That would be optimal. Note that it's not just user names: it's much nicer
if you can regenerate a readable full name too, so instead of having
something like "torvalds <torvalds>", you could map "torvalds" into "Linus
Torvalds <torvalds@linux-foundation.org>", which is a lot more readable.
But as far as git is concerned, this is all about being _pretty_, it
doesn't really have any semantic meaning!
Anyway, git-cvsimport knows about a magic file ("CVSROOT/users") that can
map user names into full names and emails. Having soemthing equvalent
for a SVN import would be nice (git-svnimport does the same thing, and
uses ".git/svn-authors" as the default source of author name conversion
data).
> b. CVS tag/branch creation events do not even include a username.
> Any suggestions for what to use here?
Git tags and branch creation doesn't do that either (unless you use signed
tags): only when you create the first commit on a branch does the user
matter.
But if there really is data that doesn't have any user information at all
(for real *changes*), then I'd just make one up. Again, the user
information really doesn't have any *semantics* in git, it's just meant to
be informational for showing the logs. It's nothing more than a structured
part of the commit (or tag) message.
> 3. I expect we should set 'committer' to the value determined from CVS
> and leave 'author' unused. But I suppose another possibility would be
> to set the 'committer' to 'cvs2svn' and the 'author' to the original CVS
> author. Which one makes sense?
Just make them be the same. Git-fast-import will default to that, if you
only give a committer date/name.
That's what git itself does if you just do a "git commit": the committer
will the the same as the author.
> 4. It appears that a commit can only have a single 'from'
No, commits can have an arbitrary number of parents, and if you create a
tag where the data comes from several sources, you could literally do that
ass a really strange merge, and that would probably be the most "correct"
thing to do, even if it might end up looking *really* odd.
[ To be strictly technically correct, I have to admit that I think we
limit the number of parents to 16, but that's not a fundamental limit,
that's just because nobody has ever been so crazy as to need more than
that.
However, there is no "data structure limit" in that number, it's just aa
arbitrary "you'd be crazy to generate a merge of that many parents" kind
of thing, and we could lift the limit if you actually think it's worth
it.
I think the most we have ever seen in practice is a merge of 12 parents,
and the people who did that were told to please not do it again, because
it really does make the graph look extremely "cool". ]
> What would be the most git-like way to handle this situation? Should
> the branch be created in one commit, then have files from other sources
> added to it in other commits? Or should (is this even possible?) all
> files be added to the branch in a single commit, using multiple "merge"
> sources?
Using multiple parents and just generating a single commit (it will be
called a "merge", but really, in git terms a commit is just a commit, and
the difference in number of parents is really not a _technical_
difference, it's just a difference for how these things get visualized).
It would be extremely interesting to see how this works in practice, but I
_think_ it would work really well. The possible downsides might be:
- it *may* just end up looking so confusing that people would prefer some
alternate model.
- we might have some performance issues with lots and lots of parents,
and maybe we'd need to fix something. In particular, I can well imagine
that showing the diff for the end result would be "interesting" (read:
"totally useless")
> 5. Is there any significance at all to the order that commits are output
> to git-fast-import? Obviously, blobs have to be defined before they are
> used, and '<committish>'s have to be defined before they are referenced.
> But is there any other significance to the order of commits?
Not afaik. Git internally very fundamentally simply doesn't care (there
simply _is_ no object ordering, there is just objects that point to other
objects), and I don't think git-fast-import could possibly care either.
You do need to be "topologically" sorted (since you cannot even point to
commits without having their SHA1's), but that should be it.
Linus
^ permalink raw reply
* Re: [PATCH] Add --show-size to git log to print message size
From: Linus Torvalds @ 2007-07-15 18:14 UTC (permalink / raw)
To: Marco Costalba; +Cc: Alex Riesen, Junio C Hamano, Git Mailing List
In-Reply-To: <e5bfff550707150529l7e9bdd9fu253d38f99d4d2ed7@mail.gmail.com>
On Sun, 15 Jul 2007, Marco Costalba wrote:
>
> To further push for git patch, please check this from current linux tree:
>
> git log --parents --pretty=raw -z -r -p c4201214
>
> As you can see the diff contains a '\0' value (actually removed by the patch).
So arguably maybe we should have turned that patch into a binary patch,
but then it would have been really hard to read, and GNU patch and friends
couldn't have read it.
So I think a better option would be:
> qgit of course fails, as any tool based on parsing '\0' delimiting
> character records. If the size of the patch was explicitly given
> instead no fail will occur.
You have an alternate fix, namely to only look at the NUL character at
newline boundaries. Also, when it comes to "git log", you actually know
even more: each commit begins with "commit".
A patch will always be nicely line-oriented, and will never have a NULL at
the *beginning* of a line.
So you could actually make the parsing really strict, and look for the
sequence
'\n\0commit '
and that's a very trustworthy delimeter.
But yes, you can have NUL-characters in the middle of patches.
Linus
^ permalink raw reply
* Re: Perforce support.
From: Jan Hudec @ 2007-07-15 17:51 UTC (permalink / raw)
To: Govind Salinas; +Cc: git
In-Reply-To: <69b0c0350707121134t61905e87xaa2fc78c30891bb0@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1594 bytes --]
On Thu, Jul 12, 2007 at 11:34:56 -0700, Govind Salinas wrote:
> I have been playing around with git for a month or so and have started
> writing, what I hope will be, a nice GUI over git that works well on
> Windows (Cygwin) and offers some feeling of familiarity to our
> Perforce users. That however is only half the problem.
There are already several guis for git. None of them covers complete git
functionality, but if you can start adding functionality to one of them
instead of starting from scratch, it would give you a good head start. At
least the git-gui (in Tcl/Tk, part of git distribution) and qgit4
(git://repo.or.cz/qgit4.git, discuss changes on the git mailing list -- se
also http://digilander.libero.it/mcostalba/, but that only discusses the
previous Qt3-based branch) work on Windows.
> We need to be able to go back and forth to our main Perforce depot,
> and while I understand that git-svn support is very good, I have only
> seen limited support of Perforce. I was wondering if anyone has been
> using git with p4 and how well did it work. We have very complex and
> somewhat large "clients" that do a lot of mapping of directories
> (which strikes me as particularly insane) and I was wondering if any
> of the tools support that.
>
> If anyone has any suggestions/guidance on how to do this I would appreciate
> it.
Search the list. The archive at http://marc.info/?l=git provides quite
sensible search support. There were some interesting discussions about
perforce in last few months.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ 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