10:16 p.m.
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
10:19 p.m.
On Mon, Oct 26, 2009 at 10:16 PM, Michael Stahnke <mastahnke(a)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.
--
Jeff Ollie
1:56 a.m.
On Tuesday 27 October 2009, Jeffrey Ollie wrote:
On Mon, Oct 26, 2009 at 10:16 PM, Michael Stahnke
<mastahnke(a)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).
9:31 a.m.
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(a)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.
10:03 a.m.
On Mon, Oct 26, 2009 at 9:16 PM, Michael Stahnke <mastahnke(a)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.
--
Stephen J Smoogen.
Ah, but a man's reach should exceed his grasp. Or what's a heaven for?
-- Robert Browning
12:55 p.m.
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.)
10:16 a.m.
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.
10:30 a.m.
If we're going to violate policy, why exactly do we have one to begin with?
-Adam
--
http://maxamillion.googlepages.com
---------------------------------------------------------
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
12:31 p.m.
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.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
10:55 p.m.
On Wed, Oct 28, 2009 at 12:31 PM, Jesse Keating <jkeating(a)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
--
http://maxamillion.googlepages.com
---------------------------------------------------------
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
10:28 a.m.
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(a)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
--
A: No.
Q: Should I include quotations after my reply?
Don't top post: see http://www.caliburn.nl/topposting.html for more.
9:12 a.m.
Did this upgrade ever happen? I know a few units within my $DAYJOB
would like to see an update.
stahnma
12:18 p.m.
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(a)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
12:54 p.m.
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/
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If the triangles were to make a God they would give him three sides.
-- Montesquieu
2:29 p.m.
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 ;).
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Just because you've always done it that way doesn't mean it's not
incredibly stupid.
-- Demotivators (www.despair.com)
4:25 p.m.
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
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
4:40 p.m.
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.
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
No sense being pessimistic, it probably wouldn't work anyway
4:54 p.m.
On Wed, Aug 25, 2010 at 15:40, Todd Zullinger <tmz(a)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.
--
Stephen J Smoogen.
“The core skill of innovators is error recovery, not failure avoidance.”
Randy Nelson, President of Pixar University.
"We have a strategic plan. It's called doing things.""
— Herb Kelleher, founder Southwest Airlines
12:18 a.m.
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
8:55 a.m.
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.
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I have never let my schooling interfere with my education.
-- Mark Twain (1835-1910)
9:52 a.m.
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
3:08 p.m.
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. :)
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Whenever I feel blue, I start breathing again.
9:55 a.m.
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(a)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.
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
It was such a lovely day, I thought it a pity to get up.
-- W. Somerset Maugham
4820
days inactive
5295
days old
epel-devel@lists.fedoraproject.org
22 comments
11 participants
participants (11)
-
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ä