* [PATCH 1/5] fetch-pack: Properly remove the shallow file when it becomes empty.
From: Alexandre Julliard @ 2006-11-24 14:58 UTC (permalink / raw)
To: git
The code was unlinking the lock file instead.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
---
fetch-pack.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fetch-pack.c b/fetch-pack.c
index d00573d..bb310b6 100644
--- a/fetch-pack.c
+++ b/fetch-pack.c
@@ -700,7 +700,7 @@ int main(int argc, char **argv)
fd = hold_lock_file_for_update(&lock, shallow, 1);
if (!write_shallow_commits(fd, 0)) {
- unlink(lock.filename);
+ unlink(shallow);
rollback_lock_file(&lock);
} else {
close(fd);
--
1.4.4.1.ga335e
--
Alexandre Julliard
^ permalink raw reply related
* Re: [PATCH] git-cvsimport: add suport for CVS pserver method HTTP/1.x proxying
From: Jeff King @ 2006-11-24 14:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfyc9cjci.fsf@assigned-by-dhcp.cox.net>
On Fri, Nov 24, 2006 at 12:57:49AM -0800, Junio C Hamano wrote:
> + # Skip up to the empty line of the proxy server output
> + # including the response headers.
> + while ($rep = <$s>) {
> + last if (!defined $rep ||
> + $rep eq "\n" ||
> + $rep eq "\r\n");
> + }
Nit: checking defined($rep) inside the loop is redundant.
^ permalink raw reply
* Re: [PATCH] Add -v and --abbrev options to git-branch
From: Jakub Narebski @ 2006-11-24 14:04 UTC (permalink / raw)
To: git
In-Reply-To: <1164375910450-git-send-email-hjemli@gmail.com>
Lars Hjemli wrote:
> The new -v option makes git-branch show the abbreviated sha1 + subjectline
> for each branch.
Isn't what git-show-ref is about? Or git-for-each-ref?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] Add -v and --abbrev options to git-branch
From: Lars Hjemli @ 2006-11-24 13:45 UTC (permalink / raw)
To: git
The new -v option makes git-branch show the abbreviated sha1 + subjectline
for each branch.
Additionally, minimum abbreviation length can be specified with
--abbrev=<length>
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
---
Documentation/git-branch.txt | 9 +++++++-
builtin-branch.c | 46 ++++++++++++++++++++++++++++++++++++-----
2 files changed, 48 insertions(+), 7 deletions(-)
diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
index 5376760..4f5b5d5 100644
--- a/Documentation/git-branch.txt
+++ b/Documentation/git-branch.txt
@@ -8,7 +8,7 @@ git-branch - List, create, or delete bra
SYNOPSIS
--------
[verse]
-'git-branch' [-r] [-a]
+'git-branch' [-r] [-a] [-v] [--abbrev=<length>]
'git-branch' [-l] [-f] <branchname> [<start-point>]
'git-branch' (-d | -D) <branchname>...
@@ -52,6 +52,13 @@ OPTIONS
-a::
List both remote-tracking branches and local branches.
+-v::
+ Show sha1 and subject message for each head.
+
+--abbrev=<length>::
+ Alter minimum display length for sha1 in output listing,
+ default value is 7.
+
<branchname>::
The name of the branch to create or delete.
The new branch name must pass all checks defined by
diff --git a/builtin-branch.c b/builtin-branch.c
index 22e3285..f14d814 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -11,7 +11,7 @@
#include "builtin.h"
static const char builtin_branch_usage[] =
-"git-branch (-d | -D) <branchname> | [-l] [-f] <branchname> [<start-point>] | [-r] | [-a]";
+"git-branch (-d | -D) <branchname> | [-l] [-f] <branchname> [<start-point>] | [-r | -a] [-v] [--abbrev=<length>] ";
static const char *head;
@@ -87,10 +87,11 @@ static void delete_branches(int argc, co
struct ref_item {
char *name;
unsigned int kind;
+ unsigned char sha1[20];
};
struct ref_list {
- int index, alloc;
+ int index, alloc, maxwidth;
struct ref_item *list;
int kinds;
};
@@ -100,6 +101,7 @@ static int append_ref(const char *refnam
struct ref_list *ref_list = (struct ref_list*)(cb_data);
struct ref_item *newitem;
int kind = REF_UNKNOWN_TYPE;
+ int len;
/* Detect kind */
if (!strncmp(refname, "refs/heads/", 11)) {
@@ -128,6 +130,10 @@ static int append_ref(const char *refnam
newitem = &(ref_list->list[ref_list->index++]);
newitem->name = xstrdup(refname);
newitem->kind = kind;
+ memcpy(newitem->sha1, sha1, 20);
+ len = strlen(newitem->name);
+ if (len > ref_list->maxwidth)
+ ref_list->maxwidth = len;
return 0;
}
@@ -151,7 +157,24 @@ static int ref_cmp(const void *r1, const
return strcmp(c1->name, c2->name);
}
-static void print_ref_list(int kinds)
+static void print_ref_info(const unsigned char *sha1, int abbrev)
+{
+ struct commit *commit;
+ char subject[256];
+
+
+ commit = lookup_commit(sha1);
+ if (commit && !parse_commit(commit))
+ pretty_print_commit(CMIT_FMT_ONELINE, commit, ~0,
+ subject, sizeof(subject), 0,
+ NULL, NULL, 0);
+ else
+ sprintf(subject, " **** invalid ref ****");
+
+ printf(" %s %s", find_unique_abbrev(sha1, abbrev), subject);
+}
+
+static void print_ref_list(int kinds, int verbose, int abbrev)
{
int i;
char c;
@@ -169,9 +192,11 @@ static void print_ref_list(int kinds)
!strcmp(ref_list.list[i].name, head))
c = '*';
- printf("%c %s\n", c, ref_list.list[i].name);
+ printf("%c %-*s", c, ref_list.maxwidth, ref_list.list[i].name);
+ if (verbose)
+ print_ref_info(ref_list.list[i].sha1, abbrev);
+ printf("\n");
}
-
free_ref_list(&ref_list);
}
@@ -215,6 +240,7 @@ static void create_branch(const char *na
int cmd_branch(int argc, const char **argv, const char *prefix)
{
int delete = 0, force_delete = 0, force_create = 0;
+ int verbose = 0, abbrev = DEFAULT_ABBREV;
int reflog = 0;
int kinds = REF_LOCAL_BRANCH;
int i;
@@ -255,6 +281,14 @@ int cmd_branch(int argc, const char **ar
reflog = 1;
continue;
}
+ if (!strncmp(arg, "--abbrev=", 9)) {
+ abbrev = atoi(arg+9);
+ continue;
+ }
+ if (!strcmp(arg, "-v")) {
+ verbose = 1;
+ continue;
+ }
usage(builtin_branch_usage);
}
@@ -268,7 +302,7 @@ int cmd_branch(int argc, const char **ar
if (delete)
delete_branches(argc - i, argv + i, force_delete);
else if (i == argc)
- print_ref_list(kinds);
+ print_ref_list(kinds, verbose, abbrev);
else if (i == argc - 1)
create_branch(argv[i], head, force_create, reflog);
else if (i == argc - 2)
--
1.4.4
^ permalink raw reply related
* git-svn: why fetching files is so slow
From: Pazu @ 2006-11-24 13:36 UTC (permalink / raw)
To: git
... compared to the standalone svn client. I'm working with repositories over
the internet, using not-so-fast links, but still, a svn checkout takes somewhere
around 5 to 10 minutes, while git-svn fetch takes at least 10 times that just to
fetch the initial revision. Later fetches also take *a lot* more time than a svn
update would.
Cheers,
-- Pazu
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Jakub Narebski @ 2006-11-24 12:41 UTC (permalink / raw)
To: git
In-Reply-To: <4566E512.4010405@xs4all.nl>
Han-Wen Nienhuys wrote:
> Jakub Narebski escreveu:
>
>>> - --pretty option with wholly uninformative options full, medium,
>>> short, raw. It's not even documented what each option does.
>>
>> And 'oneline' and undocumented 'email'. True, git lacks documentation (and
>> this one of main complaints in git survey).
>
> The recently posted patch documenting is an improvement, but why not
> add an option so you can do
>
> --format 'committer %c\nauthor %a\n'
>
> this catches all combinations, and is easier for scripting.
>
> Right now, I have some scripts that have to munge log output with
> regular expressions to strip out the "author:" prefixes.
If we ever implemented this, I'd rather to separate what is now of format
parsing in git-for-each-ref (although I'd like to make it more like rpm's
--query-format argument, with %-n{header}, %[array] etc.) into separate
module, and reuse it for git-log and friends --pretty/--format handling.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Han-Wen Nienhuys @ 2006-11-24 12:26 UTC (permalink / raw)
To: git
In-Reply-To: <ejkd6g$vog$1@sea.gmane.org>
Jakub Narebski escreveu:
>> - --pretty option with wholly uninformative options full, medium,
>> short, raw. It's not even documented what each option does.
>
> And 'oneline' and undocumented 'email'. True, git lacks documentation (and
> this one of main complaints in git survey).
The recently posted patch documenting is an improvement, but why not
add an option so you can do
--format 'committer %c\nauthor %a\n'
this catches all combinations, and is easier for scripting.
Right now, I have some scripts that have to munge log output with
regular expressions to strip out the "author:" prefixes.
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* Re: [PATCH] Make git-clone --use-separate-remote the default
From: Salikh Zakirov @ 2006-11-24 11:56 UTC (permalink / raw)
To: git
In-Reply-To: <7vslg9axzv.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> and if you write
>
> git push $remote master
>
> it is handled exactly as if you wrote:
>
> git push $remote master:master
>
> The manual correctly describes the above, but the issue the fix
> addresses is about what happens to that 'master' string that
> follows the colon, and the 'master' string becomes ambiguous if
> the remote end uses separate-remote layout.
Indeed, the manual describes it correctly.
My point is that this semantics fairly complex
and easy to understand incorrectly.
> Even under separate-remote layout, we would want to be able to
> say:
>
> git push master
>
> to mean we want to push to remote's heads/master when the remote
> has remotes/{origin,blech}/master.
I agree with your main point that 'git push master' should "just work"
for all existing and new repositories, however,
it is very confusing that 'git push master' can update something other than
refs/heads/master, depending on the refs existing in the remote repo.
^ permalink raw reply
* Re: [PATCH] git-cvsimport: add suport for CVS pserver method HTTP/1.x proxying
From: Junio C Hamano @ 2006-11-24 11:48 UTC (permalink / raw)
To: Ignacio Arenaza; +Cc: git
In-Reply-To: <67hcwp6wpp.fsf@poseidon.eteo.mondragon.edu>
Ignacio Arenaza <iarenuno@eteo.mondragon.edu> writes:
> Junio C Hamano <junkio@cox.net> writes:
>
>> Let's save a bit of trouble from you. Here is what I've queued
>> for 'master', with fixes from the discussion so far.
>
> Looks good to me, but it seems you missed the 'if(...) {' and
> 'if(...){' formating issues you raised before.
I deliberately left out the style changes to avoid cluttering
the patch; as I said in my first response, that should come as a
separate patch that does not change anything else.
^ permalink raw reply
* Re: [PATCH] Make git-clone --use-separate-remote the default
From: Junio C Hamano @ 2006-11-24 11:37 UTC (permalink / raw)
To: Sergey Vlasov; +Cc: git
In-Reply-To: <20061124143200.52aa1901.vsu@altlinux.ru>
Sergey Vlasov <vsu@altlinux.ru> writes:
> BTW, this is broken (and was broken even in 1.4.3.x):
>
> $ mkdir ~/tmp/test_repo
> $ ( cd ~/tmp/test_repo; git-init-db )
> defaulting to local storage area
> $ git push ~/tmp/test_repo tag v1.4.4.1
> error: src refspec tag does not match any.
> error: dst refspec tag does not match any existing ref on the remote and does not start with refs/.
> fatal: unexpected EOF
>
> Omitting the "tag" word works:
I think this was broken when git-push was made a built-in, and
the documentation was not updated.
I use only tags in vN.M.L.. format and Linus does so too, so
probably that was one of the reasons why this was not noticed
for quite some time.
Fixes welcome, preferably to the builtin-push.c not to the
documentation.
^ permalink raw reply
* Re: [PATCH] Make git-clone --use-separate-remote the default
From: Sergey Vlasov @ 2006-11-24 11:32 UTC (permalink / raw)
To: Salikh Zakirov; +Cc: git
In-Reply-To: <ek6glc$pn$1@sea.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 4264 bytes --]
On Fri, 24 Nov 2006 13:14:00 +0300 Salikh Zakirov wrote:
> git-push.1 has following description:
>
> Some short-cut notations are also supported.
>
> o tag <tag> means the same as refs/tags/<tag>:refs/tags/<tag>.
BTW, this is broken (and was broken even in 1.4.3.x):
$ mkdir ~/tmp/test_repo
$ ( cd ~/tmp/test_repo; git-init-db )
defaulting to local storage area
$ git push ~/tmp/test_repo tag v1.4.4.1
error: src refspec tag does not match any.
error: dst refspec tag does not match any existing ref on the remote and does not start with refs/.
fatal: unexpected EOF
Omitting the "tag" word works:
$ git push ~/tmp/test_repo v1.4.4.1
updating 'refs/tags/v1.4.4.1'
from 0000000000000000000000000000000000000000
to 21dff5f4982333d694d105595a701540d4d0d1db
Generating pack...
Done counting 28130 objects.
Deltifying 28130 objects.
100% (28130/28130) done
Writing 28130 objects.
100% (28130/28130) done
Total 28130, written 28130 (delta 19344), reused 27628 (delta 18891)
refs/tags/v1.4.4.1: 0000000000000000000000000000000000000000 -> 21dff5f4982333d694d105595a701540d4d0d1db
Seems that nobody really uses the "tag NAME" syntax...
> o A parameter <ref> without a colon is equivalent to
> <ref>:<ref>, hence updates <ref> in
> the destination from <ref> in the source.
>
> Maybe this is only my reading of manual page, but I understood
> it like it does not leave the room for ambiguity, because it is using
> _the same_ refspec as the local one.
>
> That's why, when I do
>
> git-push repo x
>
> and it results in
>
> git-push repo refs/heads/x:refs/remotes/origin/x
>
> instead of expected
>
> git-push repo refs/heads/x:refs/heads/x
>
> just because the remote repo did not have refs/heads/x, but happened
> to have refs/remotes/origin/x, would be highly surprising to me.
Such interpretation would indeed be horrible, but I'm afraid this is
exactly the case now:
$ mkdir ~/tmp/test_repo
$ ( cd ~/tmp/test_repo; git-init-db )
defaulting to local storage area
$ git push ~/tmp/test_repo v1.4.0^0:refs/remotes/origin/master
updating 'refs/remotes/origin/master' using 'v1.4.0^0'
from 0000000000000000000000000000000000000000
to 41292ddd37202ff6dce34986c87a6000c5d3fbfa
Generating pack...
Done counting 19857 objects.
Deltifying 19857 objects.
100% (19857/19857) done
Writing 19857 objects.
100% (19857/19857) done
Total 19857, written 19857 (delta 13472), reused 19038 (delta 12884)
refs/remotes/origin/master: 0000000000000000000000000000000000000000 -> 41292ddd37202ff6dce34986c87a6000c5d3fbfa
$ git push ~/tmp/test_repo master
updating 'refs/remotes/origin/master' using 'refs/heads/master'
from 41292ddd37202ff6dce34986c87a6000c5d3fbfa
to e945f95157c2c515e763ade874931fc1eb671a0b
Generating pack...
Done counting 8667 objects.
Result has 8278 objects.
Deltifying 8278 objects.
100% (8278/8278) done
Writing 8278 objects.
100% (8278/8278) done
Total 8278, written 8278 (delta 5924), reused 7396 (delta 5065)
refs/remotes/origin/master: 41292ddd37202ff6dce34986c87a6000c5d3fbfa -> e945f95157c2c515e763ade874931fc1eb671a0b
BTW, I cannot find the description of the matching algorithm used by
connect.c:count_refspec_match() anywhere in the git-push or git-fetch
man page, and I cannot understand why this algorithm is different from
the default search order ($name, refs/$name, refs/tags/$name,
refs/heads/$name, refs/remotes/$name, refs/remotes/$name/HEAD).
> The expected behaviour on 'git-push repo x' in my understanding is
> 1) git finds the exact reference for 'x' (i.e. either refs/heads/x or
> refs/tags/x) according to local lookup rules
> 2) git uses the found reference _unambiguously_ to create or update
> exactly the same reference in the remote repo.
>
> Am I the only one to have this understanding?
The problem is that "$x" and "$x:$x" would be not equivalent anymore,
unless we add a special case for "$x:$y" where $x == $y - hmm, but the
current code seems to have that special case:
else if (!strcmp(rs[i].src, rs[i].dst) &&
matched_src) {
/* pushing "master:master" when
* remote does not have master yet.
*/
(but that code triggers only in case we did not find any matching ref in
the destination repo).
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Jakub Narebski @ 2006-11-24 11:29 UTC (permalink / raw)
To: git
In-Reply-To: <E1Gn1PG-0002oW-00@skye.ra.phy.cam.ac.uk>
Sanjoy Mahajan wrote:
> The car analogy is excellently clear.
>
>> they need more than the "stupid simple" git usage, but if they don't
>> need the extreme power of git, Hg is simpler for people to learn how
>> to use.
>
> As a 80%-hg/20%-git user, I'm curious what features of git you had in
> mind, so I know where to look as I wander up the git learning curve.
>
> My experience with the git user interface, for what it's worth, is
> that I never quite get the conceptual model crystal clear enough in my
> head. So it won't stay for long enough for me to progress up the
> learning curve and retain the gains. I move up a bit, but the gain
> soon evaporates and I backslide, and then just hack my way through it.
>
> I found hg's conceptual model very easy to learn, almost as if I don't
> have to remember anything. Maybe that simplicity comes at a price,
> whence my question at the start about the extreme-power features of
> git.
As I never used Mercurial (hg), only read a bit about it and discussed on
#revctrl, I cannot say what features git has that hg has not, but I can
tell what powerfull git features differ from other SCM.
First, usually in other SCM the concept of branch is closely tied to the
concept of repository, perhaps allowing to share storage between branches
on the same local filesystem (on the same machine). In git, repository
holds DAG, the graph of revisions (of versions). Branches are "only" ways
to access this graph, and to extend it of the new commits. This makes git
more powerfull, but also perhaps unnecessary complicated if you deal with
single-branch repositories, or few-branch case. Additionally this
"complication" makes very clean model of repository - but you have to
understand it...
Second, the index. One might think that it is performance hack, but it
allows for commiting changes piece by piece and, what is more important,
a place form making merge in. Cogito (alternate Git UI/porcelain) tries to
hide index. By the way, I wonder how hg does merges without index to
provide place where do merges in...
Third, explicit/on-demand packing. This allows for the most (I think)
compression of all SCMs, and for the wire format to be the same as on-disk
format (with the addition that you can send thin packs on wire). As of now
no porcelain tries to hide it, although with the latest work allowing for
historical packs it would be easy to add this without significantly
affecting preformance.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Make git-clone --use-separate-remote the default
From: Junio C Hamano @ 2006-11-24 11:24 UTC (permalink / raw)
To: Salikh Zakirov; +Cc: git
In-Reply-To: <ek6glc$pn$1@sea.gmane.org>
Salikh Zakirov <Salikh.Zakirov@Intel.com> writes:
> git-push.1 has following description:
>
> Some short-cut notations are also supported.
>
> o tag <tag> means the same as refs/tags/<tag>:refs/tags/<tag>.
>
> o A parameter <ref> without a colon is equivalent to
> <ref>:<ref>, hence updates <ref> in
> the destination from <ref> in the source.
>
> Maybe this is only my reading of manual page, but I understood
> it like it does not leave the room for ambiguity, because it is using
> _the same_ refspec as the local one.
If you write
git push $remote tag $string
it is handled exactly as if you wrote:
git push $remote refs/tags/${string}:refs/tags/${string}
and if you write
git push $remote master
it is handled exactly as if you wrote:
git push $remote master:master
The manual correctly describes the above, but the issue the fix
addresses is about what happens to that 'master' string that
follows the colon, and the 'master' string becomes ambiguous if
the remote end uses separate-remote layout.
The way this command:
git push $remote $src:$dst
is handled is:
(0) send-pack gets ls-remote equivalent from the remote. This
tells us the set of refs the remote has and the value of
each of them.
(1) $src can be a ref that is resolved locally the usual way.
You could have any valid SHA-1 expression (e.g. HEAD~6).
(2) $dst is compared with the list of refs that the remote
has, and unique match is found. So if the set of refs the
remote side has:
refs/heads/origin
refs/heads/master
refs/tags/v1.0.0
and if $dst is 'master', refs/heads/master is what will be
updated.
(3) Then send-pack generates and sends the necessary pack to
update the remote side with objects needed for $src, using
the knowledge of what the remote has. Also, send-pack
instructs the remote to update which ref with what value.
Continuing with the example, it tells the remote to update
its refs/heads/master with the value of our 'master'.
That *matching* in step (2) is what the fix is about.
The matching code of send-pack from the beginning has been the
unique tail-match. When the other end had a branch 'bugfix' and
a tag 'bugfix', then both of them would match because both
refs/heads/bugfix and refs/tags/bugfix ends with 'bugfix'
('gfix' does not match 'refs/heads/bugfix' -- we are not that
stupid ;-).
So you had to disambiguate this case by saying heads/bugfix if
you want to push the branch. That was fine between branches and
tags, since having a branch and a tag with the same name is
usually not done in order to keep user's sanity.
However, separate-remote layout poses a more serious problem,
because most of the time you would expect to see similar names
under refs/heads/ and refs/remotes/origin/ directories. If we
kept the original ref matching code, a cloned remote would have
both refs/heads/master and refs/remotes/origin/master almost
always, so somebody who is pushing 'master' to such a remote
would have had to disambiguate it by saying:
git push heads/master
which is (as described in the part of the manual you quoted) a
shorthand for
git push heads/master:heads/master
'heads/master' before the colon is used to find out which commit
in your local repository we are pushing, and 'heads/master'
after the colon is used to match against the list of refs from
the remote (which contains both 'refs/heads/master' and
'refs/remotes/origin/master'), and only because the user said
'heads/master' (not just 'master') this avoids ambiguity.
Even under separate-remote layout, we would want to be able to
say:
git push master
to mean we want to push to remote's heads/master when the remote
has remotes/{origin,blech}/master.
And that is what the fix is about.
^ permalink raw reply
* Re: [PATCH] Make git-clone --use-separate-remote the default
From: Salikh Zakirov @ 2006-11-24 10:14 UTC (permalink / raw)
To: git
In-Reply-To: <7vpsbde4fy.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> -- >8 --
> [PATCH] refs outside refs/{heads,tags} match less strongly.
>
> Pushing 'foo' when both heads/foo and tags/foo exist at the
> remote end is still considered an error and you would need to
> disambiguate between them by being more explicit.
>
> When neither heads/foo nor tags/foo exists at the remote,
> pushing 'foo' when there is only remotes/origin/foo is not
> ambiguous, while it still is ambiguous when there are more than
> one such weaker match (remotes/origin/foo and remotes/alt/foo,
> for example).
git-push.1 has following description:
Some short-cut notations are also supported.
o tag <tag> means the same as refs/tags/<tag>:refs/tags/<tag>.
o A parameter <ref> without a colon is equivalent to
<ref>:<ref>, hence updates <ref> in
the destination from <ref> in the source.
Maybe this is only my reading of manual page, but I understood
it like it does not leave the room for ambiguity, because it is using
_the same_ refspec as the local one.
That's why, when I do
git-push repo x
and it results in
git-push repo refs/heads/x:refs/remotes/origin/x
instead of expected
git-push repo refs/heads/x:refs/heads/x
just because the remote repo did not have refs/heads/x, but happened
to have refs/remotes/origin/x, would be highly surprising to me.
The expected behaviour on 'git-push repo x' in my understanding is
1) git finds the exact reference for 'x' (i.e. either refs/heads/x or
refs/tags/x) according to local lookup rules
2) git uses the found reference _unambiguously_ to create or update exactly the
same reference in the remote repo.
Am I the only one to have this understanding?
^ permalink raw reply
* Re: [PATCH] Make git-clone --use-separate-remote the default
From: Salikh Zakirov @ 2006-11-24 9:58 UTC (permalink / raw)
To: git
In-Reply-To: <20061123225835.30071.99265.stgit@machine.or.cz>
Petr Baudis wrote:
> --- a/Documentation/git-clone.txt
> +++ b/Documentation/git-clone.txt
> ...
> --use-separate-remote::
> Save remotes heads under `$GIT_DIR/remotes/origin/` instead
> - of `$GIT_DIR/refs/heads/`. Only the master branch is saved
> - in the latter.
This description does not apply to repositories which do not have 'master' branch.
Maybe "only the HEAD branch of remote repository, where
HEAD is the branch designated as main branch in repository".
^ permalink raw reply
* [PATCH] git-svn: handle authentication without relying on cached tokens on disk
From: Eric Wong @ 2006-11-24 9:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Eric Wong
This is mostly gleaned off SVN::Mirror, with added support for
--no-auth-cache and --config-dir.
Even with this patch, git-svn does not yet support repositories
where the user only has partial read permissions.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-svn.perl | 156 +++++++++++++++++++++++++++++++++++++++++++++++++++++++---
1 files changed, 148 insertions(+), 8 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index bb8935a..47cd3e2 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -39,7 +39,7 @@ memoize('revisions_eq');
memoize('cmt_metadata');
memoize('get_commit_time');
-my ($SVN_PATH, $SVN, $SVN_LOG, $_use_lib);
+my ($SVN_PATH, $SVN, $SVN_LOG, $_use_lib, $AUTH_BATON, $AUTH_CALLBACKS);
sub nag_lib {
print STDERR <<EOF;
@@ -66,7 +66,8 @@ my ($_revision,$_stdin,$_no_ignore_ext,$
$_template, $_shared, $_no_default_regex, $_no_graft_copy,
$_limit, $_verbose, $_incremental, $_oneline, $_l_fmt, $_show_commit,
$_version, $_upgrade, $_authors, $_branch_all_refs, @_opt_m,
- $_merge, $_strategy, $_dry_run, $_ignore_nodate, $_non_recursive);
+ $_merge, $_strategy, $_dry_run, $_ignore_nodate, $_non_recursive,
+ $_username, $_config_dir, $_no_auth_cache);
my (@_branch_from, %tree_map, %users, %rusers, %equiv);
my ($_svn_co_url_revs, $_svn_pg_peg_revs);
my @repo_path_split_cache;
@@ -79,6 +80,9 @@ my %fc_opts = ( 'no-ignore-externals' =>
'repack:i' => \$_repack,
'no-metadata' => \$_no_metadata,
'quiet|q' => \$_q,
+ 'username=s' => \$_username,
+ 'config-dir=s' => \$_config_dir,
+ 'no-auth-cache' => \$_no_auth_cache,
'ignore-nodate' => \$_ignore_nodate,
'repack-flags|repack-args|repack-opts=s' => \$_repack_flags);
@@ -2683,18 +2687,154 @@ sub libsvn_load {
my $kill_stupid_warnings = $SVN::Node::none.$SVN::Node::file.
$SVN::Node::dir.$SVN::Node::unknown.
$SVN::Node::none.$SVN::Node::file.
- $SVN::Node::dir.$SVN::Node::unknown;
+ $SVN::Node::dir.$SVN::Node::unknown.
+ $SVN::Auth::SSL::CNMISMATCH.
+ $SVN::Auth::SSL::NOTYETVALID.
+ $SVN::Auth::SSL::EXPIRED.
+ $SVN::Auth::SSL::UNKNOWNCA.
+ $SVN::Auth::SSL::OTHER;
1;
};
}
+sub _simple_prompt {
+ my ($cred, $realm, $default_username, $may_save, $pool) = @_;
+ $may_save = undef if $_no_auth_cache;
+ $default_username = $_username if defined $_username;
+ if (defined $default_username && length $default_username) {
+ if (defined $realm && length $realm) {
+ print "Authentication realm: $realm\n";
+ }
+ $cred->username($default_username);
+ } else {
+ _username_prompt($cred, $realm, $may_save, $pool);
+ }
+ $cred->password(_read_password("Password for '" .
+ $cred->username . "': ", $realm));
+ $cred->may_save($may_save);
+ $SVN::_Core::SVN_NO_ERROR;
+}
+
+sub _ssl_server_trust_prompt {
+ my ($cred, $realm, $failures, $cert_info, $may_save, $pool) = @_;
+ $may_save = undef if $_no_auth_cache;
+ print "Error validating server certificate for '$realm':\n";
+ if ($failures & $SVN::Auth::SSL::UNKNOWNCA) {
+ print " - The certificate is not issued by a trusted ",
+ "authority. Use the\n",
+ " fingerprint to validate the certificate manually!\n";
+ }
+ if ($failures & $SVN::Auth::SSL::CNMISMATCH) {
+ print " - The certificate hostname does not match.\n";
+ }
+ if ($failures & $SVN::Auth::SSL::NOTYETVALID) {
+ print " - The certificate is not yet valid.\n";
+ }
+ if ($failures & $SVN::Auth::SSL::EXPIRED) {
+ print " - The certificate has expired.\n";
+ }
+ if ($failures & $SVN::Auth::SSL::OTHER) {
+ print " - The certificate has an unknown error.\n";
+ }
+ printf( "Certificate information:\n".
+ " - Hostname: %s\n".
+ " - Valid: from %s until %s\n".
+ " - Issuer: %s\n".
+ " - Fingerprint: %s\n",
+ map $cert_info->$_, qw(hostname valid_from valid_until
+ issuer_dname fingerprint) );
+ my $choice;
+prompt:
+ print $may_save ?
+ "(R)eject, accept (t)emporarily or accept (p)ermanently? " :
+ "(R)eject or accept (t)emporarily? ";
+ $choice = lc(substr(<STDIN> || 'R', 0, 1));
+ if ($choice =~ /^t$/i) {
+ $cred->may_save(undef);
+ } elsif ($choice =~ /^r$/i) {
+ return -1;
+ } elsif ($may_save && $choice =~ /^p$/i) {
+ $cred->may_save($may_save);
+ } else {
+ goto prompt;
+ }
+ $cred->accepted_failures($failures);
+ $SVN::_Core::SVN_NO_ERROR;
+}
+
+sub _ssl_client_cert_prompt {
+ my ($cred, $realm, $may_save, $pool) = @_;
+ $may_save = undef if $_no_auth_cache;
+ print "Client certificate filename: ";
+ chomp(my $filename = <STDIN>);
+ $cred->cert_file($filename);
+ $cred->may_save($may_save);
+ $SVN::_Core::SVN_NO_ERROR;
+}
+
+sub _ssl_client_cert_pw_prompt {
+ my ($cred, $realm, $may_save, $pool) = @_;
+ $may_save = undef if $_no_auth_cache;
+ $cred->password(_read_password("Password: ", $realm));
+ $cred->may_save($may_save);
+ $SVN::_Core::SVN_NO_ERROR;
+}
+
+sub _username_prompt {
+ my ($cred, $realm, $may_save, $pool) = @_;
+ $may_save = undef if $_no_auth_cache;
+ if (defined $realm && length $realm) {
+ print "Authentication realm: $realm\n";
+ }
+ my $username;
+ if (defined $_username) {
+ $username = $_username;
+ } else {
+ print "Username: ";
+ chomp($username = <STDIN>);
+ }
+ $cred->username($username);
+ $cred->may_save($may_save);
+ $SVN::_Core::SVN_NO_ERROR;
+}
+
+sub _read_password {
+ my ($prompt, $realm) = @_;
+ print $prompt;
+ require Term::ReadKey;
+ Term::ReadKey::ReadMode('noecho');
+ my $password = '';
+ while (defined(my $key = Term::ReadKey::ReadKey(0))) {
+ last if $key =~ /[\012\015]/; # \n\r
+ $password .= $key;
+ }
+ Term::ReadKey::ReadMode('restore');
+ print "\n";
+ $password;
+}
+
sub libsvn_connect {
my ($url) = @_;
- my $auth = SVN::Core::auth_open([SVN::Client::get_simple_provider(),
- SVN::Client::get_ssl_server_trust_file_provider(),
- SVN::Client::get_username_provider()]);
- my $s = eval { SVN::Ra->new(url => $url, auth => $auth) };
- return $s;
+ if (!$AUTH_BATON || !$AUTH_CALLBACKS) {
+ SVN::_Core::svn_config_ensure($_config_dir, undef);
+ ($AUTH_BATON, $AUTH_CALLBACKS) = SVN::Core::auth_open_helper([
+ SVN::Client::get_simple_provider(),
+ SVN::Client::get_ssl_server_trust_file_provider(),
+ SVN::Client::get_simple_prompt_provider(
+ \&_simple_prompt, 2),
+ SVN::Client::get_ssl_client_cert_prompt_provider(
+ \&_ssl_client_cert_prompt, 2),
+ SVN::Client::get_ssl_client_cert_pw_prompt_provider(
+ \&_ssl_client_cert_pw_prompt, 2),
+ SVN::Client::get_username_provider(),
+ SVN::Client::get_ssl_server_trust_prompt_provider(
+ \&_ssl_server_trust_prompt),
+ SVN::Client::get_username_prompt_provider(
+ \&_username_prompt, 2),
+ ]);
+ }
+ SVN::Ra->new(url => $url, auth => $AUTH_BATON,
+ auth_provider_callbacks => $AUTH_CALLBACKS);
}
sub libsvn_get_file {
--
1.4.4.1.g22a08
^ permalink raw reply related
* Re: Pull and fetch
From: Paolo Ciarrocchi @ 2006-11-24 9:30 UTC (permalink / raw)
To: Sean; +Cc: Git Mailing List
In-Reply-To: <BAYC1-PASMTP11A008C336418A659F0E75AEE20@CEZ.ICE>
On 11/23/06, Sean <seanlkml@sympatico.ca> wrote:
> On Thu, 23 Nov 2006 21:45:32 +0100
> "Paolo Ciarrocchi" <paolo.ciarrocchi@gmail.com> wrote:
> > So it fetches into testbranchpull and merge its content with master.
> > Right?
>
> Exactly. You'll hear people say, git-pull is simply a fetch + a merge.
> This is what they mean.
Fair enough.
> > Since master was empy I now have 3 identical branches if I'm getting
> > it correctly.
>
> Yes.
>
> > Not so sure I've got everything.
> >
> > If I do:
> > git checkout testbranch
> > edit file
> > git commit -a
> > git fetch ../git master:testbranch
>
> You are not allowed to fetch changes into a branch you have modified
> locally. If you use the "-f" (force) option of fetch to force it,
> your local commits will be lost.
OK
> If you want to merge remote master changes into this testbranch
> after you've updated, you'd want:
>
> git pull ../git master
>
> (which fetches the remote master into a hidden temp branch, and
> then merges it with the locally checked out branch (testbranch))
Thanks, now I think I have a clear picture. I think it's worth to add
some more info to tutorial.txt about difference between fetch and
pull. I don't believe I'm the only confused user ;-)
> > Last command will merge my local change with the remote master but
> > will keep my local master unmodified, right?
>
> No.. Fetch never merges, only copies remote data into your repo.
I was confused by the "merge" terminology, if I fetch to an empty
branch the concept of copy is easy to be understood, but if I fetch to
a branch that contains data then it's somehow more difficult to think
about fetching without thinking of "merge the remote branch into
local".
But now I think I understood it ;-)
> But you're right, your local master would be unaffected.
>
> Cheers,
> Sean
>
> P.S. Please keep the questions on the list. That way if i get something
> wrong someone will correct it. Someone else might be able to give
> you a better answer too.
Sure, sorry about that. It was not my intention, I just pressed the
wrong button :)
Regards,
--
Paolo
http://docs.google.com/View?docid=dhbdhs7d_4hsxqc8
^ permalink raw reply
* Re: [PATCH] Make git-clone --use-separate-remote the default
From: Jakub Narebski @ 2006-11-24 9:22 UTC (permalink / raw)
To: git
In-Reply-To: <7vlkm1hf57.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Petr Baudis <pasky@suse.cz> writes:
>
>>> Even though I fully agree that use-separate-remotes should be
>>> the default, to the point that I think we do not even
>>> need a backward compatibility option. People who want to use
>>> traditional layout for simple one-remote-branch-only project
>>> would not suffer anyway because 'origin' still means origin in
>>> the new layout (refs/remotes/origin/HEAD).
>>
>> I don't know, we still at least need to keep the functionality for
>> --bare.
By the way, I think the backward compatibility option should be
simply named --dont-use-separate-remote, or --without-separate-remote,
or --no-separate-remote (the last is probably the best choice).
> I agree --bare should continue to be a "snapshot mirror"; I am
> not advocating for the removal of the internal implementation
> detail such as $use_separate_remote variable.
>
> However, I think having one sane behaviour is the right thing to
> do for a clone that prepares a repository with a working tree
> (including the one made with -n option, which only means "do not
> do the check-out immediately after cloning" for such a
> repository).
>
> The traditional layout is slightly simpler for a project with
> the simplest needs (that is, a single upstream repository that
> has a single 'master' branch), but I do think even that is not
> an advantage anymore.
>
> With the separate-remote layout, git-fetch would still fetch and
> update the "origin" (although that is now remotes/origin/master
> which is pointed at by remotes/origin/HEAD) and the user can
> still refer to it with "origin". Commands "git-pull origin",
> "git-pull . origin", and "git-merge origin" all will continue to
> work the same way as before for such a project as in the
> traditional layout, and that is why I think we do not need
> backward compatibility flag in this case.
The exception being that with --use-separate-remote you cannot checkout
tracking branches to see what it is there (at least for now, but IIRC we
want to relax this constraint; i.e. to forbid commiting to non-heads,
instead of forbidding checking out), you cannot use it as alternate
source (as alternate repo to check from) while still allowing to work
on it, and that gitweb doesn't show anything except heads and tags;
it doesn't show remotes.
By the way, does new "git peek-remote -a ." show anything except
refs/heads/, refs/tags/ and refs/remotes (e.g. StGit refs/bases/
and refs/patches/)?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] git-cvsimport: add suport for CVS pserver method HTTP/1.x proxying
From: Ignacio Arenaza @ 2006-11-24 9:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfyc9cjci.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Let's save a bit of trouble from you. Here is what I've queued
> for 'master', with fixes from the discussion so far.
Looks good to me, but it seems you missed the 'if(...) {' and
'if(...){' formating issues you raised before.
Saludos. Iñaki.
--
School of Management
Mondragon University
20560 Oñati - Spain
+34 943 718009 (ext. 225)
^ permalink raw reply
* Re: [PATCH] config option core.showroot to enable showing the diff of the root commit
From: Peter Baumann @ 2006-11-24 9:04 UTC (permalink / raw)
To: git
In-Reply-To: <7vlkm1cjht.fsf@assigned-by-dhcp.cox.net>
On 2006-11-24, Junio C Hamano <junkio@cox.net> wrote:
> Peter Baumann <Peter.B.Baumann@stud.informatik.uni-erlangen.de>
> writes:
>
>> One question, what's the difference between git-log -p and
>> git-whatchanged -p?
>> ...
>> As you can see, the root commit isn't shown. Is this intentional?
>
> Some historical background.
>
> The traditional command do do log-minded things was whatchanged
> and it was implemented as
>
> git rev-list $revision_args -- $path_limits |
> git diff-tree --stdin --pretty -r $format_args
>
> and whatchanged did not give --root to diff-tree by default.
> And 'diff-tree' does not show --pretty logs when there is no
> diff to be shown (which still is true today and is a useful
> behaviour), hence no mention of the root commit.
>
> On the other hand, "git-log" traditionally looked like this:
>
> git rev-list --pretty $revision_args
>
> Back then, there was no path_limits nor even diff options to
> it.
>
> Later, Linus (with help from others) made the revision walk
> machinery as callable inside programs other than "rev-list",
> eliminating the need to pipe rev-list into diff-tree to perform
> log-minded things. That enriched what "git log" can do, and
> mostly made "whatchanged" a redundant command. As you may have
> noticed, there isn't much difference between these two commands
> in builtin-log.c; their differences are solely what default
> options for diff and revision machinery are used and are meant
> to match the traditional behaviour of these commands.
>
> So there shouldn't be any differences, really, when you override
> their defaults with the likes of -p.
>
> Honestly speaking, I do not think there was _any_ consciously
> designed intention to handle root commits, either to make these
> commands behave identically or differently; regarding parentless
> commits, they just behave the way they happen to behave, because
> root commits were not something either Linus nor I were
> interested in.
>
> Given the recent discussion, however, the intention now should
> be that Porcelain level commands should default to do --root
> (i.e. when asked to do "diff" to show how a commit without a
> parent differs from its nonexistent parent, show diff with
> emptiness).
>
Ah. I see. Thanks for the clarification.
Peter
^ permalink raw reply
* Re: [PATCH] git-cvsimport: add suport for CVS pserver method HTTP/1.x proxying
From: Junio C Hamano @ 2006-11-24 8:57 UTC (permalink / raw)
To: Ignacio Arenaza; +Cc: git
In-Reply-To: <67mz6h6xmb.fsf@poseidon.eteo.mondragon.edu>
Ignacio Arenaza <iarenuno@eteo.mondragon.edu> writes:
> ... Will send a new patch with all the
> comments made so far in a few hours.
Let's save a bit of trouble from you. Here is what I've queued
for 'master', with fixes from the discussion so far.
---
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index b54a948..4310dea 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -161,8 +161,22 @@ sub new {
sub conn {
my $self = shift;
my $repo = $self->{'fullrep'};
- if($repo =~ s/^:pserver:(?:(.*?)(?::(.*?))?@)?([^:\/]*)(?::(\d*))?//) {
- my($user,$pass,$serv,$port) = ($1,$2,$3,$4);
+ if($repo =~ s/^:pserver(?:([^:]*)):(?:(.*?)(?::(.*?))?@)?([^:\/]*)(?::(\d*))?//) {
+ my($param,$user,$pass,$serv,$port) = ($1,$2,$3,$4,$5);
+
+ my($proxyhost,$proxyport);
+ if($param && ($param =~ m/proxy=([^;]+)/)) {
+ $proxyhost = $1;
+ # Default proxyport, if not specified, is 8080.
+ $proxyport = 8080;
+ if($ENV{"CVS_PROXY_PORT"}) {
+ $proxyport = $ENV{"CVS_PROXY_PORT"};
+ }
+ if($param =~ m/proxyport=([^;]+)/){
+ $proxyport = $1;
+ }
+ }
+
$user="anonymous" unless defined $user;
my $rr2 = "-";
unless($port) {
@@ -187,13 +201,43 @@ sub conn {
}
$pass="A" unless $pass;
- my $s = IO::Socket::INET->new(PeerHost => $serv, PeerPort => $port);
- die "Socket to $serv: $!\n" unless defined $s;
+ my ($s, $rep);
+ if($proxyhost) {
+
+ # Use a HTTP Proxy. Only works for HTTP proxies that
+ # don't require user authentication
+ #
+ # See: http://www.ietf.org/rfc/rfc2817.txt
+
+ $s = IO::Socket::INET->new(PeerHost => $proxyhost, PeerPort => $proxyport);
+ die "Socket to $proxyhost: $!\n" unless defined $s;
+ $s->write("CONNECT $serv:$port HTTP/1.1\r\nHost: $serv:$port\r\n\r\n")
+ or die "Write to $proxyhost: $!\n";
+ $s->flush();
+
+ $rep = <$s>;
+
+ # The answer should look like 'HTTP/1.x 2yy ....'
+ if(!($rep =~ m#^HTTP/1\.. 2[0-9][0-9]#)) {
+ die "Proxy connect: $rep\n";
+ }
+ # Skip up to the empty line of the proxy server output
+ # including the response headers.
+ while ($rep = <$s>) {
+ last if (!defined $rep ||
+ $rep eq "\n" ||
+ $rep eq "\r\n");
+ }
+ } else {
+ $s = IO::Socket::INET->new(PeerHost => $serv, PeerPort => $port);
+ die "Socket to $serv: $!\n" unless defined $s;
+ }
+
$s->write("BEGIN AUTH REQUEST\n$repo\n$user\n$pass\nEND AUTH REQUEST\n")
or die "Write to $serv: $!\n";
$s->flush();
- my $rep = <$s>;
+ $rep = <$s>;
if($rep ne "I LOVE YOU\n") {
$rep="<unknown>" unless $rep;
^ permalink raw reply related
* Re: [PATCH] config option core.showroot to enable showing the diff of the root commit
From: Junio C Hamano @ 2006-11-24 8:54 UTC (permalink / raw)
To: Peter Baumann; +Cc: git
In-Reply-To: <slrnemd98k.a3v.Peter.B.Baumann@xp.machine.xx>
Peter Baumann <Peter.B.Baumann@stud.informatik.uni-erlangen.de>
writes:
> One question, what's the difference between git-log -p and
> git-whatchanged -p?
> ...
> As you can see, the root commit isn't shown. Is this intentional?
Some historical background.
The traditional command do do log-minded things was whatchanged
and it was implemented as
git rev-list $revision_args -- $path_limits |
git diff-tree --stdin --pretty -r $format_args
and whatchanged did not give --root to diff-tree by default.
And 'diff-tree' does not show --pretty logs when there is no
diff to be shown (which still is true today and is a useful
behaviour), hence no mention of the root commit.
On the other hand, "git-log" traditionally looked like this:
git rev-list --pretty $revision_args
Back then, there was no path_limits nor even diff options to
it.
Later, Linus (with help from others) made the revision walk
machinery as callable inside programs other than "rev-list",
eliminating the need to pipe rev-list into diff-tree to perform
log-minded things. That enriched what "git log" can do, and
mostly made "whatchanged" a redundant command. As you may have
noticed, there isn't much difference between these two commands
in builtin-log.c; their differences are solely what default
options for diff and revision machinery are used and are meant
to match the traditional behaviour of these commands.
So there shouldn't be any differences, really, when you override
their defaults with the likes of -p.
Honestly speaking, I do not think there was _any_ consciously
designed intention to handle root commits, either to make these
commands behave identically or differently; regarding parentless
commits, they just behave the way they happen to behave, because
root commits were not something either Linus nor I were
interested in.
Given the recent discussion, however, the intention now should
be that Porcelain level commands should default to do --root
(i.e. when asked to do "diff" to show how a commit without a
parent differs from its nonexistent parent, show diff with
emptiness).
^ permalink raw reply
* Re: [PATCH] archive-zip: don't use sizeof(struct ...)
From: Gerrit Pape @ 2006-11-24 8:53 UTC (permalink / raw)
To: git
In-Reply-To: <45661A7D.9070207@lsrfire.ath.cx>
On Thu, Nov 23, 2006 at 11:02:37PM +0100, Ren? Scharfe wrote:
> We can't rely on sizeof(struct zip_*) returning the sum of
> all struct members. At least on ARM padding is added at the
> end, as Gerrit Pape reported. This fixes the problem but
> still lets the compiler do the summing by introducing
> explicit padding at the end of the structs and then taking
> its offset as the combined size of the preceding members.
>
> As Junio correctly notes, the _end[] marker array's size
> must be greater than zero for compatibility with compilers
> other than gcc. The space wasted by the markers can safely
> be neglected because we only have one instance of each
> struct, i.e. in sum 3 wasted bytes on i386, and 0 on ARM. :)
>
> We still rely on the compiler to not add padding between the
> struct members, but that's reasonable given that all of them
> are unsigned char arrays.
>
> Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
^ permalink raw reply
* Re: [PATCH] git-cvsimport: add suport for CVS pserver method HTTP/1.x proxying
From: Ignacio Arenaza @ 2006-11-24 8:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Martin Langhoff
In-Reply-To: <7v64d5keke.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Also it has a style inconsistency between "if(expression) {" and
> "if(expression){", and I do not like either of them, but fixing
> that should be left to a separate patch.
I just tried to use the formating of the existing code, but
it seems I missed some lines. Will send a new patch with all the
comments made so far in a few hours.
Saludos. Iñaki.
--
School of Management
Mondragon University
20560 Oñati - Spain
+34 943 718009 (ext. 225)
^ permalink raw reply
* Re: [PATCH] git-cvsimport: add suport for CVS pserver method HTTP/1.x proxying
From: Ignacio Arenaza @ 2006-11-24 8:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Martin Langhoff
In-Reply-To: <7v64d5keke.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> The "I/O Operators" section talks about evaluating <$s> in a
> scalar context (i.e. "$rep = <$s>"), which we all know would
> return a single line, and in list context, which swallows
> everything up to EOF, an obvious disaster for this particular
> use. I couldn't find how it is defined to behave in a void
> context. By experiments I know this returns only one line, but
> it leaves me feeling somewhat uneasy.
This is scalar context, as we are using the implicit $_ variable as
the destination of the asignment. It seems it's not so obvious for
non-Perl speakers, so I'll use a clearer idiom :-)
Saludos. Iñaki.
--
School of Management
Mondragon University
20560 Oñati - Spain
+34 943 718009 (ext. 225)
^ 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