* 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
* Re: Where should git-prompt.sh be installed?
From: Anders Kaseorg @ 2012-10-25 8:10 UTC (permalink / raw)
To: Danny Yates
Cc: Jonathan Nieder, git@vger.kernel.org, Felipe Contreras,
Ted Pavlic, SZEDER Gábor, Dan McGee
In-Reply-To: <3B606942-D194-4148-AF6E-1F3283C983ED@googlemail.com>
On 10/25/2012 02:02 AM, Danny Yates wrote:
> Would that not give the impression of "git sh-prompt" being a core
> command?
No more than git-sh-setup, which already works like that. Unless
perhaps by “core” you mean “not contrib”.
(Now that I think of it, I saw a request from an Ubuntu PPA user last
week to install git-subtree in a more accessible location, and there’s a
similar request about gitview at https://bugs.launchpad.net/bugs/152212
. These are less critical since the Debian package puts them in
/usr/share/doc/git/contrib. Is it a good idea to package those
somewhere like /usr/lib/git-core or /usr/bin, or is that a dangerous
slippery slope? I dunno.)
Anders
^ permalink raw reply
* Re: Is git mktag supposed to accept git cat-file input?
From: Michael J Gruber @ 2012-10-25 8:34 UTC (permalink / raw)
To: Anand Kumria; +Cc: Brandon Casey, git
In-Reply-To: <CAM1C4Gn6tr_bxG1De+kZecpJ7kLg7_hOO7q-aa7HwFkr9od6_Q@mail.gmail.com>
Anand Kumria venit, vidit, dixit 25.10.2012 02:58:
> Ahh, unix time. Of course.
That's the only difference *at the time being*, but this is not
guaranteed. Really, as Brandon says: "cat-file -p" is pretty printing
for human readability (which could be improved), and "cat-file <type>"
is the raw format which is the content being hashed to the sha1.
>
> Thanks Brandon.
>
> On 25 October 2012 01:18, Brandon Casey <drafnel@gmail.com> wrote:
>> On Wed, Oct 24, 2012 at 4:39 PM, Anand Kumria <akumria@acm.org> wrote:
>>> Hi,
>>>
>>> I am doing some experimenting with git-mktag, and was looking into the
>>> format it expects on input.
>>>
>>> Should this sequence of commands work?
>>
>> Yes, with a slight tweak...
>>
>>> kalki:[/tmp/gittest]% git tag -m "tag-test" tag-test
>>> kalki:[/tmp/gittest]% git cat-file -p e619
>>
>> '-p' means pretty-print, i.e. produce a human-readable format. mktag
>> supports the raw format. So you should invoke it like this:
>>
>> $ git cat-file tag e619
>>
>> which should produce something like:
>>
>> object c0ae36fee730f7034b1f76c1490fe6f46f7ecad5
>> type commit
>> tag tag-test
>> tagger Anand Kumria <akumria@acm.org> 1351121552 +0100
>>
>> tag-test
>>
>> and is the format expected by mktag.
>>
>> -Brandon
>>
>
>
>
^ permalink raw reply
* Re: [PATCH] Fixes handling of --reference argument.
From: Jeff King @ 2012-10-25 8:36 UTC (permalink / raw)
To: szager; +Cc: git
In-Reply-To: <5088c5a4.L25tOcUVCSwBRpYF%szager@google.com>
On Wed, Oct 24, 2012 at 09:52:52PM -0700, szager@google.com wrote:
> 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
> ;;
Is that right? We'll unconditionally do a "shift" at the end of the
loop. If it were a two-part argument like "--reference foo", the extra
shift would make sense, but for "--reference=*", no extra shift should
be neccessary. Am I missing something?
-Peff
^ permalink raw reply
* Re: t9401 fails with OS X sed
From: Jeff King @ 2012-10-25 8:41 UTC (permalink / raw)
To: Geert Bosch; +Cc: Brian Gernhardt, Git List
In-Reply-To: <F721B376-F4E6-4274-9A6E-BD1CFCBDA39F@adacore.com>
On Thu, Oct 25, 2012 at 01:04:11AM -0400, Geert Bosch wrote:
> 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.
I agree that the POSIX character class would be more portable than "\s",
but we do not have any existing uses of them, and I would worry a little
about older systems like Solaris. If we can simply use a literal space
and tab, that seems like the safest.
Brian, can you work up a patch?
-Peff
^ permalink raw reply
* Re: Who is the 'git' vendor?
From: Andreas Ericsson @ 2012-10-25 8:52 UTC (permalink / raw)
To: PROHASKA, Thor
Cc: 'git@vger.kernel.org',
'Thor Home (thorlp@hotkey.net.au)'
In-Reply-To: <8F7A9DADB4F4064EB938B0D3EBB63FDC208A5A34@PBNEMBMSX4120.int.Corp.sun>
On 10/25/2012 08:43 AM, PROHASKA, Thor wrote:
> 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?
>
Most likely, you'll want to put "git@vger.kernel.org" as vendor for git,
as the whole vendor concept doesn't really fly with FOSS. There's noone
to go to if it breaks your systems, and unless you purchase a support
contract from somewhere there's noone to turn to except the (excellent)
git community in case you have issues with it.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
^ permalink raw reply
* Re: [PATCH] git-send-email: skip RFC2047 quoting for ASCII subjects
From: Jeff King @ 2012-10-25 9:01 UTC (permalink / raw)
To: Krzysztof Mazur; +Cc: gitster, git
In-Reply-To: <20121024210826.GA23562@shrek.podlesie.net>
On Wed, Oct 24, 2012 at 11:08:26PM +0200, Krzysztof Mazur wrote:
> ok, I'm sending a version that just adds quote_subject() without
> changing any logic, so now we still have in first case:
>
> /[^[:ascii:]]/
>
> and in the latter case:
>
> !is_rfc2047_quoted($subject) && /^[:ascii:]]/
>
>
> In the next patch I will just add matching for "=?" in
> subject_needs_rfc2047_quoting() and we will have:
>
> /=?/ || /[^[:ascii:]]/
>
> and in the latter case:
>
> !is_rfc2047_quoted($subject) && (/=\?/ || /^[:ascii:]]/)
>
> This will also add quoting for any rfc2047 quoted subject or any
> other rfc2047-like subject, as you suggested.
Thanks, the two-patch series you outline makes a lot of sense to me.
> Krzysiek
> --
> From a70c5385f9b4da69a8ce00a1448f87f63bbd500d Mon Sep 17 00:00:00 2001
> From: Krzysztof Mazur <krzysiek@podlesie.net>
> Date: Wed, 24 Oct 2012 22:46:00 +0200
> Subject: [PATCH] git-send-email: introduce quote_subject()
When sending a patch following some cover letter material, please cut
out any non-essential headers and use the scissors symbol, like this:
-- >8 --
Subject: [PATCH] this subject overrides the whole email's subject
the regular body and diff go here...
That format is understood by "git am" and means I do not have to
manually munge it, which saves a little work.
> +sub quote_subject {
> + local $subject = shift;
> + my $encoding = shift || 'UTF-8';
> +
> + if (subject_needs_rfc2047_quoting($subject)) {
> + return quote_rfc2047($subject, $encoding);
> + }
> + return $subject;
> +}
There is some funny whitespace here (space followed by tab).
> - if ($broken_encoding{$t} && !is_rfc2047_quoted($subject) &&
> - ($subject =~ /[^[:ascii:]]/)) {
> - $subject = quote_rfc2047($subject, $auto_8bit_encoding);
> + if ($broken_encoding{$t} && !is_rfc2047_quoted($subject)) {
> + $subject = quote_subject($subject, $auto_8bit_encoding);
> }
Hmm. What is this patch on top of? It looks like it is on top of your
original patch, but when I tried it on top of that, it does not apply
either, and the index lines in the patch do not mention a sha1 that I do
not have.
Do you mind re-rolling a final 2-patch series with:
1. Your original patch and this one squashed together, with an
appropriate commit message.
2. The second "quote when we see '=?'" patch.
Thanks.
-Peff
^ permalink raw reply
* Re: [PATCH] git-send-email: add rfc2047 quoting for "=?"
From: Jeff King @ 2012-10-25 9:05 UTC (permalink / raw)
To: Krzysztof Mazur; +Cc: gitster, git
In-Reply-To: <1351114109-16310-1-git-send-email-krzysiek@podlesie.net>
On Wed, Oct 24, 2012 at 11:28:29PM +0200, Krzysztof Mazur wrote:
> For raw subjects rfc2047 quoting is needed not only for non-ASCII characters,
> but also for any possible rfc2047 in it.
> [...]
> - return ($s =~ /[^[:ascii:]]/);
> + return ($s =~ /[^[:ascii:]]/) || ($s =~ /=\?/);
Very nice and obvious bug-fix made easy by the previous refactoring. :)
> ---
> Oops, this ugly Subject was generated by git format-patch (both 1.8.0
> and km/send-email-compose-encoding).
Yeah, format-patch has the same behavior (to encode when we see "=?").
So we know it is working. It is perhaps overkill in this case, since
there is not technically a valid encoded-word, and a smart parser would
be able to see that it should leave it alone. But it is probably better
to be slightly conservative in what we generate (and the "=?" token is
unlikely to come up in day-to-day usage).
-Peff
^ permalink raw reply
* Re: Who is the 'git' vendor?
From: Jeff King @ 2012-10-25 9:10 UTC (permalink / raw)
To: PROHASKA, Thor
Cc: Andreas Ericsson, 'git@vger.kernel.org',
'Thor Home (thorlp@hotkey.net.au)'
In-Reply-To: <5088FDDC.20404@op5.se>
On Thu, Oct 25, 2012 at 10:52:44AM +0200, Andreas Ericsson wrote:
> On 10/25/2012 08:43 AM, PROHASKA, Thor wrote:
> > 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?
> >
>
> Most likely, you'll want to put "git@vger.kernel.org" as vendor for git,
> as the whole vendor concept doesn't really fly with FOSS. There's noone
> to go to if it breaks your systems, and unless you purchase a support
> contract from somewhere there's noone to turn to except the (excellent)
> git community in case you have issues with it.
Yeah. Depending on the purpose of the list, I would probably _not_ put
the SFC. They help manage the legal and financial aspects of the git
project, but they have nothing at all to do with the code itself. I
would hate for them to get a phone call about support. :)
Probably "The Git Community" or "git@vger.kernel.org" is the best thing
to fill in if you need to write something in a form. If there ends up
being some specific reason for a vendor to be contacted, folks on the
list will be able to point an inquiry in the right direction (which
might even end up being the SFC).
-Peff
^ permalink raw reply
* Re: [PATCH] configure: fix some output message
From: Jeff King @ 2012-10-25 9:11 UTC (permalink / raw)
To: Stefano Lattarini; +Cc: git
In-Reply-To: <b67d9e47dc92c2c316495ac4bd8e7ba93d339781.1351091006.git.stefano.lattarini@gmail.com>
On Wed, Oct 24, 2012 at 05:34:27PM +0200, Stefano Lattarini wrote:
> Before this change, output from ./configure could contain
> botched wording like this:
>
> checking Checking for POSIX Threads with '-pthread'... yes
>
> instead of the intended:
>
> checking for POSIX Threads with '-pthread'... yes
>
> Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
Thanks, looks obviously correct.
-Peff
^ 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