* Re: Git benchmark - comparison with Bazaar, Darcs, Git and Mercurial
From: Florian Weimer @ 2007-08-01 20:36 UTC (permalink / raw)
To: git
In-Reply-To: <85vebzrufc.fsf@lola.goethe.zz>
* David Kastrup:
> Couldn't git clone http://host/directory/to/repo tell the proxy that
> it should enter off-line mode and stop updating?
Huh? I don't see how this is relevant to the current thread.
Anyway, I don't think the max-stale cache control mechanism is widely
implemented. If you want effective expiry controls, you need to
implement them on the server side.
^ permalink raw reply
* [MinGW PATCH] Fixed error 'fatal: Not a git repository' on Vista
From: Dmitry Kakurin @ 2007-08-02 5:47 UTC (permalink / raw)
To: git
Any git command was immediately failing on Vista under MinGW with
fatal: Not a git repository
>From 51d66fbfe3a7876d9a7b699bb47c0ab186ddc7a2 Mon Sep 17 00:00:00 2001
From: Dmitry Kakurin <Dmitry.Kakurin@gmail.com>
Date: Wed, 1 Aug 2007 22:30:43 -0700
Subject: [PATCH] Fixed error 'fatal: Not a git repository' on Vista
Defined __USE_MINGW_ACCESS that changes access( ..., X_OK ) into F_OK
Signed-off-by: Dmitry Kakurin <Dmitry.Kakurin@gmail.com>
---
Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 8e9a76b..ef40267 100644
--- a/Makefile
+++ b/Makefile
@@ -500,7 +500,7 @@ ifneq (,$(findstring MINGW,$(uname_S)))
NO_SYMLINKS=YesPlease
NO_SVN_TESTS=YesPlease
NO_PERL_MAKEMAKER=YesPlease
- COMPAT_CFLAGS
+= -DNO_ETC_PASSWD -DNO_ST_BLOCKS -DSTRIP_EXTENSION=\".exe\" -I compat
+ COMPAT_CFLAGS
+= -DNO_ETC_PASSWD -DNO_ST_BLOCKS -DSTRIP_EXTENSION=\".exe\" -D__USE_MINGW_ACCESS
-I compat
COMPAT_OBJS += compat/mingw.o compat/fnmatch.o compat/regex.o
EXTLIBS += -lws2_32
X = .exe
--
1.5.2.2
^ permalink raw reply related
* Re: Git benchmark - comparison with Bazaar, Darcs, Git and Mercurial
From: Junio C Hamano @ 2007-08-02 6:09 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Carl Worth, Theodore Tso, Jakub Narebski, Git Mailing List
In-Reply-To: <alpine.LFD.0.999.0708010937050.3582@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> We might make it something like: "if you use an url, we don't default to
> local", so the difference would be that
>
> git clone file:///directory/to/repo
>
> would work the way it does now, but
>
> git clone /directory/to/repo
>
> would default to "-l" behaviour. That kind of would make sense (and should
> be easy to implement: it would be a trivial fixup to "connect.c".
The attached does not default to "-l", but filesystem level copy
behaviour, which is what happens with "clone -l" across
filesystem boundaries with the current code.
Clone of linux-2.6 repository (the source is well packed)
(hardlink -- obviously, almost no cost)
$ /usr/bin/time git clone -l --bare linux-2.6 l-clone.git
Initialized empty Git repository in /git/l-clone.git/
0 blocks
0.55user 1.00system 0:01.56elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+206724minor)pagefaults 0swaps
(same-as-network)
$ /usr/bin/time git clone --bare file://`pwd`/linux-2.6 n-clone.git
Initialized empty Git repository in /git/n-clone.git/
remote: Generating pack...
remote: Counting objects: 1076746
remote: Done counting 1169654 objects.
remote: Deltifying 1169654 objects...
remote: 100% (1169654/1169654) done
Indexing 1169654 objects...
100% (1169654/1169654) done
remote: Total 1169654 (delta 959223), reused 1160595 (delta 950164)
Resolving 959223 deltas...
100% (959223/959223) done
172.85user 20.94system 4:25.88elapsed 72%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (6294major+2019874minor)pagefaults 0swaps
(copy -- takes a lot more than hardlink but cheaper than net)
$ /usr/bin/time git clone --bare linux-2.6 c-clone.git
Initialized empty Git repository in /git/c-clone.git/
1266644 blocks
0.92user 10.81system 0:38.38elapsed 30%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (406major+204775minor)pagefaults 0swaps
I am ambivalent between -l vs no -l.
* Without -l (i.e. have all objects/ copied via cpio) would not
catch the source repository corruption, and also risks
corrupted recipient repository if an alpha-particle hits
memory cell while indexing and resolving deltas. As long as
the recipient is made uncorrupted, you have a good back-up.
* same-as-network is expensive, but it would catch if the
source is already corrupted. It still risks corrupted
recipient repository. As long as the recipient is made
uncorrupted, you have a good back-up.
* With -l, as long as the source repository is healthy, it is
very likely that the recipient would be, too. Also it is
very cheap. You do not get any back-up benefit.
None of the method is resilient against the source repository
corruption, so let's discount that from the comparison. Then
the differences between -l and non -l matters primarily if you
value the back-up benefit or not. If you want to use the cloned
repository as a back-up, then it is cheaper to do a non -l clone
and two git-fsck (source before clone, recipient after clone)
than same-as-network clone, especially as you are likely to do a
git-fsck on the recipient if you are so paranoid anyway.
Which leads me to believe that being able to use file:/// is
probably a good idea, if only for testability, but probably of
little practical value, and we can default to -l for everyday
use, and paranoids can use non -l as a way to make a back-up.
---
git-clone.sh | 61 +++++++++++++++++++++++---------------------
t/t5500-fetch-pack.sh | 2 +-
t/t5700-clone-reference.sh | 2 +-
t/t5701-clone-local.sh | 17 ++++++++++++
4 files changed, 51 insertions(+), 31 deletions(-)
diff --git a/git-clone.sh b/git-clone.sh
index 0922554..0583f64 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -87,7 +87,7 @@ Perhaps git-update-server-info needs to be run there?"
quiet=
local=no
-use_local=no
+use_local_hardlink=no
local_shared=no
unset template
no_checkout=
@@ -108,9 +108,10 @@ while
no_checkout=yes ;;
*,--na|*,--nak|*,--nake|*,--naked|\
*,-b|*,--b|*,--ba|*,--bar|*,--bare) bare=yes ;;
- *,-l|*,--l|*,--lo|*,--loc|*,--loca|*,--local) use_local=yes ;;
+ *,-l|*,--l|*,--lo|*,--loc|*,--loca|*,--local)
+ use_local_hardlink=yes ;;
*,-s|*,--s|*,--sh|*,--sha|*,--shar|*,--share|*,--shared)
- local_shared=yes; use_local=yes ;;
+ local_shared=yes; ;;
1,--template) usage ;;
*,--template)
shift; template="--template=$1" ;;
@@ -249,34 +250,36 @@ fi
rm -f "$GIT_DIR/CLONE_HEAD"
# We do local magic only when the user tells us to.
-case "$local,$use_local" in
-yes,yes)
+case "$local" in
+yes)
( cd "$repo/objects" ) ||
- die "-l flag seen but repository '$repo' is not local."
+ die "cannot chdir to local '$repo/objects'."
- case "$local_shared" in
- no)
- # See if we can hardlink and drop "l" if not.
- sample_file=$(cd "$repo" && \
- find objects -type f -print | sed -e 1q)
-
- # objects directory should not be empty since we are cloning!
- test -f "$repo/$sample_file" || exit
-
- l=
- if ln "$repo/$sample_file" "$GIT_DIR/objects/sample" 2>/dev/null
- then
- l=l
- fi &&
- rm -f "$GIT_DIR/objects/sample" &&
- cd "$repo" &&
- find objects -depth -print | cpio -pumd$l "$GIT_DIR/" || exit 1
- ;;
- yes)
- mkdir -p "$GIT_DIR/objects/info"
- echo "$repo/objects" >> "$GIT_DIR/objects/info/alternates"
- ;;
- esac
+ if test "$local_shared" = yes
+ then
+ mkdir -p "$GIT_DIR/objects/info"
+ echo "$repo/objects" >>"$GIT_DIR/objects/info/alternates"
+ else
+ l= &&
+ if test "$use_local_hardlink" = yes
+ then
+ # See if we can hardlink and drop "l" if not.
+ sample_file=$(cd "$repo" && \
+ find objects -type f -print | sed -e 1q)
+ # objects directory should not be empty because
+ # we are cloning!
+ test -f "$repo/$sample_file" || exit
+ if ln "$repo/$sample_file" "$GIT_DIR/objects/sample" 2>/dev/null
+ then
+ rm -f "$GIT_DIR/objects/sample"
+ l=l
+ else
+ echo >&2 "Warning: -l asked but cannot hardlink to $repo"
+ fi
+ fi &&
+ cd "$repo" &&
+ find objects -depth -print | cpio -pumd$l "$GIT_DIR/" || exit 1
+ fi
git-ls-remote "$repo" >"$GIT_DIR/CLONE_HEAD" || exit 1
;;
*)
diff --git a/t/t5500-fetch-pack.sh b/t/t5500-fetch-pack.sh
index 7da5153..7b6798d 100755
--- a/t/t5500-fetch-pack.sh
+++ b/t/t5500-fetch-pack.sh
@@ -129,7 +129,7 @@ pull_to_client 2nd "B" $((64*3))
pull_to_client 3rd "A" $((1*3)) # old fails
-test_expect_success "clone shallow" "git-clone --depth 2 . shallow"
+test_expect_success "clone shallow" "git-clone --depth 2 file://`pwd`/. shallow"
(cd shallow; git count-objects -v) > count.shallow
diff --git a/t/t5700-clone-reference.sh b/t/t5700-clone-reference.sh
index 6d43252..4e93aaa 100755
--- a/t/t5700-clone-reference.sh
+++ b/t/t5700-clone-reference.sh
@@ -51,7 +51,7 @@ diff expected current'
cd "$base_dir"
test_expect_success 'cloning with reference (no -l -s)' \
-'git clone --reference B A D'
+'git clone --reference B file://`pwd`/A D'
cd "$base_dir"
diff --git a/t/t5701-clone-local.sh b/t/t5701-clone-local.sh
index b093327..032c498 100755
--- a/t/t5701-clone-local.sh
+++ b/t/t5701-clone-local.sh
@@ -43,4 +43,21 @@ test_expect_success 'local clone from x.git that does not exist' '
fi
'
+test_expect_success 'Without -l, local will make a copy' '
+ cd "$D" &&
+ git clone --bare x w &&
+ cd w &&
+ linked=$(find objects -type f ! -links 1 | wc -l) &&
+ test "$linked" = 0
+'
+
+test_expect_success 'With -l, local will make a hardlink' '
+ cd "$D" &&
+ rm -fr w &&
+ git clone -l --bare x w &&
+ cd w &&
+ copied=$(find objects -type f -links 1 | wc -l) &&
+ test "$copied" = 0
+'
+
test_done
^ permalink raw reply related
* Re: [PATCH] Try to be consistent with capitalization in the documentation
From: Junio C Hamano @ 2007-08-02 6:11 UTC (permalink / raw)
To: Steve Hoelzer; +Cc: Junio C Hamano, git
In-Reply-To: <588192970708011017q12c7a6d9s532c8aed086d3032@mail.gmail.com>
"Steve Hoelzer" <shoelzer@gmail.com> writes:
> On 8/1/07, Junio C Hamano <gitster@pobox.com> wrote:
>> Steve Hoelzer <shoelzer@gmail.com> writes:
>>
>> > Signed-off-by: Steve Hoelzer <shoelzer@gmail.com>
>> > ---
>> >
>> > Try to be consistent with capitalization in the documentation.
>>
>> It looks like that all the originals are trying to consistently
>> start with lowercase in an explanatory list. Is this really
>> needed?
>
> The lists I changed were indeed all lowercase, but other lists in
> those files are all uppercase. I was aiming for consistency across all
> list items and all lists.
Fair enough. However, your patch was seriously whitespace
mangled so I made matching edits by hand and committed the
result. After I push out the result sometime tonight, please
double check the result.
^ permalink raw reply
* Re: Windows support
From: Asger Ottar Alstrup @ 2007-08-02 6:57 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0707251139580.14781@racer.site>
Johannes Schindelin wrote:
> On Wed, 25 Jul 2007, Dmitry Kakurin wrote:
>
>> How serious are you guys about Windows support?
>
> Okay, let's talk business:
>
> Pay me decently, and you will have to wait for a few weeks.
I propose that you set up a fundable:
http://fundable.com/
This is a system where anyone can contribute money to the project, but
not have to pay unless the required amount of money has been contributed
in total.
Figure out your price, describe what you will deliver, and announce it.
Regards,
Asger Ottar Alstrup
^ permalink raw reply
* Re: [PATCH 4/4] Clean up work-tree handling
From: Junio C Hamano @ 2007-08-02 7:04 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, matled
In-Reply-To: <Pine.LNX.4.64.0708011239090.14781@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> I do not think the following is exactly what your cleaned-up
>> version tries to perform, but I am writing this down primarily
>> to demonstrate the style and the level of detail I expect to
>> accompany a clean-up patch like this.
>
> After reading your description I sink into the ground in shame. I really
> like the style this has, and agree that something as nice as this should
> have been there.
Not too late. There always is a room for Documentation/
improvements ;-)
Seriously, I think config.txt mentions GIT_WORK_TREE and GIT_DIR
and git.txt has separate sections for environment and config,
but I do not see a good section that gives a comprehensive view
of how they work together to affect your git experience.
Perhaps between File/Directory Structure and Terminology
sections we would want to have a description of how repository
and worktree relate to each other.
^ permalink raw reply
* 1.5.3 plans and preparations
From: Junio C Hamano @ 2007-08-02 7:22 UTC (permalink / raw)
To: git
I'll be pushing out tonight's update and head to bed in about an
hour now.
The changes since -rc3 is rather large, as it contains a large
fixups to one of the topics that is new to 1.5.3 as well as
updates to gitk, git-gui, and gitweb.
I would say this should be pretty much what will be in -rc4 this
weekend.
Please test it thouroughly and send in obviously correct fixes.
---
GIT v1.5.3 Release Notes (draft)
========================
Updates since v1.5.2
--------------------
* The commit walkers other than http are officially deprecated,
but still supported for now.
* The submodule support has Porcelain layer.
* There are a handful pack-objects changes to help you cope better
with repositories with pathologically large blobs in them.
* For people who need to import from Perforce, a front-end for
fast-import is in contrib/fast-import/.
* Comes with git-gui 0.8.0.
* Comes with updated gitk.
* New commands and options.
- "git log --date=<format>" can use more formats: iso8601, rfc2822.
- The hunk header output from "git diff" family can be customized
with the attributes mechanism. See gitattributes(5) for details.
- "git stash" allows you to quickly save away your work in
progress and replay it later on an updated state.
- "git rebase" learned an "interactive" mode that let you
pick and reorder which commits to rebuild.
- "git fsck" can save its findings in $GIT_DIR/lost-found, without a
separate invocation of "git lost-found" command. The blobs stored by
lost-found are stored in plain format to allow you to grep in them.
- $GIT_WORK_TREE environment variable can be used together with
$GIT_DIR to work in a subdirectory of a working tree that is
not located at "$GIT_DIR/..".
- Giving "--file=<file>" option to "git config" is the same as
running the command with GIT_CONFIG=<file> environment.
- "git log" learned a new option "--follow", to follow
renaming history of a single file.
- "git-filter-branch" lets you rewrite the revision history of
the current branch, creating a new branch. You can specify a
number of filters to modify the commits, files and trees.
- "git-cvsserver" learned new options (--base-path, --export-all,
--strict-paths) inspired by git-daemon.
- "git daemon --base-path-relaxed" can help migrating a repository URL
that did not use to use --base-path to use --base-path.
- "git-commit" can use "-t templatefile" option and commit.template
configuration variable to prime the commit message given to you in the
editor.
- "git-submodule" command helps you manage the projects from
the superproject that contain them.
- In addition to core.compression configuration option,
core.loosecompression and pack.compression options can
independently tweak zlib compression levels used for loose
and packed objects.
- "git-ls-tree -l" shows size of blobs pointed at by the
tree entries, similar to "/bin/ls -l".
- "git-rev-list" learned --regexp-ignore-case and
--extended-regexp options to tweak its matching logic used
for --grep fitering.
- "git-describe --contains" is a handier way to call more
obscure command "git-name-rev --tags".
- "git gc --aggressive" tells the command to spend more cycles
to optimize the repository harder.
- "git repack" learned a "window-memory" limit which
dynamically reduces the window size to stay within the
specified memory usage.
- "git repack" can be told to split resulting packs to avoid
exceeding limit specified with "--max-pack-size".
- "git fsck" gained --verbose option. This is really really
verbose but it might help you identify exact commit that is
corrupt in your repository.
- "git format-patch" learned --numbered-files option. This
may be useful for MH users.
- "git format-patch" learned format.subjectprefix configuration
variable, which serves the same purpose as "--subject-prefix"
option.
- "git tag -n -l" shows tag annotations while listing tags.
- "git cvsimport" can optionally use the separate-remote layout.
- "git blame" can be told to see through commits that change
whitespaces and indentation levels with "-w" option.
- "git send-email" can be told not to thread the messages when
sending out more than one patches.
- "git config" learned NUL terminated output format via -z to
help scripts.
- "git init -q" makes the command quieter.
* Updated behavior of existing commands.
- "gitweb" can offer multiple snapshot formats.
***NOTE*** Unfortunately, this changes the format of the
$feature{snapshot}{default} entry in the per-site
configuration file 'gitweb_config.perl'. It used to be a
three-element tuple that describe a single format; with the
new configuration item format, you only have to say the name
of the format ('tgz', 'tbz2' or 'zip'). Please update the
your configuration file accordingly.
- "git diff" (but not the plumbing level "git diff-tree") now
recursively descends into trees by default.
- The editor to use with many interactive commands can be
overridden with GIT_EDITOR environment variable, or if it
does not exist, with core.editor configuration variable. As
before, if you have neither, environment variables VISUAL
and EDITOR are consulted in this order, and then finally we
fall back on "vi".
- "git rm --cached" does not complain when removing a newly
added file from the index anymore.
- Options to "git log" to affect how --grep/--author options look for
given strings now have shorter abbreviations. -i is for ignore case,
and -E is for extended regexp.
- "git svn dcommit" retains local merge information.
- "git config" to set values also honors type flags like --bool
and --int.
- core.quotepath configuration can be used to make textual git
output to emit most of the characters in the path literally.
- "git mergetool" chooses its backend more wisely, taking
notice of its environment such as use of X, Gnome/KDE, etc.
- "gitweb" shows merge commits a lot nicer than before. The
default view uses more compact --cc format, while the UI
allows to choose normal diff with any parent.
- snapshot files "gitweb" creates from a repository at
$path/$project/.git are more useful. We use $project part
in the filename, which we used to discard.
- "git cvsimport" creates lightweight tags; there is no
interesting information we can record in an annotated tag,
and the handcrafted ones the old code created was not
properly formed anyway.
- "git-push" pretends that you immediately fetched back from
the remote by updating corresponding remote tracking
branches if you have any.
- The diffstat given after a merge (or a pull) honors the
color.diff configuration.
- "git commit --amend" is now compatible with various message source
options such as -m/-C/-c/-F.
- "git-apply --whitespace=strip" removes blank lines added at
the end of the file.
- "git-fetch" over git native protocols with "-v" option shows
connection status, and the IP address of the other end, to
help diagnosing problems.
- We used to have core.legacyheaders configuration, when
set to false, allowed git to write loose objects in a format
that mimicks the format used by objects stored in packs. It
turns out that this was not so useful. Although we will
continue to read objects written in that format, we do not
honor that configuration anymore and create loose objects in
the legacy/traditional format.
- "--find-copies-harder" option to diff family can now be
spelled as "-C -C" for brevity.
- "git-mailsplit" (hence "git-am") can read from Maildir
formatted mailboxes.
- "git-cvsserver" does not barf upon seeing "cvs login"
request.
- "pack-objects" honors "delta" attribute set in
.gitattributes. It does not attempt to deltify blobs that
come from paths with delta attribute set to false.
- "new-workdir" script (in contrib) can now be used with a
bare repository.
- "git-mergetool" learned to use gvimdiff.
- "gitview" (in contrib) has a better blame interface.
- "git log" and friends did not handle a commit log message
that is larger than 16kB; they do now.
- "--pretty=oneline" output format for "git log" and friends
deals with "malformed" commit log messages that have more
than one lines in the first paragraph better. We used to
show the first line, cutting the title at mid-sentence; we
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.
- "git mailinfo" (hence "am") now tries to see if the message
is in utf-8 first, instead of assuming iso-8859-1, if
incoming e-mail does not say what encoding it is in.
* Builds
- old-style function definitions (most notably, a function
without parameter defined with "func()", not "func(void)")
have been eradicated.
* Performance Tweaks
- git-pack-objects avoids re-deltification cost by caching
small enough delta results it creates while looking for the
best delta candidates.
- git-pack-objects learned a new heuristcs to prefer delta
that is shallower in depth over the smallest delta
possible. This improves both overall packfile access
performance and packfile density.
- diff-delta code that is used for packing has been improved
to work better on big files.
- when there are more than one pack files in the repository,
the runtime used to try finding an object always from the
newest packfile; it now tries the same packfile as we found
the object requested the last time, which exploits the
locality of references.
- verifying pack contents done by "git fsck --full" got boost
by carefully choosing the order to verify objects in them.
Fixes since v1.5.2
------------------
All of the fixes in v1.5.2 maintenance series are included in
this release, unless otherwise noted.
* Bugfixes
- "gitweb" had trouble handling non UTF-8 text with older
Encode.pm Perl module.
--
exec >/var/tmp/1
O=v1.5.3-rc3-119-g50cff52
echo O=`git describe refs/heads/master`
git shortlog --no-merges $O..refs/heads/master ^refs/heads/maint
^ permalink raw reply
* Fixed text wrapping: [MinGW PATCH] Fixed error 'fatal: Not a git repository' on Vista
From: Dmitry Kakurin @ 2007-08-02 7:46 UTC (permalink / raw)
To: git
Any git command was immediately failing on Vista under MinGW with
fatal: Not a git repository
Defined __USE_MINGW_ACCESS that changes access( ..., X_OK ) into F_OK
Signed-off-by: Dmitry Kakurin <Dmitry.Kakurin@gmail.com>
---
Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 8e9a76b..ef40267 100644
--- a/Makefile
+++ b/Makefile
@@ -500,7 +500,7 @@ ifneq (,$(findstring MINGW,$(uname_S)))
NO_SYMLINKS=YesPlease
NO_SVN_TESTS=YesPlease
NO_PERL_MAKEMAKER=YesPlease
- COMPAT_CFLAGS += -DNO_ETC_PASSWD -DNO_ST_BLOCKS -DSTRIP_EXTENSION=\".exe\" -I compat
+ COMPAT_CFLAGS += -DNO_ETC_PASSWD -DNO_ST_BLOCKS -DSTRIP_EXTENSION=\".exe\" -D__USE_MINGW_ACCESS -I compat
COMPAT_OBJS += compat/mingw.o compat/fnmatch.o compat/regex.o
EXTLIBS += -lws2_32
X = .exe
--
1.5.2.2
^ permalink raw reply related
* Re: cvs2svn conversion directly to git ready for experimentation
From: Steffen Prohaska @ 2007-08-02 8:49 UTC (permalink / raw)
To: Michael Haggerty; +Cc: git, users
In-Reply-To: <46AFCF3E.5010805@alum.mit.edu>
[-- Attachment #1: Type: text/plain, Size: 4365 bytes --]
Michael,
On Aug 1, 2007, at 2:09 AM, Michael Haggerty wrote:
> I am looking forward to your feedback. Even better would be if
> somebody
> wants to join forces on this project. I would be happy to supply the
> cvs2svn knowledge if you can bring the git experience.
I tried it with revision trunk@3930 of cvs2svn. The results are as
follows.
some WARNING: problem encoding log message: [...]
cvs2svn Statistics:
------------------
Total CVS Files: 9578
Total CVS Revisions: 66771
Total CVS Branches: 229121
Total CVS Tags: 371259
Total Unique Tags: 112
Total Unique Branches: 79
CVS Repos Size in KB: 210390
Total SVN Commits: 18178
First Revision Date: Fri Jul 23 10:26:11 1999
Last Revision Date: Thu Jul 19 17:50:40 2007
------------------
Timings (seconds):
------------------
3295 pass1 CollectRevsPass
0 pass2 CollateSymbolsPass
3642 pass3 FilterSymbolsPass
0 pass4 SortRevisionSummaryPass
1 pass5 SortSymbolSummaryPass
109 pass6 InitializeChangesetsPass
56 pass7 BreakRevisionChangesetCyclesPass
66 pass8 RevisionTopologicalSortPass
54 pass9 BreakSymbolChangesetCyclesPass
99 pass10 BreakAllChangesetCyclesPass
92 pass11 TopologicalSortPass
46 pass12 CreateRevsPass
7 pass13 SortSymbolsPass
2 pass14 IndexSymbolsPass
70 pass15 OutputPass
7540 total
I checked that CVS head and two other branches match when checked
out from CVS and from the imported git archive. Everything is ok
(ignoring some differences introduced by keyword expansion).
Note, I tried earlier to use cvs2svn to import to svn followed by
git-svnimport to import to git. The repository resulting from
this two step import not even passed this minimal requirement of
matching checkouts from cvs and git.
cvs2svn created a lot of branches that are not present in CVS,
with names identical to CVS tags. Apparently these branches are
used to create a commit matching a certain CVS tag.
I checked one suspicious commit that indicates to me if the root
points of branches are right. Note, git-cvsimport fails this check;
parsecvs and cvs2svn pass the check.
The branching structure looks, ... hmm ..., interesting. cvs2svn
manufactured commits to get the branching points right.
Apparently our CVS has some weired commits like 'unlabeled-1.1.1'
and two other named tags (maybe vendor branches?) that cause
these manufactured commits. In gitk I see long lines running
parallel to the cvs trunk all down to these weired CVS tags. They
are not very useful, altough they might be correct. Note,
parsecvs imports our repository without such basically useless
links. However, I can't verify if parsecvs gets something wrong.
Other branches are created over a couple of commits mixing in
several branches (maybe again our weired commits already
mentioned). See branching1.png, branching2.png, branching3.png.
[ I have to apologize, our cvs repository contains proprietary
information, so I can't publish it's history freely. ]
cvs2svn is the first tool besided parsecvs that worked for me,
that is imported the whole repository, passed the basic test of
matching checkouts from cvs and git, and got the one suspicious
commit right that I'm using for verifying the branching points.
[ I have no time to go into the details of all these tests.
Therefore only a very short summary:
All tools needed basic cleanup of a few corrupted ,v files and
,v files that were duplicated in Attic.
git-cvsimport fails to create branches at the right commit.
fromcvs's togit surrendered during the import.
fromcvs's tohg accepted more of the history, but finally
surrendered as well.
parsecvs works for me (crashes on corrupted ,v files).
cvs2svn followed by git-svnimport create wrong state at the
tips of branches.
cvs2svn direct git import works for me (reports corrupted ,v files).
]
Right now, I'd prefer the import by parsecvs because of the
simpler history. However, I don't know if I loose history
information by doing so. I'd start by a run of cvs2svn to validate
the overall structure of the CVS repository. Dealing with corruption
in the CVS repository seems to be superior in cvs2svn. It reports
errors when parsecvs just crashes.
Steffen
[-- Attachment #2.1: branching1.png --]
[-- Type: application/applefile, Size: 74 bytes --]
[-- Attachment #2.2: branching1.png --]
[-- Type: image/png, Size: 3389 bytes --]
[-- Attachment #3: Type: text/plain, Size: 1 bytes --]
[-- Attachment #4.1: branching2.png --]
[-- Type: application/applefile, Size: 74 bytes --]
[-- Attachment #4.2: branching2.png --]
[-- Type: image/png, Size: 1653 bytes --]
[-- Attachment #5: Type: text/plain, Size: 1 bytes --]
[-- Attachment #6.1: branching3.png --]
[-- Type: application/applefile, Size: 74 bytes --]
[-- Attachment #6.2: branching3.png --]
[-- Type: image/png, Size: 2807 bytes --]
[-- Attachment #7: Type: text/plain, Size: 4 bytes --]
^ permalink raw reply
* [tschwinge@gnu.org: [PATCH] Support building on GNU/Hurd]
From: Thomas Schwinge @ 2007-08-02 8:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
[-- Attachment #1.1: Type: text/plain, Size: 276 bytes --]
Hello Junio!
I sent this patch (see the attached email message) to the git mailing
list on 2007-07-28, alongside with another GNU/Hurd-related patch. The
latter patch was included already (by you), but not this one. Could you
please include it?
Thanks!
Regards,
Thomas
[-- Attachment #1.2: Type: message/rfc822, Size: 2979 bytes --]
From: Thomas Schwinge <tschwinge@gnu.org>
To: git@vger.kernel.org
Cc: Thomas Schwinge <tschwinge@gnu.org>
Subject: [PATCH] Support building on GNU/Hurd
Date: Sat, 28 Jul 2007 18:39:38 +0200
Message-ID: <11856407793933-git-send-email-tschwinge@gnu.org>
GNU/Hurd systems don't have strlcpy either.
Signed-off-by: Thomas Schwinge <tschwinge@gnu.org>
---
Makefile | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index 2fea115..8d9a01b 100644
--- a/Makefile
+++ b/Makefile
@@ -458,6 +458,10 @@ ifeq ($(uname_S),AIX)
NO_STRLCPY = YesPlease
NEEDS_LIBICONV=YesPlease
endif
+ifeq ($(uname_S),GNU)
+ # GNU/Hurd
+ NO_STRLCPY=YesPlease
+endif
ifeq ($(uname_S),IRIX64)
NO_IPV6=YesPlease
NO_SETENV=YesPlease
--
1.5.3.rc3.26.g6c58-dirty
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply related
* Re: [tschwinge@gnu.org: [PATCH] Support building on GNU/Hurd]
From: Junio C Hamano @ 2007-08-02 9:03 UTC (permalink / raw)
To: Thomas Schwinge; +Cc: git
In-Reply-To: <20070802085642.GK6234@fencepost.gnu.org>
Please do not PGP sign your patch. Plain-text inline patches.
^ permalink raw reply
* [PATCH] Support building on GNU/Hurd
From: Thomas Schwinge @ 2007-08-02 9:14 UTC (permalink / raw)
To: gitster; +Cc: git, Thomas Schwinge
In-Reply-To: <7vy7guxq8u.fsf@assigned-by-dhcp.cox.net>
GNU/Hurd systems don't have strlcpy either.
Signed-off-by: Thomas Schwinge <tschwinge@gnu.org>
---
Makefile | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index 73b487f..682892f 100644
--- a/Makefile
+++ b/Makefile
@@ -456,6 +456,10 @@ ifeq ($(uname_S),AIX)
NO_STRLCPY = YesPlease
NEEDS_LIBICONV=YesPlease
endif
+ifeq ($(uname_S),GNU)
+ # GNU/Hurd
+ NO_STRLCPY=YesPlease
+endif
ifeq ($(uname_S),IRIX64)
NO_IPV6=YesPlease
NO_SETENV=YesPlease
--
1.5.3.rc3.26.g6c58-dirty
^ permalink raw reply related
* Re: git-diff on touched files: bug or feature?
From: Matthieu Moy @ 2007-08-02 9:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4pjj5fp6.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> writes:
> Matthieu Moy <Matthieu.Moy@imag.fr> writes:
>
>> $ touch bar
>> $ git diff
>> diff --git a/bar b/bar <--- here ---<
>> $ git status
>> # On branch master
>> nothing to commit (working directory clean)
>> $ git diff <--- status updated
>> the stat in the index.
>>
>> Is this intended,
>
> Yes. Very much so, intentionally, from very early days of git.
> This serves as a reminder to the user that he started editing
> but changed his mind to end up with the same contents as the
> original, until the next "update-index --refresh" (which is
> internally invoked from "status").
>
> If the feature still makes sense in the modern world is a
> different story, but I do find it useful.
I understand that it can be usefull, but I really don't like having it
by default (is there a way to deactivate it BTW?):
I've hit this while working on a project, doing a lot of modifications
through scripting (some regexp substitutions and such kinds of
things). Then, git-diff shows me pages of "diff --git ...", and a few
relevant entries in the middle of it. That's very bad from the
usability point of view (I actually had some ~20 lines diff surrounded
by 100+ irrelevant lines), and also kills performance: if a script
touches a lot of files, I expect the next "diff" or "status" to be
slow, but not the second next. Here, diff will be slow until I run
git-status again.
And I find the "reminder" feature very fragile. That means git-status
is no longer a read-only operation for the user. As a user, I expect
to be able to run git-status without changing the behavior of
subsequent git commands, which is not the case here. That means for
example that someone used to running git-diff /before/ git-status will
get the reminder, while someone used to running git-diff /after/
git-status (which I find sensible, get an overview before getting the
details of what you did) won't get it. Note also that this makes a
difference between git-status (which updates the stat in the index)
and git-status -a (which doesn't). That's an implementation detail
that shouldn't be exposed to the user.
Since I don't see any mention of this in the man pages for git-diff or
git-status (I might have missed it), I wonder how many user actually
ever used this as a feature.
I'd be in favor of disabling this by default, and providing a
configuration option and/or a command line option to diff to enable
it. I can try writting a patch for this if people agree on the
specification.
--
Matthieu
^ permalink raw reply
* Re: 1.5.3 plans and preparations
From: Johannes Schindelin @ 2007-08-02 9:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfy32z9hv.fsf@assigned-by-dhcp.cox.net>
Hi,
whew, what a bunch of changes!
On Thu, 2 Aug 2007, Junio C Hamano wrote:
> - "git-filter-branch" lets you rewrite the revision history of
> the current branch, creating a new branch. You can specify a
> number of filters to modify the commits, files and trees.
It is no longer the current branch, not even by default. You can rewrite
one or more branches, and you have to specify them.
> - "git commit --amend" is now compatible with various message source
> options such as -m/-C/-c/-F.
Urgh. That makes it much more easy for new users to shoot themselves in
the foot. By "-C" and "-F" you do not even see the runstatus anymore,
since no editor was fired up. Please say something like "use with care",
or "do not try this at home", too.
Ciao,
Dscho
^ permalink raw reply
* Re: 1.5.3 plans and preparations
From: David Kastrup @ 2007-08-02 9:42 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0708021021060.14781@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Thu, 2 Aug 2007, Junio C Hamano wrote:
>
>> - "git commit --amend" is now compatible with various message source
>> options such as -m/-C/-c/-F.
>
> Urgh. That makes it much more easy for new users to shoot
> themselves in the foot. By "-C" and "-F" you do not even see the
> runstatus anymore, since no editor was fired up. Please say
> something like "use with care", or "do not try this at home", too.
Hm? How is that specific to "--amend"? Isn't that just a consequence
of -m/-C/-F, regardless of whether one uses --amend or not?
When there are unmerged changes, --amend will not complete anyway.
And of course, if you got things wrong, you can always do another
--amend, so it is not like there is serious damage involved.
What do I overlook here?
And before you complain about not getting a copy by Email again: I
have to go via Gmane from my work account, since it will for some
unfathomable reason drop most of my mails (except those I use for
testing the problem) from this address. It is manual work to add a
"Cc" header in this setup (which I often forget), and even then, I
doubt this copy will arrive at your place via mail (please tell me if
it does).
--
David Kastrup
^ permalink raw reply
* Re: git-diff on touched files: bug or feature?
From: Johannes Schindelin @ 2007-08-02 9:51 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Junio C Hamano, git
In-Reply-To: <vpqhcni47ek.fsf@bauges.imag.fr>
Hi,
On Thu, 2 Aug 2007, Matthieu Moy wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
> > Matthieu Moy <Matthieu.Moy@imag.fr> writes:
> >
> >> $ touch bar
> >> $ git diff
> >> diff --git a/bar b/bar <--- here ---<
> >> $ git status
> >> # On branch master
> >> nothing to commit (working directory clean)
> >> $ git diff <--- status updated
> >> the stat in the index.
> >>
> >> Is this intended,
> >
> > Yes. Very much so, intentionally, from very early days of git.
> > This serves as a reminder to the user that he started editing
> > but changed his mind to end up with the same contents as the
> > original, until the next "update-index --refresh" (which is
> > internally invoked from "status").
> >
> > If the feature still makes sense in the modern world is a
> > different story, but I do find it useful.
>
> I understand that it can be usefull, but I really don't like having it
> by default (is there a way to deactivate it BTW?).
Yes. Just call "git status" and be done with it.
Ciao,
Dscho
^ permalink raw reply
* Re: git-diff on touched files: bug or feature?
From: Junio C Hamano @ 2007-08-02 9:54 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpqhcni47ek.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@imag.fr> writes:
> I understand that it can be usefull, but I really don't like having it
> by default (is there a way to deactivate it BTW?):
You said it yourself below --- run git-status (or update-index --refresh)
first.
> I've hit this while working on a project, doing a lot of modifications
> through scripting (some regexp substitutions and such kinds of
> things).
I have to say that you are quite mistaken.
Scripted style bulk modification that indiscriminately touch
everbody but actually only modifies some, e.g. "perl -p -i", is
a fine component of people's workflow, but that is *NOT* the
norm. If it were, then you are not programming nor editing --
your script is doing the work. But as you know, after such a
bulk operation, you can always...
> ... until I run git-status again.
... refresh away the cache-dirtiness.
The default should be tuned for users who perform manual editing
with status checks. And power users like yourself who run "bulk
touch indiscriminately but modify only some" scripts should
learn to run git-status (or "update-index --refresh") after such
operation. Swapping the defaults to optimize for the abnormal
case is madness.
^ permalink raw reply
* Re: git-diff on touched files: bug or feature?
From: Matthieu Moy @ 2007-08-02 9:57 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0708021050500.14781@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Thu, 2 Aug 2007, Matthieu Moy wrote:
>
>> > If the feature still makes sense in the modern world is a
>> > different story, but I do find it useful.
>>
>> I understand that it can be usefull, but I really don't like having it
>> by default (is there a way to deactivate it BTW?).
>
> Yes. Just call "git status" and be done with it.
That's not what I mean (my original message mentionned that already
BTW). By "deactivate", I mean "make git-diff never show empty diffs".
I don't want to run two commands where I need only one.
--
Matthieu
^ permalink raw reply
* Re: git-diff on touched files: bug or feature?
From: Junio C Hamano @ 2007-08-02 10:01 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <7vd4y6xnw4.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> writes:
> Matthieu Moy <Matthieu.Moy@imag.fr> writes:
> ...
>> I've hit this while working on a project, doing a lot of modifications
>> through scripting (some regexp substitutions and such kinds of
>> things).
>
> I have to say that you are quite mistaken.
>
> Scripted style bulk modification that indiscriminately touch
> everbody but actually only modifies some, e.g. "perl -p -i", is
> a fine component of people's workflow, but that is *NOT* the
> norm.
Having said that, there is another lesson to take home from
this.
Quite honestly, a script that indiscriminately touches everybody
but only modifies a few is simply broken. Think about "make".
"git diff" reporting many cache-dirty files is simply reminding
you the brokenness of such a script.
^ permalink raw reply
* Re: Interpreting EDITOR/VISUAL environment variables.
From: Matthias Lederhofer @ 2007-08-02 10:10 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <85r6mnrs1z.fsf@lola.goethe.zz>
David Kastrup <dak@gnu.org> wrote:
> a) Using system and shell-quoting the filename. Advantage: one can
> set EDITOR='"/home/dak/My Programs/editor"' and have it work.
> Disadvantage: shell-quoting a file name seems shell- and
> system-dependent.
What about this instead of quoting the argument?
sh -c '$EDITOR "$1" "$2"' editor +5 /path/to/file
(i.e. for C execvp("/bin/sh", "-c", "$EDITOR \"$1\" \"$2\"", "editor",
"+5", "/path/to/file"))
^ permalink raw reply
* Re: Git benchmark - comparison with Bazaar, Darcs, Git and Mercurial
From: David Kastrup @ 2007-08-02 10:29 UTC (permalink / raw)
To: git
In-Reply-To: <7vejim1n92.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> writes:
> * With -l, as long as the source repository is healthy, it is
> very likely that the recipient would be, too. Also it is
> very cheap. You do not get any back-up benefit.
Oh, but one does: an overzealous prune or rm -oopswrongoption in one
repo does not hurt the other.
> Which leads me to believe that being able to use file:/// is
> probably a good idea, if only for testability, but probably of
> little practical value, and we can default to -l for everyday
> use, and paranoids can use non -l as a way to make a back-up.
Sane enough, I guess.
--
David Kastrup
^ permalink raw reply
* Re: [MinGW PATCH] Fixed error 'fatal: Not a git repository' on Vista
From: Johannes Schindelin @ 2007-08-02 10:33 UTC (permalink / raw)
To: Dmitry Kakurin; +Cc: git, Johannes Sixt
In-Reply-To: <DE6EEF3D318C4051827B95DF26D97BE7@ntdev.corp.microsoft.com>
Hi,
[please consider reading Documentation/SubmittingPatches; you did not Cc:
the maintainer, Johannes Sixt]
On Wed, 1 Aug 2007, Dmitry Kakurin wrote:
> Any git command was immediately failing on Vista under MinGW with
> fatal: Not a git repository
Thanks for submitting this patch. I cannot test personally, because
nobody I know has Vista.
I guess that Hannes will apply your patch when he comes back from his
well-deserved holiday.
You might want to consider pushing your changes to the mob branch on
repo.or.cz/git/mingw.git.
>From your mail, I take it that the .zip file I sent you is working
properly?
Ciao,
Dscho
^ permalink raw reply
* Re: Interpreting EDITOR/VISUAL environment variables.
From: David Kastrup @ 2007-08-02 10:31 UTC (permalink / raw)
To: git
In-Reply-To: <20070802101056.GA31182@moooo.ath.cx>
Matthias Lederhofer <matled@gmx.net> writes:
> David Kastrup <dak@gnu.org> wrote:
>> a) Using system and shell-quoting the filename. Advantage: one can
>> set EDITOR='"/home/dak/My Programs/editor"' and have it work.
>> Disadvantage: shell-quoting a file name seems shell- and
>> system-dependent.
Actually I was talking C here, and the editor is never called from C
in git but rather from the shell. So this problem is a non-problem
for us.
> What about this instead of quoting the argument?
>
> sh -c '$EDITOR "$1" "$2"' editor +5 /path/to/file
>
> (i.e. for C execvp("/bin/sh", "-c", "$EDITOR \"$1\" \"$2\"", "editor",
> "+5", "/path/to/file"))
It suffers from the fault that it does not work as far as I can see.
-c does not set the positional parameters.
--
David Kastrup
^ permalink raw reply
* Shell script cleanups/style changes?
From: David Kastrup @ 2007-08-02 10:44 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 742 bytes --]
Hi, I wanted to ask what the general stance towards shell script
cleanups and simplifications would be. For example, I find the expr
usage quite inscrutable in commit, and there is no necessity of
putting "shift" in every case branch instead of once behind it, and a
lot of conditionals and other manipulations can be made much easier on
the eye by using parameter expansion patterns that are, as far as I
can see, available with every reasonable Bourne Shell and clones.
Here is an example context diff (in this case, I find it more readable
than unified) to illustrate (untested!, please don't apply without a
regular formatted git patch).
Should I bother doing such cleanups as I read up on code, or should I
just leave things alone?
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 6998 bytes --]
diff --git a/git-commit.sh b/git-commit.sh
index d7e7028..bdf20be 100755
*** a/git-commit.sh
--- b/git-commit.sh
***************
*** 97,101 ****
no_edit=t
log_given=t$log_given
logfile="$1"
- shift
;;
--- 97,100 ----
***************
*** 102,107 ****
-F*|-f*)
no_edit=t
log_given=t$log_given
! logfile=`expr "z$1" : 'z-[Ff]\(.*\)'`
! shift
;;
--- 101,105 ----
-F*|-f*)
no_edit=t
log_given=t$log_given
! logfile="${1#-?}"
;;
***************
*** 108,113 ****
--F=*|--f=*|--fi=*|--fil=*|--file=*)
no_edit=t
log_given=t$log_given
! logfile=`expr "z$1" : 'z-[^=]*=\(.*\)'`
! shift
;;
--- 106,110 ----
--F=*|--f=*|--fi=*|--fil=*|--file=*)
no_edit=t
log_given=t$log_given
! logfile="${1#*=}"
;;
***************
*** 114,117 ****
-a|--a|--al|--all)
all=t
- shift
;;
--- 111,113 ----
***************
*** 118,127 ****
--au=*|--aut=*|--auth=*|--autho=*|--author=*)
! force_author=`expr "z$1" : 'z-[^=]*=\(.*\)'`
! shift
;;
--au|--aut|--auth|--autho|--author)
case "$#" in 1) usage ;; esac
shift
force_author="$1"
- shift
;;
--- 114,121 ----
--au=*|--aut=*|--auth=*|--autho=*|--author=*)
! force_author="${1#*=}"
;;
--au|--aut|--auth|--autho|--author)
case "$#" in 1) usage ;; esac
shift
force_author="$1"
;;
***************
*** 128,144 ****
-e|--e|--ed|--edi|--edit)
edit_flag=t
- shift
;;
-i|--i|--in|--inc|--incl|--inclu|--includ|--include)
also=t
- shift
;;
--int|--inte|--inter|--intera|--interac|--interact|--interacti|\
--interactiv|--interactive)
interactive=t
- shift
;;
-o|--o|--on|--onl|--only)
only=t
- shift
;;
--- 122,134 ----
***************
*** 145,159 ****
-m|--m|--me|--mes|--mess|--messa|--messag|--message)
case "$#" in 1) usage ;; esac
- shift
log_given=m$log_given
! if test "$log_message" = ''
! then
! log_message="$1"
! else
! log_message="$log_message
! $1"
! fi
no_edit=t
- shift
;;
--- 135,142 ----
-m|--m|--me|--mes|--mess|--messa|--messag|--message)
case "$#" in 1) usage ;; esac
log_given=m$log_given
! log_message="${log_message}${log_message:+
! }$1"
no_edit=t
;;
***************
*** 160,172 ****
-m*)
log_given=m$log_given
! if test "$log_message" = ''
! then
! log_message=`expr "z$1" : 'z-m\(.*\)'`
! else
! log_message="$log_message
! `expr "z$1" : 'z-m\(.*\)'`"
! fi
no_edit=t
- shift
;;
--- 143,149 ----
-m*)
log_given=m$log_given
! log_message="${log_message}${log_message:+
! }${1#-m}"
no_edit=t
;;
***************
*** 173,185 ****
--m=*|--me=*|--mes=*|--mess=*|--messa=*|--messag=*|--message=*)
log_given=m$log_given
! if test "$log_message" = ''
! then
! log_message=`expr "z$1" : 'z-[^=]*=\(.*\)'`
! else
! log_message="$log_message
! `expr "z$1" : 'zq-[^=]*=\(.*\)'`"
! fi
no_edit=t
- shift
;;
--- 150,156 ----
--m=*|--me=*|--mes=*|--mess=*|--messa=*|--messag=*|--message=*)
log_given=m$log_given
! log_message="${log_message}${log_message:+
! }${1#*=}"
no_edit=t
;;
***************
*** 186,197 ****
-n|--n|--no|--no-|--no-v|--no-ve|--no-ver|--no-veri|--no-verif|\
--no-verify)
verify=
- shift
;;
--a|--am|--ame|--amen|--amend)
amend=t
use_commit=HEAD
- shift
;;
-c)
case "$#" in 1) usage ;; esac
--- 157,166 ----
***************
*** 199,203 ****
log_given=t$log_given
use_commit="$1"
no_edit=
- shift
;;
--- 168,171 ----
***************
*** 204,213 ****
--ree=*|--reed=*|--reedi=*|--reedit=*|--reedit-=*|--reedit-m=*|\
--reedit-me=*|--reedit-mes=*|--reedit-mess=*|--reedit-messa=*|\
--reedit-messag=*|--reedit-message=*)
log_given=t$log_given
! use_commit=`expr "z$1" : 'z-[^=]*=\(.*\)'`
no_edit=
- shift
;;
--ree|--reed|--reedi|--reedit|--reedit-|--reedit-m|--reedit-me|\
--reedit-mes|--reedit-mess|--reedit-messa|--reedit-messag|\
--- 172,180 ----
--ree=*|--reed=*|--reedi=*|--reedit=*|--reedit-=*|--reedit-m=*|\
--reedit-me=*|--reedit-mes=*|--reedit-mess=*|--reedit-messa=*|\
--reedit-messag=*|--reedit-message=*)
log_given=t$log_given
! use_commit="${1#*=}"
no_edit=
;;
--ree|--reed|--reedi|--reedit|--reedit-|--reedit-m|--reedit-me|\
--reedit-mes|--reedit-mess|--reedit-messa|--reedit-messag|\
***************
*** 217,223 ****
log_given=t$log_given
use_commit="$1"
no_edit=
- shift
;;
-C)
case "$#" in 1) usage ;; esac
--- 184,189 ----
***************
*** 225,229 ****
log_given=t$log_given
use_commit="$1"
no_edit=t
- shift
;;
--- 191,194 ----
***************
*** 230,239 ****
--reu=*|--reus=*|--reuse=*|--reuse-=*|--reuse-m=*|--reuse-me=*|\
--reuse-mes=*|--reuse-mess=*|--reuse-messa=*|--reuse-messag=*|\
--reuse-message=*)
log_given=t$log_given
! use_commit=`expr "z$1" : 'z-[^=]*=\(.*\)'`
no_edit=t
- shift
;;
--reu|--reus|--reuse|--reuse-|--reuse-m|--reuse-me|--reuse-mes|\
--reuse-mess|--reuse-messa|--reuse-messag|--reuse-message)
--- 195,203 ----
--reu=*|--reus=*|--reuse=*|--reuse-=*|--reuse-m=*|--reuse-me=*|\
--reuse-mes=*|--reuse-mess=*|--reuse-messa=*|--reuse-messag=*|\
--reuse-message=*)
log_given=t$log_given
! use_commit="${1#*=}"
no_edit=t
;;
--reu|--reus|--reuse|--reuse-|--reuse-m|--reuse-me|--reuse-mes|\
--reuse-mess|--reuse-messa|--reuse-messag|--reuse-message)
***************
*** 242,273 ****
log_given=t$log_given
use_commit="$1"
no_edit=t
- shift
;;
-s|--s|--si|--sig|--sign|--signo|--signof|--signoff)
signoff=t
- shift
;;
-t|--t|--te|--tem|--temp|--templ|--templa|--templat|--template)
case "$#" in 1) usage ;; esac
shift
templatefile="$1"
no_edit=
- shift
;;
-q|--q|--qu|--qui|--quie|--quiet)
quiet=t
- shift
;;
-v|--v|--ve|--ver|--verb|--verbo|--verbos|--verbose)
verbose=t
- shift
;;
-u|--u|--un|--unt|--untr|--untra|--untrac|--untrack|--untracke|\
--untracked|--untracked-|--untracked-f|--untracked-fi|--untracked-fil|\
--untracked-file|--untracked-files)
untracked_files=t
- shift
;;
--)
shift
--- 206,231 ----
***************
*** 280,285 ****
--- 238,244 ----
break
;;
esac
+ shift
done
case "$edit_flag" in t) no_edit= ;; esac
***************
*** 437,448 ****
if test t = "$verify" && test -x "$GIT_DIR"/hooks/pre-commit
then
! if test "$TMP_INDEX"
! then
! GIT_INDEX_FILE="$TMP_INDEX" "$GIT_DIR"/hooks/pre-commit
! else
! GIT_INDEX_FILE="$USE_INDEX" "$GIT_DIR"/hooks/pre-commit
! fi || exit
fi
if test "$log_message" != ''
--- 396,403 ----
if test t = "$verify" && test -x "$GIT_DIR"/hooks/pre-commit
then
! GIT_INDEX_FILE="${TMP_INDEX:-${USE_INDEX}}" "$GIT_DIR"/hooks/pre-commit \
! || exit
fi
if test "$log_message" != ''
[-- Attachment #3: Type: text/plain, Size: 20 bytes --]
--
David Kastrup
^ permalink raw reply
* Re: Windows support
From: Johannes Schindelin @ 2007-08-02 10:45 UTC (permalink / raw)
To: Asger Ottar Alstrup; +Cc: git
In-Reply-To: <f8rv65$1b3$1@sea.gmane.org>
Hi,
On Thu, 2 Aug 2007, Asger Ottar Alstrup wrote:
> Johannes Schindelin wrote:
> > On Wed, 25 Jul 2007, Dmitry Kakurin wrote:
> >
> > > How serious are you guys about Windows support?
> >
> > Okay, let's talk business:
> >
> > Pay me decently, and you will have to wait for a few weeks.
>
> I propose that you set up a fundable:
>
> http://fundable.com/
>
> This is a system where anyone can contribute money to the project, but not
> have to pay unless the required amount of money has been contributed in total.
>
> Figure out your price, describe what you will deliver, and announce it.
I am not that much interested in money, really. But I do want to get
something back in return for my efforts. And no, this does not include
whining and complaints.
It includes useful bug reports. It includes a willingness to keep working
with me until the bugs are fleshed out. It possibly includes making (and
maintaining!) an installer.
At the moment, I am happy to say that Git works for me. Even on Windows.
I have no problems with the command line, and both Cygwin and MinGW Git do
their job reliably and joyfully here.
But there might come a time when I get into a position much like Shawn,
when I have to work with Aunt and Uncle Tillies, who are not as
clueful and intelligent^W^W^Wused to the command line as I am.
So I want to exploit Open Source, meaning that I give _you_ something, and
_you_ give me something back. And that might very well be just a
suggestion "make the commit button stick out; I did not find it, since
there are so many buttons". Or a nice comic "how to use git". Also a
beer is appreciated. Or whatever.
My complaint "let's talk business" was some (frustrated) way to get the
attention of people who do _not_ give something back, and are astonished
that just complaining will not get them anywhere.
FWIW I just applied for the project "Git on MSys" on SourceForge. Let's
see how this will work out.
Oh, and I will _not_ do such a thing as think about what you might want,
and then proclaim what would be my price for it. You _know_ what you
want, so why don't you just tell me, as a detailed list?
Ciao,
Dscho
^ 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