Re: Rebase of the pr-msvc-support branch?
Den 2009-01-09 14:23 skrev Eric Blake: According to Peter Rosin on 1/9/2009 3:11 AM: I don't have gnulib-tool, which is mentioned in that file, how do I get hold of that tool (for cygwin)? Here's how to get a shallow gnulib clone, then build git-merge-changelog: *snip* Great, thanks, works like a charm! Hmm, is it allowed for ChangeLog entries to not be in chronological order? Or should I redate them when I rebase? That point is a bit fuzzy; personally, I'm okay with preserving the date that a patch was written, but ordering the changelog in the order patches were applied (so dates are out of order), but rewriting the entries to have the date of the merge is also probably acceptable. Ok, went with keeping the dates the patches were applied to the old branch. I'm doing the rebase now, thanks for the help. Cheers, Peter
Re: Rebase of the pr-msvc-support branch?
Hello Markus, * Duft Markus wrote on Mon, Jan 12, 2009 at 08:29:48AM CET: Maybe on windows, we should recommend using interix? You can't be serious, on a GNU mailing list, suggesting that we recommend a proprietary system over a free one. http://www.gnu.org/prep/maintain/html_node/Ethical-and-Philosophical-Consideration.html As to your your praise of autotools with parity, it'd be good to have actual data (on Cygwin or MinGW, of course) of the overhead. That helps us see if we're improving, and how far we have yet to go. And as to an unstable impression of Cygwin, I suggest you file bug reports about problems with the Cygwin people. If you don't understand the above points, then I think you are going a bit overboard in promoting parity on interix on these mailing lists. Cheers, Ralf
Re: Rebase of the pr-msvc-support branch?
Den 2009-01-09 03:58 skrev Eric Blake: Check out Bruno Haible's git-merge-changelog, currently in the gnulib repository. It handles rebasing/merging of ChangeLog entries with minimal I don't have gnulib-tool, which is mentioned in that file, how do I get hold of that tool (for cygwin)? hassle, reducing the risk of a ChangeLog merge interfering with your rebase from 100% down to about 2%. Hmm, is it allowed for ChangeLog entries to not be in chronological order? Or should I redate them when I rebase? Den 2009-01-09 08:24 skrev Ralf Wildenhues: * Bob Friesenhahn wrote on Thu, Jan 08, 2009 at 09:17:37PM CET: so that we can bite the bullet and integrate your branch into mainline. Go ahead, make my day!!! :-) Agreed, too. Them bullets sure taste rather bitter, though. ;-) Can someone pour me a pint of bitter, please? ;-) Cheers, Peter
Re: Rebase of the pr-msvc-support branch?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Peter Rosin on 1/9/2009 3:11 AM: Den 2009-01-09 03:58 skrev Eric Blake: Check out Bruno Haible's git-merge-changelog, currently in the gnulib repository. It handles rebasing/merging of ChangeLog entries with minimal I don't have gnulib-tool, which is mentioned in that file, how do I get hold of that tool (for cygwin)? Here's how to get a shallow gnulib clone, then build git-merge-changelog: $ git clone --depth=1 git://git.sv.gnu.org/gnulib.git $ gnulib/gnulib-tool --create-testdir --dir=/tmp/testdir123 \ git-merge-changelog $ cd /tmp/testdir123 $ ./configure $ make $ make install (optionally you can check out all of gnulib, by removing --depth) you also have to modify .git/config (or ~/.gitconfig) to install git-merge-changelog as your merge handler for changelogs. Hmm, is it allowed for ChangeLog entries to not be in chronological order? Or should I redate them when I rebase? That point is a bit fuzzy; personally, I'm okay with preserving the date that a patch was written, but ordering the changelog in the order patches were applied (so dates are out of order), but rewriting the entries to have the date of the merge is also probably acceptable. - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAklnT7UACgkQ84KuGfSFAYCSigCeNKGQkS0swWILxvaxBkxi8ncD MnQAoLvZpKHnwFCeTtjjPDWFMtkHiEuD =+iQk -END PGP SIGNATURE-
Re: Rebase of the pr-msvc-support branch?
On Fri, 9 Jan 2009, Ralf Wildenhues wrote: Agreed, too; 2.2.8 soon would be good. A couple of small issues need looking at (esp. the aclocal.m4 messup reported by Akim). Any volunteers for the release? so that we can bite the bullet and integrate your branch into mainline. Agreed, too. Them bullets sure taste rather bitter, though. ;-) Those of us who have been targeting Windows for many years have bitten many bitter bullets. There is little doubt that my anticipated lifespan has already been reduced due to intense frustration associated with Windows. It will solve a lot of problems if autotools can be used to build real Windows programs. Bob == Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: Rebase of the pr-msvc-support branch?
* Bob Friesenhahn wrote on Fri, Jan 09, 2009 at 06:37:18PM CET: It will solve a lot of problems if autotools can be used to build real Windows programs. Yes, but we need to address the efficiency issue. For example, http://www.open-mpi.org/community/lists/devel/2008/11/4959.php dropped the cccl idea due to the slowness. Now, with a binary wrapper things may be a bit better, still, faster fork would probably help loads for autotools on w32. Cheers, Ralf
Rebase of the pr-msvc-support branch?
Hi! I'm wondering how to proceed; some of the patches in the pr-msvc-support branch no longer apply cleanly to git-head. So, before things get totally out of hand, I would like to rebase the branch. However, I have never rebased anything before. I could probably rebase my own repo, but I don't know how to push that rebase to the repo on savannah. man git-rebase only talks about rebasing a local repo, and there are big fat warnings about rebasing when you are collaborating with others... Should I kill the branch on savannah, rebase my local tree and finally push a brand new pr-msvc-support branch? Should I create a new topic branch named pr-msvc-support2? Should I merge git-head into the branch? That sure feels backwards, but what do I know? Please help. I have exported 22 patches from my git repo (three or four are not yet pushed to the savannah repo) and have modified those that need modification so that they apply cleanly to git-head, so I know exactly what needs to be done. At least I think I do, I haven't tested the result yet... BTW, I think some of those patches have merit on their own and could probably be cherry-picked into git-head, if someone cares enough. One final minor question, should we skip the patches to ChangeLog in the branch and recreate that part of the patches when/if the branch is merged? It seems that there is approximately 100% risk for the ChangeLog hunk to cause merge problems. Cheers, Peter
Re: Rebase of the pr-msvc-support branch?
Someone needs to cut the next libtool so that we can bite the bullet and integrate your branch into mainline. Bob == Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: Rebase of the pr-msvc-support branch?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Peter Rosin on 1/8/2009 12:43 PM: Should I kill the branch on savannah, rebase my local tree and finally push a brand new pr-msvc-support branch? Should I create a new topic branch named pr-msvc-support2? Should I merge git-head into the branch? That sure feels backwards, but what do I know? Please help. Now that you've told us the branch will be rebased, it makes sense to just keep the same branch name, rebase locally, then push that rebased branch in place of the current one. Rebasing topic branches is acceptable with advance warning, and as long as we don't rebase the master branch. One final minor question, should we skip the patches to ChangeLog in the branch and recreate that part of the patches when/if the branch is merged? It seems that there is approximately 100% risk for the ChangeLog hunk to cause merge problems. Check out Bruno Haible's git-merge-changelog, currently in the gnulib repository. It handles rebasing/merging of ChangeLog entries with minimal hassle, reducing the risk of a ChangeLog merge interfering with your rebase from 100% down to about 2%. - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAklmvVwACgkQ84KuGfSFAYBDnACeNFJnSH1GEGIwAWt0h1JfXfMJ vY8AniR9sshdBEkqEvCupRchs18Kf38J =jvW4 -END PGP SIGNATURE-
Re: Rebase of the pr-msvc-support branch?
Peter Rosin p...@lysator.liu.se writes: Should I kill the branch on savannah, rebase my local tree and finally push a brand new pr-msvc-support branch? Should I create a new topic branch named pr-msvc-support2? Should I merge git-head into the branch? That sure feels backwards, but what do I know? Please help. As a practical matter, I've found that Git at Savannah is configured to prevent updating a branch other than through a fast forward, even if you use the + syntax on git-push. That means that pushing a rebased version of a branch won't work. If the libtool Git is set up that way, you can work around the problem by first deleting the branch, then creating a new branch with the same name as the old one with the rebased content, e.g. git push origin :pr-msvc-support # Delete branch. git push origin HEAD:pr-msvc-support # Recreate branch. -- Ben Pfaff http://benpfaff.org
Re: Rebase of the pr-msvc-support branch?
* Eric Blake wrote on Fri, Jan 09, 2009 at 03:58:36AM CET: According to Peter Rosin on 1/8/2009 12:43 PM: Should I kill the branch on savannah, rebase my local tree and finally push a brand new pr-msvc-support branch? Now that you've told us the branch will be rebased, it makes sense to just keep the same branch name, rebase locally, then push that rebased branch in place of the current one. Rebasing topic branches is acceptable with advance warning, and as long as we don't rebase the master branch. Agreed. I've also thought of just merging master into the branch, but I'm still not quite proficient enough in git to judge how that will make later merging/cherry-picking into master easier or harder. I guess that merging into the branch now is probably made harder by the fact that we've cherry-picked from the branch into master? Anyway, if you want to rebase, fine with me. * Bob Friesenhahn wrote on Thu, Jan 08, 2009 at 09:17:37PM CET: Someone needs to cut the next libtool Agreed, too; 2.2.8 soon would be good. A couple of small issues need looking at (esp. the aclocal.m4 messup reported by Akim). Any volunteers for the release? so that we can bite the bullet and integrate your branch into mainline. Agreed, too. Them bullets sure taste rather bitter, though. ;-) Cheers, Ralf
