* Re: GIT 0.99.9
From: Wolfgang Denk @ 2005-10-30 20:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvezesyhi.fsf@assigned-by-dhcp.cox.net>
In message <7vvezesyhi.fsf@assigned-by-dhcp.cox.net> you wrote:
>
> I hate it when somebody tells me "it works for me", but I cannot
> help you here, sorry. I'm no rpm expert and the "make rpm" rule
> seems to work for me.
Which environment (Linux distribution) did you test this on? I tried
Fedora Core 2 and 4, both with the same result. I get the same
problem when building from the git source tree or when using the
source RPM.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
A person with one watch knows what time it is; a person with two
watches is never sure. Proverb
^ permalink raw reply
* git 0.99.9: Subversion importer breaks RPM generation (rpmbuild bug)
From: H. Peter Anvin @ 2005-10-30 20:12 UTC (permalink / raw)
To: Git Mailing List, rpm-list
The Subversion importer Perl script breaks RPM generation. First of
all, it introduces new module dependencies which don't exist in for
example RHEL4. The easiest way to deal with that is probably to fork
off the subversion exporter into a separate package, but the really bad
one is:
git-svnimport.perl:require v5.8.0; # for shell-safe open("-|",LIST)
... which RPM thinks means that you need a Perl module called v5.8.0
which doesn't, of course, exist. This is arguably an rpmbuild bug, but
it nevertheless breaks at the moment.
I'm afraid I cannot update any of the kernel.org machines to 0.99.9
until these problems have been cleaned up.
-hpa
^ permalink raw reply
* Re: git-pull (or cg-fetch?) with exit status
From: Randal L. Schwartz @ 2005-10-30 20:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3bmiudl1.fsf@assigned-by-dhcp.cox.net>
>>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
Junio> old_head=$(git-rev-parse --verify HEAD) &&
Junio> git-pull -n >/dev/null 2>&1 || exit
Junio> new_head=$(git-rev-parse --verify HEAD)
Junio> test "$old_head" = "$new_head" || make test install
This looks like it might work. I'll try it out next time. Thanks.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: GIT 0.99.9
From: Junio C Hamano @ 2005-10-30 17:31 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: git
In-Reply-To: <20051030172018.520BD353416@atlas.denx.de>
Wolfgang Denk <wd@denx.de> writes:
> In message <7vd5lnztav.fsf@assigned-by-dhcp.cox.net> you wrote:
>> GIT 0.99.9 is found at usual places.
>
> "make rpm" does not work for me:
I hate it when somebody tells me "it works for me", but I cannot
help you here, sorry. I'm no rpm expert and the "make rpm" rule
seems to work for me.
^ permalink raw reply
* Re: GIT 0.99.9
From: Wolfgang Denk @ 2005-10-30 17:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd5lnztav.fsf@assigned-by-dhcp.cox.net>
In message <7vd5lnztav.fsf@assigned-by-dhcp.cox.net> you wrote:
> GIT 0.99.9 is found at usual places.
"make rpm" does not work for me:
...
make -C templates install
make[2]: Entering directory `/usr/local/BUILD/git-core-0.99.9/templates'
: no custom templates yet
find blt
blt
blt/branches
blt/hooks
blt/hooks/post-commit
blt/hooks/applypatch-msg
blt/hooks/commit-msg
blt/hooks/post-update
blt/hooks/update
blt/hooks/pre-applypatch
blt/hooks/pre-commit
blt/info
blt/info/exclude
blt/description
blt/remotes
install -d -m755 '/var/tmp/git-core-0.99.9-1-root-wd/usr/share/git-core/templates/'
(cd blt && tar cf - .) | \
(cd '/var/tmp/git-core-0.99.9-1-root-wd/usr/share/git-core/templates/' && tar xf -)
tar: This does not look like a tar archive
tar: Skipping to next header
tar: Error exit delayed from previous errors
make[2]: *** [install] Error 2
make[2]: Leaving directory `/usr/local/BUILD/git-core-0.99.9/templates'
make[1]: *** [install] Error 2
make[1]: Leaving directory `/usr/local/BUILD/git-core-0.99.9'
error: Bad exit status from /var/tmp/rpm-tmp.96513 (%install)
RPM build errors:
Bad exit status from /var/tmp/rpm-tmp.96513 (%install)
make: *** [rpm] Error 1
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"The computer programmer is a creator of universes for which he alone
is responsible. Universes of virtually unlimited complexity can be
created in the form of computer programs." - Joseph Weizenbaum,
_Computer Power and Human Reason_
^ permalink raw reply
* Re: git-pull (or cg-fetch?) with exit status
From: Junio C Hamano @ 2005-10-30 17:19 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <86fyqjt9w9.fsf@blue.stonehenge.com>
merlyn@stonehenge.com (Randal L. Schwartz) writes:
> Other than grep the output of the "pull" commands, I'd like to have a
> flag added that will also set an exit status to "successful" if new
> things were pulled. That way, I can automate a "make install"
> resulting from a successful new pull, ala:
>
> git-pull --silent && make install
How about this instead of your one-liner?
old_head=$(git-rev-parse --verify HEAD) &&
git-pull -n >/dev/null 2>&1 || exit
new_head=$(git-rev-parse --verify HEAD)
test "$old_head" = "$new_head" || make test install
git-pull has at least 4 different possible outcomes, and its
exit code talks about its success/failure right now.
1. fetch did not succeed, so pull should result in failure. In
this case there is no change in your repository, and no
point rebuilding.
2. fetch contacted the other end and concluded conversation
correctly.
2-a. There was no change upstream (or you were up-to-date --
the other side was behind you). This is a successful
pull, but you probably do not want to rebuild.
2-b. There were changes upstream and we tried to merge.
Merge was successful. This case you would want to
rebuild.
2-c. There were changes upstream and automerge failed. You
cannot rebuild in this case.
With your proposal we should need to exit non-zero in case 2-a
when we are running with --silent. This feels somewhat
counter-intuitive if not wrong, even if it is only done under a
particular flag.
^ permalink raw reply
* Re: Tracking few files among many
From: Peter Eriksen @ 2005-10-30 15:52 UTC (permalink / raw)
To: git
In-Reply-To: <4364E6D7.9010707@op5.se>
On Sun, Oct 30, 2005 at 04:29:27PM +0100, Andreas Ericsson wrote:
> Peter Eriksen wrote:
> >Hello,
> >
> >There's something I can't figure out. I'm tracking a few
> >configuration files in $HOME, but some operations are really
> >slow. Let's take git-status as example:
...
> OTOH, since you *know* git-status (precisely because it looks for files
> not added to the index) to be slow, you should use git-diff* instead. I
> imagine you know what files you're tracking anyways since it's just a
> subset of 25000-something.
I understand now, I just didn't think about this behavior before.
What I could do is add all my files to .gitignore, but that would
be insane.
Perhaps I was just confused about it calling those files "not tracked".
I know, I know, it was changed recently to this exactly because it
was confusing before.
Thanks for clearing that up for me.
Peter
^ permalink raw reply
* Re: Tracking few files among many
From: Andreas Ericsson @ 2005-10-30 15:29 UTC (permalink / raw)
To: git
In-Reply-To: <20051030130001.GA26652@ebar091.ebar.dtu.dk>
Peter Eriksen wrote:
> Hello,
>
> There's something I can't figure out. I'm tracking a few
> configuration files in $HOME, but some operations are really
> slow. Let's take git-status as example:
>
> ~ > git-status >laaangsom.txt
> ~ > wc -l laaangsom.txt
> 25875 laaangsom.txt
> ~ > cat laaangsom.txt
> #
> # Changed but not updated:
> # (use git-update-index to mark for commit)
> #
> # modified: .gaim/blist.xml
> # modified: .gaim/prefs.xml
> # modified: .mozilla/firefox/s4q22693.default/prefs.js
> #
> #
> # Untracked files:
> # (use "git add" to add to commit)
> #
> # [ A lot of untracked files. See the line count above. ]
>
> What is going on? This really doesn't seem like the wanted
> behavior. Have I missed something?
Apart from the fact that git tracks objects using sha1-hashes, no.
However, hashing +25000 files takes quite some time even on a fairly
quick computer. I also imagine that some of those files are quite large,
so that doesn't really help.
If you really (really, really) want to use git to track configuration
file changes in your homedir, I'd suggest creating a separate directory
to keep the real files in and then symlink to those from their usual
locations.
OTOH, since you *know* git-status (precisely because it looks for files
not added to the index) to be slow, you should use git-diff* instead. I
imagine you know what files you're tracking anyways since it's just a
subset of 25000-something.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* git-pull (or cg-fetch?) with exit status
From: Randal L. Schwartz @ 2005-10-30 13:24 UTC (permalink / raw)
To: git
Other than grep the output of the "pull" commands, I'd like to have a
flag added that will also set an exit status to "successful" if new
things were pulled. That way, I can automate a "make install"
resulting from a successful new pull, ala:
git-pull --silent && make install
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: GIT 0.99.9
From: Johannes Schindelin @ 2005-10-30 13:21 UTC (permalink / raw)
To: A Large Angry SCM; +Cc: Junio C Hamano, git
In-Reply-To: <43644608.90608@gmail.com>
Hi,
On Sat, 29 Oct 2005, A Large Angry SCM wrote:
> Junio, I think you're doing an great job with Git.
Concur!
> Particularly, since I'm thinking that it may be mature enough to replace
> another SCM with a very large code base that I deal with.
Add to that the fact that most, if not all, changes are made backwards
compatible, i.e. git has stable for a *long* time now.
Ciao,
Dscho
^ permalink raw reply
* Tracking few files among many
From: Peter Eriksen @ 2005-10-30 13:00 UTC (permalink / raw)
To: git
Hello,
There's something I can't figure out. I'm tracking a few
configuration files in $HOME, but some operations are really
slow. Let's take git-status as example:
~ > git-status >laaangsom.txt
~ > wc -l laaangsom.txt
25875 laaangsom.txt
~ > cat laaangsom.txt
#
# Changed but not updated:
# (use git-update-index to mark for commit)
#
# modified: .gaim/blist.xml
# modified: .gaim/prefs.xml
# modified: .mozilla/firefox/s4q22693.default/prefs.js
#
#
# Untracked files:
# (use "git add" to add to commit)
#
# [ A lot of untracked files. See the line count above. ]
What is going on? This really doesn't seem like the wanted
behavior. Have I missed something? I'm using
46774a81f9d6ca4d230d33757afe9dd07bfe398b (GIT 0.99.9).
Regards,
Peter
^ permalink raw reply
* [PATCH] gitk: Specify line hover font
From: Frank Sorenson @ 2005-10-30 9:06 UTC (permalink / raw)
To: Paul Mackerras, Git Mailing List
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hovering over a line in gitk displays the commit one-liner in a
box, but the text usually overflows the box. The box size is
computed with a specified font, so this patch sets the text font
as well.
Signed-off-by: Frank Sorenson <frank@tuxrocks.com>
- --- a/gitk 2005-10-30 01:52:29.000000000 -0700
+++ b/gitk 2005-10-30 01:51:45.000000000 -0700
@@ -3143,7 +3143,7 @@
set t [$canv create rectangle $x0 $y0 $x1 $y1 \
-fill \#ffff80 -outline black -width 1 -tags hover]
$canv raise $t
- - set t [$canv create text $x $y -anchor nw -text $text -tags hover]
+ set t [$canv create text $x $y -anchor nw -text $text -tags hover -font $mainfont]
$canv raise $t
}
Frank
- --
Frank Sorenson - KD7TZK
Systems Manager, Computer Science Department
Brigham Young University
frank@tuxrocks.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFDZIz1aI0dwg4A47wRAjgLAKDFMGTgTPnGI9zBv48p1emAvLg6GgCeNwz3
OSrKWqnqGYpgMC89amkpUos=
=dD0G
-----END PGP SIGNATURE-----
^ permalink raw reply
* rev-list --sparse?
From: Junio C Hamano @ 2005-10-30 8:37 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0510292204520.3348@g5.osdl.org>
I was reviewing the rev-list documentation and it struck me that
dense/sparse command line flag do not make much sense.
Since dense is by default in effect, --dense is a no-op. One
possible use of it would be to hardcode --dense on a rev-list
command line in a script, like:
git-rev-list $some_opts --dense $some_paths
to defeat user-supplied --sparse that can be in $some_opts, but
for this to work the script needs to have parsed out user input
into some_opts and some_paths in the first place anyway, so it
can just detect and remove --sparse just as easily.
The --sparse flag does not seem to have much use either; not
giving pathspec has the same effect.
^ permalink raw reply
* Re: GIT 0.99.9
From: Linus Torvalds @ 2005-10-30 5:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vd5lnztav.fsf@assigned-by-dhcp.cox.net>
On Sat, 29 Oct 2005, Junio C Hamano wrote:
>
> GIT 0.99.9 is found at usual places.
Congrats. I personally think this is very much worthy of a 1.0 after just
giving it some time to shake out any possible last-minute bugs.
Linus
^ permalink raw reply
* Re: GIT 0.99.9
From: A Large Angry SCM @ 2005-10-30 4:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vslujy8or.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> A Large Angry SCM <gitzilla@gmail.com> writes:
>
>>It's nice to see the TODO list get shorter for a change! Especially
>>since the removed TODO items are not on the HAVEDONE list.
^^^
Oops! The ``not'' wasn't supposed to be there!!!!
>
> Huh? What are you talking about?
My typing was in error. The ``not'' should not have been there.
> Most of the items that were on the TODO list and marked [DONE]
> are on the HAVEDONE list, although I rephrased many of them to
> be more appropriate for the release notes. The only thing that
> I did not list on HAVEDONE list was 'whatchanged -m'
> documentation. There are many documentation contributions from
> the list I do not mention in HAVEDONE.
>
> I dropped from the TODO list was the "Perhaps show ^{commit},
> ^{tree} instead of ^{} from ls-remote", whose benefit was
> dubious.
>
>
Junio, I think you're doing an great job with Git. Particularly, since
I'm thinking that it may be mature enough to replace another SCM with a
very large code base that I deal with.
^ permalink raw reply
* Re: GIT 0.99.9
From: Junio C Hamano @ 2005-10-30 3:39 UTC (permalink / raw)
To: gitzilla; +Cc: git
In-Reply-To: <43643AF8.9090001@gmail.com>
A Large Angry SCM <gitzilla@gmail.com> writes:
> It's nice to see the TODO list get shorter for a change! Especially
> since the removed TODO items are not on the HAVEDONE list.
Huh? What are you talking about?
Most of the items that were on the TODO list and marked [DONE]
are on the HAVEDONE list, although I rephrased many of them to
be more appropriate for the release notes. The only thing that
I did not list on HAVEDONE list was 'whatchanged -m'
documentation. There are many documentation contributions from
the list I do not mention in HAVEDONE.
I dropped from the TODO list was the "Perhaps show ^{commit},
^{tree} instead of ^{} from ls-remote", whose benefit was
dubious.
^ permalink raw reply
* Re: GIT 0.99.9
From: A Large Angry SCM @ 2005-10-30 3:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd5lnztav.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> GIT 0.99.9 is found at usual places.
>
> As I said in the 0.99.8 announcement, git already does
> everything I want it to do, and from here on I'd like to see us
> concentrate on fixes (both correctness and performance) until we
> hit 1.0 which should happen shortly.
>
> Many thanks to everybody who contributed the comments, extra set
> of eyeballs, and code.
>
>
> Done in 0.99.9
> ==============
[Lots of text deleted]
It's nice to see the TODO list get shorter for a change! Especially
since the removed TODO items are not on the HAVEDONE list.
So, with 0.99.9 being the (non) "scary" release of Git, are you
targeting the Git 1.0 to be the (non) "turkey" release or the "fruit
cake" release? ;-)
^ permalink raw reply
* GIT 0.99.9
From: Junio C Hamano @ 2005-10-30 1:29 UTC (permalink / raw)
To: git; +Cc: linux-kernel
GIT 0.99.9 is found at usual places.
As I said in the 0.99.8 announcement, git already does
everything I want it to do, and from here on I'd like to see us
concentrate on fixes (both correctness and performance) until we
hit 1.0 which should happen shortly.
Many thanks to everybody who contributed the comments, extra set
of eyeballs, and code.
Done in 0.99.9
==============
Ports
~~~~~
* Cygwin port [HPA].
* OpenBSD build [Merlyn and others].
Fixes
~~~~~
* clone request over git native protocol from a repository with
too many refs did not work; this has been fixed.
* git-daemon got safer for kernel.org use [HPA].
* Extended SHA1 parser was not enforcing uniqueness for
abbreviated SHA1; this has been fixed.
* http transport does not barf on funny characters in URL.
* The ref naming restrictions have been formalized and the
coreish refuses to create funny refs; we still need to audit
importers. See git-check-ref-format(1).
New Features and Commands
~~~~~~~~~~~~~~~~~~~~~~~~~
* .git/config file as a per-repository configuration mechanism,
and some commands understand it [Linus]. See
git(7).
* The core.filemode configuration item can be used to make us a
bit more FAT friendly. See git(7).
* The extended SHA1 notation acquired Peel-the-onion operator
^{type} and ^{}. See git-rev-parse(1).
* SVN importer [Matthias]. See git-svnimport(1).
* .git/objects/[0-9a-f]{2} directories are created on demand,
and removed when becomes empty after prune-packed [Linus].
* Filenames output from various commands without -z option are
quoted when they embed funny characters (TAB and LF) using
C-style quoting within double-quotes, to match the proposed
GNU diff/patch notation [me, but many people contributed in
the discussion].
* git-mv is expected to be a better replacement for git-rename.
While the latter has two parameter restriction, it acts more
like the regular 'mv' that can move multiple things to one
destinatino directory [Josef Weidendorfer].
* git-checkout can take filenames to revert the changes to
them. See git-checkout(1)
* The new program git-am is a replacement for git-applymbox that
has saner command line options and a bit easier to use when a
patch does not apply cleanly.
* git-ls-remote can show unwrapped onions using ^{} notation, to
help Cogito to track tags.
* git-merge-recursive backend can merge unrelated projects.
* git-clone over native transport leaves the result packed.
* git-http-fetch issues multiple requests in parallel when
underlying cURL library supports it [Nick and Daniel].
* git-fetch-pack and git-upload-pack try harder to figure out
better common commits [Johannes].
* git-read-tree -u removes a directory when it makes it empty.
* git-diff-* records abbreviated SHA1 names of original and
resulting blob; this sometimes helps to apply otherwise an
unapplicable patch by falling back to 3-way merge.
* git-format-patch now takes series of from..to rev ranges and
with '-m --stdout', writes them out to the standard output.
This can be piped to 'git-am' to implement cheaper
cherry-picking.
* git-tag takes '-u' to specify the tag signer identity [Linus].
* git-rev-list can take optional pathspecs to skip commits that
do not touch them (--dense) [Linus].
* Comes with new and improved gitk [Paulus and Linus].
^ permalink raw reply
* [PATCH] Add usage statement to git-checkout.sh
From: Chris Shoemaker @ 2005-10-29 21:46 UTC (permalink / raw)
To: git; +Cc: Chris Shoemaker
Signed-off-by: Chris Shoemaker <c.shoemaker@cox.net>
---
git-checkout.sh | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
2fcbb6e58c0902e19373305b7ea77234f5d3ffba
diff --git a/git-checkout.sh b/git-checkout.sh
--- a/git-checkout.sh
+++ b/git-checkout.sh
@@ -1,6 +1,10 @@
#!/bin/sh
. git-sh-setup || die "Not a git archive"
+usage () {
+ die "usage: git checkout [-f] [-b <new_branch>] [<branch>] [<paths>...]"
+}
+
old=$(git-rev-parse HEAD)
new=
force=
@@ -26,6 +30,9 @@ while [ "$#" != "0" ]; do
--)
break
;;
+ -*)
+ usage
+ ;;
*)
if rev=$(git-rev-parse --verify "$arg^0" 2>/dev/null)
then
^ permalink raw reply
* [PATCH] Add to documentation of git-update-index arguments and usage.
From: Chris Shoemaker @ 2005-10-29 21:46 UTC (permalink / raw)
To: git; +Cc: Chris Shoemaker
In-Reply-To: <11306224011899-git-send-email-c.shoemaker@cox.net>
Removed unknown [--version] option.
Signed-off-by: Chris Shoemaker <c.shoemaker@cox.net>
---
Documentation/git-update-index.txt | 28 ++++++++++++++++++++++++----
update-index.c | 2 +-
2 files changed, 25 insertions(+), 5 deletions(-)
f51a2698073b75c6e0e0f96c0f1f6432167ed85b
diff --git a/Documentation/git-update-index.txt b/Documentation/git-update-index.txt
--- a/Documentation/git-update-index.txt
+++ b/Documentation/git-update-index.txt
@@ -9,12 +9,13 @@ git-update-index - Modifies the index or
SYNOPSIS
--------
'git-update-index'
- [--add] [--remove] [--refresh] [--replace]
- [--ignore-missing]
- [--force-remove]
+ [--add] [--remove | --force-remove] [--replace]
+ [--refresh [-q] [--unmerged] [--ignore-missing]]
[--cacheinfo <mode> <object> <file>]\*
- [--info-only]
+ [--chmod=(+|-)x]
+ [--info-only] [--index-info]
[-z] [--stdin]
+ [--verbose]
[--] [<file>]\*
DESCRIPTION
@@ -42,12 +43,28 @@ OPTIONS
Looks at the current cache and checks to see if merges or
updates are needed by checking stat() information.
+-q::
+ Quiet. If --refresh finds that the cache needs an update, the
+ default behavior is to error out. This option makes
+ git-update-index continue anyway.
+
+--unmerged::
+ If --refresh finds unmerged changes in the cache, the default
+ behavior is to error out. This option makes git-update-index
+ continue anyway.
+
--ignore-missing::
Ignores missing files during a --refresh
--cacheinfo <mode> <object> <path>::
Directly insert the specified info into the cache.
+--index-info::
+ Read index info from stdin.
+
+--chmod=(+|-)x::
+ Set the execute permissions on the updated files.
+
--info-only::
Do not create objects in the object database for all
<file> arguments that follow this flag; just insert
@@ -70,6 +87,9 @@ OPTIONS
read list of paths from the standard input. Paths are
separated by LF (i.e. one path per line) by default.
+--verbose::
+ Report what is being added and removed from index.
+
-z::
Only meaningful with `--stdin`; paths are separated with
NUL character instead of LF.
diff --git a/update-index.c b/update-index.c
--- a/update-index.c
+++ b/update-index.c
@@ -393,7 +393,7 @@ static void read_index_info(int line_ter
}
static const char update_index_usage[] =
-"git-update-index [-q] [--add] [--replace] [--remove] [--unmerged] [--refresh] [--cacheinfo] [--chmod=(+|-)x] [--info-only] [--force-remove] [--stdin] [--index-info] [--ignore-missing] [-z] [--version] [--] <file>...";
+"git-update-index [-q] [--add] [--replace] [--remove] [--unmerged] [--refresh] [--cacheinfo] [--chmod=(+|-)x] [--info-only] [--force-remove] [--stdin] [--index-info] [--ignore-missing] [-z] [--verbose] [--] <file>...";
int main(int argc, const char **argv)
{
^ permalink raw reply
* [PATCH] Add to usage and docs for git-add.sh
From: Chris Shoemaker @ 2005-10-29 21:46 UTC (permalink / raw)
To: git; +Cc: Chris Shoemaker
In-Reply-To: <11306224012707-git-send-email-c.shoemaker@cox.net>
Signed-off-by: Chris Shoemaker <c.shoemaker@cox.net>
---
Documentation/git-add.txt | 9 ++++++++-
git-add.sh | 7 +++++++
2 files changed, 15 insertions(+), 1 deletions(-)
2bc166e3e8241432b88ff793ec69a979a7056b3e
diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
--- a/Documentation/git-add.txt
+++ b/Documentation/git-add.txt
@@ -7,7 +7,7 @@ git-add - Add files to the cache.
SYNOPSIS
--------
-'git-add' <file>...
+'git-add' [-n] [-v] <file>...
DESCRIPTION
-----------
@@ -19,6 +19,13 @@ OPTIONS
<file>...::
Files to add to the cache.
+-n::
+ Don't actually add the file(s), just show if they exist.
+
+-v::
+ Be verbose.
+
+
Author
------
Written by Linus Torvalds <torvalds@osdl.org>
diff --git a/git-add.sh b/git-add.sh
--- a/git-add.sh
+++ b/git-add.sh
@@ -1,5 +1,9 @@
#!/bin/sh
+usage() {
+ die "usage: git add [-n] [-v] <file>..."
+}
+
show_only=
verbose=
while : ; do
@@ -10,6 +14,9 @@ while : ; do
-v)
verbose=--verbose
;;
+ -*)
+ usage
+ ;;
*)
break
;;
^ permalink raw reply
* Re: Problem with cg-clone
From: Junio C Hamano @ 2005-10-29 20:19 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: git
In-Reply-To: <1130616653.5396.56.camel@blade>
Marcel Holtmann <marcel@holtmann.org> writes:
>> The attached patch should fix git-local-fetch which I think the
>> above problem is. git-clone -l -s would be much faster if you
>> are doing a local clone, however.
>
> I can confirm that with this patch everything is back to normal.
Thanks. What Linus separately done (funny we did that
two-minutes apart) amounts to the same thing.
^ permalink raw reply
* Re: Problem with cg-clone
From: Marcel Holtmann @ 2005-10-29 20:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwtjwytzw.fsf@assigned-by-dhcp.cox.net>
Hi Junio,
> > I installed the latest git and cogito from their repositories and now
> > the local clone command is failing:
> >
> > # cg-clone linux-2.6 test-2.6
> > defaulting to local storage area
> > Using hard links
> > `/data/kernel/linux-2.6/.git/HEAD' -> `.git/refs/heads/.origin-fetching'
> > error: Couldn't find 8a212ab6b8a4ccc6f3c3d1beba5f92655c576404: not separate or in any pack
> > Cannot obtain needed object 8a212ab6b8a4ccc6f3c3d1beba5f92655c576404
> > while processing commit 0000000000000000000000000000000000000000.
> > cg-fetch: objects fetch failed
> > cg-clone: fetch failed
>
> The attached patch should fix git-local-fetch which I think the
> above problem is. git-clone -l -s would be much faster if you
> are doing a local clone, however.
I can confirm that with this patch everything is back to normal.
Regards
Marcel
^ permalink raw reply
* Re: Problem with cg-clone
From: Junio C Hamano @ 2005-10-29 19:59 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: git
In-Reply-To: <1130605726.5396.39.camel@blade>
Marcel Holtmann <marcel@holtmann.org> writes:
> I installed the latest git and cogito from their repositories and now
> the local clone command is failing:
>
> # cg-clone linux-2.6 test-2.6
> defaulting to local storage area
> Using hard links
> `/data/kernel/linux-2.6/.git/HEAD' -> `.git/refs/heads/.origin-fetching'
> error: Couldn't find 8a212ab6b8a4ccc6f3c3d1beba5f92655c576404: not separate or in any pack
> Cannot obtain needed object 8a212ab6b8a4ccc6f3c3d1beba5f92655c576404
> while processing commit 0000000000000000000000000000000000000000.
> cg-fetch: objects fetch failed
> cg-clone: fetch failed
The attached patch should fix git-local-fetch which I think the
above problem is. git-clone -l -s would be much faster if you
are doing a local clone, however.
---
diff --git a/local-fetch.c b/local-fetch.c
index 87a93de..0a07114 100644
--- a/local-fetch.c
+++ b/local-fetch.c
@@ -52,9 +52,10 @@ static int setup_indices(void)
return 0;
}
-static int copy_file(const char *source, const char *dest, const char *hex,
+static int copy_file(const char *source, char *dest, const char *hex,
int warn_if_not_exists)
{
+ safe_create_leading_directories(dest);
if (use_link) {
if (!link(source, dest)) {
pull_say("link %s\n", hex);
@@ -150,7 +151,7 @@ static int fetch_file(const unsigned cha
static int object_name_start = -1;
static char filename[PATH_MAX];
char *hex = sha1_to_hex(sha1);
- const char *dest_filename = sha1_file_name(sha1);
+ char *dest_filename = sha1_file_name(sha1);
if (object_name_start < 0) {
strcpy(filename, path); /* e.g. git.git */
^ permalink raw reply related
* Re: Problem with cg-clone
From: Linus Torvalds @ 2005-10-29 19:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Marcel Holtmann, git
In-Reply-To: <7vacgs157c.fsf@assigned-by-dhcp.cox.net>
On Sat, 29 Oct 2005, Junio C Hamano wrote:
>
> Marcel Holtmann <marcel@holtmann.org> writes:
>
> > Previously this was working fine and since cogito hasn't changed the
> > last few days, I suspect that git is at fault here or changed something.
> > Any ideas?
>
> I think I know what is going on.
>
> git-init-db does not create .git/objects/[0-9a-f]{2}/
> directories anymore, but git-local-fetch has not taught to
> create them on demand.
Here's a quick hack, totally untested, of course.
More properly it should use move_temp_to_file(), but if you're about to do
a v0.99.9 release, maybe this could be good enough.
Linus
---
diff --git a/local-fetch.c b/local-fetch.c
index 87a93de..21f5bf8 100644
--- a/local-fetch.c
+++ b/local-fetch.c
@@ -52,9 +52,20 @@ static int setup_indices(void)
return 0;
}
-static int copy_file(const char *source, const char *dest, const char *hex,
+static int copy_file(const char *source, char *dest, const char *hex,
int warn_if_not_exists)
{
+ char *dir = strrchr(dest, '/');
+
+ if (dir) {
+ *dir = 0;
+ if (mkdir(dir, 0777)) {
+ if (errno != EEXIST)
+ perror(dir);
+ }
+ *dir = '/';
+ }
+
if (use_link) {
if (!link(source, dest)) {
pull_say("link %s\n", hex);
@@ -150,7 +161,7 @@ static int fetch_file(const unsigned cha
static int object_name_start = -1;
static char filename[PATH_MAX];
char *hex = sha1_to_hex(sha1);
- const char *dest_filename = sha1_file_name(sha1);
+ char *dest_filename = sha1_file_name(sha1);
if (object_name_start < 0) {
strcpy(filename, path); /* e.g. git.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