* Re: [PATCH 1/3] t9350: point out that refs are not updated correctly
From: Jonathan Nieder @ 2012-10-25 4:27 UTC (permalink / raw)
To: Felipe Contreras
Cc: Sverre Rabbelier, Junio C Hamano, Jeff King, Git List,
Daniel Barkalow, Ramkumar Ramachandra, Dmitry Ivankov,
Johannes Schindelin, Ævar Arnfjörð, Eric Herman,
Fernando Vezzosi
In-Reply-To: <CAMP44s2kjv9fHbruXv7NyVm9m+FjFnYDryuPZQ-RQXN9Nj6MAw@mail.gmail.com>
Felipe Contreras wrote:
> Again, if you don't have marks, I don't see what you expect to be
> exported with 'master..master', even with marks, I don't see what you
> expect.
And that's fine. Unless you were trying to do some work and this lack
of understanding got in the way.
In that case, with a calmer and more humble approach you might find
people willing to help you. Maybe they will learn something from you,
too.
Ciao,
Jonathan
^ permalink raw reply
* [PATCH] Fixes handling of --reference argument.
From: szager @ 2012-10-25 4:52 UTC (permalink / raw)
To: git
Signed-off-by: Stefan Zager <szager@google.com>
---
git-submodule.sh | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index ab6b110..dcceb43 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -270,7 +270,6 @@ cmd_add()
;;
--reference=*)
reference="$1"
- shift
;;
--)
shift
--
1.7.7.3
^ permalink raw reply related
* Re: Git push slowly under 1000M/s network
From: Joey Jiao @ 2012-10-25 5:04 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <CAJo=hJuGksy7pzzy7-7eTUxNmtT9qR2xCPxSfYO58_8SohFjxQ@mail.gmail.com>
Yes, I believe it's gerrit problem and will discuss there.
During first minutes of restarting gerrit, the pushing becomes quite
faster 13s instead.
2012/10/24 Shawn Pearce <spearce@spearce.org>:
> On Mon, Oct 22, 2012 at 11:27 PM, Joey Jiao <joey.jiaojg@gmail.com> wrote:
>> It looks like the client is waiting the pushing result status from
>> server although by checking server side, the real object has already
>> been upload succeed.
>>
>> Below is the log after adding time info.
>> $ time git push -v ssh://git.qrd.qualcomm.com:29418/kernel/msm.git
>> HEAD:refs/changes/33599 2>&1|tee -a log.txt
> ...
>> remote: Resolving deltas: 0% (0/2)
>> remote: (W) afafdad: no files changed, message updated
> ...
>> real 9m56.928s
>> user 0m0.364s
>> sys 0m0.160s
>
> What version of Gerrit are you using?
> How many changes already exist in this project?
>
> I am fairly certain this is an issue with Gerrit. Which may be better
> discussed at http://groups.google.com/group/repo-discuss
--
-Joey Jiao
^ permalink raw reply
* Re: t9401 fails with OS X sed
From: Geert Bosch @ 2012-10-25 5:04 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: Git List
In-Reply-To: <609AC6E7-45CD-4472-B1DC-FBB785D6B815@gernhardtsoftware.com>
On Oct 24, 2012, at 23:54, Brian Gernhardt <brian@gernhardtsoftware.com> wrote:
> It works if I change \s to [[:space:]], but I don't know how portable that is.
As \s is shorthand for the POSIX character class [:space:], I'd say the latter
should be more portable: anything accepting the shorthand should also accept
the full character class. If not, you probably only care about horizontal tab
and space, for which you could just use a simple regular expression. Just a
literal space and tab character between square brackets is probably going to be
most portable, though not most readable.
-Geert
^ permalink raw reply
* Re: [PATCH 1/3] t9350: point out that refs are not updated correctly
From: Felipe Contreras @ 2012-10-25 5:13 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Sverre Rabbelier, Junio C Hamano, Jonathan Nieder, Jeff King,
Git List, Daniel Barkalow, Ramkumar Ramachandra, Dmitry Ivankov,
Ævar Arnfjörð Bjarmason, Eric Herman,
Fernando Vezzosi
In-Reply-To: <alpine.DEB.1.00.1210242333550.5980@bonsai2>
On Wed, Oct 24, 2012 at 11:41 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Wed, 24 Oct 2012, Felipe Contreras wrote:
>
>> 2) master..master shouldn't export anything
>
> The underlying issue -- as explained in the thread -- is when you want to
> update master to a commit that another ref already points to. In that case
> no commits need to exported, but the ref needs to be updated nevertheless.
>
> We just wrote the test in the most convenient way, no need to complicate
> things more than necessary.
That test cannot work, and it shouldn't work.
You say you want to 'update master to a commit that another ref
already points to'. What other ref? If you want to update master, this
is what you do:
% git fast-export master
What do you expect 'git fast-export master..master' to export? This?
---
reset refs/heads/master
from $(git rev-parse master)
---
What is a remote helper supposed to do with a SHA-1? Nothing, a git
SHA-1 is useless to say, a mercurial remote helper. To make sense of
it you would need to access the git repository and get the commit
object, and that's defeating the purpose of a fast exporter.
No, that's not what you want.
But at this point there's only one ref in the picture, you said
'update master to a commit that another ref already points to', but
there's only one ref, where is the other ref?
Maybe your test should do this:
% git fast-export foo master
But wait, that actually works, except that the output will be nothing
close what you expected before, we would get all the commits and files
that constitute 'foo', which is actually useful, and what we expect
from fast-export, and in addition, master will be updated to the right
ref.
No, the problem is not only 'update master to a commit that another
ref already points to', but that this happens in two different
commands, and that can only be done with marks, just like the test I
proposed.
The original test doesn't expose the problem we are trying to solve,
and it shouldn't work anyway.
Moreover, what we eventually want to do is support the transport
helpers, so how about you run this:
---
#!/bin/sh
cat > git-remote-foo <<-\EOF
#!/bin/sh
read l
echo $l 1>&2
echo export
echo refspec refs/heads/*:refs/foo/origin/*
test -e /tmp/marks-git && echo *import-marks /tmp/marks-git
echo *export-marks /tmp/marks-git
echo
read l
echo $l 1>&2
echo ? refs/heads/master
echo
read l
echo $l 1>&2
while read l; do
echo $l 1>&2
test "$l" == 'done' && exit
done
EOF
chmod +x git-remote-foo
export PATH=$PWD:$PATH
rm -f /tmp/marks-git
(
git init test
cd test
echo Test >> Test
git add --all
git commit -m 'Initial commit'
git branch foo
echo "== master =="
git push foo::test master
echo "== foo =="
git push foo::test foo
)
---
I get this output with my patch:
---
[master (root-commit) b159eff] Initial commit
1 file changed, 1 insertion(+)
create mode 100644 Test
== master ==
capabilities
list
export
feature done
blob
mark :1
data 5
Test
reset refs/heads/master
commit refs/heads/master
mark :2
author Felipe Contreras <felipe.contreras@gmail.com> 1351140987 +0200
committer Felipe Contreras <felipe.contreras@gmail.com> 1351140987 +0200
data 15
Initial commit
M 100644 :1 Test
done
== foo ==
capabilities
list
export
feature done
reset refs/heads/foo
from :2
done
---
Hey, did you see that? 'foo' is updated, both 'master' and 'foo' point
to the same object.
What is the problem?
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH 1/3] t9350: point out that refs are not updated correctly
From: Felipe Contreras @ 2012-10-25 5:18 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Sverre Rabbelier, Junio C Hamano, Jeff King, Git List,
Daniel Barkalow, Ramkumar Ramachandra, Dmitry Ivankov,
Johannes Schindelin, Ævar Arnfjörð, Eric Herman,
Fernando Vezzosi
In-Reply-To: <20121025042731.GA11243@elie.Belkin>
On Thu, Oct 25, 2012 at 6:27 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Felipe Contreras wrote:
>
>> Again, if you don't have marks, I don't see what you expect to be
>> exported with 'master..master', even with marks, I don't see what you
>> expect.
>
> And that's fine. Unless you were trying to do some work and this lack
> of understanding got in the way.
What is fine? What lack of understanding?
You still haven't said what you expect the output to be.
Consider this repo:
---
git init test
cd test
echo one >> file
git add --all
git commit -m 'one'
echo two >> file
git commit -m 'one'
---
What *exactly* should the output of 'git fast-export master..master'
be? I say nothing, what do you say?
> In that case, with a calmer and more humble approach you might find
> people willing to help you. Maybe they will learn something from you,
> too.
I don't need help, I am helping you, I was asked to take a look at
this patch series. If you don't want my help, then by all means, keep
this series rotting, it has being doing so for the past year without
anybody complaining.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH 1/3] t9350: point out that refs are not updated correctly
From: Jonathan Nieder @ 2012-10-25 5:28 UTC (permalink / raw)
To: Felipe Contreras
Cc: Sverre Rabbelier, Junio C Hamano, Jeff King, Git List,
Daniel Barkalow, Ramkumar Ramachandra, Dmitry Ivankov,
Johannes Schindelin, Ævar Arnfjörð, Eric Herman,
Fernando Vezzosi
In-Reply-To: <CAMP44s1Pe8Ef6-GRbmSs7rY7gWyaPCN+jWGysyttZp3drSDoZg@mail.gmail.com>
Felipe Contreras wrote:
> I don't need help, I am helping you, I was asked to take a look at
> this patch series. If you don't want my help, then by all means, keep
> this series rotting, it has being doing so for the past year without
> anybody complaining.
Ah, so _that_ (namely getting Sverre's remote helper to work) is the
work you were trying to do. Thanks for explaining.
If I understand correctly, it is possible to get Sverre's remote
helper to work without affecting this particular testcase. From that
point of view I think you were on the right track.
The testcase is imho correct and does not need changing. So yes, I
don't want your help changing it. I don't suspect you will be using
"git fast-export $(git rev-parse master)..master". It is safe and
good to add additional testcases documenting the syntax that you do
use, as an independent topic.
Thanks,
Jonathan
^ permalink raw reply
* Re: [PATCH 1/3] t9350: point out that refs are not updated correctly
From: Sverre Rabbelier @ 2012-10-25 5:39 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Felipe Contreras, Junio C Hamano, Jeff King, Git List,
Daniel Barkalow, Ramkumar Ramachandra, Dmitry Ivankov,
Johannes Schindelin, Ævar Arnfjörð, Eric Herman,
Fernando Vezzosi
In-Reply-To: <20121025052823.GB11243@elie.Belkin>
On Wed, Oct 24, 2012 at 10:28 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> The testcase is imho correct and does not need changing. So yes, I
> don't want your help changing it. I don't suspect you will be using
> "git fast-export $(git rev-parse master)..master". It is safe and
> good to add additional testcases documenting the syntax that you do
> use, as an independent topic.
To re-iterate Dscho's point, the reason for this testcase is that if
you do this:
$ git checkout master
$ git branch next
$ git push hg://example.com master
$ git push hg://example.com next
With the current design, next will not be present on the remote. This
is caused by the fact that git looks at "fast-export ^master next",
sees that it's empty, and decides not to export anything. This patch
series solves that, by having "fast-export ^master next" emit a "from
:42\nreset next" (or something like that, assuming :42 is where master
is currently at).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH 1/3] t9350: point out that refs are not updated correctly
From: Felipe Contreras @ 2012-10-25 5:40 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Sverre Rabbelier, Junio C Hamano, Jeff King, Git List,
Daniel Barkalow, Ramkumar Ramachandra, Dmitry Ivankov,
Johannes Schindelin, Ævar Arnfjörð, Eric Herman,
Fernando Vezzosi
In-Reply-To: <20121025052823.GB11243@elie.Belkin>
On Thu, Oct 25, 2012 at 7:28 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Felipe Contreras wrote:
>
>> I don't need help, I am helping you, I was asked to take a look at
>> this patch series. If you don't want my help, then by all means, keep
>> this series rotting, it has being doing so for the past year without
>> anybody complaining.
>
> Ah, so _that_ (namely getting Sverre's remote helper to work) is the
> work you were trying to do. Thanks for explaining.
No, that's not what I'm doing. I haven't even seen a remote-hg branch
from either Sverre, or Johannes. IIRC the msysgit wiki mentions that
there were some patches not quite accepted in upstream that prevented
the remote-hg from getting upstream. But I don't know which patches
are those, I don't know why they are needed, and I haven't even been
able to run this stuff.
I was told this might be an issue for all remote helpers, and it seems
to be the case (albeit a small issue IMO).
> If I understand correctly, it is possible to get Sverre's remote
> helper to work without affecting this particular testcase. From that
> point of view I think you were on the right track.
That makes sense. So are there any other patches?
> The testcase is imho correct and does not need changing. So yes, I
> don't want your help changing it. I don't suspect you will be using
> "git fast-export $(git rev-parse master)..master". It is safe and
> good to add additional testcases documenting the syntax that you do
> use, as an independent topic.
All right, so I run this and get this:
% git fast-export master..master
reset refs/heads/master
from 8c7a786b6c8eae8eac91083cdc9a6e337bc133b0
As an user of fast-export, what do I do with that now?
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH 1/3] t9350: point out that refs are not updated correctly
From: Felipe Contreras @ 2012-10-25 5:50 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Jonathan Nieder, Junio C Hamano, Jeff King, Git List,
Daniel Barkalow, Ramkumar Ramachandra, Dmitry Ivankov,
Johannes Schindelin, Ævar Arnfjörð, Eric Herman,
Fernando Vezzosi
In-Reply-To: <CAGdFq_gg3gPvCADje9ibz8xHgPOLF+=79EqksVzG2JeTOfHocw@mail.gmail.com>
On Thu, Oct 25, 2012 at 7:39 AM, Sverre Rabbelier <srabbelier@gmail.com> wrote:
> On Wed, Oct 24, 2012 at 10:28 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
>> The testcase is imho correct and does not need changing. So yes, I
>> don't want your help changing it. I don't suspect you will be using
>> "git fast-export $(git rev-parse master)..master". It is safe and
>> good to add additional testcases documenting the syntax that you do
>> use, as an independent topic.
>
> To re-iterate Dscho's point, the reason for this testcase is that if
> you do this:
> $ git checkout master
> $ git branch next
> $ git push hg://example.com master
> $ git push hg://example.com next
>
> With the current design, next will not be present on the remote. This
> is caused by the fact that git looks at "fast-export ^master next",
> sees that it's empty, and decides not to export anything. This patch
> series solves that, by having "fast-export ^master next" emit a "from
> :42\nreset next" (or something like that, assuming :42 is where master
> is currently at).
Only if the remote helper is using marks, and this particular patch is
adding a test-case without any use of marks at all.
IOW; this test is testing something completely different, which
happens to fix the original issue, but this is not the only way to
fix, and in IMO certainly not the best.
As I showed in my script above:
$ git checkout master
$ git branch next
$ git push hg://example.com master
$ git push hg://example.com next
This works just fine. Go ahead, apply my patch, and run it, the second
branch gets updated.
It will fail this test, but that's because the test is not testing
what it should: that *when using marks* the second branch exported is
ignored.
This test does that:
---
cat > expected << EOF
reset refs/heads/master
from ##mark##
EOF
test_expect_failure 'refs are updated even if no commits need to be exported' '
cp tmp-marks /tmp
git fast-export --import-marks=tmp-marks \
--export-marks=tmp-marks master | true &&
git fast-export --import-marks=tmp-marks \
--export-marks=tmp-marks master > actual &&
mark=$(grep $(git rev-parse master) tmp-marks | cut -f 1 -d " ")
sed -i -e "s/##mark##/$mark/" expected &&
test_cmp expected actual
'
---
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH 1/3] t9350: point out that refs are not updated correctly
From: Jonathan Nieder @ 2012-10-25 5:53 UTC (permalink / raw)
To: Felipe Contreras
Cc: Sverre Rabbelier, Junio C Hamano, Jeff King, Git List,
Daniel Barkalow, Ramkumar Ramachandra, Dmitry Ivankov,
Johannes Schindelin, Ævar Arnfjörð, Eric Herman,
Fernando Vezzosi
In-Reply-To: <CAMP44s3Xwt5+J_yGte_HC3hG+MhMkWnJQ7mtuB_Y+sOLB1b1+A@mail.gmail.com>
Felipe Contreras wrote:
> All right, so I run this and get this:
>
> % git fast-export master..master
> reset refs/heads/master
> from 8c7a786b6c8eae8eac91083cdc9a6e337bc133b0
>
> As an user of fast-export, what do I do with that now?
You passed "master.." on the command line, indicating that your
repository already has commit 8c7a786b6c8eae8eac91083cdc9a6e337bc133b0.
Now you can update the "master" branch to point to that commit,
as the fast-export output indicates.
Jonathan
^ permalink raw reply
* Re: Where should git-prompt.sh be installed?
From: Danny Yates @ 2012-10-25 6:02 UTC (permalink / raw)
To: Jonathan Nieder
Cc: git@vger.kernel.org, Anders Kaseorg, Felipe Contreras, Ted Pavlic,
SZEDER Gábor, Dan McGee
In-Reply-To: <20121025005106.GA9112@elie.Belkin>
Would that not give the impression of "git sh-prompt" being a core command? If so, that would be poor, IMHO.
When I was investigating this last night, I expected to find it (git-prompt.sh) in contrib, although that doesn't make an enormous amount of sense. Ideally, the full path to wherever it's installed should be mentioned in the bash completion file (which is where I went to look when __git_ps1 stopped working), but that would mean modifying a file from upstream and I'm not sure if that's easy/"the done thing".
Danny.
On 25 Oct 2012, at 01:51, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Hi,
>
> In olden days the admin would copy contrib/completion/git-completion.sh
> to
>
> /etc/bash_completion.d/git
>
> and mortals could source /etc/bash_completion or
> /etc/bash_completion.d/git in their ~/.bashrc (possibly shared among
> multiple machines) so that the bash completion and __git_ps1 helpers
> could work.
>
> With Git 1.7.12 __git_ps1 has been split into a separate file, to help
> users who only want __git_ps1 to avoid the overhead of loading the
> entire completion script (and allow the completion script to be loaded
> by bash-completion magic on the fly!). Now the sysadmin should copy
> contrib/completion/git-completion.sh to
>
> /usr/share/bash-completion/completions/git
>
> and contrib/completion/git-prompt.sh to
>
> /usr/share/git-core/contrib/?? (somewhere?)
>
> Mortals source /etc/bash_completion in their ~/.bashrc (possibly
> shared among multiple machines) and expect bash completion to work.
> For __git_ps1, users should source that ?? path.
>
> Questions:
>
> 1) what path is appropriate for ?? above?
> 2) is this documented anywhere?
>
> Possible answers:
>
> 1) Fedora uses /etc/profile.d/git-prompt.sh. Gentoo uses
> /usr/share/bash-completion/git-prompt. Maybe others use
> some other path.
>
> 2) The scripts themselves suggest copying to ~/.git-completion.sh
> and ~/.git-prompt.sh.
>
> Proposal:
>
> 1) /usr/lib/git-core/git-sh-prompt
> 2) git-sh-prompt(1)
>
> Sensible?
>
> Thanks,
> Jonathan
^ permalink raw reply
* Re: [PATCH 1/3] t9350: point out that refs are not updated correctly
From: Sverre Rabbelier @ 2012-10-25 6:07 UTC (permalink / raw)
To: Felipe Contreras
Cc: Jonathan Nieder, Junio C Hamano, Jeff King, Git List,
Daniel Barkalow, Ramkumar Ramachandra, Dmitry Ivankov,
Johannes Schindelin, Ævar Arnfjörð, Eric Herman,
Fernando Vezzosi
In-Reply-To: <CAMP44s3kBxzJbyoxPqWbRMWmpX9sNPGjdRy_KrTeRoVmGC-+Hg@mail.gmail.com>
On Wed, Oct 24, 2012 at 10:50 PM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> This works just fine. Go ahead, apply my patch, and run it, the second
> branch gets updated.
Yes, but as you said:
> That is already the case, my patch will cause this to generate the same output:
> % git fast-export --{im,ex}port-marks=/tmp/marks ^foo foo.foo
> Which is still not got, but not catastrophic by any means.
Which is exactly the reason we (Dscho and I during our little
hackathon) went with the approach we did. We considered the approach
you took (if I still had the repository I might even find something
very like your patch in my reflog), but dismissed it for that reason.
By teaching fast-export to properly re-export interesting refs, this
exporting of negated refs does not happen. Additionally, you say it is
not catastrophic, but it _is_, if you run: 'git fast-export ^master
foo', you do not expect master to suddenly show up on the remote side.
I agree that your test more accurately describes what we're testing
(and in fact, it should probably go in the tests for remote helpers).
However, this test points out a shortcoming of fast-export that
prevents us from implementing a cleaner solution to the 'fast-export
push an existing ref' problem.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH 1/3] t9350: point out that refs are not updated correctly
From: Felipe Contreras @ 2012-10-25 6:19 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Jonathan Nieder, Junio C Hamano, Jeff King, Git List,
Daniel Barkalow, Ramkumar Ramachandra, Dmitry Ivankov,
Johannes Schindelin, Ævar Arnfjörð, Eric Herman,
Fernando Vezzosi
In-Reply-To: <CAGdFq_jfiX9apPyq6pba4S4iCQLGLmDvSrLaujSB5rO0i+fzfg@mail.gmail.com>
On Thu, Oct 25, 2012 at 8:07 AM, Sverre Rabbelier <srabbelier@gmail.com> wrote:
> On Wed, Oct 24, 2012 at 10:50 PM, Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
>> This works just fine. Go ahead, apply my patch, and run it, the second
>> branch gets updated.
>
> Yes, but as you said:
>
>> That is already the case, my patch will cause this to generate the same output:
>> % git fast-export --{im,ex}port-marks=/tmp/marks ^foo foo.foo
>> Which is still not got, but not catastrophic by any means.
>
> Which is exactly the reason we (Dscho and I during our little
> hackathon) went with the approach we did. We considered the approach
> you took (if I still had the repository I might even find something
> very like your patch in my reflog), but dismissed it for that reason.
> By teaching fast-export to properly re-export interesting refs, this
> exporting of negated refs does not happen.
Oh really? This is with your patches:
% git fast-export --{im,ex}port-marks=/tmp/marks foo1 ^foo2 foo3..foo3
reset refs/heads/foo1
from :21
reset refs/heads/foo3
from :21
reset refs/heads/foo3
from :21
reset refs/heads/foo2
from :21
This is with mine:
% ./git fast-export --{im,ex}port-marks=/tmp/marks foo1 ^foo2 foo3..foo3
reset refs/heads/foo3
from :21
reset refs/heads/foo2
from :21
reset refs/heads/foo1
from :21
Now tell me again. What is the benefit of your approach?
> Additionally, you say it is
> not catastrophic, but it _is_, if you run: 'git fast-export ^master
> foo', you do not expect master to suddenly show up on the remote side.
If 'git fast-export ^master foo' is catastrophic, so is 'git
fast-export foo ^master', and that already exports master *today*.
> I agree that your test more accurately describes what we're testing
> (and in fact, it should probably go in the tests for remote helpers).
> However, this test points out a shortcoming of fast-export that
> prevents us from implementing a cleaner solution to the 'fast-export
> push an existing ref' problem.
Which is something few users will notice. What they surely notice is
that there's no remote-hg they can readily use. Nobody expects all
software to be perfect or have all the features from day 1. Something
that just fetches a hg repo is already better than the current
situation: *nothing*.
And BTW, in mercurial a commit can be only on one branch anyway, so
you can't have 'foo' and 'master' both pointing to the same
commit/revision. Sure bookmarks is another story, but again, I don't
think people would prefer remote-hg to stay out because bookmarks
don't work _perfectly_.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH 1/3] t9350: point out that refs are not updated correctly
From: Felipe Contreras @ 2012-10-25 6:39 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Sverre Rabbelier, Junio C Hamano, Jeff King, Git List,
Daniel Barkalow, Ramkumar Ramachandra, Dmitry Ivankov,
Johannes Schindelin, Ævar Arnfjörð, Eric Herman,
Fernando Vezzosi
In-Reply-To: <20121025055343.GA13729@elie.Belkin>
On Thu, Oct 25, 2012 at 7:53 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Felipe Contreras wrote:
>
>> All right, so I run this and get this:
>>
>> % git fast-export master..master
>> reset refs/heads/master
>> from 8c7a786b6c8eae8eac91083cdc9a6e337bc133b0
>>
>> As an user of fast-export, what do I do with that now?
>
> You passed "master.." on the command line, indicating that your
> repository already has commit 8c7a786b6c8eae8eac91083cdc9a6e337bc133b0.
No I didn't.
Maybe I'm not interested in all the old history and I just want to
create a repository from that point forward. For example 'git
fast-export v1.5.0..master. I don't want no references to objects I
don't have, there's no way I can do anything sensible with that SHA-1.
% git fast-export master..master | git --git-dir=/tmp/git/.git fast-import
fatal: Not a valid commit: 8c7a786b6c8eae8eac91083cdc9a6e337bc133b0
fast-import: dumping crash report to /tmp/git/.git/fast_import_crash_32498
Does it make sense to you that the output of fast-export doesn't work
with fast-import?
> Now you can update the "master" branch to point to that commit,
> as the fast-export output indicates.
I don't have that commit, I don't even know what 8c7a786 means.
Show me a single remote helper that manually stores SHA-1's and I
might believe you, but I doubt that, marks are too convenient. Or show
me a script. I doubt there will be any, because otherwise somebody
would have pushed for this patch, and there doesn't seem to be too
many people.
But fine, lets assume it's a valid use-case and people need this... it
still has absolutely nothing to do with the original intent of the
patch series. The series is in fact doing two things:
1) Use SHA-1's when a mark can't be found
2) Update refs that have been already visited (through marks)
These two things are orthogonal to each other, we should have two
tests, and in fact, two separate patch series. One will be useful for
remote helpers, the other one will be useful to nobody IMO, but that's
something that can be discussed there, and I particularly don't care.
My test and my patch are good for 2), and so far I haven't seen
anybody saying otherwise.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Who is the 'git' vendor?
From: PROHASKA, Thor @ 2012-10-25 6:43 UTC (permalink / raw)
To: 'git@vger.kernel.org'; +Cc: 'Thor Home (thorlp@hotkey.net.au)'
Hi,
The organisation I am currently working for uses 'git'.
In order to manage all the software used in the organisation we have been compiling a list of software that includes the software Vendor's name.
My colleague has listed the vendor of git as being the 'Software Freedom Conservancy'. Can you please advise me if this is correct? If not, who should the vendor be identified as?
Regards,
Thor
Thor Prohaska
Test Coordinator - Desktop Anywhere
Enterprise Engineering BT,
3/300 Queen St, Brisbane
Desk Phone: 07 3362 1809
Mobile: 0419 344 806
________________________________
This e-mail is sent by Suncorp Group Limited ABN 66 145 290 124 or one of its related entities "Suncorp".
Suncorp may be contacted at Level 18, 36 Wickham Terrace, Brisbane or on 13 11 55 or at suncorp.com.au.
The content of this e-mail is the view of the sender or stated author and does not necessarily reflect the view of Suncorp. The content, including attachments, is a confidential communication between Suncorp and the intended recipient. If you are not the intended recipient, any use, interference with, disclosure or copying of this e-mail, including attachments, is unauthorised and expressly prohibited. If you have received this e-mail in error please contact the sender immediately and delete the e-mail and any attachments from your system.
^ permalink raw reply
* git push tags
From: Angelo Borsotti @ 2012-10-25 6:58 UTC (permalink / raw)
To: git
Hello,
git push tag updates silently the specified tag. E.g.
git init --bare release.git
git clone release.git integrator
cd integrator
git branch -avv
touch f1; git add f1; git commit -m A
git tag v1
git push origin tag v1
touch f2; git add f2; git commit -m B
git tag -f v1
git push origin tag v1
the second git push updates the tag in the remote repository. This is
somehow counterintuitive because tags normally do not move (unless
forced to that), and is not documented.
This is also harmful because it allows to change silently something
(tags) that normally must not change.
-Angelo Borsotti
^ permalink raw reply
* Re: [PATCH 1/3] t9350: point out that refs are not updated correctly
From: Sverre Rabbelier @ 2012-10-25 7:06 UTC (permalink / raw)
To: Felipe Contreras
Cc: Jonathan Nieder, Junio C Hamano, Jeff King, Git List,
Daniel Barkalow, Ramkumar Ramachandra, Dmitry Ivankov,
Johannes Schindelin, Ævar Arnfjörð, Eric Herman,
Fernando Vezzosi
In-Reply-To: <CAMP44s1cRg_we5nXeRG1WcWz7YUOBrauJigeNna1YETcno9p=A@mail.gmail.com>
On Wed, Oct 24, 2012 at 11:19 PM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> Oh really? This is with your patches:
>
> % git fast-export --{im,ex}port-marks=/tmp/marks foo1 ^foo2 foo3..foo3
> reset refs/heads/foo1
> from :21
>
> reset refs/heads/foo3
> from :21
>
> reset refs/heads/foo3
> from :21
>
> reset refs/heads/foo2
> from :21
That's weird, we have this bit:
+ if (elem->whence != REV_CMD_REV && elem->whence != REV_CMD_RIGHT)
+ continue;
If I understand correctly that should cause it to only output revs
(e.g. 'foo1') and the rhs side of a have..want spec.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH 1/3] t9350: point out that refs are not updated correctly
From: Jonathan Nieder @ 2012-10-25 7:18 UTC (permalink / raw)
To: Felipe Contreras
Cc: Sverre Rabbelier, Junio C Hamano, Jeff King, Git List,
Daniel Barkalow, Ramkumar Ramachandra, Dmitry Ivankov,
Johannes Schindelin, Ævar Arnfjörð, Eric Herman,
Fernando Vezzosi
In-Reply-To: <CAMP44s2bNZLiyinu3wgmw4gaRM9XUvA857-8fOGebhKYFmDesw@mail.gmail.com>
Felipe Contreras wrote:
> Show me a single remote helper that manually stores SHA-1's and I
> might believe you, but I doubt that, marks are too convenient.
Oh dear lord. Why are you arguing? Explain how coming to a consensus
on this will help accomplish something useful, and then I can explain
my point of view. In the meantime, this seems like a waste of time.
Let's agree to disagree.
Regards,
Jonathan
^ permalink raw reply
* Re: [PATCH 1/3] t9350: point out that refs are not updated correctly
From: Jonathan Nieder @ 2012-10-25 7:34 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Felipe Contreras, Junio C Hamano, Jeff King, Git List,
Daniel Barkalow, Ramkumar Ramachandra, Dmitry Ivankov,
Johannes Schindelin, Ævar Arnfjörð, Eric Herman,
Fernando Vezzosi
In-Reply-To: <CAGdFq_hgYPF5eeCB9hSsjVfUyEhkBNJAtzoNuNqs5N6V-+w9Hg@mail.gmail.com>
Sverre Rabbelier wrote:
> That's weird, we have this bit:
>
> + if (elem->whence != REV_CMD_REV && elem->whence != REV_CMD_RIGHT)
> + continue;
>
> If I understand correctly that should cause it to only output revs
> (e.g. 'foo1') and the rhs side of a have..want spec.
If I remember right, '^foo1' is (whence == REV_CMD_REV) with (flags ==
UNINTERESTING). That's why sequencer.c checks for unadorned revs like
this:
if (opts->revs->cmdline.nr == 1 &&
opts->revs->cmdline.rev->whence == REV_CMD_REV &&
opts->revs->no_walk &&
!opts->revs->cmdline.rev->flags) {
Maybe
if (elem->flags & UNINTERESTING)
continue;
if (elem->whence == REV_CMD_PARENTS_ONLY) /* foo^@ */
continue;
would work well here? That would handle bizarre cases like "--not
next..master" (and ordinary cases like "master...next") better, by
focusing on the semantics instead of syntax.
^ permalink raw reply
* Re: [PATCH 1/3] t9350: point out that refs are not updated correctly
From: Sverre Rabbelier @ 2012-10-25 7:43 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Felipe Contreras, Junio C Hamano, Jeff King, Git List,
Daniel Barkalow, Ramkumar Ramachandra, Dmitry Ivankov,
Johannes Schindelin, Ævar Arnfjörð, Eric Herman,
Fernando Vezzosi
In-Reply-To: <20121025073454.GB15790@elie.Belkin>
On Thu, Oct 25, 2012 at 12:34 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> If I remember right, '^foo1' is (whence == REV_CMD_REV) with (flags ==
> UNINTERESTING). That's why sequencer.c checks for unadorned revs like
> this:
>
> if (opts->revs->cmdline.nr == 1 &&
> opts->revs->cmdline.rev->whence == REV_CMD_REV &&
> opts->revs->no_walk &&
> !opts->revs->cmdline.rev->flags) {
>
> Maybe
>
> if (elem->flags & UNINTERESTING)
> continue;
> if (elem->whence == REV_CMD_PARENTS_ONLY) /* foo^@ */
> continue;
>
> would work well here? That would handle bizarre cases like "--not
> next..master" (and ordinary cases like "master...next") better, by
> focusing on the semantics instead of syntax.
I know there was a reason why using UNINTERESTING didn't work
(otherwise we could've used that to start with, instead of needing
Junio's whence solution). I think all refs ended up being marked as
UNINTERESTING or somesuch.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* [RFC/PATCH] __git_ps1: migrate out of contrib/completion
From: Jonathan Nieder @ 2012-10-25 7:45 UTC (permalink / raw)
To: Danny Yates
Cc: git@vger.kernel.org, Anders Kaseorg, Felipe Contreras, Ted Pavlic,
SZEDER Gábor, Dan McGee
In-Reply-To: <3B606942-D194-4148-AF6E-1F3283C983ED@googlemail.com>
Different installers put the git-prompt.sh shell library at different
places on the installed system, so there is no shared location users
can count on:
Fedora - /etc/profile.d/git-prompt.sh
Gentoo - /usr/share/bash-completion/git-prompt
Arch - /usr/share/git/git-prompt.sh
The __git_ps1 helper doesn't have anything to do with bash completion
in principle, but because it was written in the context of that
project, its sources are kept in contrib/completion/git-prompt.sh.
Let's make it a first-class shell library in the toplevel and install
it to $(gitexecdir) alongside git-sh-setup and git-sh-i18n, where it
can be easily found.
Keep a symlink in contrib/completion/ to avoid breaking setups where
this library is used directly from the source tree.
Now you can put the following in your ~/.bashrc:
if test "${BASH+set}" && test "${PS1+set}" # interactive!
then
gitexecdir=$(git --exec-path)
if test -r "$gitexecdir/git-sh-prompt)"
then
. "$gitexecdir/git-sh-prompt"
fi
if type -t __git_ps1 >/dev/null
then
PS1='\w$(__git_ps1)\$ '
fi
fi
and the shell prompt will show the current branch name in git
repositories when on a machine with a new enough version of git.
Reported-by: Danny Yates <mail4danny@googlemail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Danny Yates wrote:
> Would that not give the impression of "git sh-prompt" being a core
> command? If so, that would be poor, IMHO.
Not any more than $(git --exec-path)/git-sh-setup and git-sh-i18n. :)
> When I was investigating this last night, I expected to find it
> (git-prompt.sh) in contrib, although that doesn't make an enormous
> amount of sense. Ideally, the full path to wherever it's installed
> should be mentioned in the bash completion file (which is where I
> went to look when __git_ps1 stopped working),
Yes, certainly.
> but that would mean
> modifying a file from upstream and I'm not sure if that's easy/"the
> done thing".
We're talking on the upstream list now, so that's not an issue.
Thanks,
Jonathan
Documentation/git-sh-prompt.txt | 79 ++++++
Makefile | 1 +
contrib/completion/git-completion.bash | 2 +-
contrib/completion/git-prompt.sh | 291 +--------------------
.../completion/git-prompt.sh => git-sh-prompt.sh | 0
5 files changed, 82 insertions(+), 291 deletions(-)
create mode 100644 Documentation/git-sh-prompt.txt
rewrite contrib/completion/git-prompt.sh (100%)
mode change 100644 => 120000
rename contrib/completion/git-prompt.sh => git-sh-prompt.sh (100%)
diff --git a/Documentation/git-sh-prompt.txt b/Documentation/git-sh-prompt.txt
new file mode 100644
index 00000000..2c705fef
--- /dev/null
+++ b/Documentation/git-sh-prompt.txt
@@ -0,0 +1,79 @@
+git-sh-prompt(1)
+================
+
+NAME
+----
+git-sh-prompt - Functions to describe repository in bash or zsh prompt
+
+SYNOPSIS
+--------
+[verse]
+'. "$(git --exec-path)/git-sh-prompt"'
+
+DESCRIPTION
+-----------
+This script allows you to see the current branch in your bash prompt.
+
+To enable:
+
+1. Add the following line to your .bashrc and .zshrc:
+
+ . "$(git --exec-path)/git-sh-prompt"
+
+2. Change your PS1 to also show the current branch:
+
+ Bash: PS1='[\u@\h \W$(__git_ps1 " (%s)")]\$ '
+ Zsh: PS1='[%n@%m %c$(__git_ps1 " (%s)")]\$ '
+
+The argument to __git_ps1 will only be displayed if you are currently
+in a git repository. The %s token is replaced by the name of the current
+branch.
+
+In addition, if you set GIT_PS1_SHOWDIRTYSTATE to a nonempty value,
+unstaged (`*`) and staged (`+`) changes are indicated next to the branch
+name. You can configure this per repository with the `bash.showDirtyState`
+variable, which defaults to `true` once GIT_PS1_SHOWDIRTYSTATE is enabled.
+
+You can also see if something is currently stashed, by setting
+GIT_PS1_SHOWSTASHSTATE to a nonempty value. If something is stashed,
+then a '$' is shown next to the branch name.
+
+If you would like to see if there are untracked files, set
+GIT_PS1_SHOWUNTRACKEDFILES to a nonempty value. If there are untracked
+files, a '%' is shown next to the branch name.
+
+If you would like to see the difference between HEAD and its upstream,
+set GIT_PS1_SHOWUPSTREAM=auto. A '<' indicates the current branch is
+behind, '>' indicates it is ahead, '<>' indicates it has diverged, and
+'=' indicates no difference. You can further control behavior by
+setting GIT_PS1_SHOWUPSTREAM to a space-separated list of values:
+
+verbose::
+ show number of commits ahead of/behind (+/-) upstream
+legacy::
+ don't use the '--count' option available in recent versions
+ of git-rev-list
+git::
+ always compare HEAD to `@{upstream}`
+svn::
+ always compare HEAD to your 'git svn' upstream
+
+By default, __git_ps1 compares HEAD to your 'git svn' upstream if it can
+find one, or `@{upstream}` otherwise. Once you have set GIT_PS1_SHOWUPSTREAM,
+you can override it on a per-repository basis by setting the `bash.showUpstream`
+config variable.
+
+FUNCTIONS
+---------
+
+'__gitdir' [<directory>]::
+ Print the path to the git repository (`.git` directory). This is
+ similar to `git rev-parse --git-dir` but it is faster because it avoids
+ forking a new process when possible.
+
+'__git_ps1_show_upstream'::
+ Internal function.
+
+'__git_ps1 [<format>]'::
+ Print text to add to the shell's PS1 prompt, including the current
+ branch name. If <format> is not specified, it defaults to " (%s)".
diff --git a/Makefile b/Makefile
index f69979e3..c12d973b 100644
--- a/Makefile
+++ b/Makefile
@@ -459,6 +459,7 @@ SCRIPT_LIB += git-rebase--interactive
SCRIPT_LIB += git-rebase--merge
SCRIPT_LIB += git-sh-setup
SCRIPT_LIB += git-sh-i18n
+SCRIPT_LIB += git-sh-prompt
SCRIPT_PERL += git-add--interactive.perl
SCRIPT_PERL += git-difftool.perl
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index be800e09..01238588 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -21,7 +21,7 @@
# 2) Add the following line to your .bashrc/.zshrc:
# source ~/.git-completion.sh
# 3) Consider changing your PS1 to also show the current branch,
-# see git-prompt.sh for details.
+# see git-sh-prompt(1) for details.
if [[ -n ${ZSH_VERSION-} ]]; then
autoload -U +X bashcompinit && bashcompinit
diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
deleted file mode 100644
index bf20491e..00000000
--- a/contrib/completion/git-prompt.sh
+++ /dev/null
@@ -1,290 +0,0 @@
-# bash/zsh git prompt support
-#
-# Copyright (C) 2006,2007 Shawn O. Pearce <spearce@spearce.org>
-# Distributed under the GNU General Public License, version 2.0.
-#
-# This script allows you to see the current branch in your prompt.
-#
-# To enable:
-#
-# 1) Copy this file to somewhere (e.g. ~/.git-prompt.sh).
-# 2) Add the following line to your .bashrc/.zshrc:
-# source ~/.git-prompt.sh
-# 3) Change your PS1 to also show the current branch:
-# Bash: PS1='[\u@\h \W$(__git_ps1 " (%s)")]\$ '
-# ZSH: PS1='[%n@%m %c$(__git_ps1 " (%s)")]\$ '
-#
-# The argument to __git_ps1 will be displayed only if you are currently
-# in a git repository. The %s token will be the name of the current
-# branch.
-#
-# In addition, if you set GIT_PS1_SHOWDIRTYSTATE to a nonempty value,
-# unstaged (*) and staged (+) changes will be shown next to the branch
-# name. You can configure this per-repository with the
-# bash.showDirtyState variable, which defaults to true once
-# GIT_PS1_SHOWDIRTYSTATE is enabled.
-#
-# You can also see if currently something is stashed, by setting
-# GIT_PS1_SHOWSTASHSTATE to a nonempty value. If something is stashed,
-# then a '$' will be shown next to the branch name.
-#
-# If you would like to see if there're untracked files, then you can set
-# GIT_PS1_SHOWUNTRACKEDFILES to a nonempty value. If there're untracked
-# files, then a '%' will be shown next to the branch name.
-#
-# If you would like to see the difference between HEAD and its upstream,
-# set GIT_PS1_SHOWUPSTREAM="auto". A "<" indicates you are behind, ">"
-# indicates you are ahead, "<>" indicates you have diverged and "="
-# indicates that there is no difference. You can further control
-# behaviour by setting GIT_PS1_SHOWUPSTREAM to a space-separated list
-# of values:
-#
-# verbose show number of commits ahead/behind (+/-) upstream
-# legacy don't use the '--count' option available in recent
-# versions of git-rev-list
-# git always compare HEAD to @{upstream}
-# svn always compare HEAD to your SVN upstream
-#
-# By default, __git_ps1 will compare HEAD to your SVN upstream if it can
-# find one, or @{upstream} otherwise. Once you have set
-# GIT_PS1_SHOWUPSTREAM, you can override it on a per-repository basis by
-# setting the bash.showUpstream config variable.
-
-# __gitdir accepts 0 or 1 arguments (i.e., location)
-# returns location of .git repo
-__gitdir ()
-{
- # Note: this function is duplicated in git-completion.bash
- # When updating it, make sure you update the other one to match.
- if [ -z "${1-}" ]; then
- if [ -n "${__git_dir-}" ]; then
- echo "$__git_dir"
- elif [ -n "${GIT_DIR-}" ]; then
- test -d "${GIT_DIR-}" || return 1
- echo "$GIT_DIR"
- elif [ -d .git ]; then
- echo .git
- else
- git rev-parse --git-dir 2>/dev/null
- fi
- elif [ -d "$1/.git" ]; then
- echo "$1/.git"
- else
- echo "$1"
- fi
-}
-
-# stores the divergence from upstream in $p
-# used by GIT_PS1_SHOWUPSTREAM
-__git_ps1_show_upstream ()
-{
- local key value
- local svn_remote svn_url_pattern count n
- local upstream=git legacy="" verbose=""
-
- svn_remote=()
- # get some config options from git-config
- local output="$(git config -z --get-regexp '^(svn-remote\..*\.url|bash\.showupstream)$' 2>/dev/null | tr '\0\n' '\n ')"
- while read -r key value; do
- case "$key" in
- bash.showupstream)
- GIT_PS1_SHOWUPSTREAM="$value"
- if [[ -z "${GIT_PS1_SHOWUPSTREAM}" ]]; then
- p=""
- return
- fi
- ;;
- svn-remote.*.url)
- svn_remote[ $((${#svn_remote[@]} + 1)) ]="$value"
- svn_url_pattern+="\\|$value"
- upstream=svn+git # default upstream is SVN if available, else git
- ;;
- esac
- done <<< "$output"
-
- # parse configuration values
- for option in ${GIT_PS1_SHOWUPSTREAM}; do
- case "$option" in
- git|svn) upstream="$option" ;;
- verbose) verbose=1 ;;
- legacy) legacy=1 ;;
- esac
- done
-
- # Find our upstream
- case "$upstream" in
- git) upstream="@{upstream}" ;;
- svn*)
- # get the upstream from the "git-svn-id: ..." in a commit message
- # (git-svn uses essentially the same procedure internally)
- local svn_upstream=($(git log --first-parent -1 \
- --grep="^git-svn-id: \(${svn_url_pattern#??}\)" 2>/dev/null))
- if [[ 0 -ne ${#svn_upstream[@]} ]]; then
- svn_upstream=${svn_upstream[ ${#svn_upstream[@]} - 2 ]}
- svn_upstream=${svn_upstream%@*}
- local n_stop="${#svn_remote[@]}"
- for ((n=1; n <= n_stop; n++)); do
- svn_upstream=${svn_upstream#${svn_remote[$n]}}
- done
-
- if [[ -z "$svn_upstream" ]]; then
- # default branch name for checkouts with no layout:
- upstream=${GIT_SVN_ID:-git-svn}
- else
- upstream=${svn_upstream#/}
- fi
- elif [[ "svn+git" = "$upstream" ]]; then
- upstream="@{upstream}"
- fi
- ;;
- esac
-
- # Find how many commits we are ahead/behind our upstream
- if [[ -z "$legacy" ]]; then
- count="$(git rev-list --count --left-right \
- "$upstream"...HEAD 2>/dev/null)"
- else
- # produce equivalent output to --count for older versions of git
- local commits
- if commits="$(git rev-list --left-right "$upstream"...HEAD 2>/dev/null)"
- then
- local commit behind=0 ahead=0
- for commit in $commits
- do
- case "$commit" in
- "<"*) ((behind++)) ;;
- *) ((ahead++)) ;;
- esac
- done
- count="$behind $ahead"
- else
- count=""
- fi
- fi
-
- # calculate the result
- if [[ -z "$verbose" ]]; then
- case "$count" in
- "") # no upstream
- p="" ;;
- "0 0") # equal to upstream
- p="=" ;;
- "0 "*) # ahead of upstream
- p=">" ;;
- *" 0") # behind upstream
- p="<" ;;
- *) # diverged from upstream
- p="<>" ;;
- esac
- else
- case "$count" in
- "") # no upstream
- p="" ;;
- "0 0") # equal to upstream
- p=" u=" ;;
- "0 "*) # ahead of upstream
- p=" u+${count#0 }" ;;
- *" 0") # behind upstream
- p=" u-${count% 0}" ;;
- *) # diverged from upstream
- p=" u+${count#* }-${count% *}" ;;
- esac
- fi
-
-}
-
-
-# __git_ps1 accepts 0 or 1 arguments (i.e., format string)
-# returns text to add to bash PS1 prompt (includes branch name)
-__git_ps1 ()
-{
- local g="$(__gitdir)"
- if [ -n "$g" ]; then
- local r=""
- local b=""
- if [ -f "$g/rebase-merge/interactive" ]; then
- r="|REBASE-i"
- b="$(cat "$g/rebase-merge/head-name")"
- elif [ -d "$g/rebase-merge" ]; then
- r="|REBASE-m"
- b="$(cat "$g/rebase-merge/head-name")"
- else
- if [ -d "$g/rebase-apply" ]; then
- if [ -f "$g/rebase-apply/rebasing" ]; then
- r="|REBASE"
- elif [ -f "$g/rebase-apply/applying" ]; then
- r="|AM"
- else
- r="|AM/REBASE"
- fi
- elif [ -f "$g/MERGE_HEAD" ]; then
- r="|MERGING"
- elif [ -f "$g/CHERRY_PICK_HEAD" ]; then
- r="|CHERRY-PICKING"
- elif [ -f "$g/BISECT_LOG" ]; then
- r="|BISECTING"
- fi
-
- b="$(git symbolic-ref HEAD 2>/dev/null)" || {
-
- b="$(
- case "${GIT_PS1_DESCRIBE_STYLE-}" in
- (contains)
- git describe --contains HEAD ;;
- (branch)
- git describe --contains --all HEAD ;;
- (describe)
- git describe HEAD ;;
- (* | default)
- git describe --tags --exact-match HEAD ;;
- esac 2>/dev/null)" ||
-
- b="$(cut -c1-7 "$g/HEAD" 2>/dev/null)..." ||
- b="unknown"
- b="($b)"
- }
- fi
-
- local w=""
- local i=""
- local s=""
- local u=""
- local c=""
- local p=""
-
- if [ "true" = "$(git rev-parse --is-inside-git-dir 2>/dev/null)" ]; then
- if [ "true" = "$(git rev-parse --is-bare-repository 2>/dev/null)" ]; then
- c="BARE:"
- else
- b="GIT_DIR!"
- fi
- elif [ "true" = "$(git rev-parse --is-inside-work-tree 2>/dev/null)" ]; then
- if [ -n "${GIT_PS1_SHOWDIRTYSTATE-}" ]; then
- if [ "$(git config --bool bash.showDirtyState)" != "false" ]; then
- git diff --no-ext-diff --quiet --exit-code || w="*"
- if git rev-parse --quiet --verify HEAD >/dev/null; then
- git diff-index --cached --quiet HEAD -- || i="+"
- else
- i="#"
- fi
- fi
- fi
- if [ -n "${GIT_PS1_SHOWSTASHSTATE-}" ]; then
- git rev-parse --verify refs/stash >/dev/null 2>&1 && s="$"
- fi
-
- if [ -n "${GIT_PS1_SHOWUNTRACKEDFILES-}" ]; then
- if [ -n "$(git ls-files --others --exclude-standard)" ]; then
- u="%"
- fi
- fi
-
- if [ -n "${GIT_PS1_SHOWUPSTREAM-}" ]; then
- __git_ps1_show_upstream
- fi
- fi
-
- local f="$w$i$s$u"
- printf -- "${1:- (%s)}" "$c${b##refs/heads/}${f:+ $f}$r$p"
- fi
-}
diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
new file mode 120000
index 00000000..a4fbb216
--- /dev/null
+++ b/contrib/completion/git-prompt.sh
@@ -0,0 +1 @@
+../../git-sh-prompt.sh
\ No newline at end of file
diff --git a/contrib/completion/git-prompt.sh b/git-sh-prompt.sh
similarity index 100%
rename from contrib/completion/git-prompt.sh
rename to git-sh-prompt.sh
--
1.8.0
^ permalink raw reply related
* Re: [PATCH 1/3] t9350: point out that refs are not updated correctly
From: Jonathan Nieder @ 2012-10-25 7:48 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Felipe Contreras, Junio C Hamano, Jeff King, Git List,
Daniel Barkalow, Ramkumar Ramachandra, Dmitry Ivankov,
Johannes Schindelin, Ævar Arnfjörð, Eric Herman,
Fernando Vezzosi
In-Reply-To: <CAGdFq_j5sWsHwJY-rWP-XJ6cMF6uwSq=9beFe9ZuZyixBa1fVA@mail.gmail.com>
Sverre Rabbelier wrote:
> I know there was a reason why using UNINTERESTING didn't work
> (otherwise we could've used that to start with, instead of needing
> Junio's whence solution). I think all refs ended up being marked as
> UNINTERESTING or somesuch.
True. Is it be possible to check UNINTERESTING in revs->cmdline
before the walk?
^ permalink raw reply
* Re: [PATCH 1/3] t9350: point out that refs are not updated correctly
From: Sverre Rabbelier @ 2012-10-25 7:50 UTC (permalink / raw)
To: Jonathan Nieder, Johannes Schindelin
Cc: Felipe Contreras, Junio C Hamano, Jeff King, Git List,
Daniel Barkalow, Ramkumar Ramachandra, Dmitry Ivankov,
Ævar Arnfjörð, Eric Herman, Fernando Vezzosi
In-Reply-To: <20121025074829.GD15790@elie.Belkin>
On Thu, Oct 25, 2012 at 12:48 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Sverre Rabbelier wrote:
>
>> I know there was a reason why using UNINTERESTING didn't work
>> (otherwise we could've used that to start with, instead of needing
>> Junio's whence solution). I think all refs ended up being marked as
>> UNINTERESTING or somesuch.
>
> True. Is it be possible to check UNINTERESTING in revs->cmdline
> before the walk?
That might work, maybe Dscho remembers why we did not go with that approach.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: signing commits with openssl/PKCS#11
From: Brandon Casey @ 2012-10-25 8:02 UTC (permalink / raw)
To: Mat Arge; +Cc: git
In-Reply-To: <1392235.RizYqAYdkC@off17>
On Mon, Oct 22, 2012 at 6:38 AM, Mat Arge <argemat1010@gmail.com> wrote:
> Hy!
>
> I would like to sign each commit with a X.509 certificate and a private key
> stored on a PKCS#11 token. I assume that that should be possible somehow using
> a hook which calls openssl. Does somebody know a working implementation of
> this?
Creating signatures from an rsa key on a pkcs11 token should be
possible, but gnupg doesn't support pkcs11 for philosophical reasons.
You need to use gnupg-pkcs11 which is maintained outside of the gnupg
tree.
Once you configure gnupg-pkcs11-scd, you'll be able to use git and gpg
to sign tags as usual.
I configured this a while back for use with CAC cards using the
following resources:
http://alpha.uwb.edu.pl/map/eToken_gpg_howto.shtml (dead)
http://alpha.uwb.edu.pl/amicke/eToken_gpg_howto.shtml (replacement
for above?)
http://gnupg-pkcs11.sourceforge.net/man.html
Try those docs. If you have questions, I'll try to find my notes.
-Brandon
^ 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