[ITA] Git et al

classic Classic list List threaded Threaded
38 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[ITA] Git et al

Adam Dinwoodie-2
Our Git package hasn't been updated in a long time. Although its
maintainer, Eric Blake, has been on the mailing lists, I don't think
he's done any work in keeping Git up-to-date (including replying to a
number of requests for updates), so I'd like to offer to take over.

I've just built and packaged the latest released version -- 1.8.5.2 --
and have the packages ready to upload for both x86 and x86_64. I've
incorporated the enhancements Yaakov made for the Cygwin Ports version
(including splitting some of the packages), as well as some minor
fixes to resolve differences between the latest Cygwin Ports version
and the latest upstream.

I'm thus offering to take over the following existing packages:
- git
- git-completion
- git-svn
- gitk

I'll also be adding the following packages, which are split out of the
main git package:
- git-cvs
- git-debuginfo
- git-email
- git-gui
- gitweb

Following http://cygwin.com/setup.html, I've copied the assorted
setup.hint files below and uploaded the packages to
http://tastycake.net/~adam/git. I've uploaded as .xz bundles, on the
grounds that (a) that's what Cygport created, and (b) that's what's
used in the examples at [1]. Let me know if the contribution guide is
still correct and I need to repackage as bzip2 tarballs.

[1]: https://sourceware.org/cygwin-apps/package-upload.html

I've also copied my upload SSH key at the bottom of this email. I've
not included it in a normal upload request email yet, since I'm not
currently maintaining any packages. I'll send it in a separate email
if and when I get approved as maintainer, if necessary.

Adam

git/setup.hint
category: Devel
requires: bash libgcc1 libiconv2 perl perl-Error perl_vendor python
zlib0 cygutils less openssh rsync
sdesc: "Distributed version control system"
ldesc: "Git is a free and open source distributed version control system
designed to handle everything from small to very large projects with speed and
efficiency. Git is easy to learn and has a tiny footprint with lightning fast
performance. It outclasses SCM tools like Subversion, CVS, Perforce, and
ClearCase with features like cheap local branching, convenient staging areas,
and multiple workflows."

git-completion/setup.hint
category: Devel
requires:  bash bash-completion git
sdesc: "Bash completion for Git version control system"
ldesc: "Git is a free and open source distributed version control system
designed to handle everything from small to very large projects with speed and
efficiency. Git is easy to learn and has a tiny footprint with lightning fast
performance. It outclasses SCM tools like Subversion, CVS, Perforce, and
ClearCase with features like cheap local branching, convenient staging areas,
and multiple workflows."
external-source: git

git-cvs/setup.hint
category: Devel
requires: git perl cvsps perl-DBD-SQLite
sdesc: "CVS compatibilty support for Git version control system"
ldesc: "Git is a free and open source distributed version control system
designed to handle everything from small to very large projects with speed and
efficiency. Git is easy to learn and has a tiny footprint with lightning fast
performance. It outclasses SCM tools like Subversion, CVS, Perforce, and
ClearCase with features like cheap local branching, convenient staging areas,
and multiple workflows."
external-source: git

git-debuginfo/setup.hint
category: Debug
requires: cygwin-debuginfo
external-source: git
sdesc: "Debug info for git"
ldesc: "This package contains files necessary for debugging the
git package with gdb."

git-email/setup.hint
category: Devel
requires: git perl perl-Error
sdesc: "Email tools for Git version control system"
ldesc: "Git is a free and open source distributed version control system
designed to handle everything from small to very large projects with speed and
efficiency. Git is easy to learn and has a tiny footprint with lightning fast
performance. It outclasses SCM tools like Subversion, CVS, Perforce, and
ClearCase with features like cheap local branching, convenient staging areas,
and multiple workflows."
external-source: git

git-gui/setup.hint
category: Devel
requires: bash tcl-tk git gitk
sdesc: "Graphical interface for Git version control system"
ldesc: "Git is a free and open source distributed version control system
designed to handle everything from small to very large projects with speed and
efficiency. Git is easy to learn and has a tiny footprint with lightning fast
performance. It outclasses SCM tools like Subversion, CVS, Perforce, and
ClearCase with features like cheap local branching, convenient staging areas,
and multiple workflows."
external-source: git

gitk/setup.hint
category: Devel
requires: bash tcl-tk git
sdesc: "Git repository browser"
ldesc: "Git is a free and open source distributed version control system
designed to handle everything from small to very large projects with speed and
efficiency. Git is easy to learn and has a tiny footprint with lightning fast
performance. It outclasses SCM tools like Subversion, CVS, Perforce, and
ClearCase with features like cheap local branching, convenient staging areas,
and multiple workflows."
external-source: git

git-svn/setup.hint
category: Devel
requires: git perl perl_vendor
sdesc: "Subversion compatibility support for Git version control system"
ldesc: "Git is a free and open source distributed version control system
designed to handle everything from small to very large projects with speed and
efficiency. Git is easy to learn and has a tiny footprint with lightning fast
performance. It outclasses SCM tools like Subversion, CVS, Perforce, and
ClearCase with features like cheap local branching, convenient staging areas,
and multiple workflows."
external-source: git

gitweb/setup.hint
category: Devel
requires: bash perl ruby git lighttpd
sdesc: "Web interface for Git version control system"
ldesc: "Git is a free and open source distributed version control system
designed to handle everything from small to very large projects with speed and
efficiency. Git is easy to learn and has a tiny footprint with lightning fast
performance. It outclasses SCM tools like Subversion, CVS, Perforce, and
ClearCase with features like cheap local branching, convenient staging areas,
and multiple workflows."
external-source: git

Name: Adam Dinwoodie
Package: git
---- BEGIN SSH2 PUBLIC KEY ----
AAAAB3NzaC1yc2EAAAADAQABAAACAQDQWpZlqxcfJ0Ke9XT/NT2WTKN3wLJR516Pg0o3TC
NXdc0VgZpb74vGGHVWm1LPj6+o5LQQ+TqyBwZ3KFpB6hUGwMpmU19/MvtE5cWnfT8gPAv5
h1CIFT0X6+kz9NEemZhJRAXgp65oJUObsb8i+9jl+trr6YNcJUhgLBrTVa25lczNY1c795
3Kj19z8iUSMZ7JIPu45l5YD7Y74hpWjXr1YyJo6D58SLAQ2y27muy0/yH9PNc9YGKuiHv/
mRrZaqLGzxnGoH8asc8NhJrMC55f0gdOkAkn10oVozWPJXg6L6JtXuI6SukEg/M5SpQkTS
I2bJVOleobCzTA0/cFJMeQ67Zul3bubszCPCSzUCO3QClS8YRWvkMrlGDP4/+qW4u8VjCD
/+UB4Wn6f5s/zCcv3ESnvul8N9A4eRcxyY7aom6iYc5YYkd4d9J6j3Sf0S9w7CQau0sAZP
LpJcW6FrmHHXY09hnPE2wz4eERO9BTimp4wb1CJCLFXSqrAQIN09eDncPhHjeqKiODWSaY
nRUsNIV1cXPQLIZuyTmNGc/A1KAypNBSwDGivihACt7fiAA4Qdpn4w7dYrci6TjEmDBx18
xu7UKrW/1XPp8SJFySbrACKHHi017T4BYkgpjMWfTs4w/KyX6VJ1/1kMP5W30Y3IGkGJzh
MiJHJyu/dt408Q==
---- END SSH2 PUBLIC KEY ----
Reply | Threaded
Open this post in threaded view
|

Re: [ITA] Git et al

Adam Dinwoodie-2
On 11 January 2014 20:01, Adam Dinwoodie wrote:
> Following http://cygwin.com/setup.html, I've copied the assorted
> setup.hint files below and uploaded the packages to
> http://tastycake.net/~adam/git.

Correction: http://tastycake.net/~adam/cygwin/
Reply | Threaded
Open this post in threaded view
|

Re: [ITA] Git et al

Corinna Vinschen-2
In reply to this post by Adam Dinwoodie-2
On Jan 11 20:01, Adam Dinwoodie wrote:
> Our Git package hasn't been updated in a long time. Although its
> maintainer, Eric Blake, has been on the mailing lists, I don't think
> he's done any work in keeping Git up-to-date (including replying to a
> number of requests for updates), so I'd like to offer to take over.

Thanks for the offer, but let's wait for Eric.  He seems to be very
busy these days.


Corinna

--
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

attachment0 (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [ITA] Git et al

Eric Blake (cygwin)-2
In reply to this post by Adam Dinwoodie-2
On 01/11/2014 01:01 PM, Adam Dinwoodie wrote:
> Our Git package hasn't been updated in a long time. Although its
> maintainer, Eric Blake, has been on the mailing lists, I don't think
> he's done any work in keeping Git up-to-date (including replying to a
> number of requests for updates), so I'd like to offer to take over.

While I'm not completely gone from cygwin, and while it is unusual for
someone to forcefully take over a package while the current maintainer
is still around, this is one case where I'm willing to give up my
maintainership.  There are some packages I still maintain (like
coreutils) where there are cygwin-specific patches that I want to ensure
still work across multiple cygwin versions and where I still actively
maintain efforts for those projects upstream; but when it comes to git,
I only originally volunteered for maintainer status because it built out
of the box and was needed for my work on upstream coreutils, and I am
not a very active upstream git contributor.  In short, git is a big
enough project and my cygwin time limited enough that I have not been
able to maintain it well, so I hope you can do a better job with keeping
the cygwin port up-to-date.  That said, while I don't have as much time
for cygwin packaging, I still DO plan on using git on cygwin, so I at
least want to make sure my use cases still work when upgrading to the
build you just provided before we actually upload it.

>
> Following http://cygwin.com/setup.html, I've copied the assorted
> setup.hint files below and uploaded the packages to
> http://tastycake.net/~adam/git. I've uploaded as .xz bundles, on the

It may still be a few days before I can test that your new packaging
works for me (I'd welcome a review from anyone else as well), but the
overall idea of adopting the package from me seems reasonable.

I also wonder if you would be willing to adopt asciidoc, as the only
reason I took that package was to build git documentation out-of-the-box
(I have never personally used it except for building git).

--
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


signature.asc (617 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [ITA] Git et al

Adam Dinwoodie-2
On 13 January 2014 21:32, Eric Blake wrote:
> On 01/11/2014 01:01 PM, Adam Dinwoodie wrote:
>> Our Git package hasn't been updated in a long time. Although its
>> maintainer, Eric Blake, has been on the mailing lists, I don't think
>> he's done any work in keeping Git up-to-date (including replying to a
>> number of requests for updates), so I'd like to offer to take over.
>
> While I'm not completely gone from cygwin, and while it is unusual for
> someone to forcefully take over a package while the current maintainer
> is still around,

When I first concocted this plan about six months ago, if memory serves,
you hadn't been active for a while.  You since have, and I should have
asked you before proposing myself.  Even if it works out with everyone
happy, I'm sorry for the rudeness.

> this is one case where I'm willing to give up my maintainership.
> There are some packages I still maintain (like coreutils) where there
> are cygwin-specific patches that I want to ensure still work across
> multiple cygwin versions and where I still actively maintain efforts
> for those projects upstream; but when it comes to git, I only
> originally volunteered for maintainer status because it built out of
> the box and was needed for my work on upstream coreutils, and I am not
> a very active upstream git contributor.

In honesty, I'm not sure how much time I'm going to be able to devote to
contributing upstream.  I've had a bit of a dig in the Git code, but
I've not actively pushed anything upstream yet.

> In short, git is a big enough project and my cygwin time limited
> enough that I have not been able to maintain it well, so I hope you
> can do a better job with keeping the cygwin port up-to-date.  That
> said, while I don't have as much time for cygwin packaging, I still DO
> plan on using git on cygwin, so I at least want to make sure my use
> cases still work when upgrading to the build you just provided before
> we actually upload it.
>
> It may still be a few days before I can test that your new packaging
> works for me (I'd welcome a review from anyone else as well), but the
> overall idea of adopting the package from me seems reasonable.

There's already a known, fairly major problem with my build, reported by
Steven Penny[0].  I'm hoping to get a fix to that out tomorrow evening.

[0]: http://cygwin.com/ml/cygwin/2014-01/msg00086.html

> I also wonder if you would be willing to adopt asciidoc, as the only
> reason I took that package was to build git documentation out-of-the-box
> (I have never personally used it except for building git).

I'd only be using it for Git as well, but assuming it builds
out-of-the-box, I don't see any reason why not.
Reply | Threaded
Open this post in threaded view
|

Re: [ITA] Git et al

Adam Dinwoodie-2
On 13 January 2014 23:58, Adam Dinwoodie wrote:

> On 13 January 2014 21:32, Eric Blake wrote:
>> That said, while I don't have as much time for cygwin packaging, I
>> still DO plan on using git on cygwin, so I at least want to make sure
>> my use cases still work when upgrading to the build you just provided
>> before we actually upload it.
>>
>> It may still be a few days before I can test that your new packaging
>> works for me (I'd welcome a review from anyone else as well), but the
>> overall idea of adopting the package from me seems reasonable.
>
> There's already a known, fairly major problem with my build, reported by
> Steven Penny[0].  I'm hoping to get a fix to that out tomorrow evening.
>
> [0]: http://cygwin.com/ml/cygwin/2014-01/msg00086.html

There's a new build available at http://tastycake.net/~adam/cygwin/
which resolves that issue.  If you want to give it a try and let me know
how you get on, I'd be exceedingly grateful.
Reply | Threaded
Open this post in threaded view
|

Re: [ITA] Git et al

Balaji Venkataraman-2
On Wed, Jan 15, 2014 at 3:06 AM, Adam Dinwoodie wrote:

> There's a new build available at http://tastycake.net/~adam/cygwin/
> which resolves that issue.  If you want to give it a try and let me know
> how you get on, I'd be exceedingly grateful.

I tried to add the path above to the list of mirrors in setup-x86.exe.
Is that how you are expecting folks to get your build? It seemed to
find setup.ini but just hung there for a while after which I gave up.
Not sure if it's a firewall problem on my end (which I doubt - since I
access other Cygwin mirrors routinely from behind the FW) or a server
problem or PEBCAK. Thanks.
Reply | Threaded
Open this post in threaded view
|

Re: [ITA] Git et al

Christopher Faylor-8
On Fri, Jan 17, 2014 at 10:42:52AM -0800, Balaji Venkataraman wrote:

>On Wed, Jan 15, 2014 at 3:06 AM, Adam Dinwoodie wrote:
>>There's a new build available at http://tastycake.net/~adam/cygwin/
>>which resolves that issue.  If you want to give it a try and let me
>>know how you get on, I'd be exceedingly grateful.
>
>I tried to add the path above to the list of mirrors in setup-x86.exe.
>Is that how you are expecting folks to get your build?  It seemed to
>find setup.ini but just hung there for a while after which I gave up.
>Not sure if it's a firewall problem on my end (which I doubt - since I
>access other Cygwin mirrors routinely from behind the FW) or a server
>problem or PEBCAK.  Thanks.

No, that's not intended to be a setup.exe download.

If you don't know what the above link was for then you are not the
target audience for it.

cgf
Reply | Threaded
Open this post in threaded view
|

Re: [ITA] Git et al

Balaji Venkataraman-2
On Fri, Jan 17, 2014 at 10:48 AM, Christopher Faylor wrote:

> On Fri, Jan 17, 2014 at 10:42:52AM -0800, Balaji Venkataraman wrote:
>>On Wed, Jan 15, 2014 at 3:06 AM, Adam Dinwoodie wrote:

> No, that's not intended to be a setup.exe download.

Before I tried using it w/ setup.exe, I did notice that the folders
contain tar files, which I can download and untar but if that was how
one is expected to get it, a direct pointer to the file would have
sufficed. Perhaps that was the intent but I thought I should check if
setup.exe could be used. Thanks for clarifying.
Reply | Threaded
Open this post in threaded view
|

Re: [ITA] Git et al

Eric Blake (cygwin)-2
In reply to this post by Adam Dinwoodie-2
On 01/15/2014 04:06 AM, Adam Dinwoodie wrote:

> On 13 January 2014 23:58, Adam Dinwoodie wrote:
>> On 13 January 2014 21:32, Eric Blake wrote:
>>> That said, while I don't have as much time for cygwin packaging, I
>>> still DO plan on using git on cygwin, so I at least want to make sure
>>> my use cases still work when upgrading to the build you just provided
>>> before we actually upload it.
>>>
>>> It may still be a few days before I can test that your new packaging
>>> works for me (I'd welcome a review from anyone else as well), but the
>>> overall idea of adopting the package from me seems reasonable.
>>
>> There's already a known, fairly major problem with my build, reported by
>> Steven Penny[0].  I'm hoping to get a fix to that out tomorrow evening.
>>
>> [0]: http://cygwin.com/ml/cygwin/2014-01/msg00086.html
>
> There's a new build available at http://tastycake.net/~adam/cygwin/
> which resolves that issue.  If you want to give it a try and let me know
> how you get on, I'd be exceedingly grateful.
I've now had a chance to test this, and at least my use cases worked.  I
can't say I used ALL of git functionality, but what I did use shows that
your build is good.  Let's go ahead and pass the maintainer baton.

--
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


signature.asc (617 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [ITA] Git et al

Adam Dinwoodie-2
On Fri, Jan 24, 2014 at 07:25:32AM -0700, Eric Blake wrote:
> On 01/15/2014 04:06 AM, Adam Dinwoodie wrote:
> > There's a new build available at http://tastycake.net/~adam/cygwin/
> > which resolves that issue.  If you want to give it a try and let me know
> > how you get on, I'd be exceedingly grateful.
>
> I've now had a chance to test this, and at least my use cases worked.  I
> can't say I used ALL of git functionality, but what I did use shows that
> your build is good.  Let's go ahead and pass the maintainer baton.

I have an outstanding issue with the packaging I've just spotted --
git-cvs relies on perl-DBD-SQLite, which doesn't exist.  I suspect this
is a result of taking Yaakov's cygport files.  I've not used Git's CVS
tools before, so it might take me a little while to work out whether the
problems I'm seeing are the result of missing packages, PEBCAK or
something else.

Thinking about it, my build and packages take Yaakov's work over at
Cygwin Ports to split the Git packages (at the moment, git-cvs is part
of the main git package, for example, while my build separates it out).
I know there have been debates about this in the past; is there
currently any guideline about the best way to manage such package
splits?
Reply | Threaded
Open this post in threaded view
|

Re: [ITA] Git et al

Yaakov (Cygwin/X)
On 2014-01-29 05:53, Adam Dinwoodie wrote:
> I have an outstanding issue with the packaging I've just spotted --
> git-cvs relies on perl-DBD-SQLite, which doesn't exist.

More specifically, there has been one for x86_64 since I built
git.x86_64 during the bootstrap, but I see now that I didn't add it for
x86.  I just uploaded an x86 package.

But along these lines, git-email also needs a few Perl modules which are
not yet available for x86; I'll proceed with those as well, hopefully
tonight.

> Thinking about it, my build and packages take Yaakov's work over at
> Cygwin Ports to split the Git packages (at the moment, git-cvs is part
> of the main git package, for example, while my build separates it out).
> I know there have been debates about this in the past; is there
> currently any guideline about the best way to manage such package
> splits?

I'm not sure to what debates you are referring, but the point of the
split was to provide correct dependencies while isolating those to the
components that actually need them.  This was already done with the more
obvious tcl-tk dependency of gitk and git-gui, but my packages took it a
step further.  So, for example, git-svn actually requires
subversion-perl, but subversion is not small and not all git users are
going to want that just in order to use git.


Yaakov

Reply | Threaded
Open this post in threaded view
|

Re: [ITA] Git et al

Adam Dinwoodie-2
On Wed, Jan 29, 2014 at 10:54:27AM -0600, Yaakov (Cygwin/X) wrote:

> On 2014-01-29 05:53, Adam Dinwoodie wrote:
> >Thinking about it, my build and packages take Yaakov's work over at
> >Cygwin Ports to split the Git packages (at the moment, git-cvs is part
> >of the main git package, for example, while my build separates it out).
> >I know there have been debates about this in the past; is there
> >currently any guideline about the best way to manage such package
> >splits?
>
> I'm not sure to what debates you are referring, but the point of the
> split was to provide correct dependencies while isolating those to
> the components that actually need them.  This was already done with
> the more obvious tcl-tk dependency of gitk and git-gui, but my
> packages took it a step further.  So, for example, git-svn actually
> requires subversion-perl, but subversion is not small and not all
> git users are going to want that just in order to use git.

I seem to recall there being some discussion (I can't remember the
specific cases) about whether it would be sensible to have, for at least
the first release after a split, all the new packages depending on the
thinned down base one.

As an example, someone using git-cvs currently would only have the git
package.  If we list git-cvs as a requirement for the new git package,
when they upgrade git they'll automatically get git-cvs and won't lose
any functionality.  The following update can lose the git-cvs
requirement, giving the full advantage of the separated packages.

I think this makes things a bit more user friendly, at least for folk
who need the separated-out packages and who update their Cygwin setup
frequently, at the expense of postponing a lot of the advantage of those
separated out packages.
Reply | Threaded
Open this post in threaded view
|

Re: [ITA] Git et al

ASSI
In reply to this post by Yaakov (Cygwin/X)
Yaakov (Cygwin/X) writes:
> On 2014-01-29 05:53, Adam Dinwoodie wrote:
>> I have an outstanding issue with the packaging I've just spotted --
>> git-cvs relies on perl-DBD-SQLite, which doesn't exist.
>
> More specifically, there has been one for x86_64 since I built
> git.x86_64 during the bootstrap, but I see now that I didn't add it
> for x86.  I just uploaded an x86 package.

Does it use the system SQLite and if so, does it run the tests cleanly?
I'm building that package locally against the installed libraries and
I've been getting "UNIQUE constraint" errors from the test suite since
the 3.8.x version of SQLite has landed.


Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves
Reply | Threaded
Open this post in threaded view
|

Re: [ITA] Git et al

Jan Nijtmans-2
2014-01-29 Achim Gratz <[hidden email]>:
> Does it use the system SQLite and if so, does it run the tests cleanly?
> I'm building that package locally against the installed libraries and
> I've been getting "UNIQUE constraint" errors from the test suite since
> the 3.8.x version of SQLite has landed.

SQLite 3.7.17 is still available, and SQLite 3.8.3
(beta) is available as test package. Especially
3.7.17 is meant to be able to verify such
kinds of possible regressions.

Does this 3.7.17 work well with git? If so, this
looks like a regression which should be
reported to the SQLite developers. If there
is anything I can do to help, let me know.
Version 3.8.3 will come out soon.

Regards,
      Jan Nijtmans
Reply | Threaded
Open this post in threaded view
|

Re: [ITA] Git et al

ASSI
Jan Nijtmans writes:
> Does this 3.7.17 work well with git? If so, this
> looks like a regression which should be
> reported to the SQLite developers. If there
> is anything I can do to help, let me know.
> Version 3.8.3 will come out soon.

I haven't had time yet to look into what the test error with DBD::SQLite
really is.  It could be some feature that used to be enabled by default
but now isn't (or the other way around) or just that an error message
expected by the test is formatted differently.  I started building the
module against the system library rather than the included (older)
SQLite amalgamation due to the well known locking problems when
interacting with concurrent access to the same database.

As for git, I don't use git-cvs so it's hard to tell if those test
errors translate into any problem at all.


Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra
Reply | Threaded
Open this post in threaded view
|

Re: [ITA] Git et al

Yaakov (Cygwin/X)
In reply to this post by Adam Dinwoodie-2
On 2014-01-29 11:07, Adam Dinwoodie wrote:

> I seem to recall there being some discussion (I can't remember the
> specific cases) about whether it would be sensible to have, for at least
> the first release after a split, all the new packages depending on the
> thinned down base one.
>
> As an example, someone using git-cvs currently would only have the git
> package.  If we list git-cvs as a requirement for the new git package,
> when they upgrade git they'll automatically get git-cvs and won't lose
> any functionality.  The following update can lose the git-cvs
> requirement, giving the full advantage of the separated packages.

That's what announcements are for, and for those who don't read them,
postponing the change isn't going to help.


Yaakov

Reply | Threaded
Open this post in threaded view
|

Re: [ITA] Git et al

Yaakov Selkowitz
In reply to this post by Adam Dinwoodie-2
On 2014-01-11 14:01, Adam Dinwoodie wrote:
> Our Git package hasn't been updated in a long time. Although its
> maintainer, Eric Blake, has been on the mailing lists, I don't think
> he's done any work in keeping Git up-to-date (including replying to a
> number of requests for updates), so I'd like to offer to take over.

I haven't seen any progress on this for some time.  Adam, are you still
working on this, and if so, what issues still remain?


Yaakov

Reply | Threaded
Open this post in threaded view
|

Re: [ITA] Git et al

Adam Dinwoodie-2
On Tue, Jun 10, 2014 at 05:00:00PM -0500, Yaakov Selkowitz wrote:
> On 2014-01-11 14:01, Adam Dinwoodie wrote:
> >Our Git package hasn't been updated in a long time. Although its
> >maintainer, Eric Blake, has been on the mailing lists, I don't think
> >he's done any work in keeping Git up-to-date (including replying to a
> >number of requests for updates), so I'd like to offer to take over.
>
> I haven't seen any progress on this for some time.  Adam, are you
> still working on this, and if so, what issues still remain?

In theory I'm still working on this; in practice I haven't had time to
devote to it in a while.  I'd (perhaps naively) assumed it would mostly
Just Work(TM), which turned out not to be the case.

The only outstanding issue with my build is that git-cvs wasn't working.
That seemed to be down to my build environment, as my attempts to build
the source code available via the Cygwin mirrors showed the same
behaviour, but those binaries work as expected.

I'm considering this a deal breaker since the official way to get the
current Cygwin source code is via CVS.  If I hadn't fixed it by the time
the Cygwin source moves to Git, I was going to suggest moving to the
up-to-date Git build (or more likely, a fresh build of the latest and
greatest upstream version) and accepting that while git-cvs wouldn't
work, that would no longer affect a significant proportion of people.
Reply | Threaded
Open this post in threaded view
|

Re: [ITA] Git et al

ASSI
Adam Dinwoodie writes:
> The only outstanding issue with my build is that git-cvs wasn't working.
> That seemed to be down to my build environment, as my attempts to build
> the source code available via the Cygwin mirrors showed the same
> behaviour, but those binaries work as expected.

What's the version of cvsimport you've got installed?  Git needs 2.x.

> I'm considering this a deal breaker since the official way to get the
> current Cygwin source code is via CVS.  If I hadn't fixed it by the time
> the Cygwin source moves to Git, I was going to suggest moving to the
> up-to-date Git build (or more likely, a fresh build of the latest and
> greatest upstream version) and accepting that while git-cvs wouldn't
> work, that would no longer affect a significant proportion of people.

Where's the cygport file for that?


Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs
12