Hey folks - just in case you haven't all figured this out yet, if you're using the neat little trick of putting a few lines in your ~/.bashrc so that when you're in a directory containing a git repo, the prompt will display what branch you're in, it'll stop working when you update to the latest git - 1.7.12 - in F18 or Rawhide. To fix it, you need to change:
source /etc/bash_completion.d/git
to:
source /usr/share/doc/git-1.7.12/contrib/completion/git-prompt.sh
because upstream split the prompt stuff out from the bash_completion script. Perhaps the git packagers could consider providing git-prompt.sh in a more permanent location, so we don't have to poke .bashrc every time the git version changes? Thanks!
On 08/23/2012 12:12 AM, Adam Williamson wrote:
Hey folks - just in case you haven't all figured this out yet, if you're using the neat little trick of putting a few lines in your ~/.bashrc so that when you're in a directory containing a git repo, the prompt will display what branch you're in, it'll stop working when you update to the latest git - 1.7.12 - in F18 or Rawhide. To fix it, you need to change:
source /etc/bash_completion.d/git
to:
source /usr/share/doc/git-1.7.12/contrib/completion/git-prompt.sh
because upstream split the prompt stuff out from the bash_completion script. Perhaps the git packagers could consider providing git-prompt.sh in a more permanent location, so we don't have to poke .bashrc every time the git version changes? Thanks!
Nice one. I've adjusted my .bashrc as follows, which should work for all versions:
# show extra info in the prompt in git repos git_prompt_dir=/usr/share/doc/git-*/contrib/completion git_integration=$git_prompt_dir/git-prompt.sh test -e $git_integration || git_integration=$git_prompt_dir/git-completion.bash if test -e $git_integration; then source $git_integration export GIT_PS1_SHOWDIRTYSTATE=1 PS1='[\e[1m]\h:\W$(__git_ps1 " (%s)")$[\e[0m] ' fi
cheers, Pádraig.
Adam Williamson wrote:
Hey folks - just in case you haven't all figured this out yet, if you're using the neat little trick of putting a few lines in your ~/.bashrc so that when you're in a directory containing a git repo, the prompt will display what branch you're in, it'll stop working when you update to the latest git - 1.7.12 - in F18 or Rawhide. To fix it, you need to change:
source /etc/bash_completion.d/git
to:
source /usr/share/doc/git-1.7.12/contrib/completion/git-prompt.sh
because upstream split the prompt stuff out from the bash_completion script. Perhaps the git packagers could consider providing git-prompt.sh in a more permanent location, so we don't have to poke .bashrc every time the git version changes? Thanks!
This is definitely planned. I mailed Adam (the other Adam) today to point out that this was broken by the 1.7.12 update. I don't have time to work on a fix though. But certainly, git-prompt.sh should be placed in a more permanent location in the next build.
On 2012-08-23 04:34, Todd Zullinger wrote:
Adam Williamson wrote:
source /usr/share/doc/git-1.7.12/contrib/completion/git-prompt.sh
because upstream split the prompt stuff out from the bash_completion script. Perhaps the git packagers could consider providing git-prompt.sh in a more permanent location, so we don't have to poke .bashrc every time the git version changes? Thanks!
This is definitely planned. I mailed Adam (the other Adam) today to point out that this was broken by the 1.7.12 update. I don't have time to work on a fix though. But certainly, git-prompt.sh should be placed in a more permanent location in the next build.
Somewhat unrelated, but I think it'd be better to stop using versioned %doc dirs altogether, just stick with /usr/share/doc/%name and let packages for which it's usual to have multiple versions installed handle doc dir conflicts just as they handle other possibly conflicting files...
On Thu, Aug 23, 2012 at 7:06 AM, Ville Skyttä ville.skytta@iki.fi wrote:
On 2012-08-23 04:34, Todd Zullinger wrote:
Adam Williamson wrote:
source /usr/share/doc/git-1.7.12/contrib/completion/git-prompt.sh
because upstream split the prompt stuff out from the bash_completion script. Perhaps the git packagers could consider providing git-prompt.sh in a more permanent location, so we don't have to poke .bashrc every time the git version changes? Thanks!
This is definitely planned. I mailed Adam (the other Adam) today to point out that this was broken by the 1.7.12 update. I don't have time to work on a fix though. But certainly, git-prompt.sh should be placed in a more permanent location in the next build.
Somewhat unrelated, but I think it'd be better to stop using versioned %doc dirs altogether, just stick with /usr/share/doc/%name and let packages for which it's usual to have multiple versions installed handle doc dir conflicts just as they handle other possibly conflicting files...
Ideally, this shouldn't be an issue, as things in %doc shouldn't be things that affect run-time operation. Ergo, git-prompt.sh shouldn't be in %doc, or if it is, it should also be elsewhere for usage.
-J
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On 2012-08-23 15:12, Jon Ciesla wrote:
things in %doc shouldn't be things that affect run-time operation
True, but there are other considerations in favour of unversioned dirs such as bookmarkability and general referenceability, consistency with other distros, and general cleanliness. But this stuff deserves a discussion of its own.
On Thu, Aug 23, 2012 at 7:45 AM, Ville Skyttä ville.skytta@iki.fi wrote:
On 2012-08-23 15:12, Jon Ciesla wrote:
things in %doc shouldn't be things that affect run-time operation
True, but there are other considerations in favour of unversioned dirs such as bookmarkability and general referenceability, consistency with other distros, and general cleanliness. But this stuff deserves a discussion of its own.
Absolutely, I didn't mean to imply disagreement with that.
-J
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On 08/23/2012 08:45 AM, Ville Skyttä wrote:
On 2012-08-23 15:12, Jon Ciesla wrote:
things in %doc shouldn't be things that affect run-time operation
True, but there are other considerations in favour of unversioned dirs such as bookmarkability and general referenceability, consistency with other distros, and general cleanliness. But this stuff deserves a discussion of its own.
+1
But an unversioned softlink to the latest would suffice.
John
I wrote:
This is definitely planned. I mailed Adam (the other Adam) today to point out that this was broken by the 1.7.12 update. I don't have time to work on a fix though. But certainly, git-prompt.sh should be placed in a more permanent location in the next build.
I placed git-prompt.sh in /etc/profile.d where it should be sourced for normal login shells. This should make the change transparent to most users.
https://admin.fedoraproject.org/updates/git-1.7.12-2.fc18
Todd Zullinger tmz@pobox.com a écrit:
I placed git-prompt.sh in /etc/profile.d where it should be sourced for normal login shells. This should make the change transparent to most users.
Great. Thank you for doing this.
Do you think it would be possible to take similar actions for things that are in the contrib package of git, like, e.g, git-new-workdir? It's a really useful tool that I manually install in /usr/local/bin. The problem, like for the git-prompt.sh is that each time there is a git version change, I have to manually update the git-new-workdir.
So I am thinking that maybe we should have a git-contrib package that properly installs all the juicy stuff that we find today in /usr/share/doc/git-<version>/contrib.
If you think the idea could have legs, I can fill a tracker bug for this.
Thanks.
Todd Zullinger tmz@pobox.com writes:
I placed git-prompt.sh in /etc/profile.d where it should be sourced for normal login shells.
As I wrote in the update comment, please revert it. It pollutes the environment of every user with functions which are probably never be used.
As these functions are useless without doing further modifications to ~/.bash_profile, it does not matter whether the user sources the script explicitly and modifies $PS1, or whether he modifies $PS1 only, or whether a script is sourced which modifies $PS1.
Please move the script to /usr/share/git or to /etc/bash_completion.d where it can be requested by the user explicitly.
Enrico
On 2012-08-24 13:08, Enrico Scholz wrote:
Please move the script to /usr/share/git or to /etc/bash_completion.d where it can be requested by the user explicitly.
+1, but /etc/bash_completion.d would be a bad choice as AFAIK this script has nothing to do with completion (and besides, everything from there gets sourced automatically if bash-completion is installed).
Enrico Scholz wrote:
Todd Zullinger tmz@pobox.com writes:
I placed git-prompt.sh in /etc/profile.d where it should be sourced for normal login shells.
As I wrote in the update comment, please revert it. It pollutes the environment of every user with functions which are probably never be used.
As these functions are useless without doing further modifications to ~/.bash_profile, it does not matter whether the user sources the script explicitly and modifies $PS1, or whether he modifies $PS1 only, or whether a script is sourced which modifies $PS1.
Please move the script to /usr/share/git or to /etc/bash_completion.d where it can be requested by the user explicitly.
Doing this would break current users that have already configured their system to use __git_ps1(). I'm not inclined to agree that this "pollution" is a significant problem that warrants causing users to have to update their configuration.
I could be in the minority here. If so and we move it again, then we'd probably want to add a release note for f18 warning users that they will need to adjust their startup scripts.
Whatever we do, someone will be unhappy, that much I know.
Todd Zullinger tmz@pobox.com writes:
I placed git-prompt.sh in /etc/profile.d where it should be sourced for normal login shells.
As I wrote in the update comment, please revert it. It pollutes the environment of every user with functions which are probably never be used.
... Doing this would break current users that have already configured their system to use __git_ps1().
What are "current users"? Those who installed your just released rawhide changes?
Else, __git_ps1 was never available without sourceing /etc/bash_completion.d/git. Nobody stops you to source the __git_ps1() function from within the bash-completion file (defining a bash function twice is not a problem).
E.g.:
1. move __git_ps1() into /usr/share/git/functions
2. add 'source /usr/share/git/functions' in /etc/bash_completion.d/git
3. document that people have to add
| source /usr/share/git/functions
to ~/.bash_profile when they want __git_ps1() without bash-completion
Enrico
Enrico Scholz wrote:
Todd Zullinger tmz@pobox.com writes:
Doing this would break current users that have already configured their system to use __git_ps1().
What are "current users"? Those who installed your just released rawhide changes?
No, it breaks anyone that's currently using __git_ps1(), as the function was previously defined in /etc/bash_completion.d/git. Newer releases of bash-completion are moving to on-demand loading, hence upstream git has split out the __git_ps1() function and a few other support functions. Not having this available for current users means anyone with __git_ps1() in their prompt will get an ugly error every time they hit return, e.g.:
bash: __git_ps1: command not found
That's far more annoying to far more people than having this function in the environment, in my opinion.
I don't see the compelling reason to jump through hoops or expect users to make more changes than needed to enable git info in their prompts. Without some justification of harm, I'm not inclined to change this. What's the reason to strongly oppose this being in /etc/profile.d?
If it's simply "I don't like these extra functions being defined", then I'm not persuaded, unless some massive amount of people have this same issue. I suspect that is not the case as anyone that has enabled bash completion until very recently would have many more functions defined by default.
Respectfully,
Todd Zullinger tmz@pobox.com writes:
Doing this would break current users that have already configured their system to use __git_ps1().
What are "current users"? Those who installed your just released rawhide changes?
No, it breaks anyone that's currently using __git_ps1(), as the function was previously defined in /etc/bash_completion.d/git. Newer releases of bash-completion are moving to on-demand loading,
Why do you mean that Fedora needs to do more than upstream git (--> a note in the changelog/release notes)? Or, how is it solved in upstream git else?
When you really want to go another way than upstream git, than modify their bash-completion script and source the __git_ps1 function there. But do not decide for other people that they need __git_ps1.
If it's simply "I don't like these extra functions being defined",
Beside the broken udisks package which installs its bash-completion unasked for every user, git-core will be the only package which pollutes my environemnt in such a massive way. What makes git-core so special that it adds 10 extra pages (nearly +200%) to the 'set' output:
$ set | wc -l 137
$ . /tmp/git-prompt.sh
$ set | wc -l 379
Please look what other packages are installing in /etc/profile.d. This is not the place for such complex stuff...
then I'm not persuaded, unless some massive amount of people
How many Fedora git-core users have __git_ps1 in their $PS1? This is a very low minority (I am in doubt that it will be more than 100). But your change affects *every* git user.
Enrico
On 2012-08-25 10:09, Todd Zullinger wrote:
Enrico Scholz wrote:
Todd Zullinger tmz@pobox.com writes:
Doing this would break current users that have already configured their system to use __git_ps1().
What are "current users"? Those who installed your just released rawhide changes?
No, it breaks anyone that's currently using __git_ps1(), as the function was previously defined in /etc/bash_completion.d/git. Newer releases of bash-completion are moving to on-demand loading, hence upstream git has split out the __git_ps1() function and a few other support functions. Not having this available for current users means anyone with __git_ps1() in their prompt will get an ugly error every time they hit return, e.g.:
bash: __git_ps1: command not found
That's far more annoying to far more people than having this function in the environment, in my opinion.
I don't see the compelling reason to jump through hoops or expect users to make more changes than needed to enable git info in their prompts. Without some justification of harm, I'm not inclined to change this. What's the reason to strongly oppose this being in /etc/profile.d?
It's the fact that you're now adding functions to *every* shell, whereas before it was just bash, and then only for people who opted into completion. Since git-prompt.sh makes no attempt to whitelist (or even blacklist) shells for compatibility its code will unconditionally attempt to run, whether doing so will result in errors or not.
Since you're looking to maintain compatibility with bash users who rely on that function, is there another, bash-specific location where that file could go? Or might it make more sense to add a simple whitelist or some other check to the top of the file instead?
On 2012-08-25 16:31, Garrett Holmstrom wrote:
On 2012-08-25 10:09, Todd Zullinger wrote:
Enrico Scholz wrote:
Todd Zullinger tmz@pobox.com writes:
Doing this would break current users that have already configured their system to use __git_ps1().
What are "current users"? Those who installed your just released rawhide changes?
No, it breaks anyone that's currently using __git_ps1(), as the function was previously defined in /etc/bash_completion.d/git. Newer releases of bash-completion are moving to on-demand loading, hence upstream git has split out the __git_ps1() function and a few other support functions. Not having this available for current users means anyone with __git_ps1() in their prompt will get an ugly error every time they hit return, e.g.:
bash: __git_ps1: command not found
That's far more annoying to far more people than having this function in the environment, in my opinion.
I don't see the compelling reason to jump through hoops or expect users to make more changes than needed to enable git info in their prompts. Without some justification of harm, I'm not inclined to change this. What's the reason to strongly oppose this being in /etc/profile.d?
It's the fact that you're now adding functions to *every* shell, whereas before it was just bash, and then only for people who opted into completion. Since git-prompt.sh makes no attempt to whitelist (or even blacklist) shells for compatibility its code will unconditionally attempt to run, whether doing so will result in errors or not.
Since you're looking to maintain compatibility with bash users who rely on that function, is there another, bash-specific location where that file could go? Or might it make more sense to add a simple whitelist or some other check to the top of the file instead?
FWIW, I don't see any problem with requiring people to update their .bash_profile between F17 and F18 to keep this trick working. The only thing I considered a 'bug' when posting my initial mail was that the script lives in a directory whose name is very mutable, so people would have to keep changing it a lot.
I don't think we need to bend over backwards to make it work for people upgrading from f17 without them having to make any manual change, and I don't think it's worth polluting the environment of every user with git installed just for that result. I think it's fine just to put the script somewhere where its location will remain permanent, and tell people to update their .bash_profile to source that.
I think we should ignore the issue of bash-completion entirely. One of the points of this upstream change is that the use of __git_ps1 had nothing to do, really, with bash-completion in the first place: you can use __git_ps1 without using bash-completion and you can use git bash-completion without using __git_ps1.
On Wed, 2012-08-22 at 16:12 -0700, Adam Williamson wrote:
Hey folks - just in case you haven't all figured this out yet, if you're using the neat little trick of putting a few lines in your ~/.bashrc so that when you're in a directory containing a git repo, the prompt will display what branch you're in, it'll stop working when you update to the latest git - 1.7.12 - in F18 or Rawhide. To fix it, you need to change:
source /etc/bash_completion.d/git
to:
source /usr/share/doc/git-1.7.12/contrib/completion/git-prompt.sh
because upstream split the prompt stuff out from the bash_completion script. Perhaps the git packagers could consider providing git-prompt.sh in a more permanent location, so we don't have to poke .bashrc every time the git version changes? Thanks!
This is actually a packaging violation. %doc files are not allowed to impact runtime operation. It would be one thing if this was presented as an example file or template that you were expected to modify and put into the right location on your own.
Realistically, this belongs in %{_datadir} somewhere, not %{doc}
On Thu, Aug 23, 2012 at 12:23:48PM -0400, Stephen Gallagher wrote:
On Wed, 2012-08-22 at 16:12 -0700, Adam Williamson wrote:
because upstream split the prompt stuff out from the bash_completion script. Perhaps the git packagers could consider providing git-prompt.sh in a more permanent location, so we don't have to poke .bashrc every time the git version changes? Thanks!
This is actually a packaging violation. %doc files are not allowed to impact runtime operation. It would be one thing if this was presented as an example file or template that you were expected to modify and put into the right location on your own.
Realistically, this belongs in %{_datadir} somewhere, not %{doc}
The subversion package does this too. I suppose you could argue that some of the files are "examples," but sometimes those "examples" are so complete that they're usable as is (scripts, xslt files, etc).
On Wed, 2012-08-22 at 16:12 -0700, Adam Williamson wrote:
Hey folks - just in case you haven't all figured this out yet, if you're using the neat little trick of putting a few lines in your ~/.bashrc so that when you're in a directory containing a git repo, the prompt will display what branch you're in, it'll stop working when you update to the latest git - 1.7.12 - in F18 or Rawhide. To fix it, you need to change:
source /etc/bash_completion.d/git
to:
source /usr/share/doc/git-1.7.12/contrib/completion/git-prompt.sh
because upstream split the prompt stuff out from the bash_completion script. Perhaps the git packagers could consider providing git-prompt.sh in a more permanent location, so we don't have to poke .bashrc every time the git version changes? Thanks!
Heads up, everyone, it got moved again (from the last location in /etc/profile.d). Stay sharp at all times! Look both ways before crossing the street!
Now you have to do:
source /usr/share/git-core/contrib/completion/git-prompt.sh
-
Adam Williamson -
Dodji Seketeli -
Enrico Scholz -
Garrett Holmstrom -
John Ellson -
Jon Ciesla -
Pádraig Brady -
Scott Schmit -
Stephen Gallagher -
Todd Zullinger -
Ville Skyttä