* 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: [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
* [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: 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
* 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: 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: [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: 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: 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
* 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: 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
* [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: Junio C Hamano @ 2011-09-29 16:49 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:
> directly to the local repository, but doesn't give me any of the
> branch refs that I'm expecting from such an operation. In other words,
> if I bundle branch foo on machine A, then unbundle on machine B, I
> expect to be able to "git checkout foo" and get on with life.
$ git bundle -h
usage: git bundle create <file> <git-rev-list args>
or: git bundle verify <file>
or: git bundle list-heads <file> [<refname>...]
or: git bundle unbundle <file> [<refname>...]
$ git bundle list-heads /var/tmp/junk/foo.bundle
632052641517de1a965c1f045b97d2eaa541b2e9 refs/heads/maint
$ git fetch /var/tmp/junk/foo.bundle maint
From /var/tmp/junk/foo.bundle
* branch maint -> FETCH_HEAD
or
$ git fetch /var/tmp/junk/foo.bundle maint:bundle_head
$ git log bundle_head
^ permalink raw reply
* Re: Lack of detached signatures
From: Joseph Parmelee @ 2011-09-29 16:47 UTC (permalink / raw)
To: Ted Ts'o
Cc: Junio C Hamano, Jeff King, Carlos Martín Nieto,
Olsen, Alan R, Michael Witten, git@vger.kernel.org
In-Reply-To: <20110929131845.GQ19250@thunk.org>
On Thu, 29 Sep 2011, Ted Ts'o wrote:
> On Wed, Sep 28, 2011 at 08:50:49PM -0700, Junio C Hamano wrote:
>>
>> I was actually more worried about helping consumers convince themselves
>> that thusly signed keys indeed belong to producers like Linus, Peter,
>> etc. There are those who worry that DNS record to code.google.com/ for
>> them may point at an evil place to give them rogue download material.
>> "Here are the keys you can verify our trees with" message on the mailing
>> list, even with the message is signed with GPG, would not be satisfactory
>> to them.
>
> What do you mean by "consumers" in this context? Most end users don't
> actually download tarballs from www.kernel.org or code.google.com! :-)
>
> If you mean developers at Linux distributions Red Hat, SuSE, or
> Handset manufacturers such as Samsung, HTC, Motorola, etc., there will
> be many of those reprsenatives at LinuxCon Europe and CELF (Consumer
> Electronics Linux Forum) Europe conferences, which will be colocated
> with the Kernel Summit in Prague.
>
> If you are thinking of random developers located in far-flung places
> of the world who don't have any contact with other Linux developers,
> this is a previously unsolved problem. There are links into the
> developing Kernel GPG tree that are signed by the GPG web trust used
> by Debian, OpenSuSE, and (soon) Fedora. Given that people generally
> have to trust one or more of those web of trusts, that's the best we
> can do, at least as far as I know. If you can suggest something
> better, please let me know!
>
>
> - Ted
>
Also included is distro developers that gen custom distros for limited
corporate use on specific hardware, and anyone else that is sufficiently
concerned about security and/or survivability that they prefer/need to build
from the upstream source.
As far as accepting public keys, a key obtained from the key servers and
signed by others, while not perfect, is vastly superior to nothing at all.
I am located in the mountains of Costa Rica. Over the years I have
collected a fair number of public keys making it very difficult for bad guys
to fake both a public key and all the signatures too, even though I can't
travel to a "key signing party" which would of course be better.
Even if we have to change all the keys now its going to be risky but still
vastly better than nothing. I would hope that a new key would be signed by
an existing valid private key as well as newly issued keys. This would
reassure people like me who have a substantial stash of old but valid public
keys, while at the same time thwarting bad guys who can fake only those old
signatures for which they have stolen valid private keys.
Joseph
^ permalink raw reply
* Re: [PATCH v4] Docs: git checkout --orphan: Copyedit, and s/root commit/orphan branch/
From: Michael Witten @ 2011-09-29 16:44 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: <3cba6bb85bde4f96903b2b617190a2b8-mfwitten@gmail.com>
On Thu, Sep 29, 2011 at 15:44, Michael Witten <mfwitten@gmail.com> wrote:
> Subject: [PATCH v4] Docs: git checkout --orphan: Copyedit, and s/root commit/orphan branch/
Do me the kind favor of replacing:
s/root commit/orphan branch/
with:
s/orphan branch/root commit/
^ permalink raw reply
* [PATCH v4] Docs: git checkout --orphan: Copyedit, and s/root commit/orphan branch/
From: Michael Witten @ 2011-09-29 15:44 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: <271cc2ed03774b4988bb61cb3e79750e-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::
+ 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 related
* Re: [PATCH v3] Docs: git checkout --orphan: `root commit' and `branch head'
From: Michael Witten @ 2011-09-29 15: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: <7vaa9oz9rl.fsf@alter.siamese.dyndns.org>
On Wed, 28 Sep 2011 13:34:22 -0700, Junio C Hamano wrote:
> As to what the updated text wants to talk about, I think most of them are
> improvement, but there are a few glitches and nits.
>
>> ...
>>
>> +--orphan::
>> + Tell 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{nbsp}init",
>
> I do not think we ever used {nbsp} in our documentation set. Is it
> absolutely necessary to use it in this context, and are you absolutely
> sure this does not break various versions of documentation toolchain
> people have?
I think it's absolutely necessary, but I'm not sure about how fragile
asciidoc is across versions with regard to this... I guess I'll remove
them.
>> + except that the new commit will be referenced by the branch head
>> + <new_branch> rather than "master".
>
> The option works as a substitute for -B/-b in the sense that it takes a
> name of the new branch, and the only difference is that the new branch
> will start with no commit (yet). To reduce confusion, it might make sense
> to update this part (and description of -b/-B) to begin like this:
>
> --orphan <new_branch>::
>
> to match the new explanation text, and the output from "git checkout -h".
> By the way, shouldn't the entry for -b in "git checkout -h" output also
> say <new branch>?
I took the "<new_branch>" from the synopsis:
SYNOPSIS
--------
[verse]
'git checkout' [-q] [-f] [-m] [<branch>]
'git checkout' [-q] [-f] [-m] [--detach] [<commit>]
'git checkout' [-q] [-f] [-m] [[-b|-B|--orphan] <new_branch>] [<start_point>]
'git checkout' [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] [--] <paths>...
'git checkout' [-p|--patch] [<tree-ish>] [--] [<paths>...]
It would seem strange to include "<new_branch>" but not "<start_point>"
in each of the individual option descriptions.
In any case, I think we should leave that for another patch.
Moreover, I think it would be better to remove all `-h' output from
all git commands; they are always incomplete and/or different. Indeed,
at this point in history, programmers absolutely stink at writing
documentation, so it's probably a good idea just to centralize all
information as much as possible. Of course, I realize this suggestion
will never fly.
> Micronit: "referenced by the branch head <new_branch>" might be easier to
> read and understand with s/branch head/branch name/. Or perhaps
>
> except that the new commit will be made on <new_branch> branch
> rather than "master".
>
> might be even better.
I have qualms with git's terminology, and using "branch head" as I have is
not only the closest thing to what I like, but it is also the only language
that is actually in complete agreement with git's own terminolgy as currently
defined by "git help glossary".
In the glossary, the term "branch name" only occurs once as part of:
branch named "master"
which is undefined.
However, how skirting the whole issue:
except that the new commit will be referenced by <new_branch>
rather than "master".
>> +Furthermore, the working tree and index are adjusted as if you ran
>> +"git{nbsp}checkout{nbsp}<start_point>"; thus, by just running
>> +"git{nbsp}commit", you can create a root commit with a tree that is
>> +exactly the same as the tree of <start_point>.
>> ++
>> +Naturally, before creating the commit, you may manipulate the index
>> +in any way you want. ...
>
> What value does "Naturally, " add to the understanding here? I would
> understand if it were "Alternatively, ", though.
"Naturally" reassures the reader that nothing really special is happening
in terms of how the next commit can be made; there are no special cases.
"Alternatively" is too strong; these 2 paragraphs are not mutually
exclusive: The bit about running just "git commit" is only a
clarification of the preceding sentence.
Nevertheless, I have rearranged the text to use "Alternatively" in
[PATCH v4]:
Message-ID: <3cba6bb85bde4f96903b2b617190a2b8-mfwitten@gmail.com>
Subject: [PATCH v4] Docs: git checkout --orphan: Copyedit,
and s/root commit/orphan branch/
It should be a reply to this email.
>> +... For example, if you want to create a root commit
>> +with a tree that is totally different from the tree of <start_point>,
>> +then just clear the working tree and index first: From the top level
>> +of the working tree, run "git{nbsp}rm{nbsp}-rf{nbsp}.", and then
>> +prepare your new working tree and index as desired.
>> ++
>> +There are two common uses for this option:
>> ++
>> +--
>> + Separate history::
>> + Suppose that for convenience, you want to maintain
>> + the website for your project in the same repository
>> + as the project itself. In such a case, it may not
>> + make much sense to interleave the history of the
>> + website with the history of the project; you can use
>> + the "--orphan" option in order to create these two
>> + completely separate histories.
>
> I suspect this is *not* common at all, and also because you would need a
> working tree to update both lines of histories that are not related to
> each other at all at the content level, I do not believe that "for
> convenience" supports or justifies the use case at all. It would be less
> convenient to update these two unrelated histories (switching between
> branches would need to nuke the whole working tree, and the semantics to
> carry local changes floating on top of the tip commit of the current
> branch across branch switching actively works against you).
>
> You would be better off using another repository to keep track of "the
> website for your project".
>
> In short, I do not think we would want to list the above as if we are
> somehow encouraging the use of this option for such a use. It falls into
> "because with --orphan you _could_", and definitely not "because having
> these two unrelated projects in the same repository you work in is
> convenient and/or necessary".
I was thinking of something like git's repo's "man", "html", and "todo",
but I was trying to express that along the lines of a more widely
recognizable scenario.
See [PATCH v4] for a more generic version.
>> + 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.
>
> This cause does make sense; you would want the local changes floating on
> top of the tip commit of the current branch carried across branch
> switching.
>
>> +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.
>
> Does this "In this case" paragraph format as part of the "Hidden history"
> paragraph?
Yes. Have you no faith in me?
>> +However, removing proprietary material from ancestry is usually a task
>> +that is better performed by linkgit:git-filter-branch[1] and
>> +linkgit:git-rebase[1], especially when there are multiple commits that
>> +are already suitable for the open source history.
>> +--
>
> In general it is true, and not "especially".
> ...
> I suspect this is not exactly "filter-branch is better but you could use
> checkout --orphan" like you made it sound in the above paragraph. 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", especially when you do not intend to accept fixes to older
> revisions; you could filter-branch the older proprietary history but you
> would not get much benefit out of the cost for doing so, I think.
I don't really see how what I wrote is fundamentally different. However,
I've rearranged it in [PATCH v4].
>> See:
>>
>> Re: Can a git changeset be created with no parent
>> Carlos Mart=C3=ADn Nieto <cmn@elego.de>
>> Message-ID: <1317073309.5579.9.camel@centaur.lab.cmartin.tk>
>> http://article.gmane.org/gmane.comp.version-control.git/182170
>>
>> and:
>>
>> git help glossary
>
> I think I had to tell somebody on this list not to do this no more than a
> month ago.
What's your point?
> It is a good practice to point to earlier discussions while polishing
> patch, and it also is good to include pointers in the commit log message
> as a _supporting material_ (additional reading), but that is *NOT* a
> substitute for a properly written commit log message. You need to state
> what problem you are trying to fix and how the proposed patch fixes it.
That's a good rule of thumb. Although, interestingly, one my last code
patches for git was accompanied by a very detailed, precisely formulated
description of the problem and the solution, and yet it was dumbed down
behind my back.
In this case, though, I think the message title gives enough information,
particularly when combined with the diff: It's a commit that alters the
documentation for "git checkout --orphan", and somehow involves the terms
"root commit" and "branch head" (though no longer in [PATCH v4]); the rest
of the log message is just meant to be cake icing for the interested.
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.
Hmmm... You know what? I think I'll make that last paragraph the message.
Sincerely,
Michael Witten
^ permalink raw reply
* Re: [BUG?] gitk assumes initial commit is empty
From: Junio C Hamano @ 2011-09-29 16:40 UTC (permalink / raw)
To: Zbigniew Jędrzejewski-Szmek; +Cc: git
In-Reply-To: <4E8481A2.6060301@in.waw.pl>
Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> writes:
> In gitk, the next commit shows changes to some files, like if they existed
> in the parent commit. So it seems that gitk assumes that initial commit
> is empty, which doesn't have to be true.
It is not about assuming but by unfortunate design.
In early days, all projects managed by git (except for git itself) had the
product of a fairly mature development hsitory in their first commit, and
it was deemed unnecessary clutter to show additions of these thousands of
paths as a patch.
This was not just about gitk but git itself. "git log" learned to show the
patch for the initial commit without requiring --root command line option
only at 0f03ca9 (config option log.showroot to show the diff of root
commits, 2006-11-23).
These days I think gitk should learn to do the same ;-)
^ permalink raw reply
* Re: Git is not scalable with too many refs/*
From: Martin Fick @ 2011-09-29 16:38 UTC (permalink / raw)
To: Julian Phillips; +Cc: Christian Couder, git, Christian Couder, Thomas Rast
In-Reply-To: <7c0105c6cca7dd0aa336522f90617fe4@quantumfyre.co.uk>
On Wednesday, September 28, 2011 08:19:16 pm Julian Phillips
wrote:
> On Wed, 28 Sep 2011 19:37:18 -0600, Martin Fick wrote:
> > On Wednesday 28 September 2011 18:59:09 Martin Fick
wrote:
> >> Julian Phillips <julian@quantumfyre.co.uk> wrote:
> -- snip --
>
> >> I've created a test repo with ~100k refs/changes/...
> >> style refs, and ~40000 refs/heads/... style refs, and
> >> checkout can walk the list of ~140k refs seven times
> >> in 85ms user time including doing whatever other
> >> processing is needed for checkout. The real time is
> >> only 114ms - but then my test repo has no real data
> >> in.
> >
> > If I understand what you are saying, it sounds like you
> > do not have a very good test case. The amount of time
> > it takes for checkout depends on how long it takes to
> > find a ref with the sha1 that you are on. If that sha1
> > is so early in the list of refs that it only took you
> > 7 traversals to find it, then that is not a very good
> > testcase. I think that you should probably try making
> > an orphaned ref (checkout a detached head, commit to
> > it), that is probably the worst testcase since it
> > should then have to search all 140K refs to eventually
> > give up.
> >
> > Again, if I understand what you are saying, if it took
> > 85ms for 7 traversals, then it takes approximately
> > 10ms per traversal, that's only 100/s! If you have to
> > traverse it 140K times, that should work out to 1400s
> > ~ 23mins.
>
> Well, it's no more than 10ms per traversal - since the
> rest of the work presumably takes some time too ...
>
> 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? 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?
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?
-Martin
--
Employee of Qualcomm Innovation Center, Inc. which is a
member of Code Aurora Forum
^ permalink raw reply
* git bundle unbundle and "check-outable" refs
From: Todd A. Jacobs @ 2011-09-29 15:51 UTC (permalink / raw)
To: git
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. It seems to add the commits
directly to the local repository, but doesn't give me any of the
branch refs that I'm expecting from such an operation. In other words,
if I bundle branch foo on machine A, then unbundle on machine B, I
expect to be able to "git checkout foo" and get on with life.
Instead, it seems that I have to figure out what commits were
unbundled, and create a new branch ref pointing to the head that I
want. I assume this is to prevent namespace collisions, but it seems
really, really cumbersome. Wouldn't it make more sense to include
branch names in the bundle, and simply prompt the user to rename refs
that conflict?
I'm certainly open to other ideas of how to accomplish this workflow,
and if there's an invocation to simplify this that I'm unaware of,
please advise. Otherwise, I really think the default behavior of the
unbundle sub-command ought to be more intuitive.
^ permalink raw reply
* Re: RFC: reverse bisect
From: Johannes Sixt @ 2011-09-29 16:27 UTC (permalink / raw)
To: Michal Vyskocil; +Cc: git
In-Reply-To: <20110929142027.GA4936@zelva.suse.cz>
Am 29.09.2011 16:20, schrieb Michal Vyskocil:
> git bisect start --reverse HEAD~999 HEAD
With the regular meaning of the start subcommand, the revs given are
ordered: bad good good...
With the reversed meaning, this would have to become: good bad bad...
This would have to be mentioned clearly in the documentation.
> git bisect good/bad/skip/run
Last time this came up on the list I suggested to add the following
commands:
git bisect regression # a synonym for git bisect start
git bisect improvement # your --reverse
-- Hannes
^ permalink raw reply
* Re: [PATCH v4] send-email: auth plain/login fix
From: Joe Perches @ 2011-09-29 15:01 UTC (permalink / raw)
To: Zbigniew Jędrzejewski-Szmek; +Cc: gitster, git, peff
In-Reply-To: <20110929141616.GU10763@in.waw.pl>
On Thu, 2011-09-29 at 16:16 +0200, Zbigniew Jędrzejewski-Szmek wrote:
> 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.
[]
> diff --git a/git-send-email.perl b/git-send-email.perl
[]
> @@ -1098,6 +1098,10 @@ X-Mailer: git-send-email $gitversion
> }
>
> if (defined $smtp_authuser) {
> + eval {
> + require Authen::SASL;
> + Authen::SASL->import(qw(Perl));
> + };
Thanks for keeping at this.
One comment:
This is a workaround for a nominal defect.
As such, I think the code should be commented
to note why it exists.
How about adding a comment like:
if (defined $smtp_authuser) {
# Workaround AUTH PLAIN/LOGIN interaction defect
# with Authen::SASL::Cyrus
eval {
require Authen::SASL;
^ permalink raw reply
* Re: Lack of detached signatures
From: Sverre Rabbelier @ 2011-09-29 14:52 UTC (permalink / raw)
To: Ted Ts'o
Cc: Junio C Hamano, Jeff King, Joseph Parmelee,
Carlos Martín Nieto, Olsen, Alan R, Michael Witten,
git@vger.kernel.org
In-Reply-To: <20110929145046.GC13705@thunk.org>
Heya,
On Thu, Sep 29, 2011 at 16:50, Ted Ts'o <tytso@mit.edu> wrote:
> On Thu, Sep 29, 2011 at 04:40:54PM +0200, Sverre Rabbelier wrote:
>>
>> This all sounds very interesting. Where is this discussion on a new
>> web of trust taking place? The kernel mailing list? Do you have a
>> message-id / gmane.org link for me to read more about this perhaps?
>
> It's been taking place on private e-mails and on conference calls
> amongst those of us who have been organizing the kernel.org recovery
> efforts. There will be a more detailed discussion and a GPG key
> signing party that I will be organizing at the upcoming kernel summit
> meeting in Prague.
>
> What are your concerns?
Not concerned at all. I just would have enjoyed listening in to those
more knowledgeable than me discussing security and trust :).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: Lack of detached signatures
From: Ted Ts'o @ 2011-09-29 14:50 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Junio C Hamano, Jeff King, Joseph Parmelee,
Carlos Martín Nieto, Olsen, Alan R, Michael Witten,
git@vger.kernel.org
In-Reply-To: <CAGdFq_h6shMp+d4f1bG=if6L11M_5ixN5JF7KgCrZJ44QBt0QQ@mail.gmail.com>
On Thu, Sep 29, 2011 at 04:40:54PM +0200, Sverre Rabbelier wrote:
>
> This all sounds very interesting. Where is this discussion on a new
> web of trust taking place? The kernel mailing list? Do you have a
> message-id / gmane.org link for me to read more about this perhaps?
It's been taking place on private e-mails and on conference calls
amongst those of us who have been organizing the kernel.org recovery
efforts. There will be a more detailed discussion and a GPG key
signing party that I will be organizing at the upcoming kernel summit
meeting in Prague.
What are your concerns?
- Ted
^ permalink raw reply
* Re: RFC: reverse bisect
From: Sverre Rabbelier @ 2011-09-29 14:42 UTC (permalink / raw)
To: Michal Vyskocil; +Cc: git
In-Reply-To: <20110929142027.GA4936@zelva.suse.cz>
Heya,
On Thu, Sep 29, 2011 at 16:20, Michal Vyskocil <mvyskocil@suse.cz> wrote:
> fprintf(stderr, "Some good revs are not ancestor of the bad rev.\n"
> "git bisect cannot work properly in this case.\n"
> - "Maybe you mistake good and bad revs?\n");
> + "Try --reverse to switch the bisect logic.\n");
Heh, glad to see the "Maybe you mistake" phrasing removed if nothing else :P.
--
Cheers,
Sverre Rabbelier
^ 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