* Re: t6021-merge-criss-cross.sh fails on some systems
From: Junio C Hamano @ 2005-12-11 8:07 UTC (permalink / raw)
To: David S. Miller; +Cc: git
In-Reply-To: <20051210.235818.90276521.davem@davemloft.net>
"David S. Miller" <davem@davemloft.net> writes:
> ... but a lot of us are doing:
>
> git pull && make && make test && make install
Fair enough.
Next such round would fail at "make test" stage with t0000;
otherwise please let me know
^ permalink raw reply
* What's in master tonight...
From: Junio C Hamano @ 2005-12-11 8:06 UTC (permalink / raw)
To: git
For the past couple of days, many of the changes merged into
"master" branch have been documentation updates and general
cleanups, except these notable fixes and improvements:
- Hooks are run with stdin/stdout thrown into /dev/null (Daniel
Barkalow).
- Updates to gitk to work around Tcl/Tk's i18n, which does not
understand MIME charset names IANA recommends (Paul
Mackerras).
- Portability enhancements for AIX and Solaris (Jason Riedy).
- Fixes to archimport (Eric Wong and Martin Langhoff)
- Fixes related to various C std issues (Morten Welinder and me)
- Catch common mistakes such as not having "merge" installed,
to reduce false bug reports on the mailing list.
- Safety fix for git-prune.
- Remove useless computation from server-info.
- Fix git-http-fetch so that it does not fail creating a ref in
a subdirectory.
- Leave paths that failed to automerge unmerged in the index
when merge-one-file returns.
- Same for merge-recursive rename/merge case (this is waiting
in "pu" tonight, waiting for comments from the original
author).
With these changes, we are really in good shape for 1.0. I'll
do another test script or two for the renaming recursive merge
to make sure I did not break things, and am hoping to tag 1.0rc5
by early next week. If things go well as planned that would
become the final 1.0.
I have not merged the 20+ help text series by Fredrik yet, but
most of them are low impact and expect most of them will be in
1.0, in one shape or another if not verbatim.
^ permalink raw reply
* Re: t6021-merge-criss-cross.sh fails on some systems
From: David S. Miller @ 2005-12-11 7:58 UTC (permalink / raw)
To: freku045; +Cc: git
In-Reply-To: <20051211003353.GA27207@c165.ib.student.liu.se>
From: Fredrik Kuivinen <freku045@student.liu.se>
Date: Sun, 11 Dec 2005 01:33:53 +0100
> It looks like 'merge' can't be found. The recursive merge strategy
> uses 'merge' to do file-level merging. Do you have merge(1)
> installed?
Yet another weird dependency. :-/ Thanks for the info.
I bet a tiny shell script could run at GIT build time
to check for the presence of these necessary items. :-)
Yes, the debian/rpm/etc. packaging dependencies will catch
this, but a lot of us are doing:
git pull && make && make test && make install
:-)
^ permalink raw reply
* [PATCH] merge-recursive: leave unmerged entries in the index.
From: Junio C Hamano @ 2005-12-11 6:26 UTC (permalink / raw)
To: Fredrik Kuivinen; +Cc: git
This does two things.
- When one branch renamed and the other branch did not, the
resulting half-merged file in the working tree used to swap
branches around and showed as if renaming side was "ours".
This was confusing and inconsistent (even though the conflict
markers were marked with branch names, it was not a good
enough excuse). This changes the order of arguments to
mergeFile in such a case to make sure we always see "our"
change between <<< and ===, and "their" change between ===
and >>>.
- When both branches renamed to the same path, and when one
branch renamed and the other branch did not, we attempt
mergeFile. When this automerge conflicted, we used to
collapse the index. Now we use update-index --index-info
to inject higher stage entries to leave the index in unmerged
state for these two cases.
What this still does _not_ do is to inject unmerged state into
the index when the structural changes conflict. I have not
thought things through what to do in each case yet, but the
cases this commit cover are the most common ones, so this would
be a good start.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* Aside from minor cleanups both in usage strings and
documentation, many of which might still remain, I consider
this the last remaining bit before we can go 1.0, and
comments and corrections are very much appreciated.
git-merge-recursive.py | 54 +++++++++++++++++++++++++++++++++++++++++-------
1 files changed, 46 insertions(+), 8 deletions(-)
e5c23ede9ccc6ddd5f2cf13154f977bb1b687051
diff --git a/git-merge-recursive.py b/git-merge-recursive.py
index b7fb096..767b13c 100755
--- a/git-merge-recursive.py
+++ b/git-merge-recursive.py
@@ -280,6 +280,22 @@ def updateFileExt(sha, mode, path, updat
runProgram(['git-update-index', '--add', '--cacheinfo',
'0%o' % mode, sha, path])
+def setIndexStages(path,
+ oSHA1, oMode,
+ aSHA1, aMode,
+ bSHA1, bMode):
+ prog = ['git-update-index', '-z', '--index-info']
+ proc = subprocess.Popen(prog, stdin=subprocess.PIPE)
+ pipe = proc.stdin
+ # Clear stages first.
+ pipe.write("0 " + ("0" * 40) + "\t" + path + "\0")
+ # Set stages
+ pipe.write("%o %s %d\t%s\0" % (oMode, oSHA1, 1, path))
+ pipe.write("%o %s %d\t%s\0" % (aMode, aSHA1, 2, path))
+ pipe.write("%o %s %d\t%s\0" % (bMode, bSHA1, 3, path))
+ pipe.close()
+ proc.wait()
+
def removeFile(clean, path):
updateCache = cacheOnly or clean
updateWd = not cacheOnly
@@ -590,6 +606,8 @@ def processRenames(renamesA, renamesB, b
else:
dstName2 = ren1.dstName
+ # NEEDSWORK: place dstNameA at stage 2 and dstNameB at stage 3
+ # What about other stages???
updateFile(False, ren1.dstSha, ren1.dstMode, dstName1)
updateFile(False, ren2.dstSha, ren2.dstMode, dstName2)
else:
@@ -611,8 +629,11 @@ def processRenames(renamesA, renamesB, b
cleanMerge = False
if not cacheOnly:
- updateFileExt(ren1.dstSha, ren1.dstMode, ren1.dstName,
- updateCache=True, updateWd=False)
+ setIndexStages(ren1.dstName,
+ ren1.srcSha, ren1.srcMode,
+ ren1.dstSha, ren1.dstMode,
+ ren2.dstSha, ren2.dstMode)
+
updateFile(clean, resSha, resMode, ren1.dstName)
else:
# Renamed in 1, maybe changed in 2
@@ -672,11 +693,24 @@ def processRenames(renamesA, renamesB, b
tryMerge = True
if tryMerge:
+
+ oName, oSHA1, oMode = ren1.srcName, ren1.srcSha, ren1.srcMode
+ aName, bName = ren1.dstName, ren1.srcName
+ aSHA1, bSHA1 = ren1.dstSha, srcShaOtherBranch
+ aMode, bMode = ren1.dstMode, srcModeOtherBranch
+ aBranch, bBranch = branchName1, branchName2
+
+ if renamesA != renames1:
+ aName, bName = bName, aName
+ aSHA1, bSHA1 = bSHA1, aSHA1
+ aMode, bMode = bMode, aMode
+ aBranch, bBranch = bBranch, aBranch
+
[resSha, resMode, clean, merge] = \
- mergeFile(ren1.srcName, ren1.srcSha, ren1.srcMode,
- ren1.dstName, ren1.dstSha, ren1.dstMode,
- ren1.srcName, srcShaOtherBranch, srcModeOtherBranch,
- branchName1, branchName2)
+ mergeFile(oName, oSHA1, oMode,
+ aName, aSHA1, aMode,
+ bName, bSHA1, bMode,
+ aBranch, bBranch);
if merge or not clean:
output('Renaming', fmtRename(ren1.srcName, ren1.dstName))
@@ -690,8 +724,12 @@ def processRenames(renamesA, renamesB, b
cleanMerge = False
if not cacheOnly:
- updateFileExt(ren1.dstSha, ren1.dstMode, ren1.dstName,
- updateCache=True, updateWd=False)
+ # Stuff stage1/2/3
+ setIndexStages(ren1.dstName,
+ oSHA1, oMode,
+ aSHA1, aMode,
+ bSHA1, bMode)
+
updateFile(clean, resSha, resMode, ren1.dstName)
return cleanMerge
--
0.99.9.GIT
^ permalink raw reply related
* Re: [PATCH 21/25] git-send-email: Usage message clean-up.
From: Junio C Hamano @ 2005-12-11 4:30 UTC (permalink / raw)
To: freku045; +Cc: git
In-Reply-To: <11342434792231-git-send-email-freku045@student.liu.se>
freku045@student.liu.se writes:
> +sub usage {
> + print <<EOT;
> +$0 [options] <file | directory> [... file | directory ]
Not going to STDERR?
^ permalink raw reply
* Re: [PATCH 17/25] git-relink: Print usage message to stderr.
From: Junio C Hamano @ 2005-12-11 4:26 UTC (permalink / raw)
To: freku045; +Cc: git
In-Reply-To: <11342434794009-git-send-email-freku045@student.liu.se>
freku045@student.liu.se writes:
> + print STDERR "usage: $0 [--safe] <dir> [<dir>...] <master_dir>\n";
> + print STDERR "All directories should contain a .git/objects/ subdirectory.\n";
> + print STDERR "Options\n";
> + print STDERR "\t--safe\t" .
> "Stops if two objects with the same hash exist but " .
> - "have different sizes. Default is to warn and continue.\n");
> + "have different sizes. Default is to warn and continue.\n";
Might be cleaner to use <<HERE document here.
^ permalink raw reply
* Re: [PATCH 7/25] git-count-objects: Die with usage message if we are invoked incorrectly.
From: Junio C Hamano @ 2005-12-11 4:22 UTC (permalink / raw)
To: freku045; +Cc: git
In-Reply-To: <11342434772549-git-send-email-freku045@student.liu.se>
freku045@student.liu.se writes:
> 5db708396a841860c4d5e41c2acd60476d2207c4
> diff --git a/git-count-objects.sh b/git-count-objects.sh
> index 40c58ef..0d544ad 100755
> --- a/git-count-objects.sh
> +++ b/git-count-objects.sh
> @@ -3,7 +3,16 @@
> # Copyright (c) 2005 Junio C Hamano
> #
>
> -GIT_DIR=`git-rev-parse --git-dir` || exit $?
> +. git-sh-setup
Not that it matters too much, but this makes count-object not
work from subdirectory.
^ permalink raw reply
* Re: [PATCH] Allow saving an object from a pipe
From: Junio C Hamano @ 2005-12-11 2:59 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0512101724290.25300@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> In order to support getting data into git with scripts, this adds a
> --stdin option to git-hash-object, which will make it read from stdin.
Thanks, will apply.
To be honest, though, I am still debating myself about the merit
of not having to have a temporary file. Because we need the
size of the blob available before starting to hash (i.e. we
cannot say "atend"), index_pipe ends up keeping the whole blob
data in memory, which is not much better than the caller storing
it in a temporary file and driving the normal hash-object from
the command line anyway.
^ permalink raw reply
* Re: [PATCH 0/25] Usage message clean-up
From: Junio C Hamano @ 2005-12-11 2:58 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0512102349040.3083@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> * -h and --help makes the script die with the usage message.
>
> Good.
Supporting -h and --help are good, but we probably do not want
to exit with non-zero status in such a case. Not a big deal,
though.
>> * The message is printed to stderr.
>
> Arguable.
One thing I really hate is a program that does more than one
pageful of help message to stderr which forces me to do "blah
>&2 --help | less", but our help messages are short and sweet,
so I feel stderr is OK.
>> * The message is of the form "usage: $0 options"
>
> Not good. We are in a transition to "git whatever" from "git-whatever".
But when the user wishes to look at the manual page, he needs to
say "man git-whatever", so either way you cannot win. I'm
neutral either way, as long as we are consistent.
> Besides, I have to admit that I am a bit annoyed by 25 mini mails for the
> same purpose.
I'd appreciate the flexibility of reviewing them indivudually,
especially when some of them seem to change the structure of the
argument parsing loop.
^ permalink raw reply
* [RFC] Planning a git-cvsdaemon
From: Martin Langhoff @ 2005-12-11 2:44 UTC (permalink / raw)
To: Git Mailing List
I am considering working on a git-cvsdaemon script, intended to
implement the CVS protocol while reading/writing to a git repo. This
would be, of course, limited in what it can do -- I am hoping to be
able to support initial checkout, diff, log and commit.
My cunning(?) plan so far is to
- Track only one configurable "head/branch" of history and make it
appear linear. Whenever we have parallel development and then a merge,
pick a side to follow, and then show the merge as one commit. Of
course, it won't do very well with octopus merges, but you shouldn't
be doing those anyway, except for bragging purposes ;-)
- Generate a view of the per-file history, so we can maintain
CVS-style file version numbers.
- Provide enough support to make new commits through CVS, possibly
with some kind of delayed-execution commit mechanism. CVS's per-file
atomicity here plays against us big-time, but I think we can fudge
something that works 99% of the time. Commits aborted halfway through
will leave a botched commit in GIT too, which someone will hopefully
identify and rollback. there is also a time window while we will have
to be telling CVS that it succeeded in its commit of the initial
files, while we don't know whether the whole commit has succeeded.
Clients committing may be left in an inconsistent state if we fail
halfway through.
- The delayed exec commit will need a locking mechanism
- Simplify as much as possible -- ko/kb will probably be ignored, and
no keyword expansion will be supported. Ignore CVS-style branching,
and do not worry about tagging.
The goal is to support command line CVS, and popular GUI CVS clients
(Eclipse's embedded CVS, TortoiseCVS), and to make it readable, but
also writable, so a team can collaborate using GIT and CVS. It is no
weekend project...
In any case, I am after feedback in general (and any truly
insurmountable issues you can think of), I haven't found yet a good
library implementing the server side of the protocol (other than
cvs's). git-cvsdaemon will probably take shape in Perl initially,
though if there's a good cvs protocol library in other scripting
language, I'm interested...
cheers,
martin
^ permalink raw reply
* Re: t6021-merge-criss-cross.sh fails on some systems
From: Fredrik Kuivinen @ 2005-12-11 0:33 UTC (permalink / raw)
To: David S. Miller; +Cc: git
In-Reply-To: <20051210.144235.125914760.davem@davemloft.net>
On Sat, Dec 10, 2005 at 02:42:35PM -0800, David S. Miller wrote:
>
> This is really weird, so I started to try and get some diagnostics.
>
> It doesn't fail on my sparc64 box running debian-testing
> but it does fail on my Ubuntu x86 laptop, a sparc64 box
> running debian-unstable, and an Ubuntu sparc64 system as
> well.
>
> This is with the current GIT tree.
>
> I ran the test one step at a time to try and get some diagnostics,
> here's what fails:
>
> davem@nuts:~/src/GIT/test$ git merge "pre E3 merge" B A
> Trying really trivial in-index merge...
> fatal: Merge requires file-level merging
> Nope.
> Merging B with A
> Merging:
> 1f14398f4c69d09ab1a4d53fe096ddec3ea45207 C3
> d1072ae2682fad309c493343c5d77c9897fb6afa B8
> found 1 common ancestor(s):
> 926159b75e3d9b240b1eae36eb1977b095ff2e1a Initial commit
> Auto-merging file
> Traceback (most recent call last):
> File "/home/davem/bin/git-merge-recursive", line 868, in ?
> firstBranch, secondBranch, graph)
> File "/home/davem/bin/git-merge-recursive", line 87, in merge
> branch1Name, branch2Name)
> File "/home/davem/bin/git-merge-recursive", line 160, in mergeTrees
> if not processEntry(entry, branch1Name, branch2Name):
> File "/home/davem/bin/git-merge-recursive", line 821, in processEntry
> branch1Name, branch2Name)
> File "/home/davem/bin/git-merge-recursive", line 212, in mergeFile
> src1, orig, src2], returnCode=True)
> File "/home/davem/share/git-core/python/gitMergeCommon.py", line 72, in runProgram
> raise ProgramError(progStr, e.strerror)
> ProgramError: merge -L B/file -L orig/file -L A/file .merge_file_kDtaE3 .merge_file_K30Hgp .merge_file_frqYIs: No such file or directory
> No merge strategy handled the merge.
> davem@nuts:~/src/GIT/test$ ls
>
> It looks like maybe some quoting issue? The call failing above is the
> one in git-merge-recursive which looks like this:
>
> [dummy, clean] = merge(graph.shaMap[h1], graph.shaMap[h2],
> firstBranch, secondBranch, graph)
>
> Any ideas?
It looks like 'merge' can't be found. The recursive merge strategy
uses 'merge' to do file-level merging. Do you have merge(1) installed?
- Fredrik
^ permalink raw reply
* Re: Latest cogito broken with bash-3.1
From: Petr Baudis @ 2005-12-11 0:11 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: git
In-Reply-To: <1134220724.15125.4.camel@blade>
Hello,
Dear diary, on Sat, Dec 10, 2005 at 02:18:44PM CET, I got a letter
where Marcel Holtmann <marcel@holtmann.org> said that...
> The cogito is the latest from kernel.org and when calling cg-commit it
> fails with this message:
>
> cg-commit: line 200: syntax error near unexpected token `('
> cg-commit: line 200: ` eval commitfiles=($(cat $filter | path_xargs git-diff-index -r -m HEAD -- | \'
>
> I played a little bit with it and it seems all the eval statements are
> broken with this bash version. I have no clue how to fix this, but maybe
> you do.
it seems like the newer bash is stricter than the older versions in
some obscure regards. Quoting the eval arguments (which is the proper
thing to do anyway) fixed that particular problem; I've hit another
problem during a test commit wrt. whitespace separators - I've fixed
that too, and pushed out.
Thanks,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: [PATCH 0/25] Usage message clean-up
From: Johannes Schindelin @ 2005-12-10 22:50 UTC (permalink / raw)
To: freku045; +Cc: git
In-Reply-To: <1134243476675-git-send-email-freku045@student.liu.se>
Hi,
On Sat, 10 Dec 2005, freku045@student.liu.se wrote:
> * Any unrecognised options should make the script die with the usage
> message.
Good.
> * -h and --help makes the script die with the usage message.
Good.
> * The message is printed to stderr.
Arguable.
> * The message is of the form "usage: $0 options"
Not good. We are in a transition to "git whatever" from "git-whatever".
Besides, I have to admit that I am a bit annoyed by 25 mini mails for the
same purpose.
Hth,
Dscho
^ permalink raw reply
* t6021-merge-criss-cross.sh fails on some systems
From: David S. Miller @ 2005-12-10 22:42 UTC (permalink / raw)
To: git
This is really weird, so I started to try and get some diagnostics.
It doesn't fail on my sparc64 box running debian-testing
but it does fail on my Ubuntu x86 laptop, a sparc64 box
running debian-unstable, and an Ubuntu sparc64 system as
well.
This is with the current GIT tree.
I ran the test one step at a time to try and get some diagnostics,
here's what fails:
davem@nuts:~/src/GIT/test$ git merge "pre E3 merge" B A
Trying really trivial in-index merge...
fatal: Merge requires file-level merging
Nope.
Merging B with A
Merging:
1f14398f4c69d09ab1a4d53fe096ddec3ea45207 C3
d1072ae2682fad309c493343c5d77c9897fb6afa B8
found 1 common ancestor(s):
926159b75e3d9b240b1eae36eb1977b095ff2e1a Initial commit
Auto-merging file
Traceback (most recent call last):
File "/home/davem/bin/git-merge-recursive", line 868, in ?
firstBranch, secondBranch, graph)
File "/home/davem/bin/git-merge-recursive", line 87, in merge
branch1Name, branch2Name)
File "/home/davem/bin/git-merge-recursive", line 160, in mergeTrees
if not processEntry(entry, branch1Name, branch2Name):
File "/home/davem/bin/git-merge-recursive", line 821, in processEntry
branch1Name, branch2Name)
File "/home/davem/bin/git-merge-recursive", line 212, in mergeFile
src1, orig, src2], returnCode=True)
File "/home/davem/share/git-core/python/gitMergeCommon.py", line 72, in runProgram
raise ProgramError(progStr, e.strerror)
ProgramError: merge -L B/file -L orig/file -L A/file .merge_file_kDtaE3 .merge_file_K30Hgp .merge_file_frqYIs: No such file or directory
No merge strategy handled the merge.
davem@nuts:~/src/GIT/test$ ls
It looks like maybe some quoting issue? The call failing above is the
one in git-merge-recursive which looks like this:
[dummy, clean] = merge(graph.shaMap[h1], graph.shaMap[h2],
firstBranch, secondBranch, graph)
Any ideas?
^ permalink raw reply
* [PATCH] Allow saving an object from a pipe
From: Daniel Barkalow @ 2005-12-10 22:25 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In order to support getting data into git with scripts, this adds a
--stdin option to git-hash-object, which will make it read from stdin.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
---
Documentation/git-hash-object.txt | 3 +++
cache.h | 1 +
hash-object.c | 15 +++++++++++++--
sha1_file.c | 34 ++++++++++++++++++++++++++++++++++
4 files changed, 51 insertions(+), 2 deletions(-)
fac4c3a5c27839006e5d086ef282b252bd5f390e
diff --git a/Documentation/git-hash-object.txt b/Documentation/git-hash-object.txt
index db12e92..eaac4c9 100644
--- a/Documentation/git-hash-object.txt
+++ b/Documentation/git-hash-object.txt
@@ -29,6 +29,9 @@ OPTIONS
-w::
Actually write the object into the object database.
+--stdin::
+ Read the object from standard input instead of from a file.
+
Author
------
Written by Junio C Hamano <junkio@cox.net>
diff --git a/cache.h b/cache.h
index 86fc250..c78d8ae 100644
--- a/cache.h
+++ b/cache.h
@@ -144,6 +144,7 @@ extern int ce_match_stat(struct cache_en
extern int ce_modified(struct cache_entry *ce, struct stat *st);
extern int ce_path_match(const struct cache_entry *ce, const char **pathspec);
extern int index_fd(unsigned char *sha1, int fd, struct stat *st, int write_object, const char *type);
+extern int index_pipe(unsigned char *sha1, int fd, const char *type, int write_object);
extern int index_path(unsigned char *sha1, const char *path, struct stat *st, int write_object);
extern void fill_stat_cache_info(struct cache_entry *ce, struct stat *st);
diff --git a/hash-object.c b/hash-object.c
index 6227936..6502b5b 100644
--- a/hash-object.c
+++ b/hash-object.c
@@ -21,8 +21,16 @@ static void hash_object(const char *path
printf("%s\n", sha1_to_hex(sha1));
}
+static void hash_stdin(const char *type, int write_object)
+{
+ unsigned char sha1[20];
+ if (index_pipe(sha1, 0, type, write_object))
+ die("Unable to add stdin to database");
+ printf("%s\n", sha1_to_hex(sha1));
+}
+
static const char hash_object_usage[] =
-"git-hash-object [-t <type>] [-w] <file>...";
+"git-hash-object [-t <type>] [-w] [--stdin] <file>...";
int main(int argc, char **argv)
{
@@ -53,9 +61,12 @@ int main(int argc, char **argv)
}
else if (!strcmp(argv[i], "--help"))
usage(hash_object_usage);
+ else if (!strcmp(argv[i], "--stdin")) {
+ hash_stdin(type, write_object);
+ }
else
die(hash_object_usage);
- }
+ }
else {
const char *arg = argv[i];
if (0 <= prefix_length)
diff --git a/sha1_file.c b/sha1_file.c
index 111a71d..fa22e9c 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1528,6 +1528,40 @@ int has_sha1_file(const unsigned char *s
return find_sha1_file(sha1, &st) ? 1 : 0;
}
+int index_pipe(unsigned char *sha1, int fd, const char *type, int write_object)
+{
+ unsigned long size = 4096;
+ char *buf = malloc(size);
+ int iret, ret;
+ unsigned long off = 0;
+ unsigned char hdr[50];
+ int hdrlen;
+ do {
+ iret = read(fd, buf + off, size - off);
+ if (iret > 0) {
+ off += iret;
+ if (off == size) {
+ size *= 2;
+ buf = realloc(buf, size);
+ }
+ }
+ } while (iret > 0);
+ if (iret < 0) {
+ free(buf);
+ return -1;
+ }
+ if (!type)
+ type = "blob";
+ if (write_object)
+ ret = write_sha1_file(buf, off, type, sha1);
+ else {
+ write_sha1_file_prepare(buf, off, type, sha1, hdr, &hdrlen);
+ ret = 0;
+ }
+ free(buf);
+ return ret;
+}
+
int index_fd(unsigned char *sha1, int fd, struct stat *st, int write_object, const char *type)
{
unsigned long size = st->st_size;
--
0.99.9.GIT
^ permalink raw reply related
* Re: [PATCH 0/25] Usage message clean-up
From: A Large Angry SCM @ 2005-12-10 22:13 UTC (permalink / raw)
To: freku045; +Cc: git
In-Reply-To: <1134243476675-git-send-email-freku045@student.liu.se>
freku045@student.liu.se wrote:
...
> I have tried to follow the following rules:
>
> * Any unrecognised options should make the script die with the usage
> message.
Good.
> * -h and --help makes the script die with the usage message.
This should not be an error. The user was asking for the usage message.
> * The message is printed to stderr.
Good unless the message was printed due to -h or --help, then it should
go to stdout.
> * The message is of the form "usage: $0 options"
>
> I am not convinced that the last bullet point is the best way to do
> things. Using "$0" is probably best for Git developers but using "git
> program-name" is probably least confusing for users, especially if we
> are going to move the git-* binaries away from /usr/bin. Another
> option is "basename $0". What do you think?
Not using $0 can make it _extremely_ annoying to determine exactly which
program printed the usage message. It may look prettier without the path
but if I have more that one $(basename $0) it may not be trivial to
determine the one that issued the message. Also keep in mind that is it
possible to have spaces in names of executables. So, "foo-bar" and "foo
bar" may be two different executables.
^ permalink raw reply
* [PATCH 14/25] git-prune: Print $0 instead of program name in usage message.
From: freku045 @ 2005-12-10 19:37 UTC (permalink / raw)
To: git; +Cc: Fredrik Kuivinen
In-Reply-To: <1134243476675-git-send-email-freku045@student.liu.se>
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
---
git-prune.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
9c6661f08f42a6a1c76e43749d6e455bd1237dcb
diff --git a/git-prune.sh b/git-prune.sh
index 7e7f0ad..289aca0 100755
--- a/git-prune.sh
+++ b/git-prune.sh
@@ -9,7 +9,7 @@ do
case "$1" in
-n) dryrun=-n echo=echo ;;
--) break ;;
- -*) echo >&2 "usage: git-prune [ -n ] [ heads... ]"; exit 1 ;;
+ -*) echo >&2 "usage: $0 [-n] [--] [<head>...]"; exit 1 ;;
*) break ;;
esac
shift;
--
0.99.9.GIT
^ permalink raw reply related
* [PATCH 15/25] git-pull: Don't print an extra new line at the end of the usage message.
From: freku045 @ 2005-12-10 19:37 UTC (permalink / raw)
To: git; +Cc: Fredrik Kuivinen
In-Reply-To: <1134243476675-git-send-email-freku045@student.liu.se>
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
---
git-pull.sh | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
6123ce84502e443c10c6689966aa51c821775a1a
diff --git a/git-pull.sh b/git-pull.sh
index 3a13984..5a1ae2c 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -12,8 +12,7 @@ usage () {
[<fetch-options>]
<repo> <head>...
-Fetch one or more remote refs and merge it/them into the current HEAD.
-'
+Fetch one or more remote refs and merge it/them into the current HEAD.'
exit 1
}
--
0.99.9.GIT
^ permalink raw reply related
* [PATCH 11/25] git-revert: Fix usage message
From: freku045 @ 2005-12-10 19:37 UTC (permalink / raw)
To: git; +Cc: Fredrik Kuivinen
In-Reply-To: <1134243476675-git-send-email-freku045@student.liu.se>
Also syncs the usage message in the documentation with the usage message in
the implementation.
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
---
Documentation/git-revert.txt | 2 +-
git-revert.sh | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
3fbfe1e03eba7db1e484b7d00ac77820e6a11907
diff --git a/Documentation/git-revert.txt b/Documentation/git-revert.txt
index e27c680..6684a60 100644
--- a/Documentation/git-revert.txt
+++ b/Documentation/git-revert.txt
@@ -7,7 +7,7 @@ git-revert - Revert an existing commit.
SYNOPSIS
--------
-'git-revert' [--edit | --no-edit] [-n] <commit>
+'git-revert' [--edit | --no-edit] [-n | --no-commit] <commit>
DESCRIPTION
-----------
diff --git a/git-revert.sh b/git-revert.sh
index 9d499c4..0a94344 100755
--- a/git-revert.sh
+++ b/git-revert.sh
@@ -19,10 +19,10 @@ esac
usage () {
case "$me" in
cherry-pick)
- die "usage git $me [--edit] [-n] [-r] <commit-ish>"
+ die "usage: $0 [--edit] [-n | --no-commit] [-r] <commit>"
;;
revert)
- die "usage git $me [--edit | --no-edit] [-n] <commit-ish>"
+ die "usage $0 [--edit | --no-edit] [-n | --no-commit] <commit>"
;;
esac
}
--
0.99.9.GIT
^ permalink raw reply related
* [PATCH 8/25] git-fetch: Print usage message if we get an unrecognized option.
From: freku045 @ 2005-12-10 19:37 UTC (permalink / raw)
To: git; +Cc: Fredrik Kuivinen
In-Reply-To: <1134243476675-git-send-email-freku045@student.liu.se>
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
---
git-fetch.sh | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
50d509080e5cf32880bf412133473557f9e5f5b2
diff --git a/git-fetch.sh b/git-fetch.sh
index 14ea295..18b421d 100755
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -2,6 +2,11 @@
#
. git-sh-setup
. git-parse-remote
+
+usage () {
+ die "usage: $0 <fetch-options> <repository> <refspec>..."
+}
+
_x40='[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]'
_x40="$_x40$_x40$_x40$_x40$_x40$_x40$_x40$_x40"
@@ -34,6 +39,9 @@ do
-v|--verbose)
verbose=Yes
;;
+ -*)
+ usage
+ ;;
*)
break
;;
--
0.99.9.GIT
^ permalink raw reply related
* [PATCH 7/25] git-count-objects: Die with usage message if we are invoked incorrectly.
From: freku045 @ 2005-12-10 19:37 UTC (permalink / raw)
To: git; +Cc: Fredrik Kuivinen
In-Reply-To: <1134243476675-git-send-email-freku045@student.liu.se>
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
---
git-count-objects.sh | 11 ++++++++++-
1 files changed, 10 insertions(+), 1 deletions(-)
5db708396a841860c4d5e41c2acd60476d2207c4
diff --git a/git-count-objects.sh b/git-count-objects.sh
index 40c58ef..0d544ad 100755
--- a/git-count-objects.sh
+++ b/git-count-objects.sh
@@ -3,7 +3,16 @@
# Copyright (c) 2005 Junio C Hamano
#
-GIT_DIR=`git-rev-parse --git-dir` || exit $?
+. git-sh-setup
+
+usage () {
+ die "usage: $0"
+}
+
+if [ "$#" != "0" ]
+then
+ usage
+fi
dc </dev/null 2>/dev/null || {
# This is not a real DC at all -- it just knows how
--
0.99.9.GIT
^ permalink raw reply related
* [PATCH 16/25] git-push: Clean-up usage message
From: freku045 @ 2005-12-10 19:37 UTC (permalink / raw)
To: git; +Cc: Fredrik Kuivinen
In-Reply-To: <1134243476675-git-send-email-freku045@student.liu.se>
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
---
git-push.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
81b8c434e68712e5309af3d573cf13ebcb911a6f
diff --git a/git-push.sh b/git-push.sh
index 140c8f8..3336312 100755
--- a/git-push.sh
+++ b/git-push.sh
@@ -2,7 +2,7 @@
. git-sh-setup
usage () {
- die "Usage: git push [--all] [--force] <repository> [<refspec>]"
+ die "usage: $0 [--all] [--force] <repository> [<refspec>...]"
}
--
0.99.9.GIT
^ permalink raw reply related
* [PATCH 25/25] git-mv: Clean-up usage message.
From: freku045 @ 2005-12-10 19:38 UTC (permalink / raw)
To: git; +Cc: Fredrik Kuivinen
In-Reply-To: <1134243476675-git-send-email-freku045@student.liu.se>
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
---
git-mv.perl | 10 +++++++++-
1 files changed, 9 insertions(+), 1 deletions(-)
a213190dc8f25c133046a35593e027cb748f662b
diff --git a/git-mv.perl b/git-mv.perl
index 83dc7e4..db6699d 100755
--- a/git-mv.perl
+++ b/git-mv.perl
@@ -12,13 +12,21 @@ use strict;
use Getopt::Std;
sub usage() {
- print <<EOT;
+ print STDERR <<EOT;
$0 [-f] [-n] <source> <destination>
$0 [-f] [-n] [-k] <source> ... <destination directory>
EOT
exit(1);
}
+sub HELP_MESSAGE() {
+ usage;
+}
+
+sub VERSION_MESSAGE() {
+ usage;
+}
+
my $GIT_DIR = `git rev-parse --git-dir`;
exit 1 if $?; # rev-parse would have given "not a git dir" message.
chomp($GIT_DIR);
--
0.99.9.GIT
^ permalink raw reply related
* [PATCH 16/25] git-push: Clean up usage message
From: freku045 @ 2005-12-10 19:37 UTC (permalink / raw)
To: git; +Cc: Fredrik Kuivinen
In-Reply-To: <1134243476675-git-send-email-freku045@student.liu.se>
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
---
git-push.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
81b8c434e68712e5309af3d573cf13ebcb911a6f
diff --git a/git-push.sh b/git-push.sh
index 140c8f8..3336312 100755
--- a/git-push.sh
+++ b/git-push.sh
@@ -2,7 +2,7 @@
. git-sh-setup
usage () {
- die "Usage: git push [--all] [--force] <repository> [<refspec>]"
+ die "usage: git push [--all] [--force] <repository> [<refspec>...]"
}
--
0.99.9.GIT
^ permalink raw reply related
* [PATCH 20/25] git-reset: Use $0 instead of program name in usage message.
From: freku045 @ 2005-12-10 19:37 UTC (permalink / raw)
To: git; +Cc: Fredrik Kuivinen
In-Reply-To: <1134243476675-git-send-email-freku045@student.liu.se>
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
---
git-reset.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
33cc93a9e686c0daa64e430bf44b441809fd1025
diff --git a/git-reset.sh b/git-reset.sh
index 72ef303..58600fc 100755
--- a/git-reset.sh
+++ b/git-reset.sh
@@ -2,7 +2,7 @@
. git-sh-setup
usage () {
- die 'Usage: git reset [--mixed | --soft | --hard] [<commit-ish>]'
+ die 'usage: $0 [--mixed | --soft | --hard] [<commit-ish>]'
}
tmp=/var/tmp/reset.$$
--
0.99.9.GIT
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox