* [PATCH] send-email: auth plain/login fix
From: Zbigniew Jędrzejewski-Szmek @ 2011-09-29 17:02 UTC (permalink / raw)
To: gitster, joe, git, peff; +Cc: Zbigniew Jędrzejewski-Szmek
In-Reply-To: <1317308474.1854.8.camel@Joe-Laptop>
git send-email was not authenticating properly when communicating over
TLS with a server supporting only AUTH PLAIN and AUTH LOGIN. This is
e.g. the standard server setup under debian with exim4 and probably
everywhere where system accounts are used.
The problem (only?) exists when libauthen-sasl-cyrus-perl
(Authen::SASL::Cyrus) is installed. Importing Authen::SASL::Perl
makes Authen::SASL use the perl implementation which works
better.
The solution is based on this forum thread:
http://www.perlmonks.org/?node_id=904354.
This patch is tested by sending it. Without this fix, the interaction with
the server failed like this:
$ git send-email --smtp-encryption=tls --smtp-server=... --smtp-debug=1 change1.patch
...
Net::SMTP::SSL=GLOB(0x238f668)<<< 250-AUTH LOGIN PLAIN
Password:
Net::SMTP::SSL=GLOB(0x238f668)>>> AUTH
Net::SMTP::SSL=GLOB(0x238f668)<<< 501 5.5.2 AUTH mechanism must be specified
5.5.2 AUTH mechanism must be specified
Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
v2: - the import is performed only if it will be used
v3: - the import is performed only if it will be used, and failure is ignored
v4: - improved commit message
v5: - comment in code
git-send-email.perl | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 98ab33a..f2a6e46 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -1095,6 +1095,12 @@ X-Mailer: git-send-email $gitversion
}
if (defined $smtp_authuser) {
+ # Workaround AUTH PLAIN/LOGIN interaction defect
+ # with Authen::SASL::Cyrus
+ eval {
+ require Authen::SASL;
+ Authen::SASL->import(qw(Perl));
+ };
if (!defined $smtp_authpass) {
--
1.7.6
^ permalink raw reply related
* Re: git bundle unbundle and "check-outable" refs
From: Jakub Narebski @ 2011-09-29 17:20 UTC (permalink / raw)
To: Todd A. Jacobs; +Cc: git
In-Reply-To: <dec8c877-bd6e-4120-b045-87179d54abe2@i30g2000yqd.googlegroups.com>
"Todd A. Jacobs" <nospam+listmail@codegnome.org> writes:
> Never having needed git bundle before, I've recently been using it as
> a sneakernet. In particular, I'm using bundles to work around
> limitations of filesystem semantics on vfat and hpfs+ drives when
> shared between Linux and OS X systems. The systems are air-gapped, so
> sneakernet is essential.
>
> At any rate, the issue I'm dealing with is that "git bundle unbundle"
> is sort of non-intuitive to deal with. [...]
I guess the fault is with "git bundle" documentation.
The "Example" section of git-bundle(1) manpage shows that you can use
path to bundle in place of URL to repository in "git clone". Actually
you can use path to bundle anywhere where URL or nickname of
repository is/can be used, i.e.:
git remote add <name> <bundle>
git fetch <bundle> [<refspec>...]
git pull <bundle> [<refspec>...]
git ls-remote <bundle>
HTH
--
Jakub Narębski
^ permalink raw reply
* Trying to Contact GIT
From: Siegel, Steven N. (GSFC-585.0)[TELOPHASE CORP] @ 2011-09-29 17:03 UTC (permalink / raw)
To: git@vger.kernel.org
I am in the process of looking at some vendor's Configuration Management Tools for evaluation for use by some NASA projects. I have searched the Internet for information and your company is one of the ones we would like to evaluate. I have a small questioner that I would like to send to you and to evaluate your responses as required by NASA. This is being conducted in order to see what kind of support and feedback we can expect from your company. I do not see a means of adding an attachment to a particular person of group and would appreciate an e-mail address to send the questioner to. Thanks
Steven Siegel
Telophase Corporation
http://www.telophase.com
ssiegel@telophase.com
Cell (301) 452-2352
NASA Phone: (301) 614-5409 or x45409
NASA e-mail: steven.n.siegel@nasa.gov
^ permalink raw reply
* Re: Trying to Contact GIT
From: Martin Langhoff @ 2011-09-29 17:58 UTC (permalink / raw)
To: Siegel, Steven N. (GSFC-585.0)[TELOPHASE CORP]; +Cc: git@vger.kernel.org
In-Reply-To: <5F8BAEE72620A649B90E75296A7CBF10ABD4B0E65F@NDMSSCC04.ndc.nasa.gov>
On Thu, Sep 29, 2011 at 1:03 PM, Siegel, Steven N.
(GSFC-585.0)[TELOPHASE CORP] <steven.n.siegel@nasa.gov> wrote:
> I am in the process of looking at some vendor's Configuration Management Tools for evaluation for use by some NASA projects.
Hi Steven
I know for a fact that NASA and JPL use free and open source software
internally. They probably have an appropriate procedure to evaluate
such software -- perhaps one that is a bit different from treating the
FOSS project as if it were an old-style software vendor.
Alternatively, there are a couple of companies that offer git-related
services (hosting, training...); their people are on this list, or you
can look at the 'hosting' section of http://git-scm.com/tools
hth,
m
--
martin.langhoff@gmail.com
martin@laptop.org -- Software Architect - OLPC
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
^ permalink raw reply
* Re: In favor of "git commit --no-parent"
From: Junio C Hamano @ 2011-09-29 18:11 UTC (permalink / raw)
To: Michael Witten
Cc: Carlos Martín Nieto, vra5107, Michael J Gruber, Matthieu Moy,
Eric Raible, Philip Oakley, Jeff King, Jay Soffian, git
In-Reply-To: <271cc2ed03774b4988bb61cb3e79750e-mfwitten@gmail.com>
Michael Witten <mfwitten@gmail.com> writes:
> On Wed, 28 Sep 2011 13:34:22 -0700, Junio C Hamano wrote:
>
>> If you are bootstrapping a new open source project from the tip of a
>> proprietary tree, "checkout --orphan && edit to sanitize && commit" to
>> start your history afresh would be perfectly adequate for your PR people
>> to say "Now we are open".
>
> So, the two usages for a new root commit are:
>
> * Separate History
> * Hidden History
> As it turns out, the command:
>
> git checkout --orphan
>
> which should be renamed:
>
> git checkout --no-parent
I doubt that "should be" is anywhere near consensus.
> is best for the "Separate History" case,...
Step back a bit. There are two independent issues:
- When does it make sense to originate two independent histories in a
single repository that has a working tree?
- What is the best tool to originate a new independent history in a
single repository that has a working tree?
As I said number of times already, be it done with "checkout --orphan" or
"commit --no-parent", the "Separate History" use case is better done in a
separate repository. There is *no* advantage to originate the two separate
histories that do not share any resemblance of tree shape as branches in a
single repository with a working tree; "git checkout $branch" between the
two would actively work against you.
You are of course free to push from these separate repositories that have
disjoint roots of their own into a single distribution repository for
people to fetch from, if you want Separate Histories in a distribution
point.
That leaves "Hidden History" the only useful use case. IOW, the answer to
the first question above is not "Separate or Hidden History", but is
"Hidden History and nothing else".
And a half of the the answer to the second question is "checkout --orphan"
(and the other half would be "filter-branch"). "checkout --orphan" does
have major safety advantage than introducing "commit --no-parent", as Peff
pointed out earlier (to which I agreed).
^ permalink raw reply
* Re: [PATCH] send-email: auth plain/login fix
From: Junio C Hamano @ 2011-09-29 18:12 UTC (permalink / raw)
To: Zbigniew Jędrzejewski-Szmek; +Cc: joe, git, peff
In-Reply-To: <1317315765-5471-1-git-send-email-zbyszek@in.waw.pl>
Thanks.
^ permalink raw reply
* Re: Git is not scalable with too many refs/*
From: Julian Phillips @ 2011-09-29 18:26 UTC (permalink / raw)
To: Martin Fick; +Cc: Christian Couder, git, Christian Couder, Thomas Rast
In-Reply-To: <201109291038.45290.mfick@codeaurora.org>
On Thu, 29 Sep 2011 10:38:44 -0600, Martin Fick wrote:
> On Wednesday, September 28, 2011 08:19:16 pm Julian Phillips
> wrote:
-- snip --
>> However, I had forgotten to make the orphaned commit as
>> you suggest - and then _bang_ 7N^2, it tries seven
>> different variants of each ref (which is silly as they
>> are all fully qualified), and with packed refs it has to
>> search for them each time, all to turn names into hashes
>> that we already know to start with.
>>
>> So, yes - it is that list traversal.
>>
>> Does the following help?
>>
>> diff --git a/builtin/checkout.c b/builtin/checkout.c
>> index 5e356a6..f0f4ca1 100644
>> --- a/builtin/checkout.c
>> +++ b/builtin/checkout.c
>> @@ -605,7 +605,7 @@ static int
>> add_one_ref_to_rev_list_arg(const char *refname,
>> int flags,
>> void *cb_data)
>> {
>> - add_one_rev_list_arg(cb_data, refname);
>> + add_one_rev_list_arg(cb_data,
>> strdup(sha1_to_hex(sha1))); return 0;
>> }
>
>
> Yes, but in some strange ways. :)
>
> First, let me clarify that all the tests here involve your
> "sort fix" from 2 days ago applied first.
>
> In the packed ref repo, it brings the time down to about
> ~10s (from > 5 mins). In the unpacked ref repo, it brings
> it down to about the same thing ~10s, but it was only
> starting at about ~20s.
>
> So, I have to ask, what does that change do, I don't quite
> understand it? Does it just do only one lookup per ref by
> normalizing it? Is the list still being traversed, just
> about 7 time less now?
In order to check for orphaned commits, checkout effectively calls
rev-list passing it a list of the names of all the refs as input. The
rev-list code then has to go through this list and convert each entry
into an actual hash that it can look up in the object database. This is
where the N^2 comes in for packed refs, as it calles resolve_ref() for
each ref in the list (N), which then loops through the list of all refs
(N) to find a match. However, the code that creates the list of refs to
pass to the rev-list code already knows the hash for each ref. So the
change above passes the hashes to rev-list, which then doesn't need to
lookup the ref - it just converts the string form hash back to binary
form, avoiding the N^2 work altogether. This is why packed and unpacked
are about the same speed, as they are now doing the same amount of work.
> Should the packed_ref list simply be
> put in an array which could be binary searched instead, it
> is a fixed list once loaded, no?
A quick look at the code suggests that probably both the list of loose
refs, and the list of packed refs could both be stored as binary
searchable arrays, or in an ordered hash table. Though whether it is
actually necessary I don't know. So far, it seems to have been possible
to fix performance issues whilst keeping the simple lists ...
> I prototyped a packed_ref implementation using the hash.c
> provided in the git sources and it seemed to speed a
> checkout up to almost instantaneous, but I was getting a few
> collisions so the implementation was not good enough. That
> is when I started to wonder if an array wouldn't be better
> in this case?
>
>
>
> Now I also decided to go back and test a noop fetch (a
> refetch) of all the changes (since this use case is still
> taking way longer than I think it should, even with the
> submodule fix posted earlier). Up until this point, even
> the sorting fix did not help. So I tried it with this fix.
> In the unpackref case, it did not seem to change (2~4mins).
> However, in the packed ref change (which was previously also
> about 2-4mins), this now only takes about 10-15s!
>
> Any clues as to why the unpacked refs would still be so slow
> on noop fetches and not be sped up by this?
Not really. I wouldn't expect this change to have any effect on fetch,
but I haven't actually looked into it.
--
Julian
^ permalink raw reply
* Re: Git is not scalable with too many refs/*
From: René Scharfe @ 2011-09-29 18:27 UTC (permalink / raw)
To: Julian Phillips
Cc: Martin Fick, Christian Couder, git, Christian Couder, Thomas Rast,
Junio C Hamano
In-Reply-To: <7c0105c6cca7dd0aa336522f90617fe4@quantumfyre.co.uk>
Am 29.09.2011 04:19, schrieb Julian Phillips:
> Does the following help?
>
> diff --git a/builtin/checkout.c b/builtin/checkout.c
> index 5e356a6..f0f4ca1 100644
> --- a/builtin/checkout.c
> +++ b/builtin/checkout.c
> @@ -605,7 +605,7 @@ static int add_one_ref_to_rev_list_arg(const char
> *refname,
> int flags,
> void *cb_data)
> {
> - add_one_rev_list_arg(cb_data, refname);
> + add_one_rev_list_arg(cb_data, strdup(sha1_to_hex(sha1)));
> return 0;
> }
Hmm. Can we get rid of the multiple ref lookups fixed by the above
*and* the overhead of dealing with a textual argument list at the same
time by calling add_pending_object directly, like this? (Factoring
out add_pending_sha1 should be a separate patch..)
René
---
builtin/checkout.c | 39 ++++++++++++---------------------------
revision.c | 11 ++++++++---
revision.h | 1 +
3 files changed, 21 insertions(+), 30 deletions(-)
diff --git a/builtin/checkout.c b/builtin/checkout.c
index 5e356a6..84e0cdc 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -588,24 +588,11 @@ static void update_refs_for_switch(struct checkout_opts *opts,
report_tracking(new);
}
-struct rev_list_args {
- int argc;
- int alloc;
- const char **argv;
-};
-
-static void add_one_rev_list_arg(struct rev_list_args *args, const char *s)
-{
- ALLOC_GROW(args->argv, args->argc + 1, args->alloc);
- args->argv[args->argc++] = s;
-}
-
-static int add_one_ref_to_rev_list_arg(const char *refname,
- const unsigned char *sha1,
- int flags,
- void *cb_data)
+static int add_pending_uninteresting_ref(const char *refname,
+ const unsigned char *sha1,
+ int flags, void *cb_data)
{
- add_one_rev_list_arg(cb_data, refname);
+ add_pending_sha1(cb_data, refname, sha1, flags | UNINTERESTING);
return 0;
}
@@ -685,19 +672,17 @@ static void suggest_reattach(struct commit *commit, struct rev_info *revs)
*/
static void orphaned_commit_warning(struct commit *commit)
{
- struct rev_list_args args = { 0, 0, NULL };
struct rev_info revs;
-
- add_one_rev_list_arg(&args, "(internal)");
- add_one_rev_list_arg(&args, sha1_to_hex(commit->object.sha1));
- add_one_rev_list_arg(&args, "--not");
- for_each_ref(add_one_ref_to_rev_list_arg, &args);
- add_one_rev_list_arg(&args, "--");
- add_one_rev_list_arg(&args, NULL);
+ struct object *object = &commit->object;
init_revisions(&revs, NULL);
- if (setup_revisions(args.argc - 1, args.argv, &revs, NULL) != 1)
- die(_("internal error: only -- alone should have been left"));
+ setup_revisions(0, NULL, &revs, NULL);
+
+ object->flags &= ~UNINTERESTING;
+ add_pending_object(&revs, object, sha1_to_hex(object->sha1));
+
+ for_each_ref(add_pending_uninteresting_ref, &revs);
+
if (prepare_revision_walk(&revs))
die(_("internal error in revision walk"));
if (!(commit->object.flags & UNINTERESTING))
diff --git a/revision.c b/revision.c
index c46cfaa..2e8aa33 100644
--- a/revision.c
+++ b/revision.c
@@ -185,6 +185,13 @@ static struct object *get_reference(struct rev_info *revs, const char *name, con
return object;
}
+void add_pending_sha1(struct rev_info *revs, const char *name,
+ const unsigned char *sha1, unsigned int flags)
+{
+ struct object *object = get_reference(revs, name, sha1, flags);
+ add_pending_object(revs, object, name);
+}
+
static struct commit *handle_commit(struct rev_info *revs, struct object *object, const char *name)
{
unsigned long flags = object->flags;
@@ -832,9 +839,7 @@ struct all_refs_cb {
static int handle_one_ref(const char *path, const unsigned char *sha1, int flag, void *cb_data)
{
struct all_refs_cb *cb = cb_data;
- struct object *object = get_reference(cb->all_revs, path, sha1,
- cb->all_flags);
- add_pending_object(cb->all_revs, object, path);
+ add_pending_sha1(cb->all_revs, path, sha1, cb->all_flags);
return 0;
}
diff --git a/revision.h b/revision.h
index 3d64ada..4541265 100644
--- a/revision.h
+++ b/revision.h
@@ -191,6 +191,7 @@ extern void add_object(struct object *obj,
const char *name);
extern void add_pending_object(struct rev_info *revs, struct object *obj, const char *name);
+extern void add_pending_sha1(struct rev_info *revs, const char *name, const unsigned char *sha1, unsigned int flags);
extern void add_head_to_pending(struct rev_info *);
--
1.7.7.rc1
^ permalink raw reply related
* Re: In favor of "git commit --no-parent"
From: Michael Witten @ 2011-09-29 18:52 UTC (permalink / raw)
To: Junio C Hamano
Cc: Carlos Martín Nieto, vra5107, Michael J Gruber, Matthieu Moy,
Eric Raible, Philip Oakley, Jeff King, Jay Soffian, git
In-Reply-To: <7vmxdnte0j.fsf@alter.siamese.dyndns.org>
On Thu, Sep 29, 2011 at 18:11, Junio C Hamano <gitster@pobox.com> wrote:
> That leaves "Hidden History" the only useful use case. IOW, the answer to
> the first question above is not "Separate or Hidden History", but is
> "Hidden History and nothing else".
>
> And a half of the the answer to the second question is "checkout --orphan"
> (and the other half would be "filter-branch").
Uh... no.
If you think that "Hidden History" is all that matters, then you think that
git commit --no-parent
is all that matters.
That's what my email was showing.
> "checkout --orphan" does
> have major safety advantage than introducing "commit --no-parent", as Peff
> pointed out earlier (to which I agreed).
Did I not provide in my previous email a decent safety mechanism?
^ permalink raw reply
* [PATCH] Documentation/git-checkout.txt: Explain --orphan without introducing an undefined "orphan branch"
From: Junio C Hamano @ 2011-09-29 18:59 UTC (permalink / raw)
To: git
Cc: Michael Witten, Carlos Martín Nieto, vra5107,
Michael J Gruber, Matthieu Moy, Eric Raible, Philip Oakley,
Jeff King, Jay Soffian
In-Reply-To: <7vmxdnte0j.fsf@alter.siamese.dyndns.org>
The name of the `--orphan` option to `checkout` is meant to express that
the next commit made on the branch does not have any parent (specifically,
it will not be a child of the current nor start_point commit), but the
glossary calls such a commit 'a root commit'. The explanation however used
an undefined term 'orphan branch', adding mental burden to the first time
readers.
Reword the description to clarify what it does without introducing a new
term, stressing that it is similar to what happens to the "master' branch
in a brand new repository created by `git init`. Also explain that it is
OK to tweak the index and the working tree before creating a commit.
Also mildly discourage the users from using this to originate a new root
commit that tracks material that is unrelated to the main branches in a
single repository with a working tree, and hint a better way of starting
an unrelated history, as it seems to be a common abuse of this option.
We may want to give a synonym `--new-root` to this option and eventually
deprecate the `--orphan` option, as "parent vs orphan" might not
immediately "click" to non native speakers of English (like myself), but
that is a separate topic.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* I am inclined to suggest doing something like this instead.
Documentation/git-checkout.txt | 26 ++++++++++++++------------
1 files changed, 14 insertions(+), 12 deletions(-)
diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index c0a96e6..63d164e 100644
--- a/Documentation/git-checkout.txt
+++ b/Documentation/git-checkout.txt
@@ -125,16 +125,16 @@ explicitly give a name with '-b' in such a case.
below for details.
--orphan::
- Create a new 'orphan' branch, named <new_branch>, started from
- <start_point> and switch to it. The first commit made on this
- new branch will have no parents and it will be the root of a new
- history totally disconnected from all the other branches and
- commits.
+ Adjust the working tree and the index as if you checked out the
+ <start_point>. The next commit begins a history that is not connected
+ to any other branches, as if you ran `git init` in a new repository,
+ except that the commit will be made on the <new_branch> branch, not on
+ the "master" branch.
+
-The index and the working tree are adjusted as if you had previously run
-"git checkout <start_point>". This allows you to start a new history
-that records a set of paths similar to <start_point> by easily running
-"git commit -a" to make the root commit.
+Running "git commit" immediately after doing this will record a root commit
+with a tree that is the same as the tree of the <start_point>. You may
+manipulate the index before creating the commit to record a tree that is
+different from that of the <start_point>.
+
This can be useful when you want to publish the tree from a commit
without exposing its full history. You might want to do this to publish
@@ -143,11 +143,13 @@ whose full history contains proprietary or otherwise encumbered bits of
code.
+
If you want to start a disconnected history that records a set of paths
-that is totally different from the one of <start_point>, then you should
-clear the index and the working tree right after creating the orphan
-branch by running "git rm -rf ." from the top level of the working tree.
+that is totally different from the one of <start_point>, you could
+clear the index and the working tree right after "git checkout --orphan"
+by running "git rm -rf ." from the top level of the working tree.
Afterwards you will be ready to prepare your new files, repopulating the
working tree, by copying them from elsewhere, extracting a tarball, etc.
+However, such a use case to keep track of a history that is unrelated to
+the main project is better done by starting a new, separate repository.
-m::
--merge::
^ permalink raw reply related
* Re: [PATCH] Documentation/git-checkout.txt: Explain --orphan without introducing an undefined "orphan branch"
From: Michael Witten @ 2011-09-29 19:02 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Carlos Martín Nieto, vra5107, Michael J Gruber,
Matthieu Moy, Eric Raible, Philip Oakley, Jeff King, Jay Soffian
In-Reply-To: <7v39fftbt0.fsf@alter.siamese.dyndns.org>
On Thu, Sep 29, 2011 at 18:59, Junio C Hamano <gitster@pobox.com> wrote:
> The name of the `--orphan` option to `checkout` is meant to express that
> the next commit made on the branch does not have any parent (specifically,
> it will not be a child of the current nor start_point commit), but the
> glossary calls such a commit 'a root commit'. The explanation however used
> an undefined term 'orphan branch', adding mental burden to the first time
> readers.
>
> Reword the description to clarify what it does without introducing a new
> term, stressing that it is similar to what happens to the "master' branch
> in a brand new repository created by `git init`. Also explain that it is
> OK to tweak the index and the working tree before creating a commit.
>
> Also mildly discourage the users from using this to originate a new root
> commit that tracks material that is unrelated to the main branches in a
> single repository with a working tree, and hint a better way of starting
> an unrelated history, as it seems to be a common abuse of this option.
>
> We may want to give a synonym `--new-root` to this option and eventually
> deprecate the `--orphan` option, as "parent vs orphan" might not
> immediately "click" to non native speakers of English (like myself), but
> that is a separate topic.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
>
> * I am inclined to suggest doing something like this instead.
>
> Documentation/git-checkout.txt | 26 ++++++++++++++------------
> 1 files changed, 14 insertions(+), 12 deletions(-)
>
> diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
> index c0a96e6..63d164e 100644
> --- a/Documentation/git-checkout.txt
> +++ b/Documentation/git-checkout.txt
> @@ -125,16 +125,16 @@ explicitly give a name with '-b' in such a case.
> below for details.
>
> --orphan::
> - Create a new 'orphan' branch, named <new_branch>, started from
> - <start_point> and switch to it. The first commit made on this
> - new branch will have no parents and it will be the root of a new
> - history totally disconnected from all the other branches and
> - commits.
> + Adjust the working tree and the index as if you checked out the
> + <start_point>. The next commit begins a history that is not connected
> + to any other branches, as if you ran `git init` in a new repository,
> + except that the commit will be made on the <new_branch> branch, not on
> + the "master" branch.
> +
> -The index and the working tree are adjusted as if you had previously run
> -"git checkout <start_point>". This allows you to start a new history
> -that records a set of paths similar to <start_point> by easily running
> -"git commit -a" to make the root commit.
> +Running "git commit" immediately after doing this will record a root commit
> +with a tree that is the same as the tree of the <start_point>. You may
> +manipulate the index before creating the commit to record a tree that is
> +different from that of the <start_point>.
> +
> This can be useful when you want to publish the tree from a commit
> without exposing its full history. You might want to do this to publish
> @@ -143,11 +143,13 @@ whose full history contains proprietary or otherwise encumbered bits of
> code.
> +
> If you want to start a disconnected history that records a set of paths
> -that is totally different from the one of <start_point>, then you should
> -clear the index and the working tree right after creating the orphan
> -branch by running "git rm -rf ." from the top level of the working tree.
> +that is totally different from the one of <start_point>, you could
> +clear the index and the working tree right after "git checkout --orphan"
> +by running "git rm -rf ." from the top level of the working tree.
> Afterwards you will be ready to prepare your new files, repopulating the
> working tree, by copying them from elsewhere, extracting a tarball, etc.
> +However, such a use case to keep track of a history that is unrelated to
> +the main project is better done by starting a new, separate repository.
>
> -m::
> --merge::
>
Fsck-you-by: Michael Witten <mfwitten@gmail.com>
^ permalink raw reply
* Re: Git is not scalable with too many refs/*
From: Junio C Hamano @ 2011-09-29 19:10 UTC (permalink / raw)
To: René Scharfe
Cc: Julian Phillips, Martin Fick, Christian Couder, git,
Christian Couder, Thomas Rast
In-Reply-To: <4E84B89F.4060304@lsrfire.ath.cx>
René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
> Hmm. Can we get rid of the multiple ref lookups fixed by the above
> *and* the overhead of dealing with a textual argument list at the same
> time by calling add_pending_object directly, like this? (Factoring
> out add_pending_sha1 should be a separate patch..)
I haven't tested it or thought about it through, but it smells right ;-)
Also we would probably want to drop "next" field from "struct ref_list"
(i.e. making it not a linear list), introduce a new "struct ref_array"
that is a ALLOC_GROW() managed array of pointers to "struct ref_list",
make get_packed_refs() and get_loose_refs() return a pointer to "struct
ref_array" after sorting the array contents by "name". Then resolve_ref()
can do a bisection search in the packed refs array when it does not find a
loose ref.
^ permalink raw reply
* Re: Git is not scalable with too many refs/*
From: Julian Phillips @ 2011-09-29 19:10 UTC (permalink / raw)
To: René Scharfe
Cc: Martin Fick, Christian Couder, git, Christian Couder, Thomas Rast,
Junio C Hamano
In-Reply-To: <4E84B89F.4060304@lsrfire.ath.cx>
On Thu, 29 Sep 2011 20:27:43 +0200, René Scharfe wrote:
> Am 29.09.2011 04:19, schrieb Julian Phillips:
>> Does the following help?
>>
>> diff --git a/builtin/checkout.c b/builtin/checkout.c
>> index 5e356a6..f0f4ca1 100644
>> --- a/builtin/checkout.c
>> +++ b/builtin/checkout.c
>> @@ -605,7 +605,7 @@ static int add_one_ref_to_rev_list_arg(const
>> char
>> *refname,
>> int flags,
>> void *cb_data)
>> {
>> - add_one_rev_list_arg(cb_data, refname);
>> + add_one_rev_list_arg(cb_data, strdup(sha1_to_hex(sha1)));
>> return 0;
>> }
>
> Hmm. Can we get rid of the multiple ref lookups fixed by the above
> *and* the overhead of dealing with a textual argument list at the
> same
> time by calling add_pending_object directly, like this? (Factoring
> out add_pending_sha1 should be a separate patch..)
Seems like a good idea. I get the same sort of times as with my patch,
but it makes the code _feel_ much nicer (and slightly smaller). Mine
was definitely more of a "it's 2am, but I think the problem is here"
type of patch ;)
--
Julian
^ permalink raw reply
* Re: [PATCH v2 4/4] upload-archive: use start_command instead of fork
From: Erik Faye-Lund @ 2011-09-29 19:54 UTC (permalink / raw)
To: Jeff King, msysGit; +Cc: René Scharfe, Johannes Sixt, Junio C Hamano, git
In-Reply-To: <20110809200504.GA31944@sigill.intra.peff.net>
OK, this is quite late, but I've got some news on the subject.
On Tue, Aug 9, 2011 at 10:05 PM, Jeff King <peff@peff.net> wrote:
> On Tue, Aug 09, 2011 at 12:25:42PM +0200, René Scharfe wrote:
>
>> > BTW, as nice as this "gzip -cn | cat" idea is, I think it needs to be
>> > wrapped in a shell script. With the code above, we will generate "gzip
>> > -cn | cat -9".
>>
>> Yes, the three added lines in the patch above would have to be moved
>> down two lines, after the compression level is added. D'oh!
>
> Also, is adding "| cat" also sufficient for arbitrary shell code (i.e.,
> whatever the user hands us via the config)? I couldn't think of an
> example that wouldn't work.
>
>> OK, that's one way to do it; another would be let gzip (and bzip2 etc.)
>> do whatever cat does to avoid end of line conversions. And yet another
>> is to take them from http://unxutils.sourceforge.net/.
>
> Yeah, I like all of those solutions better than hacking an extra pipe
> into git. I don't know enough to say how painful they are in practice,
> though.
>
It turns out, if I compile gzip myself from source the test pass just
fine. So the problem seems indeed to be MSYS vs non-MSYS applications.
So the way forward is probably to just change to a self-compiled gzip
in msysGit (and Git for Windows by proxy).
I'll post the patch to build a native-gzip to the msysGit mailing list
(I only got 1.2.4 to compile on Windows, but it's the same version as
we have in msysGit so it's probably fine), and post the latest version
of this series soon...
^ permalink raw reply
* Re: [PATCH v4] Docs: git checkout --orphan: Copyedit, and s/root commit/orphan branch/
From: Philip Oakley @ 2011-09-29 20:05 UTC (permalink / raw)
To: Michael Witten, Junio C Hamano
Cc: Carlos Martín Nieto, vra5107, Michael J Gruber, Matthieu Moy,
Eric Raible, Jeff King, Jay Soffian, git
In-Reply-To: <3cba6bb85bde4f96903b2b617190a2b8-mfwitten@gmail.com>
From: "Michael Witten" <mfwitten@gmail.com>
> It's copyediting; it's best just to read the damn patch, particularly when
> there are no subtle details to be considered beyond the exhausting game of
> making everybody involved in the email thread feel like he or she has
> gotten
> a portion of the bikeshed painted a certain color.
>
> See:
>
> Re: Can a git changeset be created with no parent
> Carlos Martín Nieto <cmn@elego.de>
> Message-ID: <1317073309.5579.9.camel@centaur.lab.cmartin.tk>
>
> Signed-off-by: Michael Witten <mfwitten@gmail.com>
> ---
> Documentation/git-checkout.txt | 69
> ++++++++++++++++++++++++++++-----------
> 1 files changed, 49 insertions(+), 20 deletions(-)
>
> diff --git a/Documentation/git-checkout.txt
> b/Documentation/git-checkout.txt
> index c0a96e6..bf042c2 100644
> --- a/Documentation/git-checkout.txt
> +++ b/Documentation/git-checkout.txt
> @@ -125,29 +125,58 @@ explicitly give a name with '-b' in such a case.
> below for details.
>
> ---orphan::
> - Create a new 'orphan' branch, named <new_branch>, started from
> - <start_point> and switch to it. The first commit made on this
> - new branch will have no parents and it will be the root of a new
> - history totally disconnected from all the other branches and
> - commits.
> -+
> -The index and the working tree are adjusted as if you had previously run
> -"git checkout <start_point>". This allows you to start a new history
> -that records a set of paths similar to <start_point> by easily running
> -"git commit -a" to make the root commit.
> -+
> -This can be useful when you want to publish the tree from a commit
> -without exposing its full history. You might want to do this to publish
> -an open source branch of a project whose current tree is "clean", but
> -whose full history contains proprietary or otherwise encumbered bits of
> -code.
> -+
> -If you want to start a disconnected history that records a set of paths
> -that is totally different from the one of <start_point>, then you should
> -clear the index and the working tree right after creating the orphan
> -branch by running "git rm -rf ." from the top level of the working tree.
> -Afterwards you will be ready to prepare your new files, repopulating the
> -working tree, by copying them from elsewhere, extracting a tarball, etc.
> +--orphan::
> + Perform these two tasks:
> ++
> +--
> + * Adjust the working tree and index as if you ran
> + "git checkout <start_point>".
> +
> + * Set up git to turn the next commit you create into a root commit
> + (that is, a commit without any parent); creating the next commit
> + is similar to creating the first commit after running "git init",
> + except that the new commit will be referenced by <new_branch>
> + rather than "master".
> +--
> ++
> +Then, by just running "git commit", you can create a root commit
> +with a tree that is exactly the same as the tree of <start_point>.
> +Alternatively, before creating the commit, you may manipulate the
> +index in any way you want; for example, to create a root commit with
> +a tree that is totally different from the tree of <start_point>,
> +just clear the working tree and index first: From the top level of
> +the working tree, run "git rm -rf .", and then prepare your new
> +working tree and index as desired.
> ++
> +There are two common uses for this option:
> ++
> +--
> + Separate history::
Can I suggest "Distinct History::" as this title.
'separate' is both a verb and a noun, and it is easy to misread the title as
if it is the verb, which would then be describing the action of creating the
hidden history (the second title), with resulting misunderstanding.
"Distinct" avoids the problem. The use of 'seperate' at the end is in
context, so not an issue.
> + Suppose that for convenience, you want to maintain
> + in the same repository as your project some ancillary
> + material that is infrequently altered. In such a case,
> + it may not make much sense to interleave the history of
> + that material with the history of your project; you can
> + use the "--orphan" option in order to create completely
> + separate histories.
> +
> + Hidden history::
> + Suppose you have a project that has proprietary
> + material that is never meant to be released to the
> + public, yet you now want to maintain an open source
> + history that may be published widely.
> ++
> +In this case, it would not be enough just to remove the proprietary
> +material from the working tree and then create a new commit, because
> +the proprietary material would still be accessible through the new
> +commit's ancestry; the proprietary history must be hidden from the new
> +commit, and the "--orphan" option allows you to do so by ensuring that
> +the new commit has no parent.
> ++
> +However, when there are multiple commits that are already suitable for
> +the open source history (or that you want to make suitable), you should
> +instead consider working with linkgit:git-filter-branch[1] and possibly
> +linkgit:git-rebase[1].
> +--
>
> -m::
> --merge::
> --
> 1.7.6.409.ge7a85
>
^ permalink raw reply
* Re: Git is not scalable with too many refs/*
From: Martin Fick @ 2011-09-29 20:11 UTC (permalink / raw)
To: René Scharfe
Cc: Julian Phillips, Christian Couder, git, Christian Couder,
Thomas Rast, Junio C Hamano
In-Reply-To: <4E84B89F.4060304@lsrfire.ath.cx>
On Thursday, September 29, 2011 12:27:43 pm René Scharfe
wrote:
> Hmm. Can we get rid of the multiple ref lookups fixed by
> the above *and* the overhead of dealing with a textual
> argument list at the same time by calling
> add_pending_object directly, like this? (Factoring out
> add_pending_sha1 should be a separate patch..)
René,
Your patch works well for me. It achieves about the same
gains as Julian's patch. Thanks!
After all the performance fixes get merged for large ref
counts, it sure should help the Gerrit community. I wonder
how it might impact Gerrit mirroring...
-Martin
Employee of Qualcomm Innovation Center, Inc. which is a
member of Code Aurora Forum
^ permalink raw reply
* Re: [PATCH v2 4/4] upload-archive: use start_command instead of fork
From: René Scharfe @ 2011-09-29 20:18 UTC (permalink / raw)
To: kusmabite; +Cc: Jeff King, msysGit, Johannes Sixt, Junio C Hamano, git
In-Reply-To: <CABPQNSba+nQ+AOmVEVNWhJi2e65EiuhRxfOWZsW03Pkc6zXdHg@mail.gmail.com>
Am 29.09.2011 21:54, schrieb Erik Faye-Lund:
> So the way forward is probably to just change to a self-compiled gzip
> in msysGit (and Git for Windows by proxy).
>
> I'll post the patch to build a native-gzip to the msysGit mailing list
> (I only got 1.2.4 to compile on Windows, but it's the same version as
> we have in msysGit so it's probably fine), and post the latest version
> of this series soon...
Good to hear that.
By the way, are you aware of http://unxutils.sourceforge.net/ (includes
a native gzip 1.2.4 binary)?
Or http://zlib.net/pigz/ (parallel gzip, no binaries)?
René
^ permalink raw reply
* Re: [PATCH v2 4/4] upload-archive: use start_command instead of fork
From: Erik Faye-Lund @ 2011-09-29 20:20 UTC (permalink / raw)
To: René Scharfe; +Cc: Jeff King, msysGit, Johannes Sixt, Junio C Hamano, git
In-Reply-To: <4E84D29F.6020305@lsrfire.ath.cx>
On Thu, Sep 29, 2011 at 10:18 PM, René Scharfe
<rene.scharfe@lsrfire.ath.cx> wrote:
> Am 29.09.2011 21:54, schrieb Erik Faye-Lund:
>> So the way forward is probably to just change to a self-compiled gzip
>> in msysGit (and Git for Windows by proxy).
>>
>> I'll post the patch to build a native-gzip to the msysGit mailing list
>> (I only got 1.2.4 to compile on Windows, but it's the same version as
>> we have in msysGit so it's probably fine), and post the latest version
>> of this series soon...
>
> Good to hear that.
>
> By the way, are you aware of http://unxutils.sourceforge.net/ (includes
> a native gzip 1.2.4 binary)?
Yes, but we prefer to build our binaries ourselves in the msysGit project.
> Or http://zlib.net/pigz/ (parallel gzip, no binaries)?
I'm aware of pigz, but changing the gzip implementation isn't really
the scope of this change IMO.
^ permalink raw reply
* RE: Lack of detached signatures
From: Olsen, Alan R @ 2011-09-29 20:31 UTC (permalink / raw)
To: Ted Ts'o, Jeff King
Cc: Junio C Hamano, Joseph Parmelee, Carlos Martín Nieto,
Michael Witten, git@vger.kernel.org
In-Reply-To: <20110928230958.GJ19250@thunk.org>
[Sorry for the top posting. Fscking Outlook demands it.]
The value of detached signatures is not that the users catch a hacked version, it is that the automated build bots catch the hacked version. There was a server compromised a number of years back that was not caught by users, but by the Gentoo build bot.
What I would eventually like to see is a similar way to check an existing git tree and make sure all the commits authenticate and have not been tampered with. That is a harder problem since the actual patch can change during a merge. (Having cryptographic sign-offs would be helpful as well. I have seen a few cases internally where the signoffs were for bogus e-mail addresses that got generated by automated tools, as well as patches that got altered after the sign-off.)
-----Original Message-----
From: Ted Ts'o [mailto:tytso@mit.edu]
Sent: Wednesday, September 28, 2011 4:10 PM
To: Jeff King
Cc: Junio C Hamano; Joseph Parmelee; Carlos Martín Nieto; Olsen, Alan R; Michael Witten; git@vger.kernel.org
Subject: Re: Lack of detached signatures
On Wed, Sep 28, 2011 at 06:25:43PM -0400, Jeff King wrote:
> [1] This is a minor nit, and probably not worth breaking away from the
> way the rest of the world does it, but it is somewhat silly to sign the
> compressed data. I couldn't care less about the exact bytes in the
> compressed version; what I care about is the actual tar file. The
> compression is just a transport.
The worry I have is that many users don't check the GPG checksum files
as it is. If they have to decompress the file, and then run gpg to
check the checksum, they might never get around to doing it.
That being said, I'm not sure I have a good solution. One is to ship
the file without using detached signatures, and ship a foo.tar.gz.gpg
file, and force them to use GPG to unwrap the file before it can be
unpacked. But users would yell and scream if we did that...
- Ted
^ permalink raw reply
* Re: Git is not scalable with too many refs/*
From: Martin Fick @ 2011-09-29 20:44 UTC (permalink / raw)
To: Junio C Hamano
Cc: René Scharfe, Julian Phillips, Christian Couder, git,
Christian Couder, Thomas Rast
In-Reply-To: <7vy5x7rwq9.fsf@alter.siamese.dyndns.org>
On Thursday, September 29, 2011 01:10:06 pm Junio C Hamano
wrote:
> Also we would probably want to drop "next" field from
> "struct ref_list" (i.e. making it not a linear list),
> introduce a new "struct ref_array" that is a
> ALLOC_GROW() managed array of pointers to "struct
> ref_list", make get_packed_refs() and get_loose_refs()
> return a pointer to "struct ref_array" after sorting the
> array contents by "name". Then resolve_ref() can do a
> bisection search in the packed refs array when it does
> not find a loose ref.
That would be nice, and I suspect it would shave a bit more
of the orphan check and possibly even a fetch. If I
understood all that, I might try. But I might need some
hand holding, my C is pretty rusty... Is there a bisection
search library in git already to use? Is there a git
sorting library for the array also?
-Martin
--
Employee of Qualcomm Innovation Center, Inc. which is a
member of Code Aurora Forum
^ permalink raw reply
* [PATCH v3 0/4] port upload-archive to Windows
From: Erik Faye-Lund @ 2011-09-29 20:59 UTC (permalink / raw)
To: git; +Cc: peff, j6t, gitster, rene.scharfe
It's been a while, but here's another updated version of this
series.
The only change since last time is that the series has been made
compatible with Peff's "when remote, disable some features"
changes.
Erik Faye-Lund (4):
compat/win32/sys/poll.c: upgrade from upstream
mingw: fix compilation of poll-emulation
enter_repo: do not modify input
upload-archive: use start_command instead of fork
builtin/archive.c | 6 +++-
builtin/upload-archive.c | 68 ++++++++++++++-------------------------------
cache.h | 2 +-
compat/mingw.h | 2 -
compat/win32/sys/poll.c | 17 ++++++++---
daemon.c | 4 +-
path.c | 30 +++++++++-----------
t/t5000-tar-tree.sh | 10 +++---
8 files changed, 60 insertions(+), 79 deletions(-)
--
1.7.6.355.g842ba.dirty
^ permalink raw reply
* [PATCH v3 1/4] compat/win32/sys/poll.c: upgrade from upstream
From: Erik Faye-Lund @ 2011-09-29 20:59 UTC (permalink / raw)
To: git; +Cc: peff, j6t, gitster, rene.scharfe
In-Reply-To: <1317329963-6656-1-git-send-email-kusmabite@gmail.com>
poll.c is updated from revision adc3a5b in
git://git.savannah.gnu.org/gnulib.git
The changes are applied with --whitespace=fix to reduce noise.
poll.h is not upgraded, because the most recent version now
contains template-stuff that breaks compilation for us.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
---
compat/win32/sys/poll.c | 19 +++++++++++++------
1 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/compat/win32/sys/poll.c b/compat/win32/sys/poll.c
index 708a6c9..403eaa7 100644
--- a/compat/win32/sys/poll.c
+++ b/compat/win32/sys/poll.c
@@ -1,7 +1,7 @@
/* Emulation for poll(2)
Contributed by Paolo Bonzini.
- Copyright 2001-2003, 2006-2010 Free Software Foundation, Inc.
+ Copyright 2001-2003, 2006-2011 Free Software Foundation, Inc.
This file is part of gnulib.
@@ -27,7 +27,10 @@
#include <malloc.h>
#include <sys/types.h>
-#include "poll.h"
+
+/* Specification. */
+#include <poll.h>
+
#include <errno.h>
#include <limits.h>
#include <assert.h>
@@ -314,10 +317,7 @@ compute_revents (int fd, int sought, fd_set *rfds, fd_set *wfds, fd_set *efds)
#endif /* !MinGW */
int
-poll (pfd, nfd, timeout)
- struct pollfd *pfd;
- nfds_t nfd;
- int timeout;
+poll (struct pollfd *pfd, nfds_t nfd, int timeout)
{
#ifndef WIN32_NATIVE
fd_set rfds, wfds, efds;
@@ -454,6 +454,7 @@ poll (pfd, nfd, timeout)
if (!hEvent)
hEvent = CreateEvent (NULL, FALSE, FALSE, NULL);
+restart:
handle_array[0] = hEvent;
nhandles = 1;
FD_ZERO (&rfds);
@@ -594,6 +595,12 @@ poll (pfd, nfd, timeout)
rc++;
}
+ if (!rc && timeout == INFTIM)
+ {
+ SwitchToThread();
+ goto restart;
+ }
+
return rc;
#endif
}
--
1.7.6.355.g842ba.dirty
^ permalink raw reply related
* [PATCH v3 2/4] mingw: fix compilation of poll-emulation
From: Erik Faye-Lund @ 2011-09-29 20:59 UTC (permalink / raw)
To: git; +Cc: peff, j6t, gitster, rene.scharfe
In-Reply-To: <1317329963-6656-1-git-send-email-kusmabite@gmail.com>
gnulib has changed the inclusion of poll.h from double quotes
to single-quotes. But because compat/win32/sys/ isn't in our
include-path, this breaks compilation. Change it back the way
it was.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
---
compat/win32/sys/poll.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/compat/win32/sys/poll.c b/compat/win32/sys/poll.c
index 403eaa7..225ddce 100644
--- a/compat/win32/sys/poll.c
+++ b/compat/win32/sys/poll.c
@@ -29,7 +29,7 @@
#include <sys/types.h>
/* Specification. */
-#include <poll.h>
+#include "poll.h"
#include <errno.h>
#include <limits.h>
--
1.7.6.355.g842ba.dirty
^ permalink raw reply related
* [PATCH v3 3/4] enter_repo: do not modify input
From: Erik Faye-Lund @ 2011-09-29 20:59 UTC (permalink / raw)
To: git; +Cc: peff, j6t, gitster, rene.scharfe
In-Reply-To: <1317329963-6656-1-git-send-email-kusmabite@gmail.com>
entr_repo(..., 0) currently modifies the input to strip away
trailing slashes. This means that we some times need to copy the
input to keep the original.
Change it to unconditionally copy it into the used_path buffer so
we can safely use the input without having to copy it.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
---
cache.h | 2 +-
daemon.c | 4 ++--
path.c | 30 ++++++++++++++----------------
3 files changed, 17 insertions(+), 19 deletions(-)
diff --git a/cache.h b/cache.h
index 607c2ea..a7e4de1 100644
--- a/cache.h
+++ b/cache.h
@@ -734,7 +734,7 @@ int safe_create_leading_directories(char *path);
int safe_create_leading_directories_const(const char *path);
int mkdir_in_gitdir(const char *path);
extern char *expand_user_path(const char *path);
-char *enter_repo(char *path, int strict);
+const char *enter_repo(const char *path, int strict);
static inline int is_absolute_path(const char *path)
{
return is_dir_sep(path[0]) || has_dos_drive_prefix(path);
diff --git a/daemon.c b/daemon.c
index 4c8346d..9253192 100644
--- a/daemon.c
+++ b/daemon.c
@@ -108,11 +108,11 @@ static void NORETURN daemon_die(const char *err, va_list params)
exit(1);
}
-static char *path_ok(char *directory)
+static const char *path_ok(char *directory)
{
static char rpath[PATH_MAX];
static char interp_path[PATH_MAX];
- char *path;
+ const char *path;
char *dir;
dir = directory;
diff --git a/path.c b/path.c
index 6f3f5d5..f7dfd0b 100644
--- a/path.c
+++ b/path.c
@@ -283,7 +283,7 @@ return_null:
* links. User relative paths are also returned as they are given,
* except DWIM suffixing.
*/
-char *enter_repo(char *path, int strict)
+const char *enter_repo(const char *path, int strict)
{
static char used_path[PATH_MAX];
static char validated_path[PATH_MAX];
@@ -297,14 +297,15 @@ char *enter_repo(char *path, int strict)
};
int len = strlen(path);
int i;
- while ((1 < len) && (path[len-1] == '/')) {
- path[len-1] = 0;
+ while ((1 < len) && (path[len-1] == '/'))
len--;
- }
+
if (PATH_MAX <= len)
return NULL;
- if (path[0] == '~') {
- char *newpath = expand_user_path(path);
+ strncpy(used_path, path, len);
+
+ if (used_path[0] == '~') {
+ char *newpath = expand_user_path(used_path);
if (!newpath || (PATH_MAX - 10 < strlen(newpath))) {
free(newpath);
return NULL;
@@ -316,24 +317,21 @@ char *enter_repo(char *path, int strict)
* anyway.
*/
strcpy(used_path, newpath); free(newpath);
- strcpy(validated_path, path);
- path = used_path;
+ strcpy(validated_path, used_path);
}
else if (PATH_MAX - 10 < len)
return NULL;
- else {
- path = strcpy(used_path, path);
- strcpy(validated_path, path);
- }
- len = strlen(path);
+ else
+ strcpy(validated_path, used_path);
+ len = strlen(used_path);
for (i = 0; suffix[i]; i++) {
- strcpy(path + len, suffix[i]);
- if (!access(path, F_OK)) {
+ strcpy(used_path + len, suffix[i]);
+ if (!access(used_path, F_OK)) {
strcat(validated_path, suffix[i]);
break;
}
}
- if (!suffix[i] || chdir(path))
+ if (!suffix[i] || chdir(used_path))
return NULL;
path = validated_path;
}
--
1.7.6.355.g842ba.dirty
^ permalink raw reply related
* [PATCH v3 4/4] upload-archive: use start_command instead of fork
From: Erik Faye-Lund @ 2011-09-29 20:59 UTC (permalink / raw)
To: git; +Cc: peff, j6t, gitster, rene.scharfe
In-Reply-To: <1317329963-6656-1-git-send-email-kusmabite@gmail.com>
The POSIX-function fork is not supported on Windows. Use our
start_command API instead.
As this is the last call-site that depends on the fork-stub in
compat/mingw.h, remove that as well.
Add an undocumented flag to git-archive that tells it that the
action originated from a remote, so features can be disabled.
Thanks to Jeff King for work on this part.
Remove the NOT_MINGW-prereq for t5000, as git-archive --remote
now works.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
Helped-by: Jeff King <peff@peff.net>
---
builtin/archive.c | 6 +++-
builtin/upload-archive.c | 68 ++++++++++++++-------------------------------
compat/mingw.h | 2 -
t/t5000-tar-tree.sh | 10 +++---
4 files changed, 31 insertions(+), 55 deletions(-)
diff --git a/builtin/archive.c b/builtin/archive.c
index 883c009..6668340 100644
--- a/builtin/archive.c
+++ b/builtin/archive.c
@@ -85,6 +85,7 @@ int cmd_archive(int argc, const char **argv, const char *prefix)
const char *exec = "git-upload-archive";
const char *output = NULL;
const char *remote = NULL;
+ int is_remote = 0;
struct option local_opts[] = {
OPT_STRING('o', "output", &output, "file",
"write the archive to this file"),
@@ -92,6 +93,9 @@ int cmd_archive(int argc, const char **argv, const char *prefix)
"retrieve the archive from remote repository <repo>"),
OPT_STRING(0, "exec", &exec, "cmd",
"path to the remote git-upload-archive command"),
+ { OPTION_BOOLEAN, 0, "remote-request", &is_remote, NULL,
+ "indicate we are serving a remote request",
+ PARSE_OPT_NOARG | PARSE_OPT_HIDDEN },
OPT_END()
};
@@ -106,5 +110,5 @@ int cmd_archive(int argc, const char **argv, const char *prefix)
setvbuf(stderr, NULL, _IOLBF, BUFSIZ);
- return write_archive(argc, argv, prefix, 1, output, 0);
+ return write_archive(argc, argv, prefix, 1, output, is_remote);
}
diff --git a/builtin/upload-archive.c b/builtin/upload-archive.c
index 2d0b383..c57e8bd 100644
--- a/builtin/upload-archive.c
+++ b/builtin/upload-archive.c
@@ -6,6 +6,7 @@
#include "archive.h"
#include "pkt-line.h"
#include "sideband.h"
+#include "run-command.h"
static const char upload_archive_usage[] =
"git upload-archive <repo>";
@@ -18,28 +19,17 @@ static const char lostchild[] =
#define MAX_ARGS (64)
-static int run_upload_archive(int argc, const char **argv, const char *prefix)
+static void prepare_argv(const char **sent_argv, const char **argv)
{
- const char *sent_argv[MAX_ARGS];
const char *arg_cmd = "argument ";
char *p, buf[4096];
int sent_argc;
int len;
- if (argc != 2)
- usage(upload_archive_usage);
-
- if (strlen(argv[1]) + 1 > sizeof(buf))
- die("insanely long repository name");
-
- strcpy(buf, argv[1]); /* enter-repo smudges its argument */
-
- if (!enter_repo(buf, 0))
- die("'%s' does not appear to be a git repository", buf);
-
/* put received options in sent_argv[] */
- sent_argc = 1;
- sent_argv[0] = "git-upload-archive";
+ sent_argc = 2;
+ sent_argv[0] = "archive";
+ sent_argv[1] = "--remote-request";
for (p = buf;;) {
/* This will die if not enough free space in buf */
len = packet_read_line(0, p, (buf + sizeof buf) - p);
@@ -62,9 +52,6 @@ static int run_upload_archive(int argc, const char **argv, const char *prefix)
*p++ = 0;
}
sent_argv[sent_argc] = NULL;
-
- /* parse all options sent by the client */
- return write_archive(sent_argc, sent_argv, prefix, 0, NULL, 1);
}
__attribute__((format (printf, 1, 2)))
@@ -96,38 +83,25 @@ static ssize_t process_input(int child_fd, int band)
int cmd_upload_archive(int argc, const char **argv, const char *prefix)
{
- pid_t writer;
- int fd1[2], fd2[2];
- /*
- * Set up sideband subprocess.
- *
- * We (parent) monitor and read from child, sending its fd#1 and fd#2
- * multiplexed out to our fd#1. If the child dies, we tell the other
- * end over channel #3.
- */
- if (pipe(fd1) < 0 || pipe(fd2) < 0) {
- int err = errno;
- packet_write(1, "NACK pipe failed on the remote side\n");
- die("upload-archive: %s", strerror(err));
- }
- writer = fork();
- if (writer < 0) {
+ const char *sent_argv[MAX_ARGS];
+ struct child_process cld = { sent_argv };
+ cld.out = cld.err = -1;
+ cld.git_cmd = 1;
+
+ if (argc != 2)
+ usage(upload_archive_usage);
+
+ if (!enter_repo(argv[1], 0))
+ die("'%s' does not appear to be a git repository", argv[1]);
+
+ prepare_argv(sent_argv, argv);
+ if (start_command(&cld)) {
int err = errno;
packet_write(1, "NACK fork failed on the remote side\n");
die("upload-archive: %s", strerror(err));
}
- if (!writer) {
- /* child - connect fd#1 and fd#2 to the pipe */
- dup2(fd1[1], 1);
- dup2(fd2[1], 2);
- close(fd1[1]); close(fd2[1]);
- close(fd1[0]); close(fd2[0]); /* we do not read from pipe */
-
- exit(run_upload_archive(argc, argv, prefix));
- }
/* parent - read from child, multiplex and send out to fd#1 */
- close(fd1[1]); close(fd2[1]); /* we do not write to pipe */
packet_write(1, "ACK\n");
packet_flush(1);
@@ -135,9 +109,9 @@ int cmd_upload_archive(int argc, const char **argv, const char *prefix)
struct pollfd pfd[2];
int status;
- pfd[0].fd = fd1[0];
+ pfd[0].fd = cld.out;
pfd[0].events = POLLIN;
- pfd[1].fd = fd2[0];
+ pfd[1].fd = cld.err;
pfd[1].events = POLLIN;
if (poll(pfd, 2, -1) < 0) {
if (errno != EINTR) {
@@ -156,7 +130,7 @@ int cmd_upload_archive(int argc, const char **argv, const char *prefix)
if (process_input(pfd[0].fd, 1))
continue;
- if (waitpid(writer, &status, 0) < 0)
+ if (waitpid(cld.pid, &status, 0) < 0)
error_clnt("%s", lostchild);
else if (!WIFEXITED(status) || WEXITSTATUS(status) > 0)
error_clnt("%s", deadchild);
diff --git a/compat/mingw.h b/compat/mingw.h
index ce9dd98..9cb6eb9 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -85,8 +85,6 @@ static inline int symlink(const char *oldpath, const char *newpath)
{ errno = ENOSYS; return -1; }
static inline int fchmod(int fildes, mode_t mode)
{ errno = ENOSYS; return -1; }
-static inline pid_t fork(void)
-{ errno = ENOSYS; return -1; }
static inline unsigned int alarm(unsigned int seconds)
{ return 0; }
static inline int fsync(int fd)
diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh
index d906898..889842e 100755
--- a/t/t5000-tar-tree.sh
+++ b/t/t5000-tar-tree.sh
@@ -96,7 +96,7 @@ test_expect_success 'git archive with --output' \
'git archive --output=b4.tar HEAD &&
test_cmp b.tar b4.tar'
-test_expect_success NOT_MINGW 'git archive --remote' \
+test_expect_success 'git archive --remote' \
'git archive --remote=. HEAD >b5.tar &&
test_cmp b.tar b5.tar'
@@ -266,7 +266,7 @@ test_expect_success 'archive --list mentions user filter' '
grep "^bar\$" output
'
-test_expect_success NOT_MINGW 'archive --list shows only enabled remote filters' '
+test_expect_success 'archive --list shows only enabled remote filters' '
git archive --list --remote=. >output &&
! grep "^tar\.foo\$" output &&
grep "^bar\$" output
@@ -298,7 +298,7 @@ test_expect_success 'extension matching requires dot' '
test_cmp b.tar config-implicittar.foo
'
-test_expect_success NOT_MINGW 'only enabled filters are available remotely' '
+test_expect_success 'only enabled filters are available remotely' '
test_must_fail git archive --remote=. --format=tar.foo HEAD \
>remote.tar.foo &&
git archive --remote=. --format=bar >remote.bar HEAD &&
@@ -341,12 +341,12 @@ test_expect_success GZIP,GUNZIP 'extract tgz file' '
test_cmp b.tar j.tar
'
-test_expect_success GZIP,NOT_MINGW 'remote tar.gz is allowed by default' '
+test_expect_success GZIP 'remote tar.gz is allowed by default' '
git archive --remote=. --format=tar.gz HEAD >remote.tar.gz &&
test_cmp j.tgz remote.tar.gz
'
-test_expect_success GZIP,NOT_MINGW 'remote tar.gz can be disabled' '
+test_expect_success GZIP 'remote tar.gz can be disabled' '
git config tar.tar.gz.remote false &&
test_must_fail git archive --remote=. --format=tar.gz HEAD \
>remote.tar.gz
--
1.7.6.355.g842ba.dirty
^ 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