* Re: 0.99.9 on Saturday next week.
From: Linus Torvalds @ 2005-10-26 17:55 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Junio C Hamano, git
In-Reply-To: <b0943d9e0510260450k624268aav@mail.gmail.com>
On Wed, 26 Oct 2005, Catalin Marinas wrote:
>
> I use Python for StGIT and it has support for parsing .ini syntax, no
> need to use GIT for this (unless the syntax you chose would diverge
> too much).
The syntax differences I'm aware of:
- the git ".ini" parser is case-insensitive in the variable names. I
don't know if this is true in general. I do know a lot of people use
MixedCase things, but I don't know if it's because they care, or
because they think it's so pretty.
- the git parser accepts either ";" or "#" as comments, and anywhere on a
line (not just at the beginning). Again, others may or may not do the
same.
- the git parser wants a "=" for the assignment. I think the Python one
also accepts ":". If people care, we could make the git parser allow
either.
- duplicate entries. The git parser allows them, and will just pass them
on multiple times. In fact, I had a patch (that I threw out) that
depended on this, and allowed you to rewrite hostnames for git_connect
with something like
[host]
rewrite = "host.com:" "git://git.host.com/"
rewrite = "other.org:" "rsync://rsync.other.org/"
and the git config file parser happily just parses this as two
different entries for "host.rewrite"
- quoting. This is likely the big one. The git parser thinks only the
regular '"' character ("rabbit ears") is a quote, and passes single-
ticks through unmolested. I don't have a clue what others do, if
anything.
In the absense of quotes, most should be trivial to handle by just being
careful.
Linus
^ permalink raw reply
* Re: [PATCH 4/4] git-fetch-pack: Implement client part of the multi_ack extension
From: Alex Riesen @ 2005-10-26 18:34 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Alex Riesen, git, junkio
In-Reply-To: <Pine.LNX.4.63.0510261041100.7424@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin, Wed, Oct 26, 2005 10:41:47 +0200:
> > > Could you please try the patch I sent with the subject "[PATCH]
> > > fetch/upload: Fix corner case with few revs"? Your output looks exactly
> > > like what I fixed with that patch.
> > I couldn't at the moment. Do you still need a test?
> If you have time and can test it, yes, please.
Johannes Schindelin, Tue, Oct 25, 2005 17:34:07 +0200:
> When git-fetch-pack did not have enough revs to send, it did not realize
> that the server actually speaks multi_ack. The server would now continue
> sending ack´s, but the client would try to unpack objects. Oops.
This patch fixed it.
^ permalink raw reply
* Re: git 565ebbf79f61873042c22a7126d002c104e056f4 broken on OpenBSD
From: Randal L. Schwartz @ 2005-10-26 18:50 UTC (permalink / raw)
To: Horst von Brand; +Cc: git
In-Reply-To: <200510261722.j9QHMLGY006576@laptop11.inf.utfsm.cl>
>>>>> "Horst" == Horst von Brand <vonbrand@inf.utfsm.cl> writes:
Horst> This is EVIL.... why not just:
Horst> #ifndef ENOTSUP
Horst> #define ENOTSUP EXDEV
Horst> #endif
I'd consider that a worse hack. It affects any place where EXDEV
is not really equivalent to ENOTSUP.
It's cleaner to test for the ones that work, building up an OR'ed expression.
--
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: [PATCH 1/4] git-init-db should error out with a message
From: Alex Riesen @ 2005-10-26 19:45 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, junkio
In-Reply-To: <Pine.LNX.4.63.0510260139000.30576@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin, Wed, Oct 26, 2005 01:39:24 +0200:
> When the HEAD symref could not be created, it is helpful for the user to
> know that.
>
Not just that. It would be interesting to give the user an option to
use the file references ("ref: refs/heads/master").
Something like that:
Add --no-symref (make init-db use file references)
---
cache.h | 1 +
init-db.c | 11 +++++++++--
refs.c | 7 ++++++-
3 files changed, 16 insertions(+), 3 deletions(-)
applies-to: dba443573167bb9b0023613428e6d1a69477fac6
097ca1bf9b21d19d425e8151986eb36f82cbeff3
diff --git a/cache.h b/cache.h
index d776016..e410ce2 100644
--- a/cache.h
+++ b/cache.h
@@ -239,6 +239,7 @@ extern char *sha1_to_hex(const unsigned
extern int read_ref(const char *filename, unsigned char *sha1);
extern const char *resolve_ref(const char *path, unsigned char *sha1, int);
extern int create_symref(const char *git_HEAD, const char *refs_heads_master);
+extern int create_file_symref(const char *git_HEAD, const char *refs_heads_master);
extern int validate_symref(const char *git_HEAD);
/* General helper functions */
diff --git a/init-db.c b/init-db.c
index aabc09f..2d2b705 100644
--- a/init-db.c
+++ b/init-db.c
@@ -161,6 +161,8 @@ static void copy_templates(const char *g
closedir(dir);
}
+static int try_symref = 1;
+
static void create_default_files(const char *git_dir,
char *template_path)
{
@@ -191,8 +193,11 @@ static void create_default_files(const c
*/
strcpy(path + len, "HEAD");
if (read_ref(path, sha1) < 0) {
- if (create_symref(path, "refs/heads/master") < 0)
- exit(1);
+ int err = 0;
+ if ( try_symref )
+ err = create_symref(path, "refs/heads/master");
+ if ( !err && create_file_symref(path, "refs/heads/master") < 0 )
+ die("cannot create %s", path);
}
path[len] = 0;
copy_templates(path, len, template_path);
@@ -220,6 +225,8 @@ int main(int argc, char **argv)
break;
else if (!strncmp(arg, "--template=", 11))
template_dir = arg+11;
+ else if (!strcmp(arg, "--no-symref"))
+ try_symref = 0;
else
die(init_db_usage);
}
diff --git a/refs.c b/refs.c
index 97506a4..8029667 100644
--- a/refs.c
+++ b/refs.c
@@ -120,6 +120,12 @@ int create_symref(const char *git_HEAD,
unlink(git_HEAD);
return symlink(refs_heads_master, git_HEAD);
#else
+ return create_file_symref(git_HEAD, refs_heads_master);
+#endif
+}
+
+int create_file_symref(const char *git_HEAD, const char *refs_heads_master)
+{
const char *lockpath;
char ref[1000];
int fd, len, written;
@@ -144,7 +150,6 @@ int create_symref(const char *git_HEAD,
return -3;
}
return 0;
-#endif
}
int read_ref(const char *filename, unsigned char *sha1)
---
0.99.8.GIT
^ permalink raw reply related
* Re: git-rev-list: make --dense the default (and introduce "--sparse")
From: Junio C Hamano @ 2005-10-26 20:03 UTC (permalink / raw)
To: git, Linus Torvalds
In-Reply-To: <Pine.LNX.4.64.0510260757350.10477@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Wed, 26 Oct 2005, Junio C Hamano wrote:
>>
>> I have not looked closely into what exactly, but the fourth
>> thing this does might be to break git-send-pack.
>
> Ack. And I see why.
>
>
> This patch (on top of the original one) does exactly that.
Thanks, this fixes it.
^ permalink raw reply
* Re: git 565ebbf79f61873042c22a7126d002c104e056f4 broken on OpenBSD
From: Junio C Hamano @ 2005-10-26 20:08 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <86mzkwdsef.fsf@blue.stonehenge.com>
merlyn@stonehenge.com (Randal L. Schwartz) writes:
> It's cleaner to test for the ones that work, building up an OR'ed expression.
You are right. In this case the only thing we care about is if
it failed because of EEXIST, so checking that and trying to fall
back on rename() otherwise seems cleanest, as Linus and others
suggests.
I swallowed Linus version. Thanks for reporting (and also ctype
fix the other day).
^ permalink raw reply
* Re: [PATCH] Fix cloning (memory corruption)
From: Junio C Hamano @ 2005-10-26 20:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0510261616550.21073@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> upload-pack would set create_full_pack=1 if nr_has==0, but would ask later
> if nr_needs<MAX_NEEDS. If that proves true, it would ignore create_full_pack,
> and arguments would be written into unreserved memory.
Thanks.
^ permalink raw reply
* Re: git 565ebbf79f61873042c22a7126d002c104e056f4 broken on OpenBSD
From: Randal L. Schwartz @ 2005-10-26 20:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr7a8ca8j.fsf@assigned-by-dhcp.cox.net>
>>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
Junio> I swallowed Linus version. Thanks for reporting (and also ctype
Junio> fix the other day).
I apologize that I don't immediately post the patch, but generally
I figure that maybe Smarter People Than Me might recognize the issue
before I can get around to figuring out what broke.
After all, my C is rusty. My Perl is much better. :)
Also, I'm learning how git works, to generate diffs and patches, etc.
--
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: [PATCH 1/4] git-init-db should error out with a message
From: Junio C Hamano @ 2005-10-26 20:27 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20051026194520.GC8030@steel.home>
Alex Riesen <fork0@users.sourceforge.net> writes:
> Not just that. It would be interesting to give the user an option to
> use the file references ("ref: refs/heads/master").
Actually, the users should not have to care how HEAD reference
is implemented. It might make sense to use regular file symref
regardless of platforms (i.e. never define USE_SYMLINK_HEAD on
any platform).
We support reading from either kind of symref, so if we did
that, the only case that *could* matter form compatibility point
of view is that repositories touched by the updated git is
unusable for an ancient git that does not understand regular
file symref. From performance and simplicity point of view,
however, using symlink when possible is better, and that is what
Johannes' patch does.
HOWEVER, I think "falling back" (both in Johannes' patch which
is in the "master" branch, and your version) has a funny failure
mode. What happens when two processes try redirecting .git/HEAD
simultaneously, possibly to different branch heads? Both of
them unlink(), one successfully does symlink(), and the other
gets EEXIST and falls back to create regular file symref.
Which is probably not so wrong; if this race matters, then you
have bigger problem -- the user is doing 'git checkout' of
different branches at the same time, or something silly like
that. But it does not feel quite right, either.
^ permalink raw reply
* Re: [PATCH 1/4] git-init-db should error out with a message
From: Alex Riesen @ 2005-10-26 20:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3bmoc9d7.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano, Wed, Oct 26, 2005 22:27:00 +0200:
> > Not just that. It would be interesting to give the user an option to
> > use the file references ("ref: refs/heads/master").
>
> Actually, the users should not have to care how HEAD reference
> is implemented. It might make sense to use regular file symref
> regardless of platforms (i.e. never define USE_SYMLINK_HEAD on
> any platform).
This my idea too. All the time I was doing that patch :)
> HOWEVER, I think "falling back" (both in Johannes' patch which
> is in the "master" branch, and your version) has a funny failure
> mode. What happens when two processes try redirecting .git/HEAD
> simultaneously, possibly to different branch heads? Both of
> them unlink(), one successfully does symlink(), and the other
> gets EEXIST and falls back to create regular file symref.
I think the file ref version uses rename of HEAD.lock into HEAD, doesn't it?
Rename(2) should just remove the symlink, right?
^ permalink raw reply
* Re: Towards CVS code-exchange and gateways
From: Petr Baudis @ 2005-10-26 20:51 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Git Mailing List
In-Reply-To: <46a038f90510260211i47c8a4e1oca8be8d0833f4b68@mail.gmail.com>
Dear diary, on Wed, Oct 26, 2005 at 11:11:49AM CEST, I got a letter
where Martin Langhoff <martin.langhoff@gmail.com> told me that...
> The goal for this script that I'm drafting is to be able to push
> commits back into cvs in a format that maximises the chance of
> git-cherry identifying them when they are echoed back (and thus
> avoiding bogus conflicts).
Aha, so you are not aiming for proper two-way incremental i/e, and one
will have to cherrypick to import after an export... well, I guess that
can be good enough for many cases. But to use Linus' words, the really
interesting problem is to have the proper revision tree in the CVS heads
as well, so that you could do normal merges. And it shouldn't be _that_
hard either...
> > If someone really desperately needs this, BTW, you might be able to
> > merge two Monotone branches (.git and .cvssync) to get two-way
> > incremental GIT and CVS interface, and then do that through Monotone.
> > ;-))
>
> I'm really scared by the concept ;-)
I *think* someone actually really did something like that. ;-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: [PATCH 1/4] git-init-db should error out with a message
From: Junio C Hamano @ 2005-10-26 23:18 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20051026204727.GA19846@steel.home>
Alex Riesen <fork0@users.sourceforge.net> writes:
> I think the file ref version uses rename of HEAD.lock into HEAD, doesn't it?
> Rename(2) should just remove the symlink, right?
If everybody used symlink or if everybody used regular file
symref, we would catch this race and the second one will be
stopped. My point was that by falling back we are introducing
this unnecessary race, which might be unimportant but still it
is a new race.
To avoid that, I think symlink version needs to honor the
HEAD.lock convention, which would slow down normal cases.
^ permalink raw reply
* [RFC] multi_ack protocol v2
From: Johannes Schindelin @ 2005-10-27 0:16 UTC (permalink / raw)
To: git
Hi,
the fetch-pack/upload-pack protocol as of now goes like this:
- server sends the refs it has, then an empty packet
- client sends what it wants, then an empty packet
- client sends a rev-list via "have" lines in the hope to find a common
rev. Interspersed, it sends empty packets.
- server answers to those empty packets with a NAK message, until it
receives a "have" line for a commit it has (and which is therefore a
common commit). This is answered by an ACK message, and no NAK or ACK is
sent after that
- client sends "done"
- server only responds if no common commit was found, with a NAK
- server sends pack
after thinking about my earlier approach, I think there's a better, less
intrusive, and all in all just simpler approach:
- client asks for multi_ack protocol by sending " multi_ack" at the end
of at least one "want" line
- server appends " continue" to the ACK message, but continues sending
ACK (but not NAK) messages
- after receiving "done", server repeats last ACK message without
" continue" appended
After much fun with non-working, fragile code which had to be retracted
from master, I hope that this approach is less prone to errors.
Note that this is incompatible to the multi_ack protocol I described
earlier, but given that my patches were buggy anyway, I'd say it does not
matter at all.
Thoughts, comments, objections?
Ciao,
Dscho
^ permalink raw reply
* git-cvsimport: $cvs->file() fails silently
From: Martin Langhoff @ 2005-10-27 4:23 UTC (permalink / raw)
To: Matthias Urlichs, Sven Verdoolaege, Git Mailing List
We have seen a few instances of files extracted from a remote CVS repo
by $cvs->file() being empty, and still git-cvsimport did not die or
complain. If I rewind the affected head and re-run git-cvsimport, the
file is imported correctly, which makes me suspect that the server
went away or there was some other networking glitch, and that the
file() and _file() methods didn't handle it gracefully.
I've been through the file(), _file() and _line() methods, and they
seem pretty conservative -- they die or return undef in all the right
places. There _must_ be one place that we're missing but I just can't
see it.
Any ideas?
martin
^ permalink raw reply
* Re: Make "gitk" work better with dense revlists
From: Paul Mackerras @ 2005-10-27 6:16 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0510251253110.10477@g5.osdl.org>
Linus Torvalds writes:
> So this makes gitk just show the diff of _that_ commit.
Committed and pushed out, but ...
> Also, having now tested the previous "handle root commit in the
> TREECHANGED" logic a bit more, I think it's (a) stable and (b) the right
> thing to do. Sign me off on that one too.
What is that about?
I'm hoping to get back to gitk hacking RSN - I've been going flat out
on the ppc32/ppc64 merge. Thanks for doing the --dense thing; I was
thinking about doing something like that inside gitk but doing it in
git-rev-list is better. It does mean that I now want to be able to
get gitk to contract the view to just a given set of files or
directories and then expand back to the whole tree view, which means
running git-rev-list multiple times, which gitk can't do at the
moment...
Paul.
^ permalink raw reply
* Re: [RFC] multi_ack protocol v2
From: Junio C Hamano @ 2005-10-27 7:13 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0510270149590.12163@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> after thinking about my earlier approach, I think there's a better, less
> intrusive, and all in all just simpler approach:
>
> - client asks for multi_ack protocol by sending " multi_ack" at the end
> of at least one "want" line
> - server appends " continue" to the ACK message, but continues sending
> ACK (but not NAK) messages
> - after receiving "done", server repeats last ACK message without
> " continue" appended
>
> After much fun with non-working, fragile code which had to be retracted
> from master, I hope that this approach is less prone to errors.
Sorry for a late reply -- real life interrupts ;-).
I do not necessarily think the last round (still found in the
proposed updates branch) was a failure. One valuable thing you
found out was that there is a way to extend the protocol with
the appended "multi-ack" trick.
Sending "have you found a common yet" every 32 "have" like the
original protocol does has a nice batching property (I think we
could even tweak pkt-line.c::packet_write() to actually buffer
these "have"s and write them out in one-go, to put them in a
single network packet) and I do not want to lose it, but other
than that, since you have found a good way to extend the initial
handshake to find out if both ends can do a v2 protocol without
breaking older server nor clients, I have no objection against
doing things drastically differently in the v2 protocol.
I noticed the sketch in Documentation/pack-protocol.txt is
somewhat buggy. Here is my attempt to correct it:
upload-pack (S) | fetch/clone-pack (C) protocol (v1):
# Tell the puller what commits we have and what their names are
S: SHA1 name
S: ...
S: SHA1 name
S: # flush -- it's your turn
# Tell the pusher what commits we want, and what we have
C: want SHA1
C: ..
C: want SHA1
C: # flush -- done with "want" lines.
C: have SHA1
C: have SHA1
C: ...
C: # flush -- this occasionally asks "had enough?"
S: NAK
# and the server answers "notyet"
C: have SHA1
C: ...
C: have SHA1
S: ACK SHA1
C: done
S: XXXXXXX -- packfile contents.
I wrote as if "want" sends names, but it actually sends SHA1s.
Also I missed a place where "flush" was needed.
So let's illustrate the v2 the same way as I understand it.
upload-pack (S) | fetch/clone-pack (C) protocol (v2):
# Tell the puller what commits we have and what their names are
S: SHA1 name
S: ...
S: SHA1 name
S: # flush -- it's your turn
# Tell the pusher what commits we want, and what we have.
# In addition, we tell the other end that we support protocol
# extensions, without breaking the old servers.
C: want SHA1 extended
C: ..
C: want SHA1
C: # flush -- done with "want" lines.
Notice that until we hear from the server, we cannot tell if our
"extended" protocol wish will be granted, and in the original
protocol, "NAK" will come in fixed length, and the only thing we
could tack arbitrary garbage to was "ACK SHA1". That's why your
"ACK SHA1 continue" works nicely, but at the time you could not
find out if you are talking with updated server until you get at
least one ACK.
However, at this point, we *could* force the server to reveal
what it supports, by doing an extra flush here, before sending
*ANY* "have" lines yet:
C: # flush -- this is another one after "I'm done with wants".
Upon receiving this, if we were talking with an old upload-pack,
we would certanly get an NAK. Note that the server already
knows that we support extended protocol at this point, so our
updated server can send anything here to say it knows what
protocol extensions it supports. Let's say it says something
like this:
S: proto v2 v3 v5
to tell the puller it understands protocol v2, v3, and v5, to
which the puller responds:
C: proto v2
After this exchange, both ends know they understand and would
want to talk at protocol level v2. This leaves door open for
future protocol extension, but more importantly, I think this
arrangement would make things safer.
Both the server side and the client side code can be modified
from the current one by splitting the above handshake part and
the current trusty "only one ACK is supported" code, and the
exchange after this protocol negotiation part can be implemented
in totally separate functions. We could also give command line
option and/or .git/config item to limit the protocol level each
end supports when we find the v2 protocol implementation of the
day was buggy, in order to work problems around without
recompilation, reducing the risk of breaking things too much.
^ permalink raw reply
* Re: Make "gitk" work better with dense revlists
From: Junio C Hamano @ 2005-10-27 7:34 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <17248.28857.90315.543669@cargo.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> writes:
> Linus Torvalds writes:
>
>> So this makes gitk just show the diff of _that_ commit.
>
> Committed and pushed out, but ...
Thanks. Pulled and pushed out.
^ permalink raw reply
* Re: [PATCH] git_progname (was: Re: User-relative paths)
From: Matthias Urlichs @ 2005-10-27 8:34 UTC (permalink / raw)
To: git
In-Reply-To: <20051025093150.GB30889@pasky.or.cz>
Hi, Petr Baudis wrote:
> Someone said that converting main()s to git_main()s would help the
> libification effort,
Wasn't me, and frankly I doubt it. "old-style" programs just call the
compatibility interface instead, and "new-style" ones call the libraries'
initialization *after* they've parsed any environment vars or flags
that are necessary.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
While the difficulties and dangers of problems tend to increase at a
geometric rate, the knowledge and manpower qualified to deal with these
problems tend to increase at an arithmetic rate.
-- Yehezkel Dror
^ permalink raw reply
* Re: [PATCH] Avoid using dc in git-count-objects
From: Matthias Urlichs @ 2005-10-27 8:50 UTC (permalink / raw)
To: git
In-Reply-To: <20051026083658.GE30889@pasky.or.cz>
Hi, Petr Baudis wrote:
> Dear diary, on Wed, Oct 26, 2005 at 10:33:33AM CEST, I got a letter
> where Johannes Schindelin <Johannes.Schindelin@gmx.de> told me that...
>> Aargh! I had the impression "expr" was a builtin... Just forget about the
>> patch, okay?
>
> I think that builtin or not, $() will always spawn a subshell. ...?
It'll fork a subshell, but if the $() is a builtin, it won't exec.
(My built-in dictionary says: "spawn"=="fork+exec"; sorry if that
disagrees with yours.)
That being said, "echo $((1 + 2 + $((3 + 4))))" will not even fork.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Prunes give you a run for your money.
^ permalink raw reply
* [PATCH 2/2] Ask vim to avoid backup copies of .stgit.msg
From: Paolo 'Blaisorblade' Giarrusso @ 2005-10-27 8:56 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20051027085622.2482.22005.stgit@zion.home.lan>
From: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Do this by adding nobackup to the modeline.
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
---
stgit/stack.py | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/stgit/stack.py b/stgit/stack.py
--- a/stgit/stack.py
+++ b/stgit/stack.py
@@ -88,7 +88,7 @@ def edit_file(series, string, comment, s
git.diff([], series.get_patch(series.get_current()).get_bottom(), None, f)
#Vim modeline must be near the end.
- print >> f, __comment_prefix, 'vi: set textwidth=75 filetype=diff:'
+ print >> f, __comment_prefix, 'vi: set textwidth=75 filetype=diff nobackup:'
f.close()
# the editor
^ permalink raw reply
* [PATCH 1/2] Parse /top.old with id and when requesting diffs
From: Paolo 'Blaisorblade' Giarrusso @ 2005-10-27 8:56 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
From: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Comparing a patch after and before a merge is very important, and looking into
.git/patches by hand is not the nicer way to do it.
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
---
stgit/commands/common.py | 5 +++++
stgit/stack.py | 6 ++++++
2 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/stgit/commands/common.py b/stgit/commands/common.py
--- a/stgit/commands/common.py
+++ b/stgit/commands/common.py
@@ -68,6 +68,11 @@ def git_id(string):
return series.get_patch(patch_name).get_top()
elif patch_id == 'bottom':
return series.get_patch(patch_name).get_bottom()
+ # Note we can return None here.
+ elif patch_id == 'top.old':
+ return series.get_patch(patch_name).get_old_top()
+ elif patch_id == 'bottom.old':
+ return series.get_patch(patch_name).get_old_bottom()
# base
if patch_name == 'base' and len(string_list) == 1:
diff --git a/stgit/stack.py b/stgit/stack.py
--- a/stgit/stack.py
+++ b/stgit/stack.py
@@ -165,6 +165,9 @@ class Patch:
elif os.path.isfile(fname):
os.remove(fname)
+ def get_old_bottom(self):
+ return self.__get_field('bottom.old')
+
def get_bottom(self):
return self.__get_field('bottom')
@@ -177,6 +180,9 @@ class Patch:
self.__set_field('bottom.old', None)
self.__set_field('bottom', string)
+ def get_old_top(self):
+ return self.__get_field('top.old')
+
def get_top(self):
return self.__get_field('top')
^ permalink raw reply
* Re: [PATCH] Add git-name-rev
From: Matthias Urlichs @ 2005-10-27 8:53 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0510261509060.31868@wbgn013.biozentrum.uni-wuerzburg.de>
Hi, Johannes Schindelin wrote:
> [PATCH] Add git-name-rev
Please update the "git" manpage when you add a new command.
(I bet that others are missing too..?)
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Let the machine do the dirty work.
-- "Elements of Programming Style", Kernighan and Ritchie
^ permalink raw reply
* Re: [RFC] multi_ack protocol v2
From: Johannes Schindelin @ 2005-10-27 9:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzmov4elu.fsf@assigned-by-dhcp.cox.net>
Hi,
On Thu, 27 Oct 2005, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > after thinking about my earlier approach, I think there's a better, less
> > intrusive, and all in all just simpler approach:
> >
> > - client asks for multi_ack protocol by sending " multi_ack" at the end
> > of at least one "want" line
> > - server appends " continue" to the ACK message, but continues sending
> > ACK (but not NAK) messages
Here must be a correction: server continues to send NAK messages. Else we
must introduce some select() or poll() crud, or the client hangs forever.
> > - after receiving "done", server repeats last ACK message without
> > " continue" appended
In effect, an ACK message with "continue" switches into v2, which
just means: "I'll keep sendin'", and an ACK *without* "continue" switches
back to v1.
This way the patch looks almost trivial. (Will send soon).
> > After much fun with non-working, fragile code which had to be retracted
> > from master, I hope that this approach is less prone to errors.
>
> Sorry for a late reply -- real life interrupts ;-).
No problem (hope you enjoyed it ;-). I tried to get some Zs anyway.
> Sending "have you found a common yet" every 32 "have" like the
> original protocol does has a nice batching property (I think we
> could even tweak pkt-line.c::packet_write() to actually buffer
> these "have"s and write them out in one-go, to put them in a
> single network packet) and I do not want to lose it, but other
> than that, since you have found a good way to extend the initial
> handshake to find out if both ends can do a v2 protocol without
> breaking older server nor clients, I have no objection against
> doing things drastically differently in the v2 protocol.
I think that we don't need to extend packet_write(). Let's leave it like
that.
> upload-pack (S) | fetch/clone-pack (C) protocol (v1):
>
> # Tell the puller what commits we have and what their names are
> S: SHA1 name
> S: ...
> S: SHA1 name
> S: # flush -- it's your turn
> # Tell the pusher what commits we want, and what we have
> C: want SHA1
> C: ..
> C: want SHA1
> C: # flush -- done with "want" lines.
> C: have SHA1
> C: have SHA1
> C: ...
> C: # flush -- this occasionally asks "had enough?"
> S: NAK
> # and the server answers "notyet"
> C: have SHA1
> C: ...
> C: have SHA1
> S: ACK SHA1
> C: done
> S: XXXXXXX -- packfile contents.
alternatively, when no "ACK" was sent, the response to "done" is "NAK".
> I wrote as if "want" sends names, but it actually sends SHA1s.
You also ask if it is sensible in upload-pack.c to accept names. I think
not. SHA1s are supposed to be unique, names not (master~10 is likely to
denote different commits on server and client).
> Also I missed a place where "flush" was needed.
Between "want" and "have". It is sent so that the server can handle them
in separate functions.
> upload-pack (S) | fetch/clone-pack (C) protocol (v2):
>
> # Tell the puller what commits we have and what their names are
> S: SHA1 name
> S: ...
> S: SHA1 name
> S: # flush -- it's your turn
> # Tell the pusher what commits we want, and what we have.
> # In addition, we tell the other end that we support protocol
> # extensions, without breaking the old servers.
> C: want SHA1 extended
> C: ..
> C: want SHA1
> C: # flush -- done with "want" lines.
>
> Notice that until we hear from the server, we cannot tell if our
> "extended" protocol wish will be granted, and in the original
> protocol, "NAK" will come in fixed length, and the only thing we
> could tack arbitrary garbage to was "ACK SHA1". That's why your
> "ACK SHA1 continue" works nicely, but at the time you could not
> find out if you are talking with updated server until you get at
> least one ACK.
>
> However, at this point, we *could* force the server to reveal
> what it supports, by doing an extra flush here, before sending
> *ANY* "have" lines yet:
>
> C: # flush -- this is another one after "I'm done with wants".
We don't need a second flush. The first can do. The client just has to
expect either "NAK" or "VER blabla blibli multi_ack". "VER" must be sent
by the server only when the client requested an extension the server has,
though.
> S: proto v2 v3 v5
As written above, I'd prefer something like "VER" in order to stay with
the 3 capital letters convention. Also, I like to read what it is about,
i.e. "VER multi_ack" instead of "VER v2".
> C: proto v2
I'd say that this is not necessary. Client can send that in the "want"
lines.
> After this exchange, both ends know they understand and would
> want to talk at protocol level v2. This leaves door open for
> future protocol extension, but more importantly, I think this
> arrangement would make things safer.
Yes. Nice.
I especially like that the client learns early that multi_ack protocol it
is. In my tests, non-multi_ack would only be happy when fed with commits
sorted by date, while multi_ack is much more efficient when fed commits
sorted by distance-to-tip (I cannot yet explain why this is so).
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Avoid using dc in git-count-objects
From: Johannes Schindelin @ 2005-10-27 9:56 UTC (permalink / raw)
To: git
In-Reply-To: <pan.2005.10.27.08.49.59.849081@smurf.noris.de>
Hi,
On Thu, 27 Oct 2005, Matthias Urlichs wrote:
> That being said, "echo $((1 + 2 + $((3 + 4))))" will not even fork.
<germanenglish>
But zats not troo. It forks fine for mee: ze result is 10.
</germanenglish>
;-)
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Link git-name-rev and git-symbolic-ref from the main git page
From: Johannes Schindelin @ 2005-10-27 9:57 UTC (permalink / raw)
To: git, junkio
According to my checks, these were the only commands not yet linked.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
Matthias Urlichs wrote:
> Johannes Schindelin wrote:
>
> > [PATCH] Add git-name-rev
>
> Please update the "git" manpage when you add a new command.
> (I bet that others are missing too..?)
I did not do it right away, because I did not expect that it
was merged into master *that* fast.
Documentation/git.txt | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 054f091..6c80e27 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -133,6 +133,9 @@ gitlink:git-ls-tree[1]::
gitlink:git-merge-base[1]::
Finds as good a common ancestor as possible for a merge
+gitlink:git-name-rev[1]::
+ Find symbolic names for given revs
+
gitlink:git-rev-list[1]::
Lists commit objects in reverse chronological order
@@ -360,6 +363,9 @@ gitlink:git-sh-setup[1]::
Common git shell script setup code.
Previously this command was known as git-sh-setup-script.
+gitlink:git-symbolic-ref[1]::
+ Read and modify symbolic refs
+
gitlink:git-tag[1]::
An example script to create a tag object signed with GPG
Previously this command was known as git-tag-script.
^ 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