* [PATCH 2/2] t/README: hint about using $(pwd) rather than $PWD in tests
From: Johannes Sixt @ 2011-01-11 7:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonathan Nieder, Nguyen Thai Ngoc Duy, git
In-Reply-To: <4D2C09D7.3070700@viscovery.net>
From: Johannes Sixt <j6t@kdbg.org>
This adds just a "do it this way" instruction without a lot of explanation,
because the details are too complex to be explained at this point.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
t/README | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/t/README b/t/README
index 90718b4..f98ebb3 100644
--- a/t/README
+++ b/t/README
@@ -283,6 +283,12 @@ Do:
Tests that are likely to smoke out future regressions are better
than tests that just inflate the coverage metrics.
+ - When a test checks for an absolute path that a git command generated,
+ construct the expected value using $(pwd) rather than $PWD,
+ $TEST_DIRECTORY, or $TRASH_DIRECTORY. It makes a difference on
+ Windows, where the shell (MSYS bash) mangles absolute path names.
+ For details, see the commit message of 4114156ae9.
+
Don't:
- exit() within a <script> part.
--
1.7.4.rc1.1258.g84aa
^ permalink raw reply related
* Re: bug? in checkout with ambiguous refnames
From: Jeff King @ 2011-01-11 6:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Uwe Kleine-König, git
In-Reply-To: <20110107195417.GC6175@sigill.intra.peff.net>
On Fri, Jan 07, 2011 at 02:54:17PM -0500, Jeff King wrote:
> +test_expect_success 'checkout reports switch to detached HEAD' '
> + grep "Switched to branch" stderr &&
> + ! grep "^HEAD is now at" stderr
Junio, one minor fixup here. The test is correct, but the description
should read "checkout reports switch to branch", not "...detached HEAD".
I had originally written the test the other way and forgot to update the
description when I tweaked it. The error is in my ambiguity test, but
got cut-and-pasted to your vagueness test, too.
-Peff
^ permalink raw reply
* Re: clone breaks replace
From: Jonathan Nieder @ 2011-01-11 6:52 UTC (permalink / raw)
To: Jeff King; +Cc: Phillip Susi, git, Christian Couder, Stephen Bash
In-Reply-To: <20110111054735.GC10094@sigill.intra.peff.net>
Jeff King wrote:
> On Fri, Jan 07, 2011 at 07:43:40PM -0500, Phillip Susi wrote:
>> What parts do not respect replacement? More importantly, what parts
>> will be broken?
[...]
> Off the top of my head, I don't know. I suspect it would take somebody
> writing a patch to create such an incomplete repository (or making one
> manually) and seeing how badly things broke.
I have two worries:
- first, how easily can the replacement be undone? (as you mention
below)
- second, what happens if the two ends of transport have different
replacements?
That second worry is the more major in my opinion. Shallow clones are
a different story --- they do not fundamentally change the history and
they have special support in git protocol. It is possible to punt on
both by saying that (1) replacements _cannot_ be undone --- a second
replacement is needed --- and (2) the receiving end of a connection is
not allowed to have any replacements for objects in common that the
sending end does not have, but then does that buy you anything
significant over a filter-branch?
^ permalink raw reply
* Re: bug? in checkout with ambiguous refnames
From: Jeff King @ 2011-01-11 6:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Uwe Kleine-König, git
In-Reply-To: <7vipy0483h.fsf@alter.siamese.dyndns.org>
On Fri, Jan 07, 2011 at 03:17:22PM -0800, Junio C Hamano wrote:
> ... And this comes on top (should probably be squashed into one) to really
> favor a branch over a tag.
>
> builtin/checkout.c | 26 ++++++++++----------------
> t/t2019-checkout-amiguous-ref.sh | 2 +-
> 2 files changed, 11 insertions(+), 17 deletions(-)
Yeah, that looks sane to me (assuming all three patches squashed
together). It took me a minute to figure out one subtlety, though:
> + if ((check_ref_format(new.path) != CHECK_REF_FORMAT_OK) ||
> + !resolve_ref(new.path, rev, 1, NULL))
> + new.path = NULL; /* not an existing branch */
> +
> + if (!(new.commit = lookup_commit_reference_gently(rev, 1))) {
We are relying on the fact that resolve_ref leaves "rev" alone in the
case that it does not find anything. Which is mostly true (the only
exception seems to be if you have a ref with non-hex garbage in it, in
which case you will get some bogus sha1 in the output). I dunno if it is
worth making it more explicit, like:
diff --git a/builtin/checkout.c b/builtin/checkout.c
index f6f6172..afff56f 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -678,7 +678,7 @@ static const char *unique_tracking_name(const char *name)
int cmd_checkout(int argc, const char **argv, const char *prefix)
{
struct checkout_opts opts;
- unsigned char rev[20];
+ unsigned char rev[20], branch_rev[20];
const char *arg;
struct branch_info new;
struct tree *source_tree = NULL;
@@ -834,8 +834,10 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
new.name = arg;
setup_branch_path(&new);
- if ((check_ref_format(new.path) != CHECK_REF_FORMAT_OK) ||
- !resolve_ref(new.path, rev, 1, NULL))
+ if ((check_ref_format(new.path) == CHECK_REF_FORMAT_OK) &&
+ resolve_ref(new.path, branch_rev, 1, NULL))
+ hashcpy(rev, branch_rev);
+ else
new.path = NULL; /* not an existing branch */
if (!(new.commit = lookup_commit_reference_gently(rev, 1))) {
My version somehow looks uglier, but I just worry about resolve_ref
violating this undocumented subtlety sometime in the future.
Also, one other question while we are on the subject. I think we all
agree that "git checkout $foo" should prefer $foo as a branch. But what
about "git checkout -b $branch $start_point"? Should $start_point follow
the same "prefer branches" rule, or should it use the usual ref lookup
rules?
I was surprised to find that the current behavior is to die(), due to an
explicit case in branch.c:create_branch.
-Peff
^ permalink raw reply related
* Re: [PATCH] docs: explain diff.*.binary option
From: Jeff King @ 2011-01-11 6:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Matthieu Moy, git
In-Reply-To: <7vpqs463o4.fsf@alter.siamese.dyndns.org>
On Mon, Jan 10, 2011 at 09:59:07AM -0800, Junio C Hamano wrote:
> Thanks. I take it that this documents 122aa6f (diff: introduce
> diff.<driver>.binary, 2008-10-05) where you said...
>
> This patch introduces a "binary" config option for a diff
> driver, so that one can explicitly set diff.foo.binary. We
> default this value to "don't know". That is, setting a diff
> attribute to "foo" and using "diff.foo.funcname" will have
> no effect on the binaryness of a file. To get the current
> behavior, one can set diff.foo.binary to true.
>
> I am scratching my head about the last sentence, though. Shouldn't that
> be "false"? In the olden days, setting diff.foo.funcname made it text but
> with this change it no longer is the case and instead binaryness is
> determined by content inspection, so forcing "text" needs to be done by
> saying "this is _not_ binary", no?
Yeah, that definitely should be "false". I think it was simply a think-o
when typing the commit message (and I just did a quick test to double
check that the behavior described by the message is in fact what
happens).
Reading that thread, too, I think I was a little confused at first back
then about how diff.*.binary would be used with respect to textconv, but
between some thinking and JSixt beating some sense into me, it came out
with at least the correct semantics, if not an accurate commit message.
:)
-Peff
^ permalink raw reply
* Re: git-config does not check validity of variable names
From: Jeff King @ 2011-01-11 5:59 UTC (permalink / raw)
To: Libor Pechacek; +Cc: git
In-Reply-To: <20110108144644.GA11019@localhost.suse.cz>
On Sat, Jan 08, 2011 at 03:46:44PM +0100, Libor Pechacek wrote:
> I've noticed that git-config accepts variable names in the form "a=b" for its
> "get" operation. That means "git config a=b" does not write anything to its
> output and exists with status 1.
>
> According to the man page only alphanumeric characters and - are allowed in
> variable names. Would it make sense to spit out an error message when the user
> supplies an invalid variable name like the above?
Probably. The current behavior isn't all that terrible, in that it
simply tries to look up the key, which of course doesn't exist (because
it cannot syntactically), and does signal an error (with the exit code).
So it is in some ways no worse than a typo like "git config
color.dif.branch". And we probably don't want to start writing to stderr
in such a case, as scripts assume they can call git config to find out
whether the variable is defined without having to redirect stderr.
That being said, I can see how the lack of a message could be confusing
for a user who mistakenly thinks "git config color.diff.branch=red"
should work. So I think a patch to make that better would get a
favorable response.
Note, though, that what you wrote above is not strictly true. The
manpage says variable names and section names must be alphanumeric. But
subsection names can contain any character except newline. So it is
valid syntactically to do:
git config color.diff=red.branch
where the subsection contains the "=". Obviously this example is
nonsense, and in practice most such "a=b" forms will end up not being
syntactically valid (because the = will be part of the variable name,
not the subsection). But if you are going to write a patch, you need to
make sure not to accidentally disallow:
git config 'diff.my custom diff driver.command'
-Peff
^ permalink raw reply
* Re: clone breaks replace
From: Jeff King @ 2011-01-11 5:47 UTC (permalink / raw)
To: Phillip Susi; +Cc: Jonathan Nieder, git, Christian Couder, Stephen Bash
In-Reply-To: <4D27B33C.2020907@cfl.rr.com>
On Fri, Jan 07, 2011 at 07:43:40PM -0500, Phillip Susi wrote:
> >Based on previous discussions, I think the answer to the first is no.
> >The resulting repo violates a fundamental assumption of git. Yes,
> >because of the replacement object, many things will still work. But many
> >parts of git intentionally do not respect replacement, and they will be
> >broken.
>
> What parts do not respect replacement? More importantly, what parts
> will be broken? The man page seems to indicate that about the only
> thing that does not by default is reachability testing, which to me
> means fsck and prune. It seems to be the purpose of replace to
> /prevent/ breakage and be respected by default, unless doing so would
> cause harm, which is why fsck and prune do not.
Off the top of my head, I don't know. I suspect it would take somebody
writing a patch to create such an incomplete repository (or making one
manually) and seeing how badly things broke. Maybe nothing would, and I
am being overly conservative. It just makes me nervous to start
violating what has always been a fundamental assumption about the object
database (though as I pointed out, we did start violating it with
shallow clones, so maybe it is not so bad).
> >Instead, I think of replacements as a specific view into history, not a
> >fundamental history-changing operation itself. Which means you can never
> >save bandwidth or space by truncating history with replacements. You can
> >only give somebody the full history, and share with them your view. If
> >you want to truncate, you must rewrite history[1].
>
> Right, but if you only care about that view, then there is no need to
> waste bandwidth fetching the original one. It goes without saying
> that people pulling from the repository mainly care about the view
> upstream chooses to publish. Upstream can choose to rewrite, which
> will cause breakage and is a sort of sneaky way to hide the original
> history, or they can use replace, which avoids the breakage and gives
> the client the choice of which view to use.
Once you have fetched with that view, how locked into that view are you?
Certainly you can never push to or be the fetch remote for another
repository that does not want to respect that view, because you simply
don't have the objects to complete the history for them.
But what about deepening your own repo? In your proposal, I contact the
server and ask for the replacement refs along with the branch refs. For
the history of the branches, it gives me the truncated version with the
replacement objects, right? Now how do I go back later and say "I'm
interested in getting the rest of history, give me the real one"?
I guess you can get the parent pointer from the real, "non-replaced"
object and ask for it. But you can't ask for a specific commit, so for
every such truncation, the parent needs to publish an extra ref (but
_not_ make it one of the ones fetched by default, or it would nullify
your original shallow fetch), and we need to contact them and find that
ref.
So I guess it's do-able, but there are a few interesting corners. I
think somebody would need to whip up a proof of concept patch to explore
those corners.
-Peff
^ permalink raw reply
* Re: clone breaks replace
From: Jeff King @ 2011-01-11 5:36 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jonathan Nieder, Phillip Susi, git, Christian Couder,
Stephen Bash
In-Reply-To: <7vmxnc48yt.fsf@alter.siamese.dyndns.org>
On Fri, Jan 07, 2011 at 02:58:34PM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > 2. Should clone fetch refs from refs/replace (either by default, or
> > with an option)?
> > ...
> > Which leads to the second question. It is basically a matter of saying
> > "do you want to fetch the view that upstream has"? I can definitely see
> > that being useful, and meriting an option. However, it may or may not be
> > worth turning on by default, as upstream's view may be confusing.
>
> I think that should be stated a bit differently. "Do you want to fetch
> the view that the upstream offers as an option, and if you want, which
> ones (meaning: there could be more than one replacement grafts to give
> different views)?"
Sure, I think that is a sane way for the user to think about it, but do
we actually support multiple views? I thought replacement objects were
all or nothing.
-Peff
^ permalink raw reply
* Re: [PATCH] commit: suggest --amend --reset-author to fix commiter identity
From: Jeff King @ 2011-01-11 5:34 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Junio C Hamano, git
In-Reply-To: <vpq1v4nirzz.fsf@bauges.imag.fr>
On Sat, Jan 08, 2011 at 11:56:00AM +0100, Matthieu Moy wrote:
> > Wouldn't it work better to just get rid of the longer form and say
> > something like:
> >
> > ... here is how to tell your name to git (existing message) ...
> >
> > After doing the above, run
> >
> > git commit --amend --reset-author
> >
> > to fix the identity used for this commit.
>
> I'm fine with that proposal too. I'll resend with that if no one
> objects. Probalby rewording it to
Hmm. When I originally wrote that message, I specifically avoided using
--reset-author because I figured people would want to most immediately
fix the broken commit, and then maybe would not be too lazy to fix
things for the future. But that was just a hunch, and I don't feel
strongly about it.
I was also afraid of people blindly running the fixup command without
doing the configuration specified in the commands above. However, I
think as long as the text makes it clear that one depends on the other,
it should be OK. So something like:
> After doing this, you can fix the identity used for this commit with:
>
> git commit --amend --reset-author
looks fine to me.
-Peff
^ permalink raw reply
* Re: [PATCH] submodule: fix relative url parsing for scp-style origin
From: Mark Levedahl @ 2011-01-11 2:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thomas Rast, git, Jeffrey Phillips Freeman
In-Reply-To: <7v62tw7kx6.fsf@alter.siamese.dyndns.org>
On 01/10/2011 12:01 PM, Junio C Hamano wrote:
> Thomas Rast<trast@student.ethz.ch> writes:
>
>> The function resolve_relative_url was not prepared to deal with an
>> scp-style origin 'user@host:path' in the case where 'path' is only a
>> single component. Fix this by extending the logic that strips one
>> path component from the $remoteurl.
>>
>> Also add tests for both styles of URLs.
>>
>> Noticed-by: Jeffrey Phillips Freeman<jeffrey.freeman@syncleus.com>
>> Signed-off-by: Thomas Rast<trast@student.ethz.ch>
>> ---
>>
>> If Mark agrees with the fix, I think this should go in before 1.7.4
>> since it's a pretty annoying bug.
> Seems obvious to me from a cursory look; thanks.
>
Looks ok to me. (FWIW, note that the original function handles
user@host:~/path just fine :^).
Mark
^ permalink raw reply
* Re: Resumable clone/Gittorrent (again) - stable packs?
From: Nguyen Thai Ngoc Duy @ 2011-01-11 1:56 UTC (permalink / raw)
To: J.H.; +Cc: John Wyzer, git
In-Reply-To: <4D2BAB0A.1060909@kernel.org>
On Tue, Jan 11, 2011 at 7:57 AM, J.H. <warthog9@kernel.org> wrote:
> On 01/10/2011 04:03 PM, Nguyen Thai Ngoc Duy wrote:
>> On Mon, Jan 10, 2011 at 11:39 PM, John Wyzer <john.wyzer@gmx.de> wrote:
>>> Why not provide an alternative mode for the git:// protocoll that instead of
>>> retrieving a big packaged blob breaks this down to the smallest atomic
>>> objects from the repository? Those are not changing and should be able to
>>> survive partial transfers.
>>> While this might not be as efficient network traffic-wise it would provide a
>>> solution for those behind breaking connections.
>>
>> That's what I'm getting to, except that I'll send deltas as much as I can.
>
> While I think we need to come up with a mechanism to allow for resumable
> fetches (I'm thinking slow sporadic links and larger repos like the
> kernel for instance), but breaking the repo up into too small a chunks
> will very adversely affect the overall transfer and could cause just as
> much system thrash on the upstream provider.
>
> I'd be curious to see what the system impact numbers and performance
> differences are though, as I do think getting some sort of resumability
> is important, but resumability at the expense of being able to get the
> data out quickly and efficiently is not going to be a good trade off :-/
Yeah, I'm interested in those numbers too. Let me get a prototype
working, then we'll have numbers to discuss.
--
Duy
^ permalink raw reply
* Re: Resumable clone/Gittorrent (again) - stable packs?
From: J.H. @ 2011-01-11 0:57 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: John Wyzer, git
In-Reply-To: <AANLkTimh1RRnjXjg-fw_-RQxNW_fLbSYis8n2BvNaCc+@mail.gmail.com>
On 01/10/2011 04:03 PM, Nguyen Thai Ngoc Duy wrote:
> On Mon, Jan 10, 2011 at 11:39 PM, John Wyzer <john.wyzer@gmx.de> wrote:
>> Why not provide an alternative mode for the git:// protocoll that instead of
>> retrieving a big packaged blob breaks this down to the smallest atomic
>> objects from the repository? Those are not changing and should be able to
>> survive partial transfers.
>> While this might not be as efficient network traffic-wise it would provide a
>> solution for those behind breaking connections.
>
> That's what I'm getting to, except that I'll send deltas as much as I can.
While I think we need to come up with a mechanism to allow for resumable
fetches (I'm thinking slow sporadic links and larger repos like the
kernel for instance), but breaking the repo up into too small a chunks
will very adversely affect the overall transfer and could cause just as
much system thrash on the upstream provider.
I'd be curious to see what the system impact numbers and performance
differences are though, as I do think getting some sort of resumability
is important, but resumability at the expense of being able to get the
data out quickly and efficiently is not going to be a good trade off :-/
- John 'Warthog9' Hawley
^ permalink raw reply
* Re: Resumable clone/Gittorrent (again) - stable packs?
From: Nguyen Thai Ngoc Duy @ 2011-01-11 0:03 UTC (permalink / raw)
To: John Wyzer; +Cc: git
In-Reply-To: <4D2B3643.2070106@gmx.de>
On Mon, Jan 10, 2011 at 11:39 PM, John Wyzer <john.wyzer@gmx.de> wrote:
> Why not provide an alternative mode for the git:// protocoll that instead of
> retrieving a big packaged blob breaks this down to the smallest atomic
> objects from the repository? Those are not changing and should be able to
> survive partial transfers.
> While this might not be as efficient network traffic-wise it would provide a
> solution for those behind breaking connections.
That's what I'm getting to, except that I'll send deltas as much as I can.
--
Duy
^ permalink raw reply
* Re: Concurrent pushes updating the same ref
From: Marc Branchaud @ 2011-01-10 22:14 UTC (permalink / raw)
To: Jeff King; +Cc: Git Mailing List
In-Reply-To: <4D25F80F.3050604@xiplink.com>
On 11-01-06 12:12 PM, Marc Branchaud wrote:
> On 11-01-06 11:30 AM, Jeff King wrote:
>> On Thu, Jan 06, 2011 at 10:46:38AM -0500, Marc Branchaud wrote:
>>
>>> fatal: Unable to create
>>> '/usr/xiplink/git/public/Main.git/refs/builds/3.3.0-3.lock': File exists.
>>> If no other git process is currently running, this probably means a
>>> git process crashed in this repository earlier. Make sure no other git
>>> process is running and remove the file manually to continue.
>>> fatal: The remote end hung up unexpectedly
>>>
>>> I think the cause is pretty obvious, and in a normal interactive situation
>>> the solution would be to simply try again. But in a script trying again
>>> isn't so straightforward.
>>>
>>> So I'm wondering if there's any sense or desire to make git a little more
>>> flexible here. Maybe teach it to wait and try again once or twice when it
>>> sees a lock file. I presume that normally a ref lock file should disappear
>>> pretty quickly, so there shouldn't be a need to wait very long.
>>
>> Yeah, we probably should try again. The simplest possible (and untested)
>> patch is below. However, a few caveats:
>>
>> 1. This patch unconditionally retries for all lock files. Do all
>> callers want that? I wonder if there are any exploratory lock
>> acquisitions that would rather return immediately than have some
>> delay.
>>
>> 2. The number of tries and sleep time are pulled out of a hat.
>>
>> 3. Even with retries, I don't know if you will get the behavior you
>> want. The lock procedure for refs is:
>>
>> 1. get the lock
>> 2. check and remember the sha1
>> 3. release the lock
>> 4. do some long-running work (like the actual push)
>> 5. get the lock
>> 6. check that the sha1 is the same as the remembered one
>> 7. update the sha1
>> 8. release the lock
>>
>> Right now you are getting contention on the lock itself. But may
>> you not also run afoul of step (6) above? That is, one push updates
>> the ref from A to B, then the other one in attempting to go from A
>> to B sees that it has already changed to B under our feet and
>> complains?
>
> Could not anything run afoul of step (6)? Who knows what might happen in
> step (4)...
>
> However, in my particular case I'm using a "force" refspec:
>
> git push origin +HEAD:refs/builds/${TAG}
>
> so (as Shawn says) step (6) shouldn't matter, right? Plus, all the
> concurrent pushes are setting the ref to the same value anyway.
Well, after modifying my build script to ignore failed pushes, I do
occasionally see failures like this:
remote: fatal: Invalid revision range
0000000000000000000000000000000000000000..1c58dc4c3fdd9475d26d0eb797cc096fb622a594
error: Ref refs/builds/3.3.0-9 is at 1c58dc4c3fdd9475d26d0eb797cc096fb622a594
but expected 0000000000000000000000000000000000000000
remote: error: failed to lock refs/builds/3.3.0-9
So I guess even the "force" refspec is getting blocked by step 6.
FYI, the repo receiving the push is running git 1.7.1.
M.
^ permalink raw reply
* [PATCH] exec_cmd: remove unused extern
From: Erik Faye-Lund @ 2011-01-10 22:00 UTC (permalink / raw)
To: git
This definition was added by commit 77cb17e9, but it's left unused since
commit 511707d. Remove the left-over definition.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
---
Just a left-over definition I found while looking through some code.
exec_cmd.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/exec_cmd.c b/exec_cmd.c
index bf22570..38545e8 100644
--- a/exec_cmd.c
+++ b/exec_cmd.c
@@ -3,7 +3,6 @@
#include "quote.h"
#define MAX_ARGS 32
-extern char **environ;
static const char *argv_exec_path;
static const char *argv0_path;
--
1.7.4.rc1.3196.gfd693
^ permalink raw reply related
* Re: [PATCH] Fix wrong failures in config test
From: Jonathan Nieder @ 2011-01-10 21:59 UTC (permalink / raw)
To: Ingo Brückl; +Cc: git, Junio C Hamano
In-Reply-To: <4d2b7b68.47102a21.bm000@wupperonline.de>
Ingo Brückl wrote:
> It's a function (available in login shells and thus during the test suite):
The test suite doesn't run in a login shell. As I hinted before, you can
put
case "$-" in
*i*) # interactive shell
;;
*)
return 0
esac
in your .bashrc before the function definition and all should be well.
> From what I've learned from you now, if 'git' is an exported bash function,
> 'VAR=val git' will always automatically result in VAR being exported
I didn't understand at first why this particular vintage of bash makes
VAR leak into the current environment. I tried to reproduce it with
Debian bash 3.2-4 (which is based on bash 3.2.39(1)-release) with no
success.
In any event git avoids
VAR=val fn
when fn is a function for this and possibly other reasons (see [1]).
I do not think git ought to guard against a git function (or alias) in
the user's environment, even though doing so might lead to a better
user experience and less confusion on the mailing list. git does not
protect against 'rm' being an alias to 'rm -i' or 'svn' being an
alias, either.
Regards,
Jonathan
[1] http://thread.gmane.org/gmane.comp.version-control.git/135766/focus=137095
^ permalink raw reply
* Re: [PATCH] Fix wrong failures in config test
From: Ingo Brückl @ 2011-01-10 21:50 UTC (permalink / raw)
To: git
In-Reply-To: <7v62tw5twb.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Yuck. I really do not want to do something like this X-<.
And you shouldn't. :-)
It's my personal problem (now that I know) to unset the alias.
Ingo
^ permalink raw reply
* Re: Resumable clone/Gittorrent (again) - stable packs?
From: Sam Vilain @ 2011-01-10 21:42 UTC (permalink / raw)
To: John Wyzer; +Cc: git
In-Reply-To: <4D2B3643.2070106@gmx.de>
On 11/01/11 05:39, John Wyzer wrote:
> Why not provide an alternative mode for the git:// protocoll that
> instead of retrieving a big packaged blob breaks this down to the
> smallest atomic objects from the repository? Those are not changing
> and should be able to survive partial transfers.
> While this might not be as efficient network traffic-wise it would
> provide a solution for those behind breaking connections.
To put this into numbers, for perl.git that might mean transferring 2GB
of data instead of 70MB of pack.
Sam
^ permalink raw reply
* Re: Resumable clone/Gittorrent (again)
From: Sam Vilain @ 2011-01-10 21:38 UTC (permalink / raw)
To: Luke Kenneth Casson Leighton
Cc: Nguyen Thai Ngoc Duy, Nicolas Pitre, Git Mailing List
In-Reply-To: <AANLkTim2A4=y=XcuPuPiYGDGZyKAUEk-yv2cZVEGhQ3C@mail.gmail.com>
On 09/01/11 06:21, Luke Kenneth Casson Leighton wrote:
> On Sat, Jan 8, 2011 at 2:17 AM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
>> there are a few characteristics of bittorrent pieces that i see:
>> verifiable, resumable, uniquely identifiable across peers and
>> reasonbly small in count.
>>
>> The fixed size helps peers uniquely identify any pieces by splitting
>> the whole transfer equally and indexing them in 1-dimension.
> ok - you haven't answered the question: are the chains perfectly
> fixed identical sizes?
>
> if so they can be slotted into the bittorrent protocol by simply
> pre-selecting the size to match. with the downside that if there are
> a million such "chains" you now pretty much overwhelm the peers with
> the amount of processing, network traffic and memory requirements to
> maintain the "pieces" map.
I'll respond also to this sub-point. This can be done; but instead of
doing it at the pack level, you take the list of objects between A and B
(for a fetch from A to B), order them by some deterministic order
(called the "commit reel" in the Gittorrent RFC) and then carve that
list up into chunks based on the uncompressed object sizes.
The ordering defined in the RFC is such that it is possible to create
"thin" packs for discrete ranges of commits using existing plumbing, so
that the total transfer size is relatively similar to a complete clone.
In experiments the network overhead was found to be around 10-20% in
this way.
However I must discourage looking for "inspiration" from the Bittorrent
protocol; it reinvents many wheels unnecessarily, and contains much
shonky advice in it. See the revision history for the gittorrent RFC
(github.com/samv/gittorrent) for the gory details.
Sam
^ permalink raw reply
* Re: Resumable clone/Gittorrent (again) - stable packs?
From: Sam Vilain @ 2011-01-10 21:07 UTC (permalink / raw)
To: Ilari Liusvaara
Cc: Jeff King, Nicolas Pitre, Zenaan Harkness, git, Shawn Pearce,
Nguyen Thai Ngoc Duy, Joshua Roys, Nick Edelen, Jonas Fonseca
In-Reply-To: <20110107185218.GA16645@LK-Perkele-VI.localdomain>
On 08/01/11 07:52, Ilari Liusvaara wrote:
> Ability to contact multiple servers in sequence, each time advertising
> everything obtained so far. Then treat the new repo as clone of the last
> address.
>
> This would e.g. be very handy if you happen to have local mirror of say, Linux
> kernel and want to fetch some related project without messing with alternates
> or downloading everything again:
>
> git clone --use-mirror=~/repositories/linux-2.6 git://foo.example/linux-foo
>
> This would first fetch everything from local source and then update that
> from remote, likely being vastly faster.
Coming to this discussion a little late, I'll summarise the previous
research.
First, the idea of applying the straight BitTorrent protocol to the pack
files was raised, but as Nicolas mentions, this is not useful because
the pack files are not deterministic. The protocol was revisited based
around the part which is stable, object manifests. The RFC is at
http://utsl.gen.nz/gittorrent/rfc.html and the prototype code (an
unsuccessful GSoC project) is at http://repo.or.cz/w/VCS-Git-Torrent.git
After some thought, I decided that the BitTorrent protocol itself is all
cruft and that trying to cut it down to be useful was a waste of time.
So, this is where the idea of "automatic mirroring" came from. With
Automatic Mirroring, the two main functions of P2P operation - peer
discovery and partial transfer - are broken into discrete features.
I wrote this patch series so far, for "client-side mirroring":
http://thread.gmane.org/gmane.comp.version-control.git/133626/focus=133628
The later levels are roughly discussed on this page:
http://code.google.com/p/gittorrent/wiki/MirrorSync
The "mirror sync" part is the complicated one, and as others have noted
no truly successful prototype has yet been built. Actually the Perl
gittorrent implementation did manage to perform an incremental clone; it
just didn't wrap it up nicely. But I won't go into that too much.
There was also another GSoC program to look at caching the object list
generation, the most expensive part of the process in the Perl
implementation. This was a generic mechanism for accelerating object
graph traversal and showed promise, however unfortunately was never merged.
The client-side mirroring patch, in its current form, already supports
out-of-date mirrors. It saves refs first into
'refs/mirrors/hostname/...' and finally contacts the main server to
check what objects it is still missing. So, if there was a regular
bittorrent+bundle transport available, it would be a useful way to
support an incremental clone; the client would first clone the (static)
bittorrent bundle, unpack it with its refs into the 'refs/mirrors/xxx/'
namespace, making the subsequent 'git fetch' to get the most recent
objects a much more efficient operation.
Hope that helps!
Cheers,
Sam
^ permalink raw reply
* Re: [PATCH] Fix wrong failures in config test
From: Jonathan Nieder @ 2011-01-10 21:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ingo Brückl, git
In-Reply-To: <7v62tw5twb.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Jonathan Nieder <jrnieder@gmail.com> writes:
>>> Unfortunately, I had a shell alias function named git that interfered. In
>>> fact it passes to the git program (command git "$@") but sadly does not know
>>> about the newly set PATH and (still inexplicably to me) makes the variable
>>> set.
>
> Yuck. I really do not want to do something like this X-<.
Please don't. :)
^ permalink raw reply
* Re: [PATCH] Fix wrong failures in config test
From: Junio C Hamano @ 2011-01-10 21:30 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Ingo Brückl, git
In-Reply-To: <20110110194242.GA11801@burratino>
Jonathan Nieder <jrnieder@gmail.com> writes:
>> Unfortunately, I had a shell alias function named git that interfered. In
>> fact it passes to the git program (command git "$@") but sadly does not know
>> about the newly set PATH and (still inexplicably to me) makes the variable
>> set.
Yuck. I really do not want to do something like this X-<.
t/test-lib.sh | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/t/test-lib.sh b/t/test-lib.sh
index cb1ca97..df1b4f2 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -77,10 +77,10 @@ export GIT_COMMITTER_EMAIL GIT_COMMITTER_NAME
export EDITOR
# Protect ourselves from common misconfiguration to export
-# CDPATH into the environment
+# CDPATH into the environment and such
unset CDPATH
-
unset GREP_OPTIONS
+unalias git >/dev/null 2>&1 || :
case $(echo $GIT_TRACE |tr "[A-Z]" "[a-z]") in
1|2|true)
^ permalink raw reply related
* Re: [PATCH] Fix wrong failures in config test
From: Jonathan Nieder @ 2011-01-10 19:42 UTC (permalink / raw)
To: Ingo Brückl; +Cc: git, Junio C Hamano
In-Reply-To: <4d2b5c52.68e3cdc2.bm000@wupperonline.de>
Ingo Brückl wrote:
> As Jonathan and Junio stated,
>> envvar=value git command
>
>> GIT_CONFIG=other-config git config anwohner.park ausweis
>
> shouldn't affect the environment of the tests.
>
> Unfortunately, I had a shell alias function named git that interfered. In
> fact it passes to the git program (command git "$@") but sadly does not know
> about the newly set PATH and (still inexplicably to me) makes the variable
> set.
For what it's worth, here's what POSIX[1] has to say:
When a given simple command is required to be executed [...] the
following expansions, assignments, and redirections shall all be
performed from the beginning of the command text to the end:
[...]
If no command name results, variable assignments shall affect
the current execution environment. Otherwise, the variable
assignments shall be exported for the execution environment of
the command and shall not affect the current execution
environment (except for special built-ins).
I am guessing the expansion of your 'git' alias starts with a special
builtin. For the future, it is probably best to guard settings for
interactive use with
if test "${PS1+set}"
then
CDPATH=something
alias foo=bar
alias baz=qux
...
fi
or even better,
case $- in
*i*)
CDPATH=something
...
esac
Thanks for explaining.
Jonathan
[1] http://unix.org/2008edition/
^ permalink raw reply
* Re: [PATCH] Fix wrong failures in config test
From: Ingo Brückl @ 2011-01-10 19:21 UTC (permalink / raw)
To: git
In-Reply-To: <7vhbdg6286.fsf@alter.siamese.dyndns.org>
I wrote:
> Is it only me [...] experiencing these failures?
And the answer is yes. Sorry.
As Jonathan and Junio stated,
> envvar=value git command
> GIT_CONFIG=other-config git config anwohner.park ausweis
shouldn't affect the environment of the tests.
Unfortunately, I had a shell alias function named git that interfered. In
fact it passes to the git program (command git "$@") but sadly does not know
about the newly set PATH and (still inexplicably to me) makes the variable
set.
So it's all my problem.
Ingo
^ permalink raw reply
* Re: [PATCH] Fix wrong failures in config test
From: Junio C Hamano @ 2011-01-10 18:30 UTC (permalink / raw)
To: Ingo Brückl; +Cc: git
In-Reply-To: <4d2b3198.674034bb.bm000@wupperonline.de>
Ingo Brückl <ib@wupperonline.de> writes:
> The tests after '--set in alternative GIT_CONFIG' failed because
> variable GIT_CONFIG was still set.
>
> Signed-off-by: Ingo Brückl <ib@wupperonline.de>
> ---
>
> Is it only me (bash 3.2.48(1)-release) experiencing these failures?
>
> t/t1300-repo-config.sh | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
t1300 first sources test-lib.sh that explicitly unsets GIT_CONFIG and the
tests that might touch GIT_CONFIG all do so by a single-shot assignment to
be exported, i.e.
GIT_CONFIG=other-config git config anwohner.park ausweis
that shouldn't affect the later test, unless the shell is broken.
With this patch, can you check which one of the new tests barf on you?
t/t1300-repo-config.sh | 21 +++++++++++++++++++++
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
index d0e5546..c91d166 100755
--- a/t/t1300-repo-config.sh
+++ b/t/t1300-repo-config.sh
@@ -7,6 +7,10 @@ test_description='Test git config in different settings'
. ./test-lib.sh
+test_expect_success 'is GIT_CONFIG set (0)?' '
+ test "z${GIT_CONFIG+set}" = z
+'
+
test -f .git/config && rm .git/config
git config core.penguin "little blue"
@@ -399,8 +403,17 @@ cat > expect << EOF
ein.bahn=strasse
EOF
+
+test_expect_success 'is GIT_CONFIG set (1)?' '
+ test "z${GIT_CONFIG+set}" = z
+'
+
GIT_CONFIG=other-config git config -l > output
+test_expect_success 'is GIT_CONFIG set (2)?' '
+ test "z${GIT_CONFIG+set}" = z
+'
+
test_expect_success 'alternative GIT_CONFIG' 'cmp output expect'
test_expect_success 'alternative GIT_CONFIG (--file)' \
@@ -419,6 +432,10 @@ test_expect_success 'refer config from subdirectory' '
GIT_CONFIG=other-config git config anwohner.park ausweis
+test_expect_success 'is GIT_CONFIG set (3)?' '
+ test "z${GIT_CONFIG+set}" = z
+'
+
cat > expect << EOF
[ein]
bahn = strasse
@@ -426,6 +443,10 @@ cat > expect << EOF
park = ausweis
EOF
+test_expect_success 'is GIT_CONFIG set (4)?' '
+ test "z${GIT_CONFIG+set}" = z
+'
+
test_expect_success '--set in alternative GIT_CONFIG' 'cmp other-config expect'
cat > .git/config << EOF
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox