* Re: Patch calculus
From: Jakub Narebski @ 2006-04-02 16:30 UTC (permalink / raw)
To: git
In-Reply-To: <20060402161121.GB18864@fieldses.org>
J. Bruce Fields wrote:
> What are the benefits of patch calculus? (What is it? The only
> explanation I've seen is at
> http://abridgegame.org/darcs/manual/node8.html,
> but I don't find it very helpful.)
See also http://www.darcs.net/DarcsWiki/PatchTheory
particularly http://www.darcs.net/DarcsWiki/WhyYouWantPatchTheory
P.S. I'm not a Darcs advocate.
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: Patch calculus
From: Jakub Narebski @ 2006-04-02 17:03 UTC (permalink / raw)
To: git
In-Reply-To: <e0ou7b$moa$1@sea.gmane.org>
J. Bruce Fields wrote:
> What are the benefits of patch calculus? (What is it? The only
> explanation I've seen is at
> http://abridgegame.org/darcs/manual/node8.html,
> but I don't find it very helpful.)
See also http://www.darcs.net/DarcsWiki/PatchTheory
particularly http://www.darcs.net/DarcsWiki/WhyYouWantPatchTheory
and http://en.wikibooks.org/wiki/Understanding_darcs
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: [RFH] xdiff shows trivially redundant diff.
From: Davide Libenzi @ 2006-04-02 17:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Linus Torvalds
In-Reply-To: <7v4q1cmj7l.fsf@assigned-by-dhcp.cox.net>
On Sun, 2 Apr 2006, Junio C Hamano wrote:
> $ git diff-tree -p 52e8a6^2 52d8a6 -- git-fetch.sh
>
> shows a change that trivially is redundant, like this:
>
> diff --git a/git-fetch.sh b/git-fetch.sh
> index b4325d9..de4f011 100755
> --- a/git-fetch.sh
> +++ b/git-fetch.sh
> @@ -320,7 +320,7 @@ fetch_main () {
> ( : subshell because we muck with IFS
> IFS=" $LF"
> (
> - git-fetch-pack $exec $keep "$remo...
> + git-fetch-pack $exec $keep --thin...
> ) |
> while read sha1 remote_name
> do
> @@ -367,21 +367,26 @@ fetch_main "$reflist"
>
> # automated tag following
> case "$no_tags$tags" in
> -'')
> - taglist=$(IFS=" " &&
> - git-ls-remote $upload_pack --tags "$remote" |
> ...
> - done)
> +'')
> + case "$reflist" in
> + *:refs/*)
> ...
>
> Notice the first '-' and '+' lines of second hunk are identical?
>
> There is another interesting thing. This is running diff
> between 52e8a6^2 and 52d8a6 blobs, but if I change them slightly
> so that the first hunk is not different, then this anomaly
> disappears.
Could you send me the two files that creates the above diff?
- Davide
^ permalink raw reply
* git-svn and svn sw --relocate
From: Nicolas Vilz 'niv' @ 2006-04-02 18:04 UTC (permalink / raw)
To: git
ok, guys... next question:
i have now my repository locally and i want to get it remotely on a
server, in order to have a few collaborators...
the steps on the svn-side are clear. But what do i have todo on the
git-svn-side of this life?
does a simple "svn sw --relocate" do the job in the git-svn meta-dir?
Sincerly
Nicolas
^ permalink raw reply
* Re: Solaris cloning woes partly diagnosed
From: Linus Torvalds @ 2006-04-02 18:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy7yol0nk.fsf@assigned-by-dhcp.cox.net>
On Sun, 2 Apr 2006, Junio C Hamano wrote:
>
> We do two funky things when we have progress bar. We play games
> with timer signal (setitimer(ITIMER_REAL) and signal(SIGALRM)),
> and we spit out messages to stderr.
I'd be willing to bet that it's the fact that we take signals.
Suddenly, some system calls will either return -1/EINTR, or they'll return
partial reads or writes.
We should be pretty good at handling that, but maybe some place forgets.
One thing to do might be to make the itimer use a much higher frequency,
to trigger the problem more easily.
We do, for example, expect that regular file writing not do that. At least
"write_sha1_from_fd()" will just do a "write()" without testing the error
return, which is bad (it would silently create a truncated object if the
/tmp filesystem filled up). If somebody has their filesystem over NFS
mounted interruptible, partial writes could also happen.
Ho humm.
Linus
^ permalink raw reply
* Re: [PATCH] Provide configurable UI font for gitk
From: Keith Packard @ 2006-04-02 19:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: keithp, git, Paul Mackerras
In-Reply-To: <7vodzkkzxr.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 191 bytes --]
On Sun, 2006-04-02 at 03:57 -0700, Junio C Hamano wrote:
> Your MUA seems to be line-wrapping the patch here and there...
Sigh. I'll resend it to Paul.
--
keith.packard@intel.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: Solaris cloning woes partly diagnosed
From: Jason Riedy @ 2006-04-02 19:10 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0604021118210.3050@g5.osdl.org>
And Linus Torvalds writes:
-
- I'd be willing to bet that it's the fact that we take signals.
Unfortunately, I'm too busy to check into this, but I've
run into similar problems in the past. Just takes a busy
file server.
- We do, for example, expect that regular file writing not do that. At least
- "write_sha1_from_fd()" will just do a "write()" without testing the error
- return, [...]
There is an xwrite in git-compat-util.h...
Jason
^ permalink raw reply
* Re: Solaris cloning woes partly diagnosed
From: Linus Torvalds @ 2006-04-02 19:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0604021118210.3050@g5.osdl.org>
On Sun, 2 Apr 2006, Linus Torvalds wrote:
>
> Suddenly, some system calls will either return -1/EINTR, or they'll return
> partial reads or writes.
Hmm. If I read the IRC logs right, the bad pack is still a _valid_ pack,
and passes git-verify-pack with flying colors.
That certainly implies that we had no problems with write-out: not only
must the SHA1 of the resulting file match itself, but it must match the
index too, and the number of objects there must match the index.
So the only way I see the pack being bad (if it does indeed pass
git-verify-pack) is if the object list we generated was bad.
However, "-q" only affects git-pack-file itself, not the generation of the
list. Which would imply that we have trouble _reading_ the list as it
comes in through a pipe. Which is just insane, because we use just a
bog-standard "fgets(... stdin)" for that. And no _way_ can stdio have
problems with a few SIGALRM's, that would break a lot of other problems.
But Oeje1 seems to be saying (in http://pastebin.com/635566):
git rev-list --objects --all | git pack-objects pack
Generating pack...
Done counting 15 objects.
Deltifying 15 objects.
100% (15/15) done
Writing 15 objects.
100% (15/15) done
806439fdfa5e9990b03f9301bd68e243795fff50
where the result _should_ be 16385 objects, not 15.
And the thing is, the _only_ thing we do there is that
while (fgets(line, sizeof(line), stdin) != NULL) {
...
add_object_entry(sha1, name_hash(NULL, line+41), 0);
so it really really looks like fgets() would have problems with a SIGALRM
coming in and doesn't just re-try on EINTR. Can Solaris stdio _really_ be
that broken? (Yeah, yeah, it may be "conforming". It's also so incredibly
programmer-unfriendly that it's not even funny)
That would be truly insane. Can somebody with Solaris check what the
following patch results in...
Linus
----
diff --git a/pack-objects.c b/pack-objects.c
index ccfaa5f..daba5de 100644
--- a/pack-objects.c
+++ b/pack-objects.c
@@ -1099,8 +1099,18 @@ int main(int argc, char **argv)
fprintf(stderr, "Generating pack...\n");
}
- while (fgets(line, sizeof(line), stdin) != NULL) {
+ for (;;) {
unsigned char sha1[20];
+
+ if (!fgets(line, sizeof(line), stdin)) {
+ if (feof(stdin))
+ break;
+ if (!ferror(stdin))
+ die("fgets returned NULL, not EOF, not error!");
+ if (errno == EINTR)
+ continue;
+ die("fgets: %s", strerror(errno));
+ }
if (line[0] == '-') {
if (get_sha1_hex(line+1, sha1))
^ permalink raw reply related
* Re: Solaris cloning woes partly diagnosed
From: Linus Torvalds @ 2006-04-02 19:22 UTC (permalink / raw)
To: Jason Riedy; +Cc: git
In-Reply-To: <29336.1144005022@lotus.CS.Berkeley.EDU>
On Sun, 2 Apr 2006, Jason Riedy wrote:
> And Linus Torvalds writes:
> -
> - I'd be willing to bet that it's the fact that we take signals.
>
> Unfortunately, I'm too busy to check into this, but I've
> run into similar problems in the past. Just takes a busy
> file server.
>
> - We do, for example, expect that regular file writing not do that. At least
> - "write_sha1_from_fd()" will just do a "write()" without testing the error
> - return, [...]
>
> There is an xwrite in git-compat-util.h...
Well, git itself is actually fairly good about these things. Right now I'm
seriously suspecting Solaris stdio as being just horribly impolite.
git tends to not just use xwrite() in most places, but check the return
value for partial sizes etc. I tried to grep for places where we were
lazy, and there really seems to be just a very small handful, and they
shouldn't impact this case at all (you have to have a seriously broken
setup for them to matter, but we should fix them nonetheless.
Linus
^ permalink raw reply
* Re: parsecvs tool now creates git repositories
From: Jan-Benedict Glaw @ 2006-04-02 19:31 UTC (permalink / raw)
To: Keith Packard; +Cc: Git Mailing List
In-Reply-To: <20060402093906.GH1259@lug-owl.de>
[-- Attachment #1: Type: text/plain, Size: 2751 bytes --]
On Sun, 2006-04-02 11:39:06 +0200, Jan-Benedict Glaw <jbglaw@lug-owl.de> wrote:
> On Sat, 2006-04-01 21:36:28 -0800, Keith Packard <keithp@keithp.com> wrote:
> > The UI is a total disaster, sufficient for testing. You must create an
> > Authors file in the current directory which looks like the git-cvsimport
> > authors file. You must also have a edit-change-log program in your path
> > which edits the commit message in place. /bin/true will work if you
> > don't need to edit the messages.
>
> Well, at least this sounds quite promising. I'll give it a run once
> I've arrived back home on the Binutils repository.
Doesn't build for me:
jbglaw@bixie:~/vax/gittish/parsecvs$ make clean
rm -f gram.o lex.o parsecvs.o cvsutil.o revlist.o atom.o revcvs.o git.o y.tab.h gram.c parsecvs
jbglaw@bixie:~/vax/gittish/parsecvs$ make
yacc -d gram.y
mv -f y.tab.c gram.c
cc -O0 -g -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -c -o gram.o gram.c
cc -O0 -g -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -c -o lex.o lex.c
lex.l: In function ‘yylex’:
lex.l:69: warning: implicit declaration of function ‘yyget_lineno’
lex.l:69: warning: nested extern declaration of ‘yyget_lineno’
<stdout>: At top level:
<stdout>:1747: warning: no previous prototype for ‘yyget_lineno’
<stdout>:1756: warning: no previous prototype for ‘yyget_in’
<stdout>:1764: warning: no previous prototype for ‘yyget_out’
<stdout>:1772: warning: no previous prototype for ‘yyget_leng’
<stdout>:1781: warning: no previous prototype for ‘yyget_text’
<stdout>:1790: warning: no previous prototype for ‘yyset_lineno’
<stdout>:1802: warning: no previous prototype for ‘yyset_in’
<stdout>:1807: warning: no previous prototype for ‘yyset_out’
<stdout>:1812: warning: no previous prototype for ‘yyget_debug’
<stdout>:1817: warning: no previous prototype for ‘yyset_debug’
<stdout>:1823: warning: no previous prototype for ‘yylex_destroy’
lex.l: In function ‘parse_data’:
lex.l:90: error: ‘yytext_ptr’ undeclared (first use in this function)
lex.l:90: error: (Each undeclared identifier is reported only once
lex.l:90: error: for each function it appears in.)
make: *** [lex.o] Error 1
MfG, JBG
--
Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
für einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Solaris cloning woes partly diagnosed
From: Jason Riedy @ 2006-04-02 19:52 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0604021159110.3050@g5.osdl.org>
And Linus Torvalds writes:
-
- so it really really looks like fgets() would have problems with a SIGALRM
- coming in and doesn't just re-try on EINTR. Can Solaris stdio _really_ be
- that broken? (Yeah, yeah, it may be "conforming". It's also so incredibly
- programmer-unfriendly that it's not even funny)
Yes, it is that broken. I haven't encountered the problem
consistently in git myself, so I can't tell you if the patch
works. Google finds similar reports and patches for BOINC, ruby,
and a few other projects.
Solaris folks will say you should be using sigaction with
SA_RESTART. IIRC, SA_RESTART isn't guaranteed to be there
or work, but all the systems I deal with right now have it.
So an alternate patch for this one use is appended... Other
uses of signal could be changed to sigaction, too. And
progress_update "should" be sig_atomic_t.
Passes the pack-objects tests, but I can't make the problem
happen on demand. (I have seen it occur before, but never
during make test, and I'd not tracked it down...)
Jason
----
diff --git a/pack-objects.c b/pack-objects.c
index ccfaa5f..1faa0bb 100644
--- a/pack-objects.c
+++ b/pack-objects.c
@@ -877,10 +877,21 @@ static int try_delta(struct unpacked *cu
return 0;
}
-static void progress_interval(int signum)
+static void progress_interval(int);
+
+static void setup_progress_signal(void)
+{
+ struct sigaction sa;
+ sa.sa_handler = progress_interval;
+ sigemptyset(&sa.sa_mask);
+ sa.sa_flags = SA_RESTART;
+ sigaction(SIGALRM, &sa, NULL);
+}
+
+void progress_interval(int signum)
{
- signal(SIGALRM, progress_interval);
progress_update = 1;
+ setup_progress_signal();
}
static void find_deltas(struct object_entry **list, int window, int depth)
@@ -1094,7 +1105,7 @@ int main(int argc, char **argv)
v.it_interval.tv_sec = 1;
v.it_interval.tv_usec = 0;
v.it_value = v.it_interval;
- signal(SIGALRM, progress_interval);
+ setup_progress_signal();
setitimer(ITIMER_REAL, &v, NULL);
fprintf(stderr, "Generating pack...\n");
}
^ permalink raw reply related
* Re: Solaris cloning woes partly diagnosed
From: Linus Torvalds @ 2006-04-02 20:28 UTC (permalink / raw)
To: Jason Riedy; +Cc: git
In-Reply-To: <824.1144007555@lotus.CS.Berkeley.EDU>
On Sun, 2 Apr 2006, Jason Riedy wrote:
>
> Solaris folks will say you should be using sigaction with
> SA_RESTART. IIRC, SA_RESTART isn't guaranteed to be there
> or work, but all the systems I deal with right now have it.
I think we might as well do that _too_.
However, once you use "sigaction()", you don't need to re-arm the signal
handler any more, so I'd suggest a simpler patch like this instead..
Junio, I think this confirms/explains the Solaris breakage.
I'll re-send the "anal stdio semantics" version of the patch on top of
this in the next email.
Linus
----
Subject: Fix Solaris stdio signal handling stupidities
This uses sigaction() to install the SIGALRM handler with SA_RESTART, so
that Solaris stdio doesn't break completely when a signal interrupts a
read.
Thanks to Jason Riedy for confirming the silly Solaris signal behaviour.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
----
diff --git a/pack-objects.c b/pack-objects.c
index ccfaa5f..1817b58 100644
--- a/pack-objects.c
+++ b/pack-objects.c
@@ -58,7 +58,7 @@ static int nr_objects = 0, nr_alloc = 0,
static const char *base_name;
static unsigned char pack_file_sha1[20];
static int progress = 1;
-static volatile int progress_update = 0;
+static volatile sig_atomic_t progress_update = 0;
/*
* The object names in objects array are hashed with this hashtable,
@@ -879,7 +879,6 @@ static int try_delta(struct unpacked *cu
static void progress_interval(int signum)
{
- signal(SIGALRM, progress_interval);
progress_update = 1;
}
@@ -1025,6 +1024,23 @@ static int reuse_cached_pack(unsigned ch
return 1;
}
+static void setup_progress_signal(void)
+{
+ struct sigaction sa;
+ struct itimerval v;
+
+ memset(&sa, 0, sizeof(sa));
+ sa.sa_handler = progress_interval;
+ sigemptyset(&sa.sa_mask);
+ sa.sa_flags = SA_RESTART;
+ sigaction(SIGALRM, &sa, NULL);
+
+ v.it_interval.tv_sec = 1;
+ v.it_interval.tv_usec = 0;
+ v.it_value = v.it_interval;
+ setitimer(ITIMER_REAL, &v, NULL);
+}
+
int main(int argc, char **argv)
{
SHA_CTX ctx;
@@ -1090,13 +1106,8 @@ int main(int argc, char **argv)
prepare_packed_git();
if (progress) {
- struct itimerval v;
- v.it_interval.tv_sec = 1;
- v.it_interval.tv_usec = 0;
- v.it_value = v.it_interval;
- signal(SIGALRM, progress_interval);
- setitimer(ITIMER_REAL, &v, NULL);
fprintf(stderr, "Generating pack...\n");
+ setup_progress_signal();
}
while (fgets(line, sizeof(line), stdin) != NULL) {
^ permalink raw reply related
* [PATCH 2/2] pack-objects: be incredibly anal about stdio semantics
From: Linus Torvalds @ 2006-04-02 20:31 UTC (permalink / raw)
To: Jason Riedy, Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0604021312510.3050@g5.osdl.org>
This is the "letter of the law" version of using fgets() properly in the
face of incredibly broken stdio implementations. We can work around the
Solaris breakage with SA_RESTART, but in case anybody else is ever that
stupid, here's the "safe" (read: "insanely anal") way to use fgets.
It probably goes without saying that I'm not terribly impressed by
Solaris libc.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
This is the same one that I already sent out, but re-diffed, and with a
proper commit message.
Not tested on Solaris.
Junio - I think that I forgot to Cc: you on the 1/2 patch, but you'll see
it on the git list.
diff --git a/pack-objects.c b/pack-objects.c
index 1817b58..0ea16ad 100644
--- a/pack-objects.c
+++ b/pack-objects.c
@@ -1110,8 +1110,18 @@ int main(int argc, char **argv)
setup_progress_signal();
}
- while (fgets(line, sizeof(line), stdin) != NULL) {
+ for (;;) {
unsigned char sha1[20];
+
+ if (!fgets(line, sizeof(line), stdin)) {
+ if (feof(stdin))
+ break;
+ if (!ferror(stdin))
+ die("fgets returned NULL, not EOF, not error!");
+ if (errno == EINTR)
+ continue;
+ die("fgets: %s", strerror(errno));
+ }
if (line[0] == '-') {
if (get_sha1_hex(line+1, sha1))
^ permalink raw reply related
* Re: [RFH] xdiff shows trivially redundant diff.
From: Junio C Hamano @ 2006-04-02 21:02 UTC (permalink / raw)
To: Davide Libenzi; +Cc: git, Linus Torvalds
In-Reply-To: <Pine.LNX.4.64.0604021035130.30097@alien.or.mcafeemobile.com>
[-- Attachment #1: Type: text/plain, Size: 979 bytes --]
Davide Libenzi <davidel@xmailserver.org> writes:
> On Sun, 2 Apr 2006, Junio C Hamano wrote:
>
>> $ git diff-tree -p 52e8a6^2 52d8a6 -- git-fetch.sh
>>
>> shows a change that trivially is redundant, like this:
>>
>> diff --git a/git-fetch.sh b/git-fetch.sh
>> index b4325d9..de4f011 100755
>> --- a/git-fetch.sh
>> +++ b/git-fetch.sh
>> @@ -320,7 +320,7 @@ fetch_main () {
>>..
>> Notice the first '-' and '+' lines of second hunk are identical?
>>
>> There is another interesting thing. This is running diff
>> between 52e8a6^2 and 52d8a6 blobs, but if I change them slightly
>> so that the first hunk is not different, then this anomaly
>> disappears.
>
> Could you send me the two files that creates the above diff?
I should have tried your pristine xdiff code myself before
bothering you, but I haven't (sorry).
The problem is from the "stripped down" version we use in git,
so you may or may not see the problem in your version. Attached
are the files.
[-- Attachment #2: diff test preimage --]
[-- Type: text/plain, Size: 9364 bytes --]
#!/bin/sh
#
USAGE='<fetch-options> <repository> <refspec>...'
. git-sh-setup
. git-parse-remote
_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"
LF='
'
IFS="$LF"
no_tags=
tags=
append=
force=
verbose=
update_head_ok=
exec=
upload_pack=
while case "$#" in 0) break ;; esac
do
case "$1" in
-a|--a|--ap|--app|--appe|--appen|--append)
append=t
;;
--upl|--uplo|--uploa|--upload|--upload-|--upload-p|\
--upload-pa|--upload-pac|--upload-pack)
shift
exec="--exec=$1"
upload_pack="-u $1"
;;
-f|--f|--fo|--for|--forc|--force)
force=t
;;
-t|--t|--ta|--tag|--tags)
tags=t
;;
-n|--n|--no|--no-|--no-t|--no-ta|--no-tag|--no-tags)
no_tags=t
;;
-u|--u|--up|--upd|--upda|--updat|--update|--update-|--update-h|\
--update-he|--update-hea|--update-head|--update-head-|\
--update-head-o|--update-head-ok)
update_head_ok=t
;;
-v|--verbose)
verbose=Yes
;;
-k|--k|--ke|--kee|--keep)
keep=--keep
;;
-*)
usage
;;
*)
break
;;
esac
shift
done
case "$#" in
0)
test -f "$GIT_DIR/branches/origin" ||
test -f "$GIT_DIR/remotes/origin" ||
die "Where do you want to fetch from today?"
set origin ;;
esac
remote_nick="$1"
remote=$(get_remote_url "$@")
refs=
rref=
rsync_slurped_objects=
if test "" = "$append"
then
: >"$GIT_DIR/FETCH_HEAD"
fi
append_fetch_head () {
head_="$1"
remote_="$2"
remote_name_="$3"
remote_nick_="$4"
local_name_="$5"
case "$6" in
t) not_for_merge_='not-for-merge' ;;
'') not_for_merge_= ;;
esac
# remote-nick is the URL given on the command line (or a shorthand)
# remote-name is the $GIT_DIR relative refs/ path we computed
# for this refspec.
case "$remote_name_" in
HEAD)
note_= ;;
refs/heads/*)
note_="$(expr "$remote_name_" : 'refs/heads/\(.*\)')"
note_="branch '$note_' of " ;;
refs/tags/*)
note_="$(expr "$remote_name_" : 'refs/tags/\(.*\)')"
note_="tag '$note_' of " ;;
*)
note_="$remote_name of " ;;
esac
remote_1_=$(expr "$remote_" : '\(.*\)\.git/*$') &&
remote_="$remote_1_"
note_="$note_$remote_"
# 2.6.11-tree tag would not be happy to be fed to resolve.
if git-cat-file commit "$head_" >/dev/null 2>&1
then
headc_=$(git-rev-parse --verify "$head_^0") || exit
echo "$headc_ $not_for_merge_ $note_" >>"$GIT_DIR/FETCH_HEAD"
[ "$verbose" ] && echo >&2 "* committish: $head_"
[ "$verbose" ] && echo >&2 " $note_"
else
echo "$head_ not-for-merge $note_" >>"$GIT_DIR/FETCH_HEAD"
[ "$verbose" ] && echo >&2 "* non-commit: $head_"
[ "$verbose" ] && echo >&2 " $note_"
fi
if test "$local_name_" != ""
then
# We are storing the head locally. Make sure that it is
# a fast forward (aka "reverse push").
fast_forward_local "$local_name_" "$head_" "$note_"
fi
}
fast_forward_local () {
mkdir -p "$(dirname "$GIT_DIR/$1")"
case "$1" in
refs/tags/*)
# Tags need not be pointing at commits so there
# is no way to guarantee "fast-forward" anyway.
if test -f "$GIT_DIR/$1"
then
if now_=$(cat "$GIT_DIR/$1") && test "$now_" = "$2"
then
[ "$verbose" ] && echo >&2 "* $1: same as $3"
else
echo >&2 "* $1: updating with $3"
fi
else
echo >&2 "* $1: storing $3"
fi
git-update-ref "$1" "$2"
;;
refs/heads/*)
# $1 is the ref being updated.
# $2 is the new value for the ref.
local=$(git-rev-parse --verify "$1^0" 2>/dev/null)
if test "$local"
then
# Require fast-forward.
mb=$(git-merge-base "$local" "$2") &&
case "$2,$mb" in
$local,*)
echo >&2 "* $1: same as $3"
;;
*,$local)
echo >&2 "* $1: fast forward to $3"
git-update-ref "$1" "$2" "$local"
;;
*)
false
;;
esac || {
echo >&2 "* $1: does not fast forward to $3;"
case ",$force,$single_force," in
*,t,*)
echo >&2 " forcing update."
git-update-ref "$1" "$2" "$local"
;;
*)
echo >&2 " not updating."
;;
esac
}
else
echo >&2 "* $1: storing $3"
git-update-ref "$1" "$2"
fi
;;
esac
}
case "$update_head_ok" in
'')
orig_head=$(git-rev-parse --verify HEAD 2>/dev/null)
;;
esac
# If --tags (and later --heads or --all) is specified, then we are
# not talking about defaults stored in Pull: line of remotes or
# branches file, and just fetch those and refspecs explicitly given.
# Otherwise we do what we always did.
reflist=$(get_remote_refs_for_fetch "$@")
if test "$tags"
then
taglist=$(IFS=" " &&
git-ls-remote $upload_pack --tags "$remote" |
while read sha1 name
do
case "$name" in
(*^*) continue ;;
esac
if git-check-ref-format "$name"
then
echo ".${name}:${name}"
else
echo >&2 "warning: tag ${name} ignored"
fi
done)
if test "$#" -gt 1
then
# remote URL plus explicit refspecs; we need to merge them.
reflist="$reflist$LF$taglist"
else
# No explicit refspecs; fetch tags only.
reflist=$taglist
fi
fi
fetch_main () {
reflist="$1"
refs=
for ref in $reflist
do
refs="$refs$LF$ref"
# These are relative path from $GIT_DIR, typically starting at refs/
# but may be HEAD
if expr "$ref" : '\.' >/dev/null
then
not_for_merge=t
ref=$(expr "$ref" : '\.\(.*\)')
else
not_for_merge=
fi
if expr "$ref" : '\+' >/dev/null
then
single_force=t
ref=$(expr "$ref" : '\+\(.*\)')
else
single_force=
fi
remote_name=$(expr "$ref" : '\([^:]*\):')
local_name=$(expr "$ref" : '[^:]*:\(.*\)')
rref="$rref$LF$remote_name"
# There are transports that can fetch only one head at a time...
case "$remote" in
http://* | https://*)
if [ -n "$GIT_SSL_NO_VERIFY" ]; then
curl_extra_args="-k"
fi
remote_name_quoted=$(perl -e '
my $u = $ARGV[0];
$u =~ s{([^-a-zA-Z0-9/.])}{sprintf"%%%02x",ord($1)}eg;
print "$u";
' "$remote_name")
head=$(curl -nsfL $curl_extra_args "$remote/$remote_name_quoted") &&
expr "$head" : "$_x40\$" >/dev/null ||
die "Failed to fetch $remote_name from $remote"
echo >&2 Fetching "$remote_name from $remote" using http
git-http-fetch -v -a "$head" "$remote/" || exit
;;
rsync://*)
TMP_HEAD="$GIT_DIR/TMP_HEAD"
rsync -L -q "$remote/$remote_name" "$TMP_HEAD" || exit 1
head=$(git-rev-parse --verify TMP_HEAD)
rm -f "$TMP_HEAD"
test "$rsync_slurped_objects" || {
rsync -av --ignore-existing --exclude info \
"$remote/objects/" "$GIT_OBJECT_DIRECTORY/" || exit
# Look at objects/info/alternates for rsync -- http will
# support it natively and git native ones will do it on
# the remote end. Not having that file is not a crime.
rsync -q "$remote/objects/info/alternates" \
"$GIT_DIR/TMP_ALT" 2>/dev/null ||
rm -f "$GIT_DIR/TMP_ALT"
if test -f "$GIT_DIR/TMP_ALT"
then
resolve_alternates "$remote" <"$GIT_DIR/TMP_ALT" |
while read alt
do
case "$alt" in 'bad alternate: '*) die "$alt";; esac
echo >&2 "Getting alternate: $alt"
rsync -av --ignore-existing --exclude info \
"$alt" "$GIT_OBJECT_DIRECTORY/" || exit
done
rm -f "$GIT_DIR/TMP_ALT"
fi
rsync_slurped_objects=t
}
;;
*)
# We will do git native transport with just one call later.
continue ;;
esac
append_fetch_head "$head" "$remote" \
"$remote_name" "$remote_nick" "$local_name" "$not_for_merge"
done
case "$remote" in
http://* | https://* | rsync://* )
;; # we are already done.
*)
( : subshell because we muck with IFS
IFS=" $LF"
(
git-fetch-pack $exec $keep "$remote" $rref || echo failed "$remote"
) |
while read sha1 remote_name
do
case "$sha1" in
failed)
echo >&2 "Fetch failure: $remote"
exit 1 ;;
esac
found=
single_force=
for ref in $refs
do
case "$ref" in
+$remote_name:*)
single_force=t
not_for_merge=
found="$ref"
break ;;
.+$remote_name:*)
single_force=t
not_for_merge=t
found="$ref"
break ;;
.$remote_name:*)
not_for_merge=t
found="$ref"
break ;;
$remote_name:*)
not_for_merge=
found="$ref"
break ;;
esac
done
local_name=$(expr "$found" : '[^:]*:\(.*\)')
append_fetch_head "$sha1" "$remote" \
"$remote_name" "$remote_nick" "$local_name" "$not_for_merge"
done
) || exit ;;
esac
}
fetch_main "$reflist"
# automated tag following
case "$no_tags$tags" in
'')
taglist=$(IFS=" " &&
git-ls-remote $upload_pack --tags "$remote" |
sed -ne 's|^\([0-9a-f]*\)[ ]\(refs/tags/.*\)^{}$|\1 \2|p' |
while read sha1 name
do
test -f "$GIT_DIR/$name" && continue
git-check-ref-format "$name" || {
echo >&2 "warning: tag ${name} ignored"
continue
}
git-cat-file -t "$sha1" >/dev/null 2>&1 || continue
echo >&2 "Auto-following $name"
echo ".${name}:${name}"
done)
case "$taglist" in
'') ;;
?*)
fetch_main "$taglist" ;;
esac
esac
# If the original head was empty (i.e. no "master" yet), or
# if we were told not to worry, we do not have to check.
case ",$update_head_ok,$orig_head," in
*,, | t,* )
;;
*)
curr_head=$(git-rev-parse --verify HEAD 2>/dev/null)
if test "$curr_head" != "$orig_head"
then
git-update-ref HEAD "$orig_head"
die "Cannot fetch into the current branch."
fi
;;
esac
[-- Attachment #3: diff test postimage --]
[-- Type: text/plain, Size: 9508 bytes --]
#!/bin/sh
#
USAGE='<fetch-options> <repository> <refspec>...'
. git-sh-setup
. git-parse-remote
_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"
LF='
'
IFS="$LF"
no_tags=
tags=
append=
force=
verbose=
update_head_ok=
exec=
upload_pack=
while case "$#" in 0) break ;; esac
do
case "$1" in
-a|--a|--ap|--app|--appe|--appen|--append)
append=t
;;
--upl|--uplo|--uploa|--upload|--upload-|--upload-p|\
--upload-pa|--upload-pac|--upload-pack)
shift
exec="--exec=$1"
upload_pack="-u $1"
;;
-f|--f|--fo|--for|--forc|--force)
force=t
;;
-t|--t|--ta|--tag|--tags)
tags=t
;;
-n|--n|--no|--no-|--no-t|--no-ta|--no-tag|--no-tags)
no_tags=t
;;
-u|--u|--up|--upd|--upda|--updat|--update|--update-|--update-h|\
--update-he|--update-hea|--update-head|--update-head-|\
--update-head-o|--update-head-ok)
update_head_ok=t
;;
-v|--verbose)
verbose=Yes
;;
-k|--k|--ke|--kee|--keep)
keep=--keep
;;
-*)
usage
;;
*)
break
;;
esac
shift
done
case "$#" in
0)
test -f "$GIT_DIR/branches/origin" ||
test -f "$GIT_DIR/remotes/origin" ||
die "Where do you want to fetch from today?"
set origin ;;
esac
remote_nick="$1"
remote=$(get_remote_url "$@")
refs=
rref=
rsync_slurped_objects=
if test "" = "$append"
then
: >"$GIT_DIR/FETCH_HEAD"
fi
append_fetch_head () {
head_="$1"
remote_="$2"
remote_name_="$3"
remote_nick_="$4"
local_name_="$5"
case "$6" in
t) not_for_merge_='not-for-merge' ;;
'') not_for_merge_= ;;
esac
# remote-nick is the URL given on the command line (or a shorthand)
# remote-name is the $GIT_DIR relative refs/ path we computed
# for this refspec.
case "$remote_name_" in
HEAD)
note_= ;;
refs/heads/*)
note_="$(expr "$remote_name_" : 'refs/heads/\(.*\)')"
note_="branch '$note_' of " ;;
refs/tags/*)
note_="$(expr "$remote_name_" : 'refs/tags/\(.*\)')"
note_="tag '$note_' of " ;;
*)
note_="$remote_name of " ;;
esac
remote_1_=$(expr "$remote_" : '\(.*\)\.git/*$') &&
remote_="$remote_1_"
note_="$note_$remote_"
# 2.6.11-tree tag would not be happy to be fed to resolve.
if git-cat-file commit "$head_" >/dev/null 2>&1
then
headc_=$(git-rev-parse --verify "$head_^0") || exit
echo "$headc_ $not_for_merge_ $note_" >>"$GIT_DIR/FETCH_HEAD"
[ "$verbose" ] && echo >&2 "* committish: $head_"
[ "$verbose" ] && echo >&2 " $note_"
else
echo "$head_ not-for-merge $note_" >>"$GIT_DIR/FETCH_HEAD"
[ "$verbose" ] && echo >&2 "* non-commit: $head_"
[ "$verbose" ] && echo >&2 " $note_"
fi
if test "$local_name_" != ""
then
# We are storing the head locally. Make sure that it is
# a fast forward (aka "reverse push").
fast_forward_local "$local_name_" "$head_" "$note_"
fi
}
fast_forward_local () {
mkdir -p "$(dirname "$GIT_DIR/$1")"
case "$1" in
refs/tags/*)
# Tags need not be pointing at commits so there
# is no way to guarantee "fast-forward" anyway.
if test -f "$GIT_DIR/$1"
then
if now_=$(cat "$GIT_DIR/$1") && test "$now_" = "$2"
then
[ "$verbose" ] && echo >&2 "* $1: same as $3"
else
echo >&2 "* $1: updating with $3"
fi
else
echo >&2 "* $1: storing $3"
fi
git-update-ref "$1" "$2"
;;
refs/heads/*)
# $1 is the ref being updated.
# $2 is the new value for the ref.
local=$(git-rev-parse --verify "$1^0" 2>/dev/null)
if test "$local"
then
# Require fast-forward.
mb=$(git-merge-base "$local" "$2") &&
case "$2,$mb" in
$local,*)
echo >&2 "* $1: same as $3"
;;
*,$local)
echo >&2 "* $1: fast forward to $3"
git-update-ref "$1" "$2" "$local"
;;
*)
false
;;
esac || {
echo >&2 "* $1: does not fast forward to $3;"
case ",$force,$single_force," in
*,t,*)
echo >&2 " forcing update."
git-update-ref "$1" "$2" "$local"
;;
*)
echo >&2 " not updating."
;;
esac
}
else
echo >&2 "* $1: storing $3"
git-update-ref "$1" "$2"
fi
;;
esac
}
case "$update_head_ok" in
'')
orig_head=$(git-rev-parse --verify HEAD 2>/dev/null)
;;
esac
# If --tags (and later --heads or --all) is specified, then we are
# not talking about defaults stored in Pull: line of remotes or
# branches file, and just fetch those and refspecs explicitly given.
# Otherwise we do what we always did.
reflist=$(get_remote_refs_for_fetch "$@")
if test "$tags"
then
taglist=$(IFS=" " &&
git-ls-remote $upload_pack --tags "$remote" |
while read sha1 name
do
case "$name" in
(*^*) continue ;;
esac
if git-check-ref-format "$name"
then
echo ".${name}:${name}"
else
echo >&2 "warning: tag ${name} ignored"
fi
done)
if test "$#" -gt 1
then
# remote URL plus explicit refspecs; we need to merge them.
reflist="$reflist$LF$taglist"
else
# No explicit refspecs; fetch tags only.
reflist=$taglist
fi
fi
fetch_main () {
reflist="$1"
refs=
for ref in $reflist
do
refs="$refs$LF$ref"
# These are relative path from $GIT_DIR, typically starting at refs/
# but may be HEAD
if expr "$ref" : '\.' >/dev/null
then
not_for_merge=t
ref=$(expr "$ref" : '\.\(.*\)')
else
not_for_merge=
fi
if expr "$ref" : '\+' >/dev/null
then
single_force=t
ref=$(expr "$ref" : '\+\(.*\)')
else
single_force=
fi
remote_name=$(expr "$ref" : '\([^:]*\):')
local_name=$(expr "$ref" : '[^:]*:\(.*\)')
rref="$rref$LF$remote_name"
# There are transports that can fetch only one head at a time...
case "$remote" in
http://* | https://*)
if [ -n "$GIT_SSL_NO_VERIFY" ]; then
curl_extra_args="-k"
fi
remote_name_quoted=$(perl -e '
my $u = $ARGV[0];
$u =~ s{([^-a-zA-Z0-9/.])}{sprintf"%%%02x",ord($1)}eg;
print "$u";
' "$remote_name")
head=$(curl -nsfL $curl_extra_args "$remote/$remote_name_quoted") &&
expr "$head" : "$_x40\$" >/dev/null ||
die "Failed to fetch $remote_name from $remote"
echo >&2 Fetching "$remote_name from $remote" using http
git-http-fetch -v -a "$head" "$remote/" || exit
;;
rsync://*)
TMP_HEAD="$GIT_DIR/TMP_HEAD"
rsync -L -q "$remote/$remote_name" "$TMP_HEAD" || exit 1
head=$(git-rev-parse --verify TMP_HEAD)
rm -f "$TMP_HEAD"
test "$rsync_slurped_objects" || {
rsync -av --ignore-existing --exclude info \
"$remote/objects/" "$GIT_OBJECT_DIRECTORY/" || exit
# Look at objects/info/alternates for rsync -- http will
# support it natively and git native ones will do it on
# the remote end. Not having that file is not a crime.
rsync -q "$remote/objects/info/alternates" \
"$GIT_DIR/TMP_ALT" 2>/dev/null ||
rm -f "$GIT_DIR/TMP_ALT"
if test -f "$GIT_DIR/TMP_ALT"
then
resolve_alternates "$remote" <"$GIT_DIR/TMP_ALT" |
while read alt
do
case "$alt" in 'bad alternate: '*) die "$alt";; esac
echo >&2 "Getting alternate: $alt"
rsync -av --ignore-existing --exclude info \
"$alt" "$GIT_OBJECT_DIRECTORY/" || exit
done
rm -f "$GIT_DIR/TMP_ALT"
fi
rsync_slurped_objects=t
}
;;
*)
# We will do git native transport with just one call later.
continue ;;
esac
append_fetch_head "$head" "$remote" \
"$remote_name" "$remote_nick" "$local_name" "$not_for_merge"
done
case "$remote" in
http://* | https://* | rsync://* )
;; # we are already done.
*)
( : subshell because we muck with IFS
IFS=" $LF"
(
git-fetch-pack $exec $keep --thin "$remote" $rref || echo failed "$remote"
) |
while read sha1 remote_name
do
case "$sha1" in
failed)
echo >&2 "Fetch failure: $remote"
exit 1 ;;
esac
found=
single_force=
for ref in $refs
do
case "$ref" in
+$remote_name:*)
single_force=t
not_for_merge=
found="$ref"
break ;;
.+$remote_name:*)
single_force=t
not_for_merge=t
found="$ref"
break ;;
.$remote_name:*)
not_for_merge=t
found="$ref"
break ;;
$remote_name:*)
not_for_merge=
found="$ref"
break ;;
esac
done
local_name=$(expr "$found" : '[^:]*:\(.*\)')
append_fetch_head "$sha1" "$remote" \
"$remote_name" "$remote_nick" "$local_name" "$not_for_merge"
done
) || exit ;;
esac
}
fetch_main "$reflist"
# automated tag following
case "$no_tags$tags" in
'')
case "$reflist" in
*:refs/*)
# effective only when we are following remote branch
# using local tracking branch.
taglist=$(IFS=" " &&
git-ls-remote $upload_pack --tags "$remote" |
sed -ne 's|^\([0-9a-f]*\)[ ]\(refs/tags/.*\)^{}$|\1 \2|p' |
while read sha1 name
do
test -f "$GIT_DIR/$name" && continue
git-check-ref-format "$name" || {
echo >&2 "warning: tag ${name} ignored"
continue
}
git-cat-file -t "$sha1" >/dev/null 2>&1 || continue
echo >&2 "Auto-following $name"
echo ".${name}:${name}"
done)
esac
case "$taglist" in
'') ;;
?*)
fetch_main "$taglist" ;;
esac
esac
# If the original head was empty (i.e. no "master" yet), or
# if we were told not to worry, we do not have to check.
case ",$update_head_ok,$orig_head," in
*,, | t,* )
;;
*)
curr_head=$(git-rev-parse --verify HEAD 2>/dev/null)
if test "$curr_head" != "$orig_head"
then
git-update-ref HEAD "$orig_head"
die "Cannot fetch into the current branch."
fi
;;
esac
^ permalink raw reply
* Re: [PATCH 2/2] pack-objects: be incredibly anal about stdio semantics
From: Junio C Hamano @ 2006-04-02 21:09 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0604021328380.3050@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> This is the "letter of the law" version of using fgets() properly in the
> face of incredibly broken stdio implementations. We can work around the
> Solaris breakage with SA_RESTART, but in case anybody else is ever that
> stupid, here's the "safe" (read: "insanely anal") way to use fgets.
Thanks.
It's good that I can say "Oh, I think this is the part that is
broken, but I am going to bed" to find the problem solved by
capable others when I wake up the next day. Global distributed
development process at the finest, although I suspect Jason,
Linus and myself are all in the same timezone ;-)
Did you mean this as a real change or a demonstration? The
sigaction change is a real fix, but somehow I find this one
similar to the "(void*) NULL" thing you objected earlier (which
was not merged because I agreed with your argument)...
^ permalink raw reply
* Re: [RFH] xdiff shows trivially redundant diff.
From: Linus Torvalds @ 2006-04-02 21:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Davide Libenzi, git
In-Reply-To: <7vzmj3k7x9.fsf@assigned-by-dhcp.cox.net>
On Sun, 2 Apr 2006, Junio C Hamano wrote:
>
> I should have tried your pristine xdiff code myself before
> bothering you, but I haven't (sorry).
It definitely happens with plain libxdiff-0.17 too.
In general, unless it's related to the "\ No newline" or the extra stuff
on the "@@"-line, I'd be very surprised if we have any differences in the
diff output wrt libxdiff-0.17. I was really pretty careful, and didn't
change the code at all, just removed unnecessary files and functions.
Linus
^ permalink raw reply
* Re: [PATCH 2/2] pack-objects: be incredibly anal about stdio semantics
From: Linus Torvalds @ 2006-04-02 21:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmzf3k7m9.fsf@assigned-by-dhcp.cox.net>
On Sun, 2 Apr 2006, Junio C Hamano wrote:
> Linus Torvalds <torvalds@osdl.org> writes:
>
> > This is the "letter of the law" version of using fgets() properly in the
> > face of incredibly broken stdio implementations. We can work around the
> > Solaris breakage with SA_RESTART, but in case anybody else is ever that
> > stupid, here's the "safe" (read: "insanely anal") way to use fgets.
>
> Did you mean this as a real change or a demonstration? The
> sigaction change is a real fix, but somehow I find this one
> similar to the "(void*) NULL" thing you objected earlier (which
> was not merged because I agreed with your argument)...
I don't have any really strong opinions on it. I think that any libc that
needs the "ferror()" test + EINTR loopback is totally broken. I would
happily say that people should just not use a development platform that is
that horrible.
But the fact that Solaris actually had that as a real problem (never mind
that we could work around it another way) just makes me go "Hmm..".
So I _think_ we're safe with just the "sigaction()" diff. Neither of the
patches _should_ make any difference at all on a sane platform.
Linus
^ permalink raw reply
* Re: Default remote branch for local branch
From: Junio C Hamano @ 2006-04-02 21:40 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git
In-Reply-To: <200604021817.30222.Josef.Weidendorfer@gmx.de>
Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
> On Saturday 01 April 2006 06:18, Pavel Roskin wrote:
>> On Fri, 2006-03-31 at 19:05 -0800, Junio C Hamano wrote:
>> > Maybe you would want something like this.
>> >
>> > In $GIT_DIR/config:
>> >
>> > [pull]
>> > origin = linus for master
>> > origin = irq-pio of libata for ata-irq-pio
>> > origin = pata-drivers of libata for ata-pata
>
> Let me try to understand this: the general idea is that
>
> pull.origin = [<refspec> of] <remote> for <branch>
>
> specifies the default action of git-pull if we are on <branch>, ie.
> a "git pull" then runs "git pull <remote> [<refspec>]".
Not quite.
It will be (if this were a serious proposal -- I am not
absolutely convinced this is a good idea) more like "git fetch
<remote>" followed by "git-merge HEAD the-refspec-named-there".
The implementation of the above would involve changes to
git-fetch, because it needs to give ".not-for-merge" mark to
different line in FETCH_HEAD depending on [<refspec> of] part.
> So the example above, if .git/remotes/linus would contain two
> refspecs, and you are on the branch of the 2nd refspec, it would
> do the wrong thing: merge the 1st refspec with current branch.
Sorry I fail to visualize this part.
>> Secondly, I think the relationship should be between a local development
>> branch and a local tracking branch.
>
> Agree.
> It is also useful to specify this relation if the upstream is purely a
> local branch, e.g. when branching off a local branch, and you want to
> pull in changes from the local upstream.
>
> This works automatically if git-pull only does upstream fetching if
> there is a remote branch associated. The default action of git-fetch
> similar could be "fetch the upstream branch, if that tracks a remote
> branch", using the same configuration.
Interesting.
You would need sanity checker for $GIT_DIR/remotes/* files if
you do this to make sure no local tracking branch is by mistake
configured to track two remote branches, which is a good change,
but then:
git-pull, without parameter, would:
(1) check if this branch has any local branch it usually
merges from; if not, do whatever we traditionally
did (or barf).
(2) if there is a local branch it merges from, check if
it is a tracking branch for a remote, by looking at
remotes/* files. It would be nice if we could
detect tracking branches fed from external svn/cvs
repositories via svn/cvs-import this way at this
time. If not, skip the next step and go directly to
(4).
(3) run git-fetch (or svn/cvs-import) to update the
tracking branch;
(4) merge from that other local branch.
> Junio's proposal has the advantage that you do not have to search in all
> files in .git/remotes (and even .git/branches) for the remote branch that
> maps to a given local branch.
> But that is not the big issue.
A bigger thing is that I am trying to avoid _requiring_ tracking
branches. If you are not micromanaging your subsystem
maintainers, you should not have to care where they were the
last time you pulled from them. You should be able to just
pull, examine what the merge brings in, and decide it is worth
merging. If it isn't, do a "reset", tell them "not good, please
rework and let me know when you are ready," and forget about it.
If we are going require tracking branches, we could do a bit
more with them, like remembering where the tip was when we
fetched the last time (or the time before that...) and diff with
that, but the tracking branch heads are not set up to do things
like that right now -- they are single pointers.
>> Perhaps you are missing a remotes editor command?
Perhaps. Also perhaps a remotes/ sanity checker.
Something like this:
$ git branch --describe ata-pata
Typically merges from pata-drivers branch of
git://.../jgarzik/libata-dev.git
which is tracked with local refs/remotes/libata/pata-drivers.
$ git branch --decribe refs/remotes/libata/pata-drivers
Tracking branch for pata-drivers branch of
git://.../jgarzik/libata-dev.git
$ git checkout origin
warning: you are checking out a tracking branch for "master" branch of
warning: git://.../torvalds/linux-2.6.git
warning: commit/pull/merge commands are disabled.
hint: you can still create a new branch from here.
^ permalink raw reply
* [PATCH] Documentation: revise top of git man page
From: J. Bruce Fields @ 2006-04-02 21:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
I'm afraid I'll be accused of trying to suck all the jokes and the
personality out of the git documentation. I'm not! Really!
That said, "man git" is one of the first things a new user is likely try,
and it seems a little cruel to start off with a somewhat obscure joke
about the architecture of git.
So instead I'm trying for a relatively straightforward description of what
git does, and what features distinguish it from other systems, together
with immediate links to introductory documentation.
I also did some minor reorganization in an attempt to clarify the
classification of commands. And revised a bit for conciseness (as is
obvious from the diffstat--hopefully I didn't cut anything important).
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
---
Documentation/git.txt | 103 +++++++++++++++++++++++--------------------------
1 files changed, 48 insertions(+), 55 deletions(-)
9fc3b77b82004356a6e5fa19e5e31a2b19f088d3
diff --git a/Documentation/git.txt b/Documentation/git.txt
index fe34f50..06b2e53 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -12,10 +12,14 @@ SYNOPSIS
DESCRIPTION
-----------
-'git' is both a program and a directory content tracker system.
-The program 'git' is just a wrapper to reach the core git programs
-(or a potty if you like, as it's not exactly porcelain but still
-brings your stuff to the plumbing).
+Git is a fast, scalable, distributed revision control system with an
+unusually rich command set that provides both high-level operations
+and full access to internals.
+
+See this link:tutorial.html[tutorial] to get started, then see
+link:everyday.html[Everyday Git] for a useful minimum set of commands, and
+"man git-commandname" for documentation of each command. CVS users may
+also want to read link:cvs-migration.html[CVS migration].
OPTIONS
-------
@@ -35,55 +39,38 @@ OPTIONS
the current setting and then exit.
-NOT LEARNING CORE GIT COMMANDS
-------------------------------
+FURTHER DOCUMENTATION
+---------------------
+
+See the references above to get started using git. The following is
+probably more detail than necessary for a first-time user.
+
+The <<Discussion,Discussion>> section below and the
+link:core-tutorial.html[Core tutorial] both provide introductions to the
+underlying git architecture.
+
+See also the link:howto-index.html[howto] documents for some useful
+examples.
+
+GIT COMMANDS
+------------
-This manual is intended to give complete background information
-and internal workings of git, which may be too much for most
-people. The <<Discussion>> section below contains much useful
-definition and clarification - read that first.
-
-If you are interested in using git to manage (version control)
-projects, use link:tutorial.html[The Tutorial] to get you started,
-and then link:everyday.html[Everyday GIT] as a guide to the
-minimum set of commands you need to know for day-to-day work.
-Most likely, that will get you started, and you can go a long
-way without knowing the low level details too much.
-
-The link:core-tutorial.html[Core tutorial] document covers how things
-internally work.
-
-If you are migrating from CVS, link:cvs-migration.html[cvs
-migration] document may be helpful after you finish the
-tutorial.
-
-After you get the general feel from the tutorial and this
-overview page, you may want to take a look at the
-link:howto-index.html[howto] documents.
-
-
-CORE GIT COMMANDS
------------------
-
-If you are writing your own Porcelain, you need to be familiar
-with most of the low level commands --- I suggest starting from
-gitlink:git-update-index[1] and gitlink:git-read-tree[1].
-
-
-Commands Overview
------------------
-The git commands can helpfully be split into those that manipulate
-the repository, the index and the files in the working tree, those that
-interrogate and compare them, and those that moves objects and
-references between repositories.
-
-In addition, git itself comes with a spartan set of porcelain
-commands. They are usable but are not meant to compete with real
-Porcelains.
-
-There are also some ancillary programs that can be viewed as useful
-aids for using the core commands but which are unlikely to be used by
-SCMs layered over git.
+We divide git into high level ("porcelain") commands and low level
+("plumbing") commands.
+
+Low-level commands (plumbing)
+-----------------------------
+
+Although git includes its
+own porcelain layer, its low-level commands are sufficient to support
+development of alternative porcelains. Developers of such porcelains
+might start by reading about gitlink:git-update-index[1] and
+gitlink:git-read-tree[1].
+
+We divide the low-level commands into commands that manipulate objects (in
+the repository, index, and working tree), commands that interrogate and
+compare objects, and commands that move objects and references between
+repositories.
Manipulation commands
~~~~~~~~~~~~~~~~~~~~~
@@ -248,8 +235,14 @@ gitlink:git-upload-pack[1]::
what are asked for.
-Porcelain-ish Commands
-----------------------
+High-level commands (porcelain)
+-------------------------------
+
+We separate the porcelain commands into the main commands and some
+ancillary user utilities.
+
+Main porcelain commands
+~~~~~~~~~~~~~~~~~~~~~~~
gitlink:git-add[1]::
Add paths to the index.
@@ -346,7 +339,7 @@ gitlink:git-whatchanged[1]::
Ancillary Commands
-------------------
+~~~~~~~~~~~~~~~~~~
Manipulators:
gitlink:git-applypatch[1]::
--
1.2.4.g0382
^ permalink raw reply related
* Re: [PATCH 2/2] pack-objects: be incredibly anal about stdio semantics
From: Jason Riedy @ 2006-04-02 22:12 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0604021417301.23419@g5.osdl.org>
And Linus Torvalds writes:
-
- I don't have any really strong opinions on it. I think that any libc that
- needs the "ferror()" test + EINTR loopback is totally broken. I would
- happily say that people should just not use a development platform that is
- that horrible.
If you consider stdio to be a low-level wrapper over syscalls
that only adds buffering and simple parsing, then passing EINTR
back to the application is a sensible choice. I wouldn't be
too surprised if L4, VxWorks, etc. do something similar.
- So I _think_ we're safe with just the "sigaction()" diff. Neither of the
- patches _should_ make any difference at all on a sane platform.
Anyone with an older HP/UX care to try these patches? HP/UX
may not be sane, but I think it may lack SA_RESTART. I don't
know if stdio calls need restarted, though.
Jason
^ permalink raw reply
* Re: [RFH] xdiff shows trivially redundant diff.
From: Davide Libenzi @ 2006-04-02 22:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Linus Torvalds
In-Reply-To: <7vzmj3k7x9.fsf@assigned-by-dhcp.cox.net>
On Sun, 2 Apr 2006, Junio C Hamano wrote:
> I should have tried your pristine xdiff code myself before
> bothering you, but I haven't (sorry).
>
> The problem is from the "stripped down" version we use in git,
> so you may or may not see the problem in your version. Attached
> are the files.
Yes, it does even vanilla libxdiff ;) It's not a problem though, since it
is created in xdl_cleanup_records() that tries to do a fast pass over the
records to try to simplify the real diff operation. In trying to be fast,
only hashes are compared, and it happens that the hash for "'')" collides
with another one (try to replace one of the "'')" chars with another one).
Why is this not a problem? Because what this lead to is only lines to be
marked as changed, with a probability of about N/2^(8 * sizeof(long) - 1),
even though they are not. And this happens only during sequential groups
of lines changed, that is when the hash-colliding line is either at the
begin or the end of the run.
- Davide
^ permalink raw reply
* Re: [RFH] xdiff shows trivially redundant diff.
From: Davide Libenzi @ 2006-04-02 22:18 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0604021411300.23419@g5.osdl.org>
On Sun, 2 Apr 2006, Linus Torvalds wrote:
> On Sun, 2 Apr 2006, Junio C Hamano wrote:
>>
>> I should have tried your pristine xdiff code myself before
>> bothering you, but I haven't (sorry).
>
> It definitely happens with plain libxdiff-0.17 too.
>
> In general, unless it's related to the "\ No newline" or the extra stuff
> on the "@@"-line, I'd be very surprised if we have any differences in the
> diff output wrt libxdiff-0.17. I was really pretty careful, and didn't
> change the code at all, just removed unnecessary files and functions.
So it does 0.18, that contains the "\ No newline" handling for text diff
and patch. See my reply to Junio also.
- Davide
^ permalink raw reply
* Re: git-svn and svn sw --relocate
From: Eric Wong @ 2006-04-02 22:21 UTC (permalink / raw)
To: Nicolas Vilz 'niv'; +Cc: git
In-Reply-To: <4430123E.5090605@iaglans.de>
Nicolas Vilz 'niv' <niv@iaglans.de> wrote:
> ok, guys... next question:
>
> i have now my repository locally and i want to get it remotely on a
> server, in order to have a few collaborators...
>
> the steps on the svn-side are clear. But what do i have todo on the
> git-svn-side of this life?
>
> does a simple "svn sw --relocate" do the job in the git-svn meta-dir?
Yes, you'll need to do that in .git/git-svn/tree and also update
.git/git-svn/info/url by hand.
--
Eric Wong
^ permalink raw reply
* [PATCH] Use sigaction and SA_RESTART in read-tree.c; add option in Makefile.
From: Jason Riedy @ 2006-04-02 22:29 UTC (permalink / raw)
To: Linus Torvalds, Junio C Hamano; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0604021312510.3050@g5.osdl.org>
Might as well ape the sigaction change in read-tree.c to avoid
the same potential problems. The fprintf status output will
be overwritten in a second, so don't bother guarding it. Do
move the fputc after disabling SIGALRM to ensure we go to the
next line, though.
Also add a NO_SA_RESTART option in the Makefile in case someone
doesn't have SA_RESTART but does restart (maybe older HP/UX?).
We want the builder to chose this specifically in case the
system both lacks SA_RESTART and does not restart stdio calls;
a compat #define in git-compat-utils.h would silently allow
broken systems.
Signed-off-by: Jason Riedy <ejr@cs.berkeley.edu>
---
Makefile | 7 +++++++
read-tree.c | 28 +++++++++++++++++++---------
2 files changed, 26 insertions(+), 9 deletions(-)
521dc260ea90a23d58a4e920203af5035ca1a673
diff --git a/Makefile b/Makefile
index c79d646..f3b1d49 100644
--- a/Makefile
+++ b/Makefile
@@ -63,6 +63,9 @@
# Define COLLISION_CHECK below if you believe that SHA1's
# 1461501637330902918203684832716283019655932542976 hashes do not give you
# sufficient guarantee that no collisions between objects will ever happen.
+#
+# Define NO_SA_RESTART if your platform does not have SA_RESTART, _AND_ if
+# it automatically restarts interrupted stdio calls.
# Define USE_NSEC below if you want git to care about sub-second file mtimes
# and ctimes. Note that you need recent glibc (at least 2.2.4) for this, and
@@ -425,6 +428,10 @@
endif
ifdef NO_ACCURATE_DIFF
ALL_CFLAGS += -DNO_ACCURATE_DIFF
+endif
+
+ifdef NO_SA_RESTART
+ ALL_CFLAGS += -DSA_RESTART=0
endif
# Shell quote (do not use $(call) to accomodate ancient setups);
diff --git a/read-tree.c b/read-tree.c
index eaff444..4422dbf 100644
--- a/read-tree.c
+++ b/read-tree.c
@@ -273,10 +273,26 @@
static void progress_interval(int signum)
{
- signal(SIGALRM, progress_interval);
progress_update = 1;
}
+static void setup_progress_signal(void)
+{
+ struct sigaction sa;
+ struct itimerval v;
+
+ memset(&sa, 0, sizeof(sa));
+ sa.sa_handler = progress_interval;
+ sigemptyset(&sa.sa_mask);
+ sa.sa_flags = SA_RESTART;
+ sigaction(SIGALRM, &sa, NULL);
+
+ v.it_interval.tv_sec = 1;
+ v.it_interval.tv_usec = 0;
+ v.it_value = v.it_interval;
+ setitimer(ITIMER_REAL, &v, NULL);
+}
+
static void check_updates(struct cache_entry **src, int nr)
{
static struct checkout state = {
@@ -289,8 +305,6 @@
unsigned last_percent = 200, cnt = 0, total = 0;
if (update && verbose_update) {
- struct itimerval v;
-
for (total = cnt = 0; cnt < nr; cnt++) {
struct cache_entry *ce = src[cnt];
if (!ce->ce_mode || ce->ce_flags & mask)
@@ -302,12 +316,8 @@
total = 0;
if (total) {
- v.it_interval.tv_sec = 1;
- v.it_interval.tv_usec = 0;
- v.it_value = v.it_interval;
- signal(SIGALRM, progress_interval);
- setitimer(ITIMER_REAL, &v, NULL);
fprintf(stderr, "Checking files out...\n");
+ setup_progress_signal();
progress_update = 1;
}
cnt = 0;
@@ -341,8 +351,8 @@
}
}
if (total) {
- fputc('\n', stderr);
signal(SIGALRM, SIG_IGN);
+ fputc('\n', stderr);
}
}
--
1.3.0.rc1
^ permalink raw reply related
* Re: [PATCH 2/2] pack-objects: be incredibly anal about stdio semantics
From: Linus Torvalds @ 2006-04-02 22:58 UTC (permalink / raw)
To: Jason Riedy; +Cc: git
In-Reply-To: <15051.1144015974@lotus.CS.Berkeley.EDU>
On Sun, 2 Apr 2006, Jason Riedy wrote:
>
> If you consider stdio to be a low-level wrapper over syscalls
> that only adds buffering and simple parsing, then passing EINTR
> back to the application is a sensible choice. I wouldn't be
> too surprised if L4, VxWorks, etc. do something similar.
No, returning EINTR is insane, because stdio has to do re-starting of
system calls by hand _anyway_ for the "short read" case.
EINTR really _is_ 100% equivalent to "short read of zero bytes" (that
literally is what it means for a read/write system call - anybody who
tells you otherwise is just crazy).
So any library that handles short reads, but doesn't handle EINTR is by
definition doing something totally idiotic and broken.
Now, I agree that somebody else might be broken too. I would not agree
that it's "acceptable". It's craptastically bad library code.
> Anyone with an older HP/UX care to try these patches? HP/UX
> may not be sane, but I think it may lack SA_RESTART. I don't
> know if stdio calls need restarted, though.
I'd assume that older HPUX is so BSD-based that all signals end up
restarting. That was the BSD signal() semantics, after all.
Linus
^ 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