* Re: [PATCH 2/2] Support sizes >=2G in various config options accepting 'g' sizes.
From: Sverre Rabbelier @ 2011-09-05 13:49 UTC (permalink / raw)
To: Nix; +Cc: git
In-Reply-To: <1315223155-4218-2-git-send-email-nix@esperi.org.uk>
Heya,
On Mon, Sep 5, 2011 at 13:45, Nix <nix@esperi.org.uk> wrote:
> 32-bit platforms with no type larger than 'long' cannot detect this
> case and will continue to silently misbehave, but the misbehaviour
> will be somewhat different and more useful, since bigFileThreshold was
> also being mistakenly treated as a signed value when it should have
> been unsigned.
Is it not possible to detect that the target value won't fit in the
max size of an int when parsing the config value?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH 2/2] Support sizes >=2G in various config options accepting 'g' sizes.
From: Nix @ 2011-09-05 13:56 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: git
In-Reply-To: <CAGdFq_gFNHq9Cgv4F4Q6VQ=G7odfUJ5pUFWn=OYE-BfXzP=Enw@mail.gmail.com>
On 5 Sep 2011, Sverre Rabbelier said:
> Heya,
>
> On Mon, Sep 5, 2011 at 13:45, Nix <nix@esperi.org.uk> wrote:
>> 32-bit platforms with no type larger than 'long' cannot detect this
>> case and will continue to silently misbehave, but the misbehaviour
>> will be somewhat different and more useful, since bigFileThreshold was
>> also being mistakenly treated as a signed value when it should have
>> been unsigned.
>
> Is it not possible to detect that the target value won't fit in the
> max size of an int when parsing the config value?
Well, we're parsing longs, not ints. If sizeof(long)>sizeof(int), or we
have long long and sizeof(long long)>sizeof(int), then we can always
detect overflows when saving into the appropriate type: but if we don't
have long long, or if we have neither strto(u)ll() nor strto[ui]max(),
we could only detect overflow by looking at the raw text string and
checking it by hand to see if it would fit. I judged this pointless
extra complexity for a very rare edge case (machines with neither
strot(u)ll() nor strto[ui]max() are generally quite old and people
aren't going to be specifying sizes in gigabytes on such machines
anyway.)
--
NULL && (void)
^ permalink raw reply
* Re: [PATCH 3/3] push: old receive-pack does not understand --quiet
From: Michael J Gruber @ 2011-09-05 14:17 UTC (permalink / raw)
Cc: Junio C Hamano, Clemens Buchacher, git, tobiasu
In-Reply-To: <4E6494F7.7010101@drmicha.warpmail.net>
Michael J Gruber venit, vidit, dixit 05.09.2011 11:23:
> Junio C Hamano venit, vidit, dixit 05.09.2011 10:35:
>> Hmm, with this whole series merged to 'pu', I somehow am getting this
>> error:
>>
>> $ make -j8 \
>> DEFAULT_TEST_TARGET=prove \
>> GIT_PROVE_OPTS=-j8 \
>> T=t5541-http-push.sh test
>> *** prove ***
>> t5541-http-push.sh .. All 1 subtests passed
>>
>> Test Summary Report
>> -------------------
>> t5541-http-push.sh (Wstat: 0 Tests: 1 Failed: 0)
>> Parse errors: No plan found in TAP output
>> Files=1, Tests=1, 0 wallclock secs ( 0.02 usr 0.00 sys + 0.06 cusr 0.01 csys = 0.09 CPU)
>> Result: FAIL
>> make[1]: *** [prove] Error 1
>> make[1]: Leaving directory `/srv/project/git/git.git/t'
>> make: *** [test] Error 2
>>
>> Without prove (drop "DEFAULT_TEST_TARGET=prove" from the command line),
>> I do not see the breakage.
>>
>> *** t5541-http-push.sh ***
>> ok 1 - set up terminal for tests
>> # passed all 1 test(s)
>> 1..1 # SKIP Network testing disabled (define GIT_TEST_HTTPD to enable)
>> make aggregate-results
>> make[3]: Entering directory `/srv/project/git/git.git/t'
>> for f in test-results/t*-*.counts; do \
>> echo "$f"; \
>> done | '/bin/sh' ./aggregate-results.sh
>> fixed 0
>> success 1
>> failed 0
>> broken 0
>> total 1
>>
>
> Being cc'ed makes me feel guilty but I don't know what for... Anyway, in
> case you need more test points, with pu at v1.7.7-rc0-315-g55af6ac and
> prove I get:
>
> *** prove ***
> t5541-http-push.sh .. skipped: Network testing disabled (define
> GIT_TEST_HTTPD to enable)
> Files=1, Tests=0, 0 wallclock secs ( 0.04 usr 0.01 sys + 0.00 cusr
> 0.02 csys = 0.07 CPU)
> Result: NOTESTS
>
> Patch 3/3 does not apply (am) to pu but leaves neither changes nor
> conflicts in my wt. -3 gives a conflict which I don't know how to
> resolve without digging further, see below.
>
> Michael
>
> The conflict in send-pack.c is simple, but what about:
...
OK, I resolved this now, and am getting the same error as you, and am
stumped. But for me, 1/3 introduces that problem already. In fact, the hunk
--- a/t/t5541-http-push.sh
+++ b/t/t5541-http-push.sh
@@ -5,6 +5,7 @@
test_description='test smart pushing over http via http-backend'
. ./test-lib.sh
+. "$TEST_DIRECTORY"/lib-terminal.sh
suffices to trigger the problem. The test run in lib-terminal increases
the count but the output is lost. Patch upcoming.
Michael
^ permalink raw reply
* [PATCH] t5541: avoid TAP test miscounting
From: Michael J Gruber @ 2011-09-05 14:24 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Clemens Buchacher, tobiasu
In-Reply-To: <4E64DA0A.8090202@drmicha.warpmail.net>
lib-terminal.sh runs a test and thus increases the test count, but the
output is lost so that TAP produces a "no plan found error".
Move the lib-terminal call after the lib-httpd and make TAP happy
(though still leave me clueless).
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
t/t5541-http-push.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/t/t5541-http-push.sh b/t/t5541-http-push.sh
index 0dcb8df..a18265c 100755
--- a/t/t5541-http-push.sh
+++ b/t/t5541-http-push.sh
@@ -5,7 +5,6 @@
test_description='test smart pushing over http via http-backend'
. ./test-lib.sh
-. "$TEST_DIRECTORY"/lib-terminal.sh
if test -n "$NO_CURL"; then
skip_all='skipping test, git built without http support'
@@ -15,6 +14,7 @@ fi
ROOT_PATH="$PWD"
LIB_HTTPD_PORT=${LIB_HTTPD_PORT-'5541'}
. "$TEST_DIRECTORY"/lib-httpd.sh
+. "$TEST_DIRECTORY"/lib-terminal.sh
start_httpd
test_expect_success 'setup remote repository' '
--
1.7.7.rc0.328.g9d6c7
^ permalink raw reply related
* "Your local changes ... would be overwritten" bug
From: Hannu Koivisto @ 2011-09-05 16:25 UTC (permalink / raw)
To: git
Greetings,
I have a problem where "git checkout origin/another-branch" in master
should remove a set of files but instead I get:
error: Your local changes to the following files would be overwritten by checkout:
file1
file2
...
Please, commit your changes or stash them before you can switch branches.
Aborting
(where the files listed are those that should be removed)
The problem occurs only if the checkout is not run in the top level
directory of the repository and the files in question have execute
bit set. Before checkout, git status says
# On branch master
nothing to commit (working directory clean)
The following script can be used to reproduce the problem:
-------------------------------------------
mkdir temp
cd temp
git init
echo foo > testfile
git add testfile
git commit -m "test1"
echo foo > testfile2
chmod +x testfile2
git add testfile2
git commit -m "test2"
mkdir foo
cd foo
git co master~1
--------------------------------------------
The problem disappears if one removes either the "chmod +x
testfile2" line or the "cd foo" line.
I'm running Cygwin git 1.7.5.1 in Windows XP.
--
Hannu
^ permalink raw reply
* Re: git 'new' alias
From: Matthieu Moy @ 2011-09-05 16:36 UTC (permalink / raw)
To: Jeff King; +Cc: Thiago Farina, Git Mailing List
In-Reply-To: <20110901211747.GA16308@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> $ git config alias.one
> !f() { r=$1; shift; echo $r@{1}..$r@{0} "$@"; }; f
(which, I've just discovered, should be written as
[alias]
one = "!f() { r=$1; shift; echo $r@{1}..$r@{0} "$@"; }; f"
otherwise "git config" messes up with the ; in the line)
> which I think was the original intent (modulo me replacing "git log"
> with "echo" for debugging, of course).
The original intent was mis-specified ;-).
I think I originally made the alias to do
git new # give me new stuff on current branch
git new origin/master # same, for origin/master
and tried to enrich it to allow
git new master --oneline
without thinking about what
git new --oneline
should do (and obviously, without really testing it, I guess I had one
version of the alias allowing each senario, and none allowing all of
them).
I now have this, which is really ugly in a config file, but does the
DWIMery I want:
new = "!f () { if echo \"$1\" | grep -q -e '^-' -e '^$'; then r=; else r=$1; shift; fi; git log $r@{1}..$r@{0} \"$@\"; } && f"
(this one has even been vaguely tested ;-) )
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: "Your local changes ... would be overwritten" bug
From: Matthieu Moy @ 2011-09-05 16:52 UTC (permalink / raw)
To: Hannu Koivisto; +Cc: git
In-Reply-To: <8362l73qi6.fsf@kalahari.s2.org>
Hannu Koivisto <azure@iki.fi> writes:
> The following script can be used to reproduce the problem:
[...]
I cannot reproduce on Linux.
> I'm running Cygwin git 1.7.5.1 in Windows XP.
Probably a dumb question (from a non-windows-user), but why not use the
native Git for windows?
What happens if you run "git status" before running the problematic "git
checkout"? (I'm asking because "git status" refreshes the stat-cache, so
it may change the result)
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: GitTogether 2011
From: Shawn Pearce @ 2011-09-05 17:57 UTC (permalink / raw)
To: Patrick Renaud
Cc: David Barr, Junio C Hamano, Sverre Rabbelier, David Bainbridge,
Scott Chacon, Dave Borowitz, git@vger.kernel.org
In-Reply-To: <CAC+LNESrs5gcP-JR3LriVznCtHgPz5EUGb51iHMH-2vbTGigFw@mail.gmail.com>
Sorry, I have been drowning in issues related to kernel.org this past week.
Google has agreed to host the event Oct. 24th and 25th in Mountain
View, CA. We only have room for like 28 people in the space this year,
so about 25 non-Google attendees. I haven't posted any news about this
yet because I just got the OK Thursday or Friday morning, and have
literally not had the time to draft a proper message to announce the
event.
I'll see if I can get that out today.
On Fri, Sep 2, 2011 at 06:42, Patrick Renaud <prenaud76@gmail.com> wrote:
> Hi there.
>> Any news on the GitTogether front?
> I'd also be interested in hearing the latest developments on this front.
> We're getting near the end of the year and if this event does not take place
> I would use that budget for another event instead. I'm sure several other
> people share a similar concern, especially those who need to travel from
> abroad in order to attend the conference.
> Cheers!
>
> --
> -Patrick
>
--
Shawn.
^ permalink raw reply
* Re: GitTogether 2011
From: Sverre Rabbelier @ 2011-09-05 18:05 UTC (permalink / raw)
To: Shawn Pearce
Cc: Patrick Renaud, David Barr, Junio C Hamano, David Bainbridge,
Scott Chacon, Dave Borowitz, git@vger.kernel.org
In-Reply-To: <CAJo=hJt1T5wPsytprSXKaCEd8yNk5tMwP75Nsb0XtpwFe07HXA@mail.gmail.com>
Heya,
On Mon, Sep 5, 2011 at 19:57, Shawn Pearce <spearce@spearce.org> wrote:
> Google has agreed to host the event Oct. 24th and 25th in Mountain
> View, CA. We only have room for like 28 people in the space this year,
> so about 25 non-Google attendees. I haven't posted any news about this
> yet because I just got the OK Thursday or Friday morning, and have
> literally not had the time to draft a proper message to announce the
> event.
Awesome!
I've copy/paste/edit-ed the wiki page from last year:
https://git.wiki.kernel.org/index.php/GitTogether11
I left ?? as indications of where information is missing.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: Dropping '+' from fetch = +refs/heads/*:refs/remotes/origin/*?
From: Shawn Pearce @ 2011-09-05 18:15 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Michael J Gruber, git
In-Reply-To: <20110902162524.GC19690@sigill.intra.peff.net>
On Fri, Sep 2, 2011 at 09:25, Jeff King <peff@peff.net> wrote:
> On Fri, Sep 02, 2011 at 09:14:15AM -0700, Junio C Hamano wrote:
>>
>> It coincides with my idea too, but it might be a very limited set. For
>> example, there may be a good "suggested by upstream" default for LHS of
>> fetch refspecs (e.g. somebody may have 47 topics published but majority of
>> people are expected to follow only his "master" branch), but it is up to
>> the user of that suggestion what the RHS would be.
...
> One possible solution is that the local config could dynamically depend
> on the remote config. E.g., the fetch refspec has something like a
> wildcard that matches only the branches that the remote provides to us
> via some "interesting branches" config key. Then it's OK for git to
> update the "interesting branches" key from the remote. Either the user
> is OK with respecting that (because they have left the wildcard in
> place), or not (because they have changed the refspec not to use that
> wildcard).
>
> I do worry that could quickly get complex, and people would start
> wanting a Turing-complete config language. :)
What are we trying to do here?
I had some thought that dropping the "+" might prevent a remote
repository from being fetched from if it was rewound by an evil
attacker that now controls it. Unfortunately that attack is a
pointless one. Which makes this change to remove the "+" from fetch
specs also pointless.
If the attacker knows Git clients always fetch rewinds, he might be
tempted to rewrite some part of history and serve his modified history
of events to clients. But the repository owner (if using a private
per-user repository model like the Linux kernel developers use) would
notice on their next push, and sound the alarm that her repository has
been damaged and should not be trusted.
If on the other hand Git clients never fetch rewinds, the attacker
would just add a new commit to the tip of the history, and serve that.
Again, the repository owner would notice on their next push, and
notify people the repository is not to be trusted.
Either way, the "+" in the fetch spec has no impact on the attack. The
default just changes the attacker's choices slightly.
Maybe instead of getting a project policy from the server, we observe
the server's behavior over time from the client's reflog. If every
update to "maint" that _I_ have observed has always been a
fast-forward, a rewind on that branch should be a lot more verbose in
the fetch output than "force update". That is pretty easy to observe
from the reflog too, its just a scan of the records and either
matching the message, or checking the merge status of the old-new
pairs listed in the record. We don't even need to read the entire log
on every fetch, we could cache this data.
The main reason to alert the user that a branch rewound is to give
them a chance to correct their client if they need to. If a branch
normally doesn't rewind (e.g. next) but then suddenly does (e.g.
release cycle), but I haven't used this client in 3 weeks, its nice to
give me more of a "HEY STUPID FIX YOUR TOPICS" warning than just the
little quiet "force update" we give.
--
Shawn.
^ permalink raw reply
* Re: "Your local changes ... would be overwritten" bug
From: Vijay Lakshminarayanan @ 2011-09-05 18:31 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Hannu Koivisto, git
In-Reply-To: <vpqty8rx774.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> Hannu Koivisto <azure@iki.fi> writes:
>
>> The following script can be used to reproduce the problem:
>
> [...]
>
> I cannot reproduce on Linux.
I can't either.
>> I'm running Cygwin git 1.7.5.1 in Windows XP.
I'm running cygwin git 1.7.5.1 in Windows Vista.
$ mkdir temp
d temp
git init
echo foo > testfile
git add testfile
git commit -m "test1"
echo foo > testfile2
chmod +x testfile2
git add testfile2
git commit -m "test2"
mkdir foo
cd foo
git co master~1
vijay@balrog ~/foo
$ cd temp
vijay@balrog ~/foo/temp
$ git init
Initialized empty Git repository in /home/vijay/foo/temp/.git/
vijay@balrog ~/foo/temp
$ echo foo > testfile
vijay@balrog ~/foo/temp
$ git add testfile
vijay@balrog ~/foo/temp
$ git commit -m "test1"
[master (root-commit) 7564449] test1
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 testfile
vijay@balrog ~/foo/temp
$ echo foo > testfile2
vijay@balrog ~/foo/temp
$ chmod +x testfile2
vijay@balrog ~/foo/temp
$ git add testfile2
vijay@balrog ~/foo/temp
$ git commit -m "test2"
[master 9675b55] test2
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100755 testfile2
vijay@balrog ~/foo/temp
$ mkdir foo
vijay@balrog ~/foo/temp
$ cd foo
vijay@balrog ~/foo/temp/foo
$ git co master~1
git: 'co' is not a git command. See 'git --help'.
Did you mean one of these?
commit
clone
log
vijay@balrog ~/foo/temp/foo
$ git checkout master~1
Note: checking out 'master~1'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:
git checkout -b new_branch_name
HEAD is now at 7564449... test1
> Probably a dumb question (from a non-windows-user), but why not use the
> native Git for windows?
Do you mean msysgit? As a GNU/Linux user, I probably don't need to
explain the luxuries a bash prompt gives you. In this scenario, cygwin
is the closest approximation on Windows system.
msysgit comes with its own bash shell etc (which is good) but rather
than go that integration route, it's much simpler to have git working
within cygwin when you're already used to it.
Cheers
~vijay
^ permalink raw reply
* Re: Overriding ~/.gitconfig using GIT_CONFIG
From: Richard Purdie @ 2011-09-05 19:29 UTC (permalink / raw)
To: Jeff King
Cc: David Aguilar, Junio C Hamano, Daniel Barkalow,
Nguy?? n Thái Ngọc Duy, GIT Mailing-list
In-Reply-To: <20110830184951.GA19204@sigill.intra.peff.net>
On Tue, 2011-08-30 at 14:49 -0400, Jeff King wrote:
> On Tue, Aug 30, 2011 at 07:39:05PM +0100, Richard Purdie wrote:
>
> > On Tue, 2011-08-30 at 11:56 -0400, Jeff King wrote:
> > > On Tue, Aug 30, 2011 at 01:13:01PM +0100, Richard Purdie wrote:
> > >
> > > > We've gone through several iterations of this but as things stand now,
> > > > to initially clone things we're doing:
> > > >
> > > > git clone --bare --mirror <url> <dir>
> > > >
> > > > but if we already have some existing clone we'd update with:
> > > >
> > > > git remote prune origin
> > > > git remote rm origin
> > > > git remote add --mirror origin <url>
> > > > git fetch --all -t
> > > >
> > > > [...]
> > > >
> > > > So if a user has an origin remote in their .gitconfig, can we ignore it?
> > >
> > > Wouldn't:
> > >
> > > git fetch --prune <url> refs/heads/*:refs/remotes/origin/*
> > >
> > > do what you want, and not look at config at all?
> >
> > Since this is a bare/mirror clone, wouldn't that need to be:
> >
> > git fetch --prune <url> refs/heads/*:refs/heads/*
>
> Sorry, yes, I forgot about the mirroring bit.
>
> > That also wouldn't fetch tags?
>
> It would only do autofollowing. You could use "-t", but if you really
> want a straight mirror, you could do:
>
> git fetch --prune refs/*:refs/*
>
> to get everything.
Thanks. Just to updated, I've changed the code to do this so we'll see
how it goes...
Cheers,
Richard
^ permalink raw reply
* Re: [PATCH 3/3] push: old receive-pack does not understand --quiet
From: Junio C Hamano @ 2011-09-05 19:34 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Clemens Buchacher, git, tobiasu
In-Reply-To: <4E6494F7.7010101@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
> Being cc'ed makes me feel guilty but I don't know what for...
No guilt involved. 28d836c (test: allow running the tests under "prove",
2010-10-14) made you a good _suspect_ for having more clues than I do to
resolve it, iow, it was asking for help, not pointing any finger.
Anyhow, thanks for a quick workaround, even though I still do not
understand what the issue is (that is, what is wrong with the
t/lib-terminal helper).
^ permalink raw reply
* [ANNOUNCE] GitTogether 2011 - Oct 24th/25th
From: Shawn Pearce @ 2011-09-05 19:56 UTC (permalink / raw)
To: git
Google is once again hosting a 2 day user/developer conference for Git
users and developers to get together, share experiences, and hack on
interesting features. This event will be held October 24th and 25th at
Google's headquarters in Mountain View, CA.
More details along with sign-up (as space is limited) can be found on the wiki:
https://git.wiki.kernel.org/index.php/GitTogether11
--
Shawn.
^ permalink raw reply
* Re: [PATCH] send-email: add option -h
From: Junio C Hamano @ 2011-09-05 20:08 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: git
In-Reply-To: <20110903170612.GA3536@ecki>
Clemens Buchacher <drizzd@aon.at> writes:
> Most other git commands print a synopsis when passed -h. Make
> send-email do the same.
>
> Signed-off-by: Clemens Buchacher <drizzd@aon.at>
> ...
> +my $help;
> +my $rc = GetOptions("help|H|h" => \$help,
I do not think what the patch aims to do is wrong per-se, but
$ git send-email --help
already shows the full documentation, and I find it is misleading to say
"help|H|h" here to pretend as if a long-help is triggered with this
command. For that matter, do we have any other place that accept -H for
help?
IOW, shouldn't this line be this instead?
> +my $rc = GetOptions("h" => \$help,
^ permalink raw reply
* Re: Linux 3.1-rc5
From: Mauro Carvalho Chehab @ 2011-09-05 20:26 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux Kernel Mailing List, git
In-Reply-To: <CA+55aFxDjVJwbpP5YT4o=qud=OcxtT3Ry4HfCtW-FvNdj+RFeQ@mail.gmail.com>
Em 04-09-2011 20:27, Linus Torvalds escreveu:
> One thing to note: If you just do
>
> git pull https://github.com/torvalds/linux.git
>
> you probably won't get the tags, since it's not your origin branch. So do
>
> git fetch --tags<...>
>
> too, so that you get not only the actual changes, but the tag that you
> can verify too.
>
It would be great if "git remote update" could also verify the tag
signature (if present), as most of us just do a "git remote update".
Maybe an extra parameter for git config remote.tagopt?
Ok, if in doubt, we can always use git tag -v <new tag>, but doing
it automagically would help us to detect if a git tag got mangled
by some at the moment we update our trees, with seems to be
a good idea.
Thanks,
Mauro
^ permalink raw reply
* Re: git 'new' alias
From: Jeff King @ 2011-09-05 20:41 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Thiago Farina, Git Mailing List
In-Reply-To: <vpqipp77xpb.fsf@bauges.imag.fr>
On Mon, Sep 05, 2011 at 06:36:48PM +0200, Matthieu Moy wrote:
> > $ git config alias.one
> > !f() { r=$1; shift; echo $r@{1}..$r@{0} "$@"; }; f
>
> (which, I've just discovered, should be written as
>
> [alias]
> one = "!f() { r=$1; shift; echo $r@{1}..$r@{0} "$@"; }; f"
>
> otherwise "git config" messes up with the ; in the line)
Yes, it definitely needs quotes. However, you also need to
backslash-escape the quotes inside, or you get:
$ git config alias.one
!f() { r=$1; shift; echo $r@{1}..$r@{0} $@; }; f
which will accidentally split any arguments with whitespace.
> I now have this, which is really ugly in a config file, but does the
> DWIMery I want:
>
> new = "!f () { if echo \"$1\" | grep -q -e '^-' -e '^$'; then r=; else r=$1; shift; fi; git log $r@{1}..$r@{0} \"$@\"; } && f"
Instead of piping into grep, I would do:
case "$1" in
""|-*) ;;
*) r=$1; shift ;;
esac
which saves a process (and is IMHO a little more obvious).
As far as getting ugly for a config file, I would note that:
1. You can always drop a git-new script in your PATH. :)
2. You can backslash-escape literal newlines in config entries. It's
not amazingly pretty, but it can help:
[alias]
new = "! \
f() { \
case \"$1\" in \
''|-*) ;; \
*) r=$1; shift ;; \
esac; \
git log $r@{1}..$r@{0} \"$@\"; \
}; \
f"
-Peff
PS I use a similar alias, and I have found that defaulting to "--oneline
--graph --boundary $r@{0}...@r{1}" is quite nice for seeing how you
differ from upstream.
^ permalink raw reply
* Re: Dropping '+' from fetch = +refs/heads/*:refs/remotes/origin/*?
From: Jeff King @ 2011-09-05 20:47 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Junio C Hamano, Michael J Gruber, git
In-Reply-To: <CAJo=hJtuUe1ajjW9dNU4JzjE+P94a42W7ZvC+iQBQTeGXVvS8Q@mail.gmail.com>
On Mon, Sep 05, 2011 at 11:15:26AM -0700, Shawn O. Pearce wrote:
> > One possible solution is that the local config could dynamically depend
> > on the remote config. E.g., the fetch refspec has something like a
> [...]
>
> What are we trying to do here?
We veered way off topic into the idea of generally pulling config from a
remote. This was just one specific example of how it could be used, and
what kinds of complications that might entail.
> If the attacker knows Git clients always fetch rewinds, he might be
> tempted to rewrite some part of history and serve his modified history
> of events to clients. But the repository owner (if using a private
> per-user repository model like the Linux kernel developers use) would
> notice on their next push, and sound the alarm that her repository has
> been damaged and should not be trusted.
>
> If on the other hand Git clients never fetch rewinds, the attacker
> would just add a new commit to the tip of the history, and serve that.
> Again, the repository owner would notice on their next push, and
> notify people the repository is not to be trusted.
>
> Either way, the "+" in the fetch spec has no impact on the attack. The
> default just changes the attacker's choices slightly.
Exactly. This is what I was hinting at in my original email in this
thread. My gut feeling is that it's not useful as a security measure,
but I was trying to challenge people to prove me wrong by showing a case
where the attacker can't just trivially modify his attack to get the
same result.
> Maybe instead of getting a project policy from the server, we observe
> the server's behavior over time from the client's reflog. If every
> update to "maint" that _I_ have observed has always been a
> fast-forward, a rewind on that branch should be a lot more verbose in
> the fetch output than "force update". That is pretty easy to observe
> from the reflog too, its just a scan of the records and either
> matching the message, or checking the merge status of the old-new
> pairs listed in the record. We don't even need to read the entire log
> on every fetch, we could cache this data.
Hmm. That would probably work most of the time in practice. But it seems
like it would be quite confusing when the heuristic is wrong (e.g.,
Junio rewinds next once every few months, and other than that, it always
fast forwards). On the other hand, if the failure mode of the heuristic
is only a slightly bigger warning, then it's not that big a deal.
> The main reason to alert the user that a branch rewound is to give
> them a chance to correct their client if they need to. If a branch
> normally doesn't rewind (e.g. next) but then suddenly does (e.g.
> release cycle), but I haven't used this client in 3 weeks, its nice to
> give me more of a "HEY STUPID FIX YOUR TOPICS" warning than just the
> little quiet "force update" we give.
Sure. I'm totally open to the idea of making the non-fast-forward
warning more obvious. Suggestions for wording (though I am tempted by
"HEY STUPID" above ;) )?
-Peff
^ permalink raw reply
* Re: Dropping '+' from fetch = +refs/heads/*:refs/remotes/origin/*?
From: Shawn Pearce @ 2011-09-05 20:53 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Michael J Gruber, git
In-Reply-To: <20110905204729.GB4221@sigill.intra.peff.net>
On Mon, Sep 5, 2011 at 13:47, Jeff King <peff@peff.net> wrote:
> On Mon, Sep 05, 2011 at 11:15:26AM -0700, Shawn O. Pearce wrote:
>> Maybe instead of getting a project policy from the server, we observe
>> the server's behavior over time from the client's reflog.
>
> Hmm. That would probably work most of the time in practice. But it seems
> like it would be quite confusing when the heuristic is wrong (e.g.,
> Junio rewinds next once every few months, and other than that, it always
> fast forwards). On the other hand, if the failure mode of the heuristic
> is only a slightly bigger warning, then it's not that big a deal.
Right. Its probably a bigger failure not to warn than to warn here too.
>> The main reason to alert the user that a branch rewound is to give
>> them a chance to correct their client if they need to. If a branch
>> normally doesn't rewind (e.g. next) but then suddenly does (e.g.
>> release cycle), but I haven't used this client in 3 weeks, its nice to
>> give me more of a "HEY STUPID FIX YOUR TOPICS" warning than just the
>> little quiet "force update" we give.
>
> Sure. I'm totally open to the idea of making the non-fast-forward
> warning more obvious. Suggestions for wording (though I am tempted by
> "HEY STUPID" above ;) )?
I'm not suggesting all non-fast-forward should issue a bigger warning.
pu updates daily with a non-fast-forward. That isn't useful.
But if the local reflog hints that this reference almost never does a
non-fast-forward, and then it does, that should be a big warning.
--
Shawn.
^ permalink raw reply
* Re: Dropping '+' from fetch = +refs/heads/*:refs/remotes/origin/*?
From: Jeff King @ 2011-09-05 20:57 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Junio C Hamano, Michael J Gruber, git
In-Reply-To: <CAJo=hJtvU+ujYBMvrgVJpBdaTUq+NOsQwVFkL-A4pHv-CRPdDg@mail.gmail.com>
On Mon, Sep 05, 2011 at 01:53:42PM -0700, Shawn O. Pearce wrote:
> > Sure. I'm totally open to the idea of making the non-fast-forward
> > warning more obvious. Suggestions for wording (though I am tempted by
> > "HEY STUPID" above ;) )?
>
> I'm not suggesting all non-fast-forward should issue a bigger warning.
> pu updates daily with a non-fast-forward. That isn't useful.
>
> But if the local reflog hints that this reference almost never does a
> non-fast-forward, and then it does, that should be a big warning.
Right. What I mean is, what should the bigger warning look like?
Also, you suggested caching to avoid looking through the whole reflog
each time. I think you could probably just sample the last 10 or so
reflog entries to get an idea.
-Peff
^ permalink raw reply
* Re: Dropping '+' from fetch = +refs/heads/*:refs/remotes/origin/*?
From: Shawn Pearce @ 2011-09-05 21:14 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Michael J Gruber, git
In-Reply-To: <20110905205735.GA5578@sigill.intra.peff.net>
On Mon, Sep 5, 2011 at 13:57, Jeff King <peff@peff.net> wrote:
> On Mon, Sep 05, 2011 at 01:53:42PM -0700, Shawn O. Pearce wrote:
>
>> > Sure. I'm totally open to the idea of making the non-fast-forward
>> > warning more obvious. Suggestions for wording (though I am tempted by
>> > "HEY STUPID" above ;) )?
>>
>> I'm not suggesting all non-fast-forward should issue a bigger warning.
>> pu updates daily with a non-fast-forward. That isn't useful.
>>
>> But if the local reflog hints that this reference almost never does a
>> non-fast-forward, and then it does, that should be a big warning.
>
> Right. What I mean is, what should the bigger warning look like?
Its a bikeshed. I refuse to paint bikesheds. :-)
> Also, you suggested caching to avoid looking through the whole reflog
> each time. I think you could probably just sample the last 10 or so
> reflog entries to get an idea.
Good point. 10 or so last records might be representative of the
branch's recent behavior, which is all that matters to the user who
wants this warning.
--
Shawn.
^ permalink raw reply
* [RFC/PATCH git] http: avoid empty error messages for some curl errors
From: Jonathan Nieder @ 2011-09-05 22:22 UTC (permalink / raw)
To: git; +Cc: Tay Ray Chuan
When asked to fetch over SSL without a valid
/etc/ssl/certs/ca-certificates.crt file, "git fetch" writes
error: while accessing https://github.com/torvalds/linux.git/info/refs
which is a little disconcerting. Better to fall back to
curl_easy_strerror(result) when the error string is empty, like the
curl utility does:
error: Problem with the SSL CA cert (path? access rights?) while
accessing https://github.com/torvalds/linux.git/info/refs
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Hi,
I ran into this error today because this machine has no certs enabled.
I'm not thrilled with the following patch because the error string
buffer is not cleared very often so it seems possible for it to be
not empty but stale at the relevant moment. I would be happier if we
could rely on libcurl always filling the error buffer on errors.
What do you think?
Jonathan
http.c | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/http.c b/http.c
index a59cac45..dec3c60a 100644
--- a/http.c
+++ b/http.c
@@ -851,8 +851,13 @@ static int http_request(const char *url, void *result, int target, int options)
init_curl_http_auth(slot->curl);
ret = HTTP_REAUTH;
}
- } else
+ } else {
+ if (!curl_errorstr[0])
+ strlcpy(curl_errorstr,
+ curl_easy_strerror(results.curl_result),
+ sizeof(curl_errorstr));
ret = HTTP_ERROR;
+ }
} else {
error("Unable to start HTTP request for %s", url);
ret = HTTP_START_FAILED;
--
1.7.6
^ permalink raw reply related
* [PATCH] http: remove extra newline in error message
From: Jonathan Nieder @ 2011-09-05 22:29 UTC (permalink / raw)
To: git; +Cc: Tay Ray Chuan, Junio C Hamano
In-Reply-To: <20110905222202.GA32071@elie>
There is no need for a blank line between the detailed error message
and the later "fatal: HTTP request failed" notice. Keep the newline
written by error() itself and eliminate the extra one.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
> I ran into this error today
Here's a patch for a simpler buglet noticed at the same time.
http.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/http.c b/http.c
index dec3c60a..fb3465f5 100644
--- a/http.c
+++ b/http.c
@@ -913,7 +913,7 @@ int http_error(const char *url, int ret)
{
/* http_request has already handled HTTP_START_FAILED. */
if (ret != HTTP_START_FAILED)
- error("%s while accessing %s\n", curl_errorstr, url);
+ error("%s while accessing %s", curl_errorstr, url);
return ret;
}
--
1.7.6
^ permalink raw reply related
* Re: "Your local changes ... would be overwritten" bug
From: Andrew Ardill @ 2011-09-05 23:37 UTC (permalink / raw)
To: Vijay Lakshminarayanan; +Cc: Matthieu Moy, Hannu Koivisto, git
In-Reply-To: <87wrdmrgbs.fsf@gmail.com>
I can not reproduce on msysgit version 1.7.6.msysgit.0, for what it is worth.
Regards,
Andrew Ardill
On 6 September 2011 04:31, Vijay Lakshminarayanan <laksvij@gmail.com> wrote:
> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
>
>> Hannu Koivisto <azure@iki.fi> writes:
>>
>>> The following script can be used to reproduce the problem:
>>
>> [...]
>>
>> I cannot reproduce on Linux.
>
> I can't either.
>
>>> I'm running Cygwin git 1.7.5.1 in Windows XP.
>
> I'm running cygwin git 1.7.5.1 in Windows Vista.
>
> $ mkdir temp
> d temp
> git init
> echo foo > testfile
> git add testfile
> git commit -m "test1"
> echo foo > testfile2
> chmod +x testfile2
> git add testfile2
> git commit -m "test2"
> mkdir foo
> cd foo
> git co master~1
>
> vijay@balrog ~/foo
> $ cd temp
>
> vijay@balrog ~/foo/temp
> $ git init
> Initialized empty Git repository in /home/vijay/foo/temp/.git/
>
> vijay@balrog ~/foo/temp
> $ echo foo > testfile
>
> vijay@balrog ~/foo/temp
> $ git add testfile
>
> vijay@balrog ~/foo/temp
> $ git commit -m "test1"
> [master (root-commit) 7564449] test1
> 1 files changed, 1 insertions(+), 0 deletions(-)
> create mode 100644 testfile
>
> vijay@balrog ~/foo/temp
> $ echo foo > testfile2
>
> vijay@balrog ~/foo/temp
> $ chmod +x testfile2
>
> vijay@balrog ~/foo/temp
> $ git add testfile2
>
> vijay@balrog ~/foo/temp
> $ git commit -m "test2"
> [master 9675b55] test2
>
> 1 files changed, 1 insertions(+), 0 deletions(-)
> create mode 100755 testfile2
>
> vijay@balrog ~/foo/temp
> $ mkdir foo
>
> vijay@balrog ~/foo/temp
> $ cd foo
>
> vijay@balrog ~/foo/temp/foo
> $ git co master~1
> git: 'co' is not a git command. See 'git --help'.
>
> Did you mean one of these?
> commit
> clone
> log
>
> vijay@balrog ~/foo/temp/foo
> $ git checkout master~1
> Note: checking out 'master~1'.
>
> You are in 'detached HEAD' state. You can look around, make experimental
> changes and commit them, and you can discard any commits you make in this
> state without impacting any branches by performing another checkout.
>
> If you want to create a new branch to retain commits you create, you may
> do so (now or later) by using -b with the checkout command again. Example:
>
> git checkout -b new_branch_name
>
> HEAD is now at 7564449... test1
>
>> Probably a dumb question (from a non-windows-user), but why not use the
>> native Git for windows?
>
> Do you mean msysgit? As a GNU/Linux user, I probably don't need to
> explain the luxuries a bash prompt gives you. In this scenario, cygwin
> is the closest approximation on Windows system.
>
> msysgit comes with its own bash shell etc (which is good) but rather
> than go that integration route, it's much simpler to have git working
> within cygwin when you're already used to it.
>
> Cheers
> ~vijay
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [tig: PATCH] Decorate replaced commits
From: Jonas Fonseca @ 2011-09-06 2:50 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <f2c76a759d9e39c32b90033cb64f677b7a2602d8.1314608820.git.git@drmicha.warpmail.net>
On Mon, Aug 29, 2011 at 05:08, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> Decorate replaced commits by "replaced" analogous to git.git's
> 5267d29 (log: decorate "replaced" on to replaced commits, 2011-08-19).
Thanks.
> Should probably follow this up with graft decorations.
Yes, that'd be great.
--
Jonas Fonseca
^ 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