* Fetching SHA id's instead of named references?
From: Klas Lindberg @ 2009-04-06 12:13 UTC (permalink / raw)
To: Git Users List
Hello
Is there a way to fetch based on SHA id's instead of named references?
My usage scenario is this: A change management tool based on version
controlled manifest files (somewhat similar to Google's Repo) must be
able to check out exact versions of all 200 trees in the project view.
To support this, tags are used since they specify an exact revision.
But there are two problems with tagging:
* Tags are not immutable.
* External components that already have a tagging style get polluted
by our excessive use of tags.
I would really prefer to just list SHA keys in the manifests, but
fetch apparently doesn't support that? Could I use a combination of
lower level commands instead?
BR / Klas
^ permalink raw reply
* Re: Fetching SHA id's instead of named references?
From: Johannes Schindelin @ 2009-04-06 12:33 UTC (permalink / raw)
To: Klas Lindberg; +Cc: Git Users List
In-Reply-To: <33f4f4d70904060513k320fb6a0ya928c714dcd11e89@mail.gmail.com>
Hi,
On Mon, 6 Apr 2009, Klas Lindberg wrote:
> Is there a way to fetch based on SHA id's instead of named references?
No, out of security concerns; imagine you included some proprietary
source code by mistake, and undo the damage by forcing a push with a
branch that does not have the incriminating code. Usually you do not
control the garbage-collection on the server, yet you still do not want
other people to fetch "by SHA-1".
BTW this is really a strong reason not to use HTTP push in such
environments.
Ciao,
Dscho
^ permalink raw reply
* Re: Fetching SHA id's instead of named references?
From: Klas Lindberg @ 2009-04-06 12:41 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Users List
In-Reply-To: <alpine.DEB.1.00.0904061431020.6619@intel-tinevez-2-302>
Hello
Thank you, but I don't understand the answer. If I mistakenly publish
a tree that contains secrets and someone manages to fetch against it
before I correct the mistake; how does the limitation to only fetch
named references help me???
By the way: I don't use push. I'd be perfectly happy if just fetch
supported SHA key references.
BR / Klas
On Mon, Apr 6, 2009 at 2:33 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Mon, 6 Apr 2009, Klas Lindberg wrote:
>
>> Is there a way to fetch based on SHA id's instead of named references?
>
> No, out of security concerns; imagine you included some proprietary
> source code by mistake, and undo the damage by forcing a push with a
> branch that does not have the incriminating code. Usually you do not
> control the garbage-collection on the server, yet you still do not want
> other people to fetch "by SHA-1".
>
> BTW this is really a strong reason not to use HTTP push in such
> environments.
>
> Ciao,
> Dscho
>
^ permalink raw reply
* Re: Broken umlaut in my name, again
From: Santi Béjar @ 2009-04-06 12:46 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Marius Storm-Olsen, Junio C Hamano, git
In-Reply-To: <20090406114618.GF20356@atjola.homenet>
2009/4/6 Björn Steinbrink <B.Steinbrink@gmx.de>:
> On 2009.03.31 17:30:39 +0200, Björn Steinbrink wrote:
>> While it makes no sense to map some email address to an empty one, doing
>> things the other way around can be useful. For example when using
>> filter-branch with an env-filter that employs a mailmap to fix up an
>> import that created such broken commits with empty email addresses.
>>
>> Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
>
> The umlaut (ö) in my name is broken in the commit that made it into
> git.git --> 5288dd58356e53d61e2b3804fc7d8d23c3a46ab3
>
> Last time this happened when I used format-patch -s instead of commit -s
> IIRC. But since then, I pay attention to do the sign-off via commit -s,
> yet my name is broken again. What did I do wrong this time?
I don't see nothing wrong in your mails. It appears to be a double
conversion to UTF-8 between the mail and the commit.
But I always use format-patch -s without problems, what was your
problem with format-patch?
Santi
^ permalink raw reply
* Re: Fetching SHA id's instead of named references?
From: Johannes Schindelin @ 2009-04-06 12:48 UTC (permalink / raw)
To: Klas Lindberg; +Cc: Git Users List
In-Reply-To: <33f4f4d70904060541s6dfb7e8ctf50f5e8a872ae1c@mail.gmail.com>
Hi,
On Mon, 6 Apr 2009, Klas Lindberg wrote:
> Thank you, but I don't understand the answer. If I mistakenly publish a
> tree that contains secrets and someone manages to fetch against it
> before I correct the mistake; how does the limitation to only fetch
> named references help me???
The issue is not if someone manages to fetch stuff before you repair it.
The issue is that that someone should not be able to manage _after_ you
repair it.
Oh, and please do not top-post,
Dscho
^ permalink raw reply
* Re: Fetching SHA id's instead of named references?
From: Matthieu Moy @ 2009-04-06 12:54 UTC (permalink / raw)
To: Klas Lindberg; +Cc: Johannes Schindelin, Git Users List
In-Reply-To: <33f4f4d70904060541s6dfb7e8ctf50f5e8a872ae1c@mail.gmail.com>
Klas Lindberg <klas.lindberg@gmail.com> writes:
> Hello
>
> Thank you, but I don't understand the answer. If I mistakenly publish
> a tree that contains secrets and someone manages to fetch against it
> before I correct the mistake; how does the limitation to only fetch
> named references help me???
What Johannes pointed out is that someone could fetch from your repo
_after_ you correct the mistake (if you don't control garbage
collection).
--
Matthieu
^ permalink raw reply
* Re: [PATCH] Initial Japanese gitk translation
From: Felipe Contreras @ 2009-04-06 13:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: FORS Luis, git
In-Reply-To: <7vws9ymudz.fsf@gitster.siamese.dyndns.org>
On Mon, Apr 6, 2009 at 4:40 AM, Junio C Hamano <gitster@pobox.com> wrote:
> "FORS Luis" <l-fors@cerca-jp.com> writes:
>> +#: gitk:340
>> +msgid "No files selected: --merge specified but no files are unmerged."
>> +msgstr "ファイルが選択されていません：--mergeオプションが指定されたのに未マージファイルはありません。"
>> +
>> +#: gitk:343
>> +msgid "No files selected: --merge specified but no unmerged files are within file limit."
>> +msgstr "ファイルが選択されていません：--mergeオプションが指定されたのに選択されたファイル未マージファイルを含みません。No hay archivos seleccionados: se seleccionó la opción --merge pero los archivos especificados no necesitan fusión."
>
> No habla Español, perdóname.
s/habla/hablo/ :)
--
Felipe Contreras
^ permalink raw reply
* Re: Fetching SHA id's instead of named references?
From: Klas Lindberg @ 2009-04-06 13:06 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Johannes Schindelin, Git Users List
In-Reply-To: <vpqprfq3ptb.fsf@bauges.imag.fr>
On Mon, Apr 6, 2009 at 2:54 PM, Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
> What Johannes pointed out is that someone could fetch from your repo
> _after_ you correct the mistake (if you don't control garbage
> collection).
Aha, ok. But how then does submodule update work? Git will only see
SHA keys for each submodule in the cotntainer tree commit, so how does
it perform fetching of those (unnamed) references?
BR / Klas
^ permalink raw reply
* Re: Performance issue: initial git clone causes massive repack
From: Nicolas Pitre @ 2009-04-06 13:12 UTC (permalink / raw)
To: Junio C Hamano
Cc: david, Nicolas Sebrecht, Robin H. Johnson, Git Mailing List
In-Reply-To: <7vab6ue520.fsf@gitster.siamese.dyndns.org>
On Sun, 5 Apr 2009, Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
> > What git-pack-objects does in this case is not a full repack. It
> > instead _reuse_ as much of the existing packs as possible, and only does
> > the heavy packing processing for loose objects and/or inter pack
> > boundaryes when gluing everything together for streaming over the net.
> > If for example you have a single pack because your repo is already fully
> > packed, then the "packing operation" involved during a clone should
> > merely copy the existing pack over with no further attempt at delta
> > compression.
>
> One possibile scenario that you still need to spend memory and cycle is if
> the cloned repository was packed to an excessive depth to cause many of
> its objects to be in deltified form on insanely deep chains, while cloning
> send-pack uses a depth that is more reasonable. Then pack-objects invoked
> by send-pack is not allowed to reuse most of the objects and would end up
> redoing the delta on them.
Nope. When pack data is reused, there is simply no consideration what
so ever for the actual delta depth limit. Only when an object already
being used as a delta base for reused deltas is itself subject to delta
compression does the real depth of the concerned delta chain is
evaluated in order to not purposely bust the specified delta depth limit
(otherwise a delta chain could grow unbounded).
Nicolas
^ permalink raw reply
* Re: Fetching SHA id's instead of named references?
From: Finn Arne Gangstad @ 2009-04-06 13:16 UTC (permalink / raw)
To: Klas Lindberg; +Cc: Matthieu Moy, Johannes Schindelin, Git Users List
In-Reply-To: <33f4f4d70904060606h4d014fbdibe195a83233d8899@mail.gmail.com>
On Mon, Apr 06, 2009 at 03:06:46PM +0200, Klas Lindberg wrote:
> On Mon, Apr 6, 2009 at 2:54 PM, Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
>
> > What Johannes pointed out is that someone could fetch from your repo
> > _after_ you correct the mistake (if you don't control garbage
> > collection).
>
> Aha, ok. But how then does submodule update work? Git will only see
> SHA keys for each submodule in the cotntainer tree commit, so how does
> it perform fetching of those (unnamed) references?
git submodule update just does "git fetch" and hopes that the required
commit appears. In practice this means that you (may) need to invent a
tag or a branch for all the submodules, otherwise they are not
fetchable.
This bit us pretty hard when we tried to use submodules earlier, so we
gave up. Maybe some day...
- Finn Arne
^ permalink raw reply
* Re: Broken umlaut in my name, again
From: Björn Steinbrink @ 2009-04-06 13:17 UTC (permalink / raw)
To: Santi Béjar; +Cc: Marius Storm-Olsen, Junio C Hamano, git
In-Reply-To: <adf1fd3d0904060546j6c2fbba9r75829f2bd383458b@mail.gmail.com>
On 2009.04.06 14:46:43 +0200, Santi Béjar wrote:
> 2009/4/6 Björn Steinbrink <B.Steinbrink@gmx.de>:
> > On 2009.03.31 17:30:39 +0200, Björn Steinbrink wrote:
> >> While it makes no sense to map some email address to an empty one, doing
> >> things the other way around can be useful. For example when using
> >> filter-branch with an env-filter that employs a mailmap to fix up an
> >> import that created such broken commits with empty email addresses.
> >>
> >> Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
> >
> > The umlaut (ö) in my name is broken in the commit that made it into
> > git.git --> 5288dd58356e53d61e2b3804fc7d8d23c3a46ab3
> >
> > Last time this happened when I used format-patch -s instead of commit -s
> > IIRC. But since then, I pay attention to do the sign-off via commit -s,
> > yet my name is broken again. What did I do wrong this time?
>
> I don't see nothing wrong in your mails. It appears to be a double
> conversion to UTF-8 between the mail and the commit.
>
> But I always use format-patch -s without problems, what was your
> problem with format-patch?
I don't recall the exact problem, and I can't find the mails anymore,
the IIRC it was something about Content-type being generated from the
original commit message, and only afterwards the sign-off line got
added, or something like that. That causes the Content-type to say
ascii, although the sign-off had UTF-8 in it. Or something like that.
Might very well have been fixed since then (it was almost 2 years ago
that I hit that bug IIRC), but it made me stick to commit -s ;-)
Björn
^ permalink raw reply
* Re: [RFC/PATCH 0/2] New 'stage' command
From: David Kågedal @ 2009-04-06 13:20 UTC (permalink / raw)
To: git
Cc: David Aguilar, Sverre Rabbelier, markus.heidelberg,
Felipe Contreras, git
In-Reply-To: <7v63hie4yh.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> David Aguilar <davvid@gmail.com> writes:
>
>> Hello
>>
>> Here's an interesting email from a while back:
Thanks, I would have brought it back up myself if you hadn't.
>> http://kerneltrap.org/mailarchive/git/2008/10/29/3857134
>>
>> The above mentions the following suggestion:
>>
>> git diff STAGE WORKTREE (like "git diff" today)
>> git diff HEAD WORKTREE (like "git diff HEAD" today)
>> git diff WORKTREE HEAD (like "git diff -R HEAD" today)
>> git diff HEAD STAGE (like "git diff --cached" today)
>> git diff commit STAGE (like "git diff --cached commit" today)
>>
>>
>> From a consistency and usability perspective, the above
>> example seems very appealing because:
>>
>> a) it does not introduce any new commands, and
>>
>> b) it is consistent with the way git-diff's command-line
>> interface works today.
>>
>> All we'd have to do is teach git-diff to special-case
>> 'STAGE' and 'WORKTREE'. Now, whether we'd want to do
>> that is a completely different discussion, but I figured I'd
>> throw the old thread out there.
>
> How would you express operations the current --index option does in such a
> scheme? Yet another WORKTREEANDTHEINDEX token?
What do you mean? This was a suggestion for how git diff should
work. I fail to see how you would need a WORKTREEANDTHEINDEX there.
I think this is a basic usability issue for a high-level porcelain
command such as diff. Having the command syntax "git diff <something>
<somethingelse>" makes sure you never wonder what you are
diffing. "git diff --cached" makes me wonder what the index is diffed
against every time I see it.
We wouldn't have to use the "STAGE" or "WORKTREE" names, of course. It
doesn't have to look like refspecs even. The last example already has
a syntax that matches the suggestion:
git diff --cached <commit>
So, extrapolating this to "git diff --worktree --cached" would mean
what "git diff -R" means today etc.
The obvious objection is that "git diff --cached <foo>" would mean the
inverse of "git diff <foo> --cached", but maybe that isn't so
unexpected by the user after all?
--
David Kågedal
^ permalink raw reply
* Re: Performance issue: initial git clone causes massive repack
From: Nicolas Pitre @ 2009-04-06 13:29 UTC (permalink / raw)
To: Matthieu Moy; +Cc: david, Nicolas Sebrecht, Robin H. Johnson, Git Mailing List
In-Reply-To: <vpq3acm6n7p.fsf@bauges.imag.fr>
On Mon, 6 Apr 2009, Matthieu Moy wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
> > If for example you have a single pack because your repo is already fully
> > packed, then the "packing operation" involved during a clone should
> > merely copy the existing pack over with no further attempt at delta
> > compression.
>
> There's still the question if your repository has too many objects
> (for example, a branch that you deleted without garbage-collecting
> it). Then, sending the whole pack sends data that one may have
> considered as "secret".
I said "merely copy", which is not a straight copy. In this case, only
the relevant objects from the existing pack will be copied into the
streamed pack, and objects from the unused branch will be left behind.
In that case, deltas which base object is left behind will automatically
be considered for alternative delta matching of course, but that is
normally a relatively small set of objects. And if that set gets really
big, that means that an even bigger set of objects was left behind,
making the actual repacking smaller in scope.
> To me, this is a non-issue (if the content of these objects are
> secret, then why are they here at all on a public server?), but I
> think there were discussions here about it (can't find the right
> keywords to dig the archives though), and other people may think
> differently.
Guess who was involved in that discussion...
I may allow you to pull certain branches directly from my own PC through
the git native protocol. That doesn't mean you have direct access to
the whole of any of the packs I have on my disk.
Nicolas
^ permalink raw reply
* Re: Broken umlaut in my name, again
From: Santi Béjar @ 2009-04-06 13:40 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Marius Storm-Olsen, Junio C Hamano, git
In-Reply-To: <20090406131747.GH20356@atjola.homenet>
2009/4/6 Björn Steinbrink <B.Steinbrink@gmx.de>:
> On 2009.04.06 14:46:43 +0200, Santi Béjar wrote:
>> 2009/4/6 Björn Steinbrink <B.Steinbrink@gmx.de>:
>> > On 2009.03.31 17:30:39 +0200, Björn Steinbrink wrote:
>> >> While it makes no sense to map some email address to an empty one, doing
>> >> things the other way around can be useful. For example when using
>> >> filter-branch with an env-filter that employs a mailmap to fix up an
>> >> import that created such broken commits with empty email addresses.
>> >>
>> >> Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
>> >
>> > The umlaut (ö) in my name is broken in the commit that made it into
>> > git.git --> 5288dd58356e53d61e2b3804fc7d8d23c3a46ab3
>> >
>> > Last time this happened when I used format-patch -s instead of commit -s
>> > IIRC. But since then, I pay attention to do the sign-off via commit -s,
>> > yet my name is broken again. What did I do wrong this time?
>>
>> I don't see nothing wrong in your mails. It appears to be a double
>> conversion to UTF-8 between the mail and the commit.
>>
>> But I always use format-patch -s without problems, what was your
>> problem with format-patch?
>
> I don't recall the exact problem, and I can't find the mails anymore,
> the IIRC it was something about Content-type being generated from the
> original commit message, and only afterwards the sign-off line got
> added, or something like that. That causes the Content-type to say
> ascii, although the sign-off had UTF-8 in it. Or something like that.
> Might very well have been fixed since then
Yes, it is fixed (at least what you described).
> (it was almost 2 years ago
> that I hit that bug IIRC),
Uf! half an eternity in git scale ;-)
Santi
^ permalink raw reply
* [PATCH 0/3] git remote update: Check args and fallback to remotes
From: Finn Arne Gangstad @ 2009-04-06 13:40 UTC (permalink / raw)
To: git; +Cc: gitster, Finn Arne Gangstad
This series is on top of next.
git remote update <non-existing> would previously silently do nothing.
With this patch series, it will (with 1/3) error out when non-existing groups
are given, and with 2/3 & 3/3 it will use a remote if a group cannot be found.
This enables "git remote update origin" for example. All previous uses
of "git remote update <x>" that did something useful should still work
exactly as before.
There seems to be no current way to check for the existence of a configured
remote, so 2/3 adds a remote_is_configured() function which checks for a
configured remote.
Finn Arne Gangstad (3):
git remote update: Report error for non-existing groups
remote: New function remote_is_configured()
git remote update: Fallback to remote if group does not exist
Documentation/git-remote.txt | 2 +-
builtin-remote.c | 17 ++++++++++++++---
remote.c | 11 +++++++++++
remote.h | 1 +
4 files changed, 27 insertions(+), 4 deletions(-)
^ permalink raw reply
* [PATCH 1/3] git remote update: Report error for non-existing groups
From: Finn Arne Gangstad @ 2009-04-06 13:41 UTC (permalink / raw)
To: git; +Cc: gitster, Finn Arne Gangstad
In-Reply-To: <1239025262-16960-1-git-send-email-finnag@pvv.org>
Previosly, git remote update <non-existing-group> would just silently fail
and do nothing. Now it will report an error saying that the group does
not exist.
Signed-off-by: Finn Arne Gangstad <finnag@pvv.org>
---
builtin-remote.c | 11 ++++++++---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/builtin-remote.c b/builtin-remote.c
index 3146eb4..51df99b 100644
--- a/builtin-remote.c
+++ b/builtin-remote.c
@@ -1188,16 +1188,18 @@ struct remote_group {
struct string_list *list;
} remote_group;
-static int get_remote_group(const char *key, const char *value, void *cb)
+static int get_remote_group(const char *key, const char *value, void *num_hits)
{
if (!prefixcmp(key, "remotes.") &&
!strcmp(key + 8, remote_group.name)) {
/* split list by white space */
int space = strcspn(value, " \t\n");
while (*value) {
- if (space > 1)
+ if (space > 1) {
string_list_append(xstrndup(value, space),
remote_group.list);
+ ++*((int *)num_hits);
+ }
value += space + (value[space] != '\0');
space = strcspn(value, " \t\n");
}
@@ -1227,8 +1229,11 @@ static int update(int argc, const char **argv)
remote_group.list = &list;
for (i = 1; i < argc; i++) {
+ int groups_found = 0;
remote_group.name = argv[i];
- result = git_config(get_remote_group, NULL);
+ result = git_config(get_remote_group, &groups_found);
+ if (!groups_found && (i != 1 || strcmp(argv[1], "default")))
+ die("No such remote group: '%s'", argv[i]);
}
if (!result && !list.nr && argc == 2 && !strcmp(argv[1], "default"))
--
1.6.2.1.471.gdfdaa
^ permalink raw reply related
* [PATCH 2/3] remote: New function remote_is_configured()
From: Finn Arne Gangstad @ 2009-04-06 13:41 UTC (permalink / raw)
To: git; +Cc: gitster, Finn Arne Gangstad
In-Reply-To: <1239025262-16960-1-git-send-email-finnag@pvv.org>
Previously, there was no beautiful way to check for the existence of
a configured remote. remote_get for example would always create the remote
"on demand".
This new function returns 1 if the remote is configured, 0 otherwise.
Signed-off-by: Finn Arne Gangstad <finnag@pvv.org>
---
remote.c | 11 +++++++++++
remote.h | 1 +
2 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/remote.c b/remote.c
index d12140e..a06761a 100644
--- a/remote.c
+++ b/remote.c
@@ -667,6 +667,17 @@ struct remote *remote_get(const char *name)
return ret;
}
+int remote_is_configured(const char *name)
+{
+ int i;
+ read_config();
+
+ for (i = 0; i < remotes_nr; i++)
+ if (!strcmp(name, remotes[i]->name))
+ return 1;
+ return 0;
+}
+
int for_each_remote(each_remote_fn fn, void *priv)
{
int i, result = 0;
diff --git a/remote.h b/remote.h
index de3d21b..99706a8 100644
--- a/remote.h
+++ b/remote.h
@@ -45,6 +45,7 @@ struct remote {
};
struct remote *remote_get(const char *name);
+int remote_is_configured(const char *name);
typedef int each_remote_fn(struct remote *remote, void *priv);
int for_each_remote(each_remote_fn fn, void *priv);
--
1.6.2.1.471.gdfdaa
^ permalink raw reply related
* [PATCH 3/3] git remote update: Fallback to remote if group does not exist
From: Finn Arne Gangstad @ 2009-04-06 13:41 UTC (permalink / raw)
To: git; +Cc: gitster, Finn Arne Gangstad
In-Reply-To: <1239025262-16960-1-git-send-email-finnag@pvv.org>
Previously, git remote update <remote> would fail unless there was
a remote group configured with the same name as the remote.
git remote update will now fall back to using the remote if no matching
group can be found.
This enables "git remote update -p <remote>..." to fetch and prune one
or more remotes, for example.
Signed-off-by: Finn Arne Gangstad <finnag@pvv.org>
---
Documentation/git-remote.txt | 2 +-
builtin-remote.c | 10 ++++++++--
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt
index 0b6e67d..9e2b4ea 100644
--- a/Documentation/git-remote.txt
+++ b/Documentation/git-remote.txt
@@ -16,7 +16,7 @@ SYNOPSIS
'git remote set-head' <name> [-a | -d | <branch>]
'git remote show' [-n] <name>
'git remote prune' [-n | --dry-run] <name>
-'git remote update' [-p | --prune] [group]
+'git remote update' [-p | --prune] [group | remote]...
DESCRIPTION
-----------
diff --git a/builtin-remote.c b/builtin-remote.c
index 51df99b..ca7c639 100644
--- a/builtin-remote.c
+++ b/builtin-remote.c
@@ -1232,8 +1232,14 @@ static int update(int argc, const char **argv)
int groups_found = 0;
remote_group.name = argv[i];
result = git_config(get_remote_group, &groups_found);
- if (!groups_found && (i != 1 || strcmp(argv[1], "default")))
- die("No such remote group: '%s'", argv[i]);
+ if (!groups_found && (i != 1 || strcmp(argv[1], "default"))) {
+ struct remote *remote;
+ if (!remote_is_configured(argv[i]))
+ die("No such remote or remote group: %s",
+ argv[i]);
+ remote = remote_get(argv[i]);
+ string_list_append(remote->name, remote_group.list);
+ }
}
if (!result && !list.nr && argc == 2 && !strcmp(argv[1], "default"))
--
1.6.2.1.471.gdfdaa
^ permalink raw reply related
* Submodules can't work recursively because Git implements policy?
From: Klas Lindberg @ 2009-04-06 13:42 UTC (permalink / raw)
To: Finn Arne Gangstad; +Cc: Matthieu Moy, Johannes Schindelin, Git Users List
On Mon, Apr 6, 2009 at 3:16 PM, Finn Arne Gangstad <finnag@pvv.org> wrote:
> git submodule update just does "git fetch" and hopes that the required
> commit appears. In practice this means that you (may) need to invent a
> tag or a branch for all the submodules, otherwise they are not
> fetchable.
>
> This bit us pretty hard when we tried to use submodules earlier, so we
> gave up. Maybe some day...
It "hopes" to find them? This is actually my other reason for bringing
the whole SHA key fetching thing up. From what I can see, it is not
possible to implement submodules sensibly without support for fetching
SHA keys. I.e. I want fetch, checkout and every other command to
recurse as needed in the presence of submodules. This limitation
forces me to implement a whole CM tool where none should be necessary.
It appears to me that the security concern (being able to hide commits
by making them unreachable from a named reference) is actually a
policy decision and not a technical one. On what grounds does Git
decide for me how to handle security concerns? It just seems more
important to be able to have recursive submodule behaviour than to
provide band aid for careless users.
Out of curiosity: Is it really possible to change the value of an
already pushed tag? Can you only do the hiding trick with branches?
BR / Klas
^ permalink raw reply
* Re: [RFC/PATCH 0/2] New 'stage' command
From: David Kågedal @ 2009-04-06 13:42 UTC (permalink / raw)
To: git
Cc: David Aguilar, Sverre Rabbelier, markus.heidelberg,
Felipe Contreras, Junio C Hamano
In-Reply-To: <871vs5kjfw.fsf@krank.kagedal.org>
David Kågedal <davidk@lysator.liu.se> writes:
> We wouldn't have to use the "STAGE" or "WORKTREE" names, of course. It
> doesn't have to look like refspecs even. The last example already has
> a syntax that matches the suggestion:
>
> git diff --cached <commit>
>
> So, extrapolating this to "git diff --worktree --cached" would mean
> what "git diff -R" means today etc.
BTW, I don't really care much about whether it's spelled "cached"
"index" "staged" or "dumbledore". I just want some regularity in the
diff command. I'll happily let someone else figure out the taxonomy.
--
David Kågedal
^ permalink raw reply
* Re: Performance issue: initial git clone causes massive repack
From: Jon Smirl @ 2009-04-06 13:52 UTC (permalink / raw)
To: Junio C Hamano
Cc: Nicolas Pitre, david, Nicolas Sebrecht, Robin H. Johnson,
Git Mailing List, Shawn O. Pearce
In-Reply-To: <7vab6ue520.fsf@gitster.siamese.dyndns.org>
On Mon, Apr 6, 2009 at 1:15 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
>> What git-pack-objects does in this case is not a full repack. It
>> instead _reuse_ as much of the existing packs as possible, and only does
>> the heavy packing processing for loose objects and/or inter pack
>> boundaryes when gluing everything together for streaming over the net.
>> If for example you have a single pack because your repo is already fully
>> packed, then the "packing operation" involved during a clone should
>> merely copy the existing pack over with no further attempt at delta
>> compression.
>
> One possibile scenario that you still need to spend memory and cycle is if
> the cloned repository was packed to an excessive depth to cause many of
> its objects to be in deltified form on insanely deep chains, while cloning
> send-pack uses a depth that is more reasonable. Then pack-objects invoked
> by send-pack is not allowed to reuse most of the objects and would end up
> redoing the delta on them.
That seems broken. You went through all of the trouble to make the
pack file smaller to reduce transmission time, and then clone undoes
the work.
What about making a very simple special case for an initial clone?
First thing an initial clone does is copy all of the pack files from
the server to the client without even looking at them. Some of these
packs will probably be marked 'keep' because they are old history and
have been densely packed. Once the packs are down, start over and do a
fetch taking these packs into account.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Submodules can't work recursively because Git implements policy?
From: Finn Arne Gangstad @ 2009-04-06 13:56 UTC (permalink / raw)
To: Klas Lindberg; +Cc: Matthieu Moy, Johannes Schindelin, Git Users List
In-Reply-To: <33f4f4d70904060642m25b2cff8nafed433eeabfb6c4@mail.gmail.com>
On Mon, Apr 06, 2009 at 03:42:31PM +0200, Klas Lindberg wrote:
> On Mon, Apr 6, 2009 at 3:16 PM, Finn Arne Gangstad <finnag@pvv.org> wrote:
>
> > git submodule update just does "git fetch" and hopes that the required
> > commit appears. In practice this means that you (may) need to invent a
> > tag or a branch for all the submodules, otherwise they are not
> > fetchable.
> >
> > This bit us pretty hard when we tried to use submodules earlier, so we
> > gave up. Maybe some day...
>
> It "hopes" to find them?
Perhaps "hopes" is a loaded word, "expects" at least. The code just
does the equivalent of "git fetch; git checkout <sha-1> || die .. "
> This is actually my other reason for bringing
> the whole SHA key fetching thing up. From what I can see, it is not
> possible to implement submodules sensibly without support for fetching
> SHA keys. I.e. I want fetch, checkout and every other command to
> recurse as needed in the presence of submodules. This limitation
> forces me to implement a whole CM tool where none should be necessary.
Yes, I could not agree more. You may also end up writing some really
complicated wrappers around git push to get things going (where do you
push, for example). We made some interesting "concept art" around this
last year at $dayjob, but decided to drop it.
> It appears to me that the security concern (being able to hide commits
> by making them unreachable from a named reference) is actually a
> policy decision and not a technical one. On what grounds does Git
> decide for me how to handle security concerns? It just seems more
> important to be able to have recursive submodule behaviour than to
> provide band aid for careless users.
Maybe the security concerns could be handled by adding some
functionality to (quickly) get rid of unwanted commits?
> Out of curiosity: Is it really possible to change the value of an
> already pushed tag? Can you only do the hiding trick with branches?
Yes, but if you modify a tag, you get additional complications. In
particular, no one will ever try to refetch the tag, so everyone who
has already fetched it will have a permanently broken tag.
- Finn Arne
^ permalink raw reply
* Re: Performance issue: initial git clone causes massive repack
From: Robin H. Johnson @ 2009-04-06 14:03 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0904060912530.6741@xanadu.home>
[-- Attachment #1: Type: text/plain, Size: 1034 bytes --]
I haven't read all this morning submissions to the thread yet, but I
wanted to make two posts before I leave on a trip (in ~20 minutes), and
I'll be back late on Thursday.
On Mon, Apr 06, 2009 at 09:29:04AM -0400, Nicolas Pitre wrote:
> > To me, this is a non-issue (if the content of these objects are
> > secret, then why are they here at all on a public server?), but I
> > think there were discussions here about it (can't find the right
> > keywords to dig the archives though), and other people may think
> > differently.
> Guess who was involved in that discussion...
> I may allow you to pull certain branches directly from my own PC through
> the git native protocol. That doesn't mean you have direct access to
> the whole of any of the packs I have on my disk.
If the native rsync protocol is allowed to the repo, then that argument
is moot.
--
Robin Hugh Johnson
Gentoo Linux Developer & Infra Guy
E-Mail : robbat2@gentoo.org
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
[-- Attachment #2: Type: application/pgp-signature, Size: 330 bytes --]
^ permalink raw reply
* Re: Performance issue: initial git clone causes massive repack
From: Nicolas Pitre @ 2009-04-06 14:14 UTC (permalink / raw)
To: Robin H. Johnson; +Cc: Git Mailing List
In-Reply-To: <20090406T140124Z@curie.orbis-terrarum.net>
On Mon, 6 Apr 2009, Robin H. Johnson wrote:
> I haven't read all this morning submissions to the thread yet, but I
> wanted to make two posts before I leave on a trip (in ~20 minutes), and
> I'll be back late on Thursday.
>
> On Mon, Apr 06, 2009 at 09:29:04AM -0400, Nicolas Pitre wrote:
> > > To me, this is a non-issue (if the content of these objects are
> > > secret, then why are they here at all on a public server?), but I
> > > think there were discussions here about it (can't find the right
> > > keywords to dig the archives though), and other people may think
> > > differently.
> > Guess who was involved in that discussion...
> > I may allow you to pull certain branches directly from my own PC through
> > the git native protocol. That doesn't mean you have direct access to
> > the whole of any of the packs I have on my disk.
> If the native rsync protocol is allowed to the repo, then that argument
> is moot.
The rsync protocol is _not_ the native git protocol. And I personally
don't encourage its usage either, except as a _temporary_ workaround for
unresolved issues. You will never see this protocol available from any
git server I maintain.
Nicolas
^ permalink raw reply
* Re: Performance issue: initial git clone causes massive repack
From: Nicolas Pitre @ 2009-04-06 14:19 UTC (permalink / raw)
To: Jon Smirl
Cc: Junio C Hamano, david, Nicolas Sebrecht, Robin H. Johnson,
Git Mailing List, Shawn O. Pearce
In-Reply-To: <9e4733910904060652t6c0f37d9t246b7394e3aad350@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2515 bytes --]
On Mon, 6 Apr 2009, Jon Smirl wrote:
> On Mon, Apr 6, 2009 at 1:15 AM, Junio C Hamano <gitster@pobox.com> wrote:
> > Nicolas Pitre <nico@cam.org> writes:
> >
> >> What git-pack-objects does in this case is not a full repack. It
> >> instead _reuse_ as much of the existing packs as possible, and only does
> >> the heavy packing processing for loose objects and/or inter pack
> >> boundaryes when gluing everything together for streaming over the net.
> >> If for example you have a single pack because your repo is already fully
> >> packed, then the "packing operation" involved during a clone should
> >> merely copy the existing pack over with no further attempt at delta
> >> compression.
> >
> > One possibile scenario that you still need to spend memory and cycle is if
> > the cloned repository was packed to an excessive depth to cause many of
> > its objects to be in deltified form on insanely deep chains, while cloning
> > send-pack uses a depth that is more reasonable. Then pack-objects invoked
> > by send-pack is not allowed to reuse most of the objects and would end up
> > redoing the delta on them.
>
> That seems broken. You went through all of the trouble to make the
> pack file smaller to reduce transmission time, and then clone undoes
> the work.
And as I already explained, this is indeed not what happens.
> What about making a very simple special case for an initial clone?
There should not be any need for initial clone hacks.
> First thing an initial clone does is copy all of the pack files from
> the server to the client without even looking at them.
This is a no go for reasons already stated many times. There are
security implications (those packs might contain stuff that you didn't
intend to be publically accessible) and there might be efficiency
reasons as well (you might have a shared object store with lots of stuff
unrelated to the particular clone).
The biggest cost right now when cloning a big packed repo is object
enumeration. Any other issues related to memory costs in the GB range
simply has no reason for it, and is mostly due to misconfigurations or
bugs that have to be fixed. Trying to work around the issue by all
sorts of hacks is simply counter productive.
In the case that started this very thread, I suspect that a small
misfeature of some delta caching might be the culprit. I asked Robin H.
Johnson to perform a really simple config addition to his repo and
retest, for which we still haven't seen any results yet.
Nicolas
^ 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