* Re: [howto] Kernel hacker's guide to git, updated
From: Jeff Garzik @ 2005-10-01 0:17 UTC (permalink / raw)
To: Horst von Brand; +Cc: Linux Kernel, Junio C Hamano, git
In-Reply-To: <200509301813.j8UIDXr5015488@laptop11.inf.utfsm.cl>
Horst von Brand wrote:
> Jeff Garzik <jgarzik@pobox.com> wrote:
>
>>Thanks for all the comments. I just updated the KHGtG with the
>>feedback I received. Go to
>>
>> http://linux.yyz.us/git-howto.html
>>
>>and click reload. Continued criticism^H^H^Hcomments welcome!
>
>
> - To know the current branch, "git branch" is enough (the one '*'-ed)
Click reload, this is already mentioned.
> - rsync(1) a repository is dangerous, it might catch it in the middle of
> a update and give you an incomplete/messed up copy. Repeat rsync until no
> change, perhaps?
Usually that's just unlucky. I have caught kernel.org in the middle of
a sync once, maybe twice.
> - I understand "git checkout -f" blows away any local changes, no questions
> asked. Not very nice to suggest that to a newbie...
I constantly run into problems if I -do not- use the "-f" flag. I
habitually use it at all times, now.
Thanks,
Jeff
^ permalink raw reply
* Re: [howto] Kernel hacker's guide to git, updated
From: Linus Torvalds @ 2005-10-01 0:10 UTC (permalink / raw)
To: Horst von Brand
Cc: Dave Jones, Anton Altaparmakov, Jeff Garzik, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0509291742170.3378@g5.osdl.org>
On Thu, 29 Sep 2005, Linus Torvalds wrote:
>
> I put my git repo on
>
> kernel.org:/pub/software/editors/uemacs/uemacs.git
Gaah. You guys shamed me into actually trying to clean up the sources a
bit.
It's by no means done, but some of it is even sparse-clean now.
I suspect there's a lot of it that still works mainly by luck than because
it does anything right.
Linus
^ permalink raw reply
* Re: [PATCH] HTTP partial transfer support for object, pack, and index transfers
From: Nick Hengeveld @ 2005-09-30 23:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk6gz6lpp.fsf@assigned-by-dhcp.cox.net>
On Fri, Sep 30, 2005 at 12:47:30AM -0700, Junio C Hamano wrote:
> I took a look at this patch. It did not cleanly apply anymore,
> but I merged it anyway, and then took the liberty of updating it
> further, according to your response to my earlier comments.
Sorry about that - we're actually using git as a back end to a content
distribution system, so I'm still learning the finer points of using it
for source control...
> They will appear near the tip of the proposed updates branch.
> I'd appreciate it if you could check it out and see I did not
> break things by mistake.
I've included a patch that fixes one small problem; I've tested partial
transfers of packs and objects with this applied and it looks good.
Don't unlink the temp file when an object transfer fails, so next attempt
will pick up where the failed transfer left off
Signed-off-by: Nick Hengeveld <nickh@reactrix.com>
---
http-fetch.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
22226e509b916958a8b7aae76945c08d15ec686a
diff --git a/http-fetch.c b/http-fetch.c
--- a/http-fetch.c
+++ b/http-fetch.c
@@ -550,7 +550,6 @@ static int fetch_object(struct alt_base
curl_result = curl_easy_perform(curl);
curl_easy_setopt(curl, CURLOPT_HTTPHEADER, no_range_header);
if (curl_result != 0) {
- unlink(tmpfile);
return error("%s", curl_errorstr);
}
^ permalink raw reply
* Re: [howto] Kernel hacker's guide to git, updated
From: Francois Romieu @ 2005-09-30 22:52 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Linux Kernel, git
In-Reply-To: <433D1E5D.20303@pobox.com>
Jeff Garzik <jgarzik@pobox.com> :
[...]
> Thanks for all the comments. I just updated the KHGtG with the feedback
> I received. Go to
>
> http://linux.yyz.us/git-howto.html
>
> and click reload. Continued criticism^H^H^Hcomments welcome!
The basic tasks make no use of git-whatchanged.
Even if it is a CVSism, it is quite handful to retrieve the history of
the patchsets by aiming at a specific file.
--
Ueimor
^ permalink raw reply
* Re: git push to a local directory with no .git in it
From: Richard Curnow @ 2005-09-30 22:51 UTC (permalink / raw)
To: git
In-Reply-To: <7v7jcze7xu.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio <at> cox.net> writes:
>
> Please don't presume, but dig.
Yes, sorry. It was late...
>
> If you do not have mairix.git/objects or mairix.git/refs/heads/
> then that's when you get that error message.
In fact, it turned out that I did still had a .git under mairix.git, but I'd
mv'd its contents up to the mairix.git level and forgotten to delete the .git
directory. Doh.
Thanks for your help, anyway. It was a very strong clue what to look for.
Richard
^ permalink raw reply
* Re: [PATCH] Support SPARSE in Makefile, better SPARSE_FLAGS
From: H. Peter Anvin @ 2005-09-30 22:16 UTC (permalink / raw)
To: Pavel Roskin; +Cc: Junio C Hamano, git
In-Reply-To: <1128118469.7352.15.camel@dv>
Pavel Roskin wrote:
>
> I know. That's what I'm using in the wrapper (plus -m64 and some
> warnings). But it should be the default. Until then, hassle-free
> sparse support in the Makefile is only possible for the projects that
> already know the architecture (e.g. the Linux kernel).
>
I think that's debatable. It introduces main-compiler dependencies into
sparse which is undesirable.
A much simpler option would be to write a "sparsegcc" script which would
be invoked just like gcc, extract the appropriate macro information
based on options, and then invoke sparse.
-hpa
^ permalink raw reply
* Re: [PATCH] Support SPARSE in Makefile, better SPARSE_FLAGS
From: Pavel Roskin @ 2005-09-30 22:14 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Junio C Hamano, git
In-Reply-To: <433D8FA6.2080808@zytor.com>
On Fri, 2005-09-30 at 12:19 -0700, H. Peter Anvin wrote:
> Pavel Roskin wrote:
> >
> > I hate to say that, but a better alternative is to fix sparse to act
> > like the native compiler by default (possibly with options to imitate
> > other architectures or to be fully arch-neutral).
> >
>
> $(CC) $(CFLAGS) -E -dM -x c /dev/null -o builtin.h
>
> ... will output a file containing all the buildin macros that you can
> feed to sparse with -include.
I know. That's what I'm using in the wrapper (plus -m64 and some
warnings). But it should be the default. Until then, hassle-free
sparse support in the Makefile is only possible for the projects that
already know the architecture (e.g. the Linux kernel).
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [PATCH] Support SPARSE in Makefile, better SPARSE_FLAGS
From: H. Peter Anvin @ 2005-09-30 19:19 UTC (permalink / raw)
To: Pavel Roskin; +Cc: Junio C Hamano, git
In-Reply-To: <1128087662.14543.14.camel@dv>
Pavel Roskin wrote:
>
> I hate to say that, but a better alternative is to fix sparse to act
> like the native compiler by default (possibly with options to imitate
> other architectures or to be fully arch-neutral).
>
$(CC) $(CFLAGS) -E -dM -x c /dev/null -o builtin.h
... will output a file containing all the buildin macros that you can
feed to sparse with -include.
Replacing -x c with, say, -x c++ gives you the builtins for C++;
including $(CFLAGS) gives the appropriate set of macros for any
particular combination of options (which can affect the builtin macro set.)
-hpa
^ permalink raw reply
* Re: First cut at git port to Cygwin
From: H. Peter Anvin @ 2005-09-30 19:08 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Junio C Hamano, git
In-Reply-To: <433D6F62.3030906@zytor.com>
Okay, I have updated the git-cygwin repository with the changes
proposed, and they seem to work.
-hpa
^ permalink raw reply
* [PATCH] Fix cg-admin-uncommit
From: Paolo 'Blaisorblade' Giarrusso @ 2005-09-30 18:35 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
From: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
It uses $1 rather than ${ARGS[0]}, which breaks when optparse found some
options, i.e. with cg-admin-uncommit -t (cg-object-id -c -t is not nice).
Please, document optparse to explain this. It's absolutely non-obvious, and when
I first hit this I thought optparse was buggy but couldn't make my way to the
fix.
Both because I was using cogito rather than debugging it, and even considering
the obfuscation level, but above all I was looking for a call to shift in
optshift and didn't find it. Now I understood the thing I pity myself, though.
Btw, why doesn't optparse consume all the cmd arguments via shift, making thus
sure that $1 never works at all?
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
---
cg-admin-uncommit | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/cg-admin-uncommit b/cg-admin-uncommit
--- a/cg-admin-uncommit
+++ b/cg-admin-uncommit
@@ -47,7 +47,7 @@ done
base=$(cg-object-id -c) || exit 1
-commit=$(cg-object-id -c "$1") || exit 1
+commit=$(cg-object-id -c "${ARGS[0]}") || exit 1
git-rev-list $base | grep -q $commit || \
die "$commit: not an ancestor of HEAD"
^ permalink raw reply
* [COGITO] cg-status in an empty repo spits out git-diff-index usage info
From: Elfyn McBratney @ 2005-09-30 18:18 UTC (permalink / raw)
To: git mailing list; +Cc: Petr Baudis
[-- Attachment #1: Type: text/plain, Size: 1246 bytes --]
[Re-sending ..]
Hello Petr, git list,
A `cg-status` in an empty repo (i.e., straight after a `cg-init -I`)
spits out git-diff-index usage information, a la:
[($) 09:03:42] beu@zippy ~/git/test
> cg-status
Heads:
>master
usage: git-diff-index [-m] [--cached] [<common diff options>] <tree-ish> [<path>...]
common diff options:
[...]
which I'm guessing isn't expected behaviour ;) `git status` does the
same, FWIW. I'm having a look around to try and figure out why, and
will try to work up a patch to fix it, but in case I don't find the bug
(or feature ;), consider this a heads-up. :)
(And I've just used gitk for the first time, too, and I must say it's
one invaluable piece of software ! Kudos to it's creators :)
This is with latest cogito.git (b06f2a707963c8712f7a6bbd4b89bae758bcf92a,
though the 'bug' is also present in 0.15.1) with git 0.99.7d.
Best,
Elfyn
--
Elfyn McBratney
Gentoo Developer/Perl Team Lead
beu/irc.freenode.net http://dev.gentoo.org/~beu/
+------------O.o--------------------- http://dev.gentoo.org/~beu/pubkey.asc
PGP Key ID: 0x69DF17AD
PGP Key Fingerprint:
DBD3 B756 ED58 B1B4 47B9 B3BD 8D41 E597 69DF 17AD
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [howto] Kernel hacker's guide to git, updated
From: Linus Torvalds @ 2005-09-30 18:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff Garzik, Linux Kernel, git
In-Reply-To: <7v64si4von.fsf@assigned-by-dhcp.cox.net>
On Fri, 30 Sep 2005, Junio C Hamano wrote:
>
> I suspect the version Linus posted has a funny interaction with
> 'git-pull'; 'git pull --tags' by mistake, or intentionally to
> file a bug report to annoy me ;-), would create an Octopus out
> of those tags, if I am not mistaken.
Hey, even more impressive is "git pull --all", which will happily try to
create an octopus of every single ref available at the other end.
Now, I think that octopus merges in _general_ are likely to be driver
error, and that it might make sense to have a separate flag to enable
them in the first place. That would solve the confusion..
So then you could do
git pull --all --octopus xyzzy
if you _really_ meant to do that.
Linus
^ permalink raw reply
* Re: [howto] Kernel hacker's guide to git, updated
From: Horst von Brand @ 2005-09-30 18:13 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Linux Kernel, Junio C Hamano, git
In-Reply-To: <433D1E5D.20303@pobox.com>
Jeff Garzik <jgarzik@pobox.com> wrote:
> Thanks for all the comments. I just updated the KHGtG with the
> feedback I received. Go to
>
> http://linux.yyz.us/git-howto.html
>
> and click reload. Continued criticism^H^H^Hcomments welcome!
- To know the current branch, "git branch" is enough (the one '*'-ed)
- rsync(1) a repository is dangerous, it might catch it in the middle of
a update and give you an incomplete/messed up copy. Repeat rsync until no
change, perhaps?
- I understand "git checkout -f" blows away any local changes, no questions
asked. Not very nice to suggest that to a newbie...
Thanks for the docu!
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
^ permalink raw reply
* Re: First cut at git port to Cygwin
From: H. Peter Anvin @ 2005-09-30 17:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4q826ffy.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
>
> Could you do update-server-info there, please?
>
Done...
>
> Knowing nothing about Cygwin environment, here are some
> comments.
>
> +# Define NO_IPV6 if you lack IPv6 support and getaddrinfo().
>
> This part probably is applicable outside Cygwin. At some point,
> can we have it in the mainline please?
>
Well, I would hope that all the changes could eventually be merged.
> # The ones that do not have to link with lcrypto nor lz.
> SIMPLE_PROGRAMS = \
> - git-get-tar-commit-id git-mailinfo git-mailsplit git-stripspace \
> - git-daemon git-var
> + git-get-tar-commit-id$(X) git-mailinfo$(X) git-mailsplit$(X) \
> + git-stripspace$(X) git-var$(X) git-daemon$(X)
>
> I have seen these $(X) in other programs' ports and found them
> quite distasteful. Since I not have immediate suggestions
> for improvements, I do not have rights to complain, though.
>
> Spelling it $X is a bit less distracting but not that much
> better. Maybe "SIMPLE_PROGRAM_NAMES = git-foo git-bar" and
> "SIMPLE_PROGRAMS = $(patsubst %,%$X,$(SIMPLE_PROGRAM_NAMES))"...
> but that would not help bits like this:
>
> - PROGRAMS += git-http-fetch
> + PROGRAMS += git-http-fetch$(X)
>
> or this:
>
> -git-%: %.o $(LIB_FILE)
> +git-%$(X): %.o $(LIB_FILE)
>
> ... so I'd shut up about this part.
My first cut had PROGRAMS_X and SIMPLE_PROGRAMS_X being patsubst of the
original versions, but in the end I decided it was even uglier, because
these patterns were needed elsewhere. I'll change them to $X except
where the parens are needed.
> diff --git a/daemon.c b/daemon.c
> --- a/daemon.c
> +++ b/daemon.c
> @@ -1,9 +1,11 @@
> #include "cache.h"
> #include "pkt-line.h"
> +#include <alloca.h>
>
> Why? I do not see any use of alloca in the added code...
I originally used alloca() before changing my mind and using calloc(); I
think there might be platforms without alloca out there.
> +#include <sys/poll.h>
>
> Is poll preferrable over select in general? Some may have only
> select available and others may have only poll available,
> perhaps? In any case, this is probably relevant to wider
> audience than just Cygwin; please give it to mainline at some
> point, perhaps conditionally allowing either/both.
The main reason I switched to poll() is that I believe all platforms
that are even remotely relevant have both these days, and forming a poll
list is so much cleaner than forming a select set. What makes forming a
select set even remotely bearable is the invalid assumption that the
number of file descriptors is bounded at compile time and therefore that
fdset_t can be statically allocated. We've had problems in the past
with that assumption on Linux, and I've tried to avoid select since then.
> + *socklist_p = malloc(sizeof(int));
> + pfd = calloc(socknum, sizeof(struct pollfd));
>
> Please use xmalloc and xcalloc just for consistency.
Check.
> test -x $path/git-$cmd && exec $path/git-$cmd "$@" ;;
> +
> + # In case we're running on Cygwin...
> + test -x $path/git-$cmd.exe && exec $path/git-$cmd.exe "$@" ;;
> esac
>
> Hmph, I think you forgot to drop double semicolon there.
D'oh!
> The git.sh script is munged by Makefile so presumably we could
> fix this part up there, like:
>
> git: git.sh Makefile
> rm -f $@+ $@
> sed -e '1s|#!.*/sh|#!$(SHELL_PATH)|' \
> -e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
> -e 's/@@X@@/$X/g' <$@.sh >$@+
> chmod +x $@+
> mv $@+ $@
>
> And then (a patch on top of your "master"):
>
> diff --git a/git.sh b/git.sh
> --- a/git.sh
> +++ b/git.sh
> @@ -12,10 +12,14 @@ case "$#" in
> exit 0 ;;
> esac
>
> - test -x $path/git-$cmd && exec $path/git-$cmd "$@" ;;
> + test -x $path/git-$cmd && exec $path/git-$cmd "$@"
>
> - # In case we're running on Cygwin...
> - test -x $path/git-$cmd.exe && exec $path/git-$cmd.exe "$@" ;;
> + case '@@X@@' in
> + '')
> + ;;
> + *)
> + test -x $path/git-$cmd@@X@@ && exec $path/git-$cmd@@X@@ "$@" ;;
> + esac
> esac
>
> echo "Usage: git COMMAND [OPTIONS] [TARGET]"
That wouldn't work, because the shell scripts don't get the .exe
extension. However, I can figure out something equivalent.
-hpa
^ permalink raw reply
* Re: [howto] Kernel hacker's guide to git, updated
From: Linus Torvalds @ 2005-09-30 16:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Oliver Neukum, git
In-Reply-To: <7vslvn6m6y.fsf@assigned-by-dhcp.cox.net>
On Fri, 30 Sep 2005, Junio C Hamano wrote:
>
> I wonder what that 32-byte small file called 'index' is doing
> there. If this is the kernel tree, its index file should weigh
> about 1.7MB if I recall correctly.
32 bytes is what you get for an empty index (it's a 12-byte header,
followed by a 20-byte SHA1 of the contents).
In general, such an index file it should be 100% equivalent to not having
an index file at all.
Linus
^ permalink raw reply
* Destructive side-effect of "cg-status"
From: Wolfgang Denk @ 2005-09-30 16:03 UTC (permalink / raw)
To: git
So far I thought "cg-status" is a harmless command which just
displays some status information. It ain't so. One of our engineers
reported a corrupted repository after I ran "cg-status" in his
directory:
$ cg-status
Heads:
>master 805f93e4ca96d0c0cb2d2f9532d9666b22961e88
R origin 805f93e4ca96d0c0cb2d2f9532d9666b22961e88
error: open failed
fatal: cache corrupted
error: open failed
? COPYING
? CREDITS
? Documentation/00-INDEX
? Documentation/BUG-HUNTING
...
error: open failed
read_cache: Permission denied
...
error: open failed
read_cache: Permission denied
...
As mentioned before, all I did was running "cg-status" in his
directory. Here is what happens:
Before:
-> rpm -q cogito
cogito-0.15.1-1
-> id
uid=500(wd) gid=500(wd) groups=200(gitmaster),400(denx),500(wd)
-> umask
0002
-> ls -ld .git
drwxrwxrwx 6 sr sr 80 Sep 30 17:49 .git
-> ls -l .git/index
-rw-r--r-- 1 sr sr 1728032 Sep 30 17:17 .git/index
Then:
-> cg-status
Heads:
>master 805f93e4ca96d0c0cb2d2f9532d9666b22961e88
R origin 805f93e4ca96d0c0cb2d2f9532d9666b22961e88
M arch/ppc/configs/bubinga_defconfig
M arch/ppc/configs/walnut_defconfig
-> ls -l .git/index
-rw------- 1 wd wd 1728032 Sep 30 17:49 .git/index
^^^^^^^^^^ ^^^^^
That means, that "cg-status" actually *rewrote* .git/index, with me
(wd) as new owner, and - ignoring my umask - with permissions that
prevent the original owner (sr) to access the file!
Arghhhh!!!
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
Generally speaking, there are other ways to accomplish whatever it is
that you think you need ... - Doug Gwyn
^ permalink raw reply
* Re: [howto] Kernel hacker's guide to git, updated
From: Alberto Patino @ 2005-09-30 15:10 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Oliver Neukum, Linux Kernel, Junio C Hamano, git
In-Reply-To: <433D447E.9030103@pobox.com>
On 9/30/05, Jeff Garzik <jgarzik@pobox.com> wrote:
> Oliver Neukum wrote:
> >
> > The error is still there.
> >
> > oliver@oenone:~/linux-2.6> git checkout -f master
> > usage: read-tree (<sha> | -m <sha1> [<sha2> <sha3>])
>
> Something's wrong with your installation, not the instructions. Works
> fine here.
>
Right , you must have a corrupted copy of the git repo. Do the initial
cloning of the linux repository again, and then retry the git
checkout.
^ permalink raw reply
* Re: [howto] Kernel hacker's guide to git, updated
From: Jeff Garzik @ 2005-09-30 14:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linux Kernel, git
In-Reply-To: <7v64si4von.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jeff Garzik <jgarzik@pobox.com> writes:
>>2) What is the easiest way to obtain a list of changes present in
>>repository B, that are not present in repository A? I used to use
>>git-changes-script [hacked cg-log script] for this:
>
>
> I think I still have the copy you sent to the list. If you do
> not mind me placing in the master branch just holler -- better
> yet please send a patch with commit log and signoff to add the
> latest, and I will apply it.
It's archived here:
http://www.kernel.org/pub/linux/kernel/people/jgarzik/git-changes-script
but it needs a git expert (read: not me :)) to fix it up for the very
latest git-core stuff.
Currently, using 'git-changes-script -L ../linux-2.6' spits out
> --------------------------
> commit 2fca877b68b2b4fc5b94277858a1bedd46017cde
> usage: git-cat-file [-t | -s | <type>] <sha1>
>
> --------------------------
> commit ff40c6d3d1437ecdf295b8e39adcb06c3d6021ef
> usage: git-cat-file [-t | -s | <type>] <sha1>
>
> --------------------------
> commit 8bf62ecee58360749c5f0e68bc97d5e02a6816b1
> usage: git-cat-file [-t | -s | <type>] <sha1>
>
> --------------------------
Regards,
Jeff
^ permalink raw reply
* Re: [howto] Kernel hacker's guide to git, updated
From: Jeff Garzik @ 2005-09-30 14:08 UTC (permalink / raw)
To: Erik Mouw; +Cc: Linux Kernel, Junio C Hamano, git
In-Reply-To: <20050930120739.GB9328@harddisk-recovery.com>
Erik Mouw wrote:
> FYI, the rsync command to get the tags blows away .git/branches/origin,
> so on the next "git pull", git will tell you "Where do you want to
> fetch from today?".
Agreed, though I always run 'git pull $url' each time, so I never
noticed this.
Since git clone pulls the tags, I have eliminated the first rsync
completely.
Jeff
^ permalink raw reply
* Re: [howto] Kernel hacker's guide to git, updated
From: Jeff Garzik @ 2005-09-30 13:58 UTC (permalink / raw)
To: Oliver Neukum; +Cc: Linux Kernel, Junio C Hamano, git
In-Reply-To: <200509301402.46740.oliver@neukum.org>
Oliver Neukum wrote:
> Am Freitag, 30. September 2005 13:15 schrieb Jeff Garzik:
>
>>Thanks for all the comments. I just updated the KHGtG with the feedback
>>I received. Go to
>>
>> http://linux.yyz.us/git-howto.html
>>
>>and click reload. Continued criticism^H^H^Hcomments welcome!
>>
>
>
> The error is still there.
>
> oliver@oenone:~/linux-2.6> git checkout -f master
> usage: read-tree (<sha> | -m <sha1> [<sha2> <sha3>])
Something's wrong with your installation, not the instructions. Works
fine here.
Jeff
^ permalink raw reply
* Re: [PATCH] Added an option to cvsimport to specify email domain
From: David Mansfield @ 2005-09-30 13:54 UTC (permalink / raw)
To: Alexey Nezhdanov; +Cc: Matthias Urlichs, git
In-Reply-To: <200509301219.42087.snake@penza-gsm.ru>
On Fri, 2005-09-30 at 12:19 +0400, Alexey Nezhdanov wrote:
> On Tuesday 27, September 2005 16:54 David Mansfield wrote:
> > On Tue, 2005-09-27 at 08:34 +0400, Alexey Nezhdanov wrote:
> > > (Re-post. Sorry for any inconvenience.)
> > >
> > > On September 14, 2005 23:34 Petr Baudis wrote:
> > > > Dear diary, on Wed, Sep 07, 2005 at 09:18:03PM CEST, I got a letter
> > > > where Junio C Hamano <junkio@cox.net> told me that...
> > > >
> > > > > David K?.A?Negedal <davidk@lysator.liu.se> writes:
> > > > > > The authorship info in commits created by git-cvsimport-script
> > > > > > only contains the username of the CVS committer. This patch
> > > > > > adds a flag -e <domain> to git-cvsimport-script that makes it
> > > > > > possible to specify an email domain that is added to all email
> > > > > > addresses in the commit "author" and "committer" fields.
> > > > > >
> > > > > > ---
> > > > > > I have stopped using cvsimport, because cvsps seems to produce bad
> > > > > > output on the repository I'm using it with, but I had already
> > > > > > prepared this patch.
> > > > >
> > > > > Hmph. One reason the original implementation did not do this is
> > > > > because Linus and other people wanted to have a repeatability,
> > > > > so making this an optional thing is good, but if we go this
> > > > > route, I think if it would be nicer to have a --author-map
> > > > > option that lets you feed a list of:
> > > > >
> > > > > <author> ==> "A U Thor <author@author.dom>"
> > > > >
> > > > > mappings, instead of a single -e, which essentially does not add
> > > > > much information to the result.
> > > > >
> > > > > I take that your oob comment indicates that you do not have much
> > > > > incentive/inclination to further hack on this, so I am not
> > > > > asking you to do the above even if you find my suggestion
> > > > > worthwhile.
> > > >
> > > > Various tools use CVSROOT/users to map usernames to realname <email>.
> > > > I actually wanted to send a patch, looked at the cvsimport script and
> > > > got totally scared away (at least for now)... ;-)
> > >
> > > git uses cvsps output to determine authorship. Do you think if this
> > > problem should be solved on cvsps side? It should be relatively easy
> > > IMHO. David, can you add another key to output CVSROOT/users mapping
> > > result instead of usernames if available?
> >
> > I apologize that I probably won't have time to look at this right now...
> >
> > David
>
> Hello. I have improved my patch and tested it with git-cvsimport-script.
> cvsps works as intended so I hope that you, David will accept this patch. You can find it here:
> http://www.penza-gsm.ru/snake/use_CVSROOT_users.patch
>
> Though git-cvsimport-script not works as good as I wanted. It confuses with cvsps output like
> Author: Alexey Nezhdanov <snakeru at users.sourceforge.net>
> and converts it to something like
> Alexey Nezhdanov snakeru at users.sourceforge.net <Alexey Nezhdanov snakeru at users.sourceforge.net>
>
> Unfortunately I do not know perl so I can not write a patch for git-cvsimport-script.
> So I asking you, Matthias, to help with this or may somebody on this list can do it instead.
>
Cool. I'll definitely take a look. Thanks for taking the time.
David
^ permalink raw reply
* Re: [PATCH] Support SPARSE in Makefile, better SPARSE_FLAGS
From: Pavel Roskin @ 2005-09-30 13:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vek779kg0.fsf@assigned-by-dhcp.cox.net>
On Thu, 2005-09-29 at 22:46 -0700, Junio C Hamano wrote:
> Pavel Roskin <proski@gnu.org> writes:
>
> > +# explicitly what architecture to check for.
> > +SPARSE = sparse
> > +SPARSE_FLAGS = -D__$(shell uname -i)__
>
> : siamese; uname --version
> uname (coreutils) 5.2.1
> Written by David MacKenzie.
Apparently my uname 5.2.1 was heavily patched by Fedora. Note that
"uname -m" is not good enough, as it would give us i686 when i386 is
really needed.
> Copyright (C) 2004 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.
> There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A
> PARTICULAR PURPOSE.
> : siamese; uname -i
> Try `uname --help' for more information.
>
> Better alternatives?
I hate to say that, but a better alternative is to fix sparse to act
like the native compiler by default (possibly with options to imitate
other architectures or to be fully arch-neutral).
I have some hacks in mind, but I don't really like them:
Not good for i686 with unpatched uname:
SPARSE_FLAGS = __$(shell uname -i 2>/dev/null || uname -m)__
gcc specific:
SPARSE_FLAGS = __$(shell $CC -dumpmachine | sed 's/-.*//')__
bash specific:
SPARSE_FLAGS = __$(shell echo $$HOSTTYPE)__
In any case, having SPARSE variable would be convenient.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [howto] Kernel hacker's guide to git, updated
From: Johannes Schindelin @ 2005-09-30 12:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Anton Altaparmakov, git
In-Reply-To: <7vek77ea2s.fsf@assigned-by-dhcp.cox.net>
Hi,
On Thu, 29 Sep 2005, Junio C Hamano wrote:
> Anton Altaparmakov <aia21@cam.ac.uk> writes:
>
> > On Thu, 29 Sep 2005, Linus Torvalds wrote:
> >> On Thu, 29 Sep 2005, Dave Jones wrote:
> >> > What I find amusing is that it was a patch rejection mail from you
> >> > *years* back (circa 2000 iirc), telling me my pine corrupted whitespace,
> >> > that made me switch MUA ;-)
> >> >
> >> > All these years later, and it's still buggered ?
> >>
> >> Actually, it seems better. It seems to be buggered by default, but it used
> >> to be that you had to actually recompile pine to make it behave. Now you
> >> can just disable "strip-whitespace-before-send" and _enable_
> >> "quell-flowed-text" and those together seem to do the trick. No extra
> >> patches or recompiles necessary.
> >
> > Indeed. I use those two options like that, too. (-:
>
> Anybody interested in adding entry to SubmittingPatches MUA
> Specific Help section?
Did I miss something? Straight from my local git directory:
-- snip --
Pine
----
(Johannes Schindelin)
I don't know how many people still use pine, but for those poor
souls it may be good to mention that the quell-flowed-text is
needed for recent versions.
... the "no-strip-whitespace-before-send" option, too. AFAIK it
was introduced in 4.60.
-- snap --
Hth,
Dscho
^ permalink raw reply
* Re: [PATCH] fetch-pack should not ask for a ref which is already there
From: Johannes Schindelin @ 2005-09-30 12:20 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0509291403050.5362@g5.osdl.org>
Hi,
On Thu, 29 Sep 2005, Linus Torvalds wrote:
> On Thu, 29 Sep 2005, Johannes Schindelin wrote:
> >
> > Wouldn't it make much more sense to add a flag which repairs an
> > incomplete fetch?
>
> No.
>
> We've seen crap. We've _seen_ people use the old git-ssh-pull etc that
> would result in incomplete repositories, and having people use the
> "--recover" flag.
>
> THAT KIND OF CRAP IS UNACCEPTABLE! I had to walk Andrew through a broken
> repository because he had used those unreliable fetch methods. I was
> ashamed of git at that point.
>
> If a ^C results in a repository that needs to be fixed up, the "source
> control management" is BROKEN. It's not source control, it's a buggy
> mess.
Okay, fair enough, I had that coming. But how about the opposite? A flag,
that says "I want to take the fast path, and if I fsck up, it is my fault
alone", just like "-f" to git-checkout?
Ciao,
Dscho
^ permalink raw reply
* Re: [howto] Kernel hacker's guide to git, updated
From: Erik Mouw @ 2005-09-30 12:07 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Linux Kernel, Junio C Hamano, git
In-Reply-To: <433D1E5D.20303@pobox.com>
On Fri, Sep 30, 2005 at 07:15:41AM -0400, Jeff Garzik wrote:
> >automatically. Running the following one-liner every once in a
> >while would sync your set of tags with Linus:
> >
> >git fetch origin `git-ls-remote --tags origin | sed -ne
> >'s|^.*refs/tags/|tag |p'`
>
> that's way too long and convoluted to deal with. Once the 'git fetch
> --tags' changes make it into the official repository (are they there
> already?), I'll remove all the remaining direct references to running rsync.
FYI, the rsync command to get the tags blows away .git/branches/origin,
so on the next "git pull", git will tell you "Where do you want to
fetch from today?".
In the mean time, better make it two separate rsync commands (sorry for
the long lines):
rsync -a --delete --verbose --stats --progress \
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/tags/ \
.git/tags/
rsync -a --delete --verbose --stats --progress \
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/heads/ \
.git/heads/
Erik
--
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands
^ 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