* [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 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
* 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: 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
* [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
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