After some discussion in IRC (Fedora-admin) we are wondering if pushing a new git in EPEL is a good idea. There are some changes such as git-command vs git command. So there could be some breakage.
Should we push a new git and cause some breakage or stick with old-n-busted?
My thoughts are to push out a new one, since I think if you are using git, you curse everytime you touch this old crusty thing :)
stahnma
On Mon, Oct 26, 2009 at 10:16 PM, Michael Stahnke mastahnke@gmail.com wrote:
After some discussion in IRC (Fedora-admin) we are wondering if pushing a new git in EPEL is a good idea. There are some changes such as git-command vs git command. So there could be some breakage.
Should we push a new git and cause some breakage or stick with old-n-busted?
My thoughts are to push out a new one, since I think if you are using git, you curse everytime you touch this old crusty thing :)
I personally would say yes. While scripts may break, the repositories will be fine.
On Tuesday 27 October 2009, Jeffrey Ollie wrote:
On Mon, Oct 26, 2009 at 10:16 PM, Michael Stahnke mastahnke@gmail.com
wrote:
After some discussion in IRC (Fedora-admin) we are wondering if pushing a new git in EPEL is a good idea. There are some changes such as git-command vs git command. So there could be some breakage.
Should we push a new git and cause some breakage or stick with old-n-busted?
My thoughts are to push out a new one, since I think if you are using git, you curse everytime you touch this old crusty thing :)
I personally would say yes. While scripts may break, the repositories will be fine.
If "git command" vs "git-command" is the only incompatibility, it should be trivial to provide the latter in the package with tiny wrapper scripts or even just one that parses $0 and add symlink to it for each needed command, or install that script multiple times with different names and hardlink them if wanted, or... (see for example rpmdev-md5, rpmdev-sha* and friends in rpmdevtools).
On Tue, 2009-10-27 at 09:56 +0300, Ville Skyttä wrote:
On Tuesday 27 October 2009, Jeffrey Ollie wrote:
On Mon, Oct 26, 2009 at 10:16 PM, Michael Stahnke mastahnke@gmail.com
wrote:
After some discussion in IRC (Fedora-admin) we are wondering if pushing a new git in EPEL is a good idea. There are some changes such as git-command vs git command. So there could be some breakage.
Should we push a new git and cause some breakage or stick with old-n-busted?
My thoughts are to push out a new one, since I think if you are using git, you curse everytime you touch this old crusty thing :)
I personally would say yes. While scripts may break, the repositories will be fine.
If "git command" vs "git-command" is the only incompatibility, it should be trivial to provide the latter in the package with tiny wrapper scripts or even just one that parses $0 and add symlink to it for each needed command, or install that script multiple times with different names and hardlink them if wanted, or... (see for example rpmdev-md5, rpmdev-sha* and friends in rpmdevtools).
No problem, I build a package from the last SRPM at git-scm.com and all are in /usr/libexec/git-core. You only need to append it to $PATH if you you prefer the old mode.
Saudos.
On Tuesday 27 October 2009, Benito Mourelo Caldeiro wrote:
On Tue, 2009-10-27 at 09:56 +0300, Ville Skyttä wrote:
If "git command" vs "git-command" is the only incompatibility, it should be trivial to provide the latter in the package with tiny wrapper scripts or even just one that parses $0 and add symlink to it for each needed command, or install that script multiple times with different names and hardlink them if wanted, or... (see for example rpmdev-md5, rpmdev-sha* and friends in rpmdevtools).
No problem, I build a package from the last SRPM at git-scm.com and all are in /usr/libexec/git-core. You only need to append it to $PATH if you you prefer the old mode.
Well, if one needs to do that manually, it's not backwards compatible. And even adding a new dir to $PATH wouldn't help scripts that use absolute paths pointing to the old location of the tools.
(I don't have an opinion whether to update git in EPEL or not.)
On Tue, 2009-10-27 at 19:55 +0200, Ville Skyttä wrote:
On Tuesday 27 October 2009, Benito Mourelo Caldeiro wrote:
On Tue, 2009-10-27 at 09:56 +0300, Ville Skyttä wrote:
If "git command" vs "git-command" is the only incompatibility, it should be trivial to provide the latter in the package with tiny wrapper scripts or even just one that parses $0 and add symlink to it for each needed command, or install that script multiple times with different names and hardlink them if wanted, or... (see for example rpmdev-md5, rpmdev-sha* and friends in rpmdevtools).
No problem, I build a package from the last SRPM at git-scm.com and all are in /usr/libexec/git-core. You only need to append it to $PATH if you you prefer the old mode.
Well, if one needs to do that manually, it's not backwards compatible. And even adding a new dir to $PATH wouldn't help scripts that use absolute paths pointing to the old location of the tools.
(I don't have an opinion whether to update git in EPEL or not.)
Ok.
One solution could be use update-alternatives for old git-* commands (they are 141 !).
Saudos.
If we're going to violate policy, why exactly do we have one to begin with?
-Adam
On Wed, 2009-10-28 at 10:30 -0500, Adam Miller wrote:
If we're going to violate policy, why exactly do we have one to begin with?
Would it really be a policy break if the old command paths were retained? AFAIK the removal of the git-* commands from /usr/bin was the only real 'break' between the versions, and if those are retained than it should be an acceptable upgrade.
On Wed, Oct 28, 2009 at 12:31 PM, Jesse Keating jkeating@redhat.com wrote: <snip>
Would it really be a policy break if the old command paths were retained? AFAIK the removal of the git-* commands from /usr/bin was the only real 'break' between the versions, and if those are retained than it should be an acceptable upgrade.
<snip>
Yes, that was the only real 'break' and from what I understood that was the issue which would cause breakage and making it a violation of policy. But as it seems to be the case with later posts in the thread that issue has been resolved as per a slight modification to the .spec file for the EL branch and after that I do agree that it is an acceptable upgrade.
-Adam
On Mon, Oct 26, 2009 at 9:16 PM, Michael Stahnke mastahnke@gmail.com wrote:
After some discussion in IRC (Fedora-admin) we are wondering if pushing a new git in EPEL is a good idea. There are some changes such as git-command vs git command. So there could be some breakage.
Should we push a new git and cause some breakage or stick with old-n-busted?
My thoughts are to push out a new one, since I think if you are using git, you curse everytime you touch this old crusty thing :)
Can the differences be papered over with a script? I would prefer to have the commands act appropriately versus dealing with broken scripts that people did not think would occur.
On 10/26/2009 11:16 PM, Michael Stahnke wrote:
After some discussion in IRC (Fedora-admin) we are wondering if pushing a new git in EPEL is a good idea. There are some changes such as git-command vs git command. So there could be some breakage.
Should we push a new git and cause some breakage or stick with old-n-busted?
My thoughts are to push out a new one, since I think if you are using git, you curse everytime you touch this old crusty thing :)
stahnma
epel-devel-list mailing list epel-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list
Has anything happened with this? It sounds like there is approval as long as we provide the previous commands as symlinks to their new locations.
-josh
Did this upgrade ever happen? I know a few units within my $DAYJOB would like to see an update.
stahnma
On 05/26/2010 10:12 AM, Michael Stahnke wrote:
Did this upgrade ever happen? I know a few units within my $DAYJOB would like to see an update.
stahnma
epel-devel-list mailing list epel-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list
The maintainers were waiting to see what would happen with RHEL6 and git. RHEL6 Beta 1 shipped with git 1.6.X but git 1.7.X was recently released so we were trying to get RHEL6 upgraded to git 1.7.X. We didn't want to provide a newer package in EPEL5 than that in RHEL6 but as of today they RHEL6 will include git-1.7.1.
tmz has a testing repo set up that has a build of git 1.7 if anyone wants to give it a try.
http://tmz.fedorapeople.org/packages/epel/5/
I'll let tmz add comments, I'm just bumping to help out.
-josh
Josh Kayse wrote:
The maintainers were waiting to see what would happen with RHEL6 and git. RHEL6 Beta 1 shipped with git 1.6.X but git 1.7.X was recently released so we were trying to get RHEL6 upgraded to git 1.7.X. We didn't want to provide a newer package in EPEL5 than that in RHEL6 but as of today they RHEL6 will include git-1.7.1.
tmz has a testing repo set up that has a build of git 1.7 if anyone wants to give it a try.
http://tmz.fedorapeople.org/packages/epel/5/
I'll let tmz add comments, I'm just bumping to help out.
So just to rehash things a little, this was first discussed around the time git-1.6.5 was current¹ and after things were clarified a bit the consensus seemed to be that updating git would be reasonable, provided that we kept the git-* commands in %{_bindir} rather than moving them to %{_libexecdir}/git-core as we've done in newer Fedora releases.
Since then, 1.7 has been released and provides a number of other compelling improvements and bug fixes². I believe one of the only changes that could bite a very small number of people is that pushing to a non-bare repository is now denied by default (but the error given points at how to configure the repository to allow the action).
I don't think this change will cause anyone serious trouble, certainly less trouble than pushing to a non-bare repository would. This change was made upstream in part because it was a constant source of confusion and issues for new git users who did not understand why pushing to a non-bare repository often did not work as they intended.
Before building this for epel-testing, I'd like to ask if anyone interested in git can give the packages in the repo quoted above a try and let me know if there are any changes or gotchas which would require us to make changes to the packaging for EL-5 or prevent us from pushing this update to EPEL proper.
Git has many parts, of which I only make use of a few on a regular basis. So extra eyes on the various sub-packages and other lesser used bits would be very welcome.
¹ http://www.redhat.com/archives/epel-devel-list/2009-October/msg00051.html ² http://www.kernel.org/pub/software/scm/git/docs/
I wrote:
Git has many parts, of which I only make use of a few on a regular basis. So extra eyes on the various sub-packages and other lesser used bits would be very welcome.
Thanks to Josh for doing some testing and finding a few issues with the previous packages. Unfortunately, I ran into a bit of a snag today. Newer git requires emacs >= 22.2 for the emacs-git subpackage.
Is anyone a user of that subpackage that could help test a few possible solutions to get an updated git into EL-5 without breaking the emacs support (which obviously isn't an option, put the pitchforks down, you emacs-haters ;).
On 06/22/2010 01:29 PM, Todd Zullinger wrote:
I wrote:
Git has many parts, of which I only make use of a few on a regular basis. So extra eyes on the various sub-packages and other lesser used bits would be very welcome.
Thanks to Josh for doing some testing and finding a few issues with the previous packages. Unfortunately, I ran into a bit of a snag today. Newer git requires emacs>= 22.2 for the emacs-git subpackage.
Is anyone a user of that subpackage that could help test a few possible solutions to get an updated git into EL-5 without breaking the emacs support (which obviously isn't an option, put the pitchforks down, you emacs-haters ;).
Any more progress on this? At what point dit the emacs >= 22.2 requirement come it? Can we still go to a 1.6.X release?
I'd like to see gitolite in EL-5 but the latest there appears to require git 1.6.4 or greater.
Orion Poplawski wrote:
Any more progress on this?
Sorry, I've not had any time for it. And it seems that no one from else uses emacs or cares about an updated git enough. I'm not an emacs user, so to test this I'd need to learn enough about emacs and vcs integration to be able to ensure I don't break things with an update. Not exactly my idea of something to do for fun. :)
At what point dit the emacs >= 22.2 requirement come it?
It was git-1.6.2 that vc-git.elc was removed from git. It's unclear to me from the commit message where the change was made whether the file was long obsolete and out of date before that or not though. the upstream commit is 7851386.
Can we still go to a 1.6.X release?
I've no interest in spending the time to update from one unsupported release to another, personally. If others are interested enough, feel free. Though if there's interest, it would be best spent looking at what needs to happen to support the older emacs on EL-5 with current git. It may well be as simple as grabbing the vc-git.elc from older git releases or from newer emacs. Any git emacs users care to lend a hand there?
I'd like to see gitolite in EL-5 but the latest there appears to require git 1.6.4 or greater.
So, you'd still have the issue of vc-git.elc being removed then.
On Wed, Aug 25, 2010 at 15:40, Todd Zullinger tmz@pobox.com wrote:
Orion Poplawski wrote:
Any more progress on this?
Sorry, I've not had any time for it. And it seems that no one from else uses emacs or cares about an updated git enough. I'm not an emacs user, so to test this I'd need to learn enough about emacs and vcs integration to be able to ensure I don't break things with an update. Not exactly my idea of something to do for fun. :)
I am an emacs user but not much of a git user (or a hardcore enough emacs user to use vcs in it.) The changes between emacs in EL-5 and 22.2 is HUGE. I am not sure how much a backport would be possible. A emacs22 would probably need to be done.
On Wed, 25 Aug 2010, Stephen John Smoogen wrote:
I am an emacs user but not much of a git user (or a hardcore enough emacs user to use vcs in it.) The changes between emacs in EL-5 and 22.2 is HUGE. I am not sure how much a backport would be possible. A emacs22 would probably need to be done.
ehh? What is the issue against not carrying a local fork, and just dropping in the upstream? It seems to tolerate the EL 5 emacs just fine [/me forgets if I needed to add leaf node build tools, but it looks like all I had to carry to build it were: asciidoc, cvsps, tla, and perhaps subversion to complete the dependency chain; I dont have a README in the deployment directory, so I assume the build was uneventful]
It appears the F 'git-1.7.2.1-1.fc11.src.rpm' also built in my modified CentoS 5 environment
smooge -- please ping me tomorrow in IRC on this -- R
[herrold@freeswitch ~]$ rpm -qi git Name : git Relocations: (not relocatable) Version : 1.7.1 Vendor: orc Release : 4orc Build Date: Tue 10 Aug 2010 09:45:46 AM EDT Install Date: Wed 18 Aug 2010 02:52:18 PM EDT Build Host: elided Group : Development/Tools Source RPM: git-1.7.1-4orc.src.rpm Size : 12090578 License: GPL URL : http://git-scm.com/ Summary : Git core and tools Description : ... [herrold@freeswitch ~]$ rpm -q emacs emacs-21.4-20.el5 [herrold@freeswitch ~]$
-- Russ herrold
R P Herrold wrote:
[herrold@freeswitch ~]$ rpm -qi git Name : git Relocations: (not relocatable) Version : 1.7.1 Vendor: orc Release : 4orc Build Date: Tue 10 Aug 2010 09:45:46 AM EDT Install Date: Wed 18 Aug 2010 02:52:18 PM EDT Build Host: elided Group : Development/Tools Source RPM: git-1.7.1-4orc.src.rpm Size : 12090578 License: GPL URL : http://git-scm.com/ Summary : Git core and tools Description : ... [herrold@freeswitch ~]$ rpm -q emacs emacs-21.4-20.el5 [herrold@freeswitch ~]$
Do you have the emacs-git package installed? And do you use the emacs git integration? That's the part that needs some love, as upstream git now rely's on the files shipped as part of emacs >= 22.2.
Just building and using git-1.7.x on EL-5 is no problem. I've been happily rebuilding the EPEL packages for ages. But then, I didn't miss the emacs support.
An emacs user who can help us find and test a good solution is what we need. The RPMForge folks have added a git-init.el to the packages they provide (which look an awful lot like the EPEL packages ;). What I don't understand is how that solves the issue of git not shipping an vcs-git.el anymore. Sadly, the rpmforge package changelog and svn log are silent on the matter.
On Thu, 26 Aug 2010, Todd Zullinger wrote:
Do you have the emacs-git package installed? And do you use the emacs git integration? That's the part that needs some love, as upstream git now rely's on the files shipped as part of emacs >= 22.2.
nope -- using one operating iscomplex enough for me ;)
An emacs user who can help us find and test a good solution is what we need.
* nod * thus my poke to smooge, as to some testing
-- Russ herrold
R P Herrold wrote:
Do you have the emacs-git package installed? And do you use the emacs git integration? That's the part that needs some love, as upstream git now rely's on the files shipped as part of emacs >= 22.2.
nope -- using one operating iscomplex enough for me ;)
Haha, I completely understand.
An emacs user who can help us find and test a good solution is what we need.
- nod * thus my poke to smooge, as to some testing
I did notice since I posted the other day that it's not git-init.el that's different between us and RPMForge. The trouble is in the lack of a vc-git.el script in newer upstream releases. The RPM Forge packages don't do anything about this, so I would presume that they either haven't noticed the change or don't care enough about emacs support to let it hold up a nice git update (which I can understand).
If there are as many emacs-git users of the RPM Forge packages as there are of the EPEL packages, I can see how simply dropping that functionality could easily go unnoticed. :)
Bring back an old thread, I'm happy to say that I believe the last hurdle for an updated git (emacs support) has been crossed. I am very thankful to Kevin Fenzi for admitting to a past emacs habit and for using it to test the vc-git support in 1.5.5.6 and in some updated packages of 1.7.4. With that help, I've update git in rawhide and plan to merge those changes to the el5 branch very soon.
I've prepared a message to epel-announce as a heads up for this update, even though I suspect it should not cause any issues for users. Any suggestions on improving it would be most welcome. Here's what I've got:
To: epel-announce@lists.fedoraproject.org Subject: Updated git-1.7.4.1 heading to EL-5
As many folks have lamented, the current git-1.5.5.6 in EL-5 is quite a bit stale. Updating it has been discussed on several occassions, but was held up until recently due to compatibility issues with the emacs-git package. With great thanks to Kevin Fenzi for dusting off an old emacs habit, that is now resolved and git-1.7.4.1 is heading to epel-testing very soon.
The update should be a welcome enhancement and not cause current users any trouble.
Since 1.5.5.6 there have been a huge amount of bug fixes and improvements in all areas of git. Of particular interest are the release notes from 1.6.0 and 1.7.0:
http://www.kernel.org/pub/software/scm/git/docs/RelNotes/1.6.0.txt http://www.kernel.org/pub/software/scm/git/docs/RelNotes/1.7.0.txt
Links to release notes for each version of git can be found here:
http://www.kernel.org/pub/software/scm/git/docs/git.html
In git-1.6.0, most git-* commands were moved out of the standard path. Use of "git $command" is preferred. It is a very good idea to migrate scripts to use the dashless form. However, to retain compatibility the EL-5 packages keep the git-* commands in /usr/bin.
Other noteworthy changes since 1.5.5.6:
* "git push" into a branch that is currently checked out (i.e. pointed at by HEAD in a repository that is not bare) is refused by default.
Similarly, "git push $there :$killed" to delete the branch $killed in a remote repository $there, when $killed branch is the current branch pointed at by its HEAD, will be refused by default.
Setting the configuration variables receive.denyCurrentBranch and receive.denyDeleteCurrent to 'ignore' in the receiving repository can be used to override these safety features.
* "git send-email" does not make deep threads by default when sending a patch series with more than two messages. All messages will be sent as a reply to the first message, i.e. cover letter.
It has been possible already to configure send-email to send "shallow thread" by setting sendemail.chainreplyto configuration variable to false. The only thing this release does is to change the default when you haven't configured that variable.
* "git status" will not be "git commit --dry-run". This change does not affect you if you run the command without pathspec.
Nobody sane found the current behaviour of "git status Makefile" useful nor meaningful, and it confused users. "git commit --dry-run" has been provided as a way to get the current behaviour of this command since 1.6.5.
For folks using git over HTTP, git now supports a 'smart' HTTP protocol which is much more efficient than the older ('dumb') HTTP protocol. Refer to the git http-backend documentation for more details:
http://www.kernel.org/pub/software/scm/git/docs/git-http-backend.html
Thanks to all the folks who have helped test the updated git packages on EL-5 and reported issues.
epel-devel@lists.fedoraproject.org
-
Adam Miller -
Benito Mourelo Caldeiro -
Jeffrey Ollie -
Jesse Keating -
Josh Kayse -
Michael Stahnke -
Orion Poplawski -
R P Herrold -
Stephen John Smoogen -
Todd Zullinger -
Ville Skyttä