Moved to git
7 views
Skip to first unread message
Rudd-O
Aug 27, 2009, 8:19:56 AM8/27/09
to zfs-fuse
I have now moved the repo to Git. Mercurial ultimately pushed me into
a no-solution corner, so I just migrated everything.
Hope this is OK with you guys.
a no-solution corner, so I just migrated everything.
Hope this is OK with you guys.
Georg-W. Koltermann
Aug 27, 2009, 9:47:13 AM8/27/09
to zfs-...@googlegroups.com
Bah.
Why should I learn another new tool when Hg already fulfilled all my wishes :-(
I'm not a developer, probably I shouldn't speak up here. I'm curious though what your no solution corner might have been. Perhaps I missed it on the mailing list?
--
Regards,
Georg.
Why should I learn another new tool when Hg already fulfilled all my wishes :-(
I'm not a developer, probably I shouldn't speak up here. I'm curious though what your no solution corner might have been. Perhaps I missed it on the mailing list?
--
Regards,
Georg.
2009/8/27 Rudd-O <rud...@rudd-o.com>
Rodrigo E. De León Plicet
Aug 27, 2009, 11:00:48 PM8/27/09
to zfs-...@googlegroups.com
Err... can you give me an example of how to pull/update stuff from the repo?
I did a:
git clone http://git.rudd-o.com/zfs
... but now I'm stuck. :(
FYI, with Mercurial, I had this:
rdl@newage:~/src$ cat update_zfs.sh
#!/bin/bash
cd zfs
hg pull http://git.rudd-o.com/zfs/
hg update
cd src
scons
sudo scons install
... and was happy. :)
Thanks in advance.
me22
Aug 28, 2009, 12:45:37 AM8/28/09
to zfs-...@googlegroups.com
2009/8/27 Rodrigo E. De León Plicet <rdel...@gmail.com>:
>
> Err... can you give me an example of how to pull/update stuff from the repo?
>
>
> Err... can you give me an example of how to pull/update stuff from the repo?
>
IIRC git tracks the origin, so just a "git pull" should do everything you need.
This is a decent doc: http://git-scm.com/course/svn.html
Joseph Spiros
Aug 28, 2009, 2:20:39 AM8/28/09
to zfs-fuse
This is great. I love git.
Emmanuel Anne
Aug 28, 2009, 5:08:26 AM8/28/09
to zfs-...@googlegroups.com
Ok, I am close to the limit of usability now, I have a diff of 300 lines between your repo and what I am currently using, it's increasingly time consuming to send patches in these conditions.
So I am thinking about just stopping to send patches, there is not much reason for me to continue to try to sync my tree with yours after all (which would be different if more people were sending patches). I might continue to improve the code on my side later though.
Anyway here is a last patch to revert the put_nvlist modification.
For some reason this allows zfs-fuse to work correctly when there is a problem in a raidz array. Apparently put_nvlist was really intended to fail in this case, the previous patch prevented it from failing and was creating an endless loop.
Now the big surprise is that even when you revert to the previous state (by applying the attached patch), the disappearing pools bug doesn't come back ! I don't have time to investigate why for now, sorry, but it could be a good way to test git after all, just try to remove a lot of patches until the bug comes back and you'll have your culprit.
So anyway even without the culprit the best option for now it to revert put_nvlist to what it was before by applying this patch.
So I am thinking about just stopping to send patches, there is not much reason for me to continue to try to sync my tree with yours after all (which would be different if more people were sending patches). I might continue to improve the code on my side later though.
Anyway here is a last patch to revert the put_nvlist modification.
For some reason this allows zfs-fuse to work correctly when there is a problem in a raidz array. Apparently put_nvlist was really intended to fail in this case, the previous patch prevented it from failing and was creating an endless loop.
Now the big surprise is that even when you revert to the previous state (by applying the attached patch), the disappearing pools bug doesn't come back ! I don't have time to investigate why for now, sorry, but it could be a good way to test git after all, just try to remove a lot of patches until the bug comes back and you'll have your culprit.
So anyway even without the culprit the best option for now it to revert put_nvlist to what it was before by applying this patch.
2009/8/28 Joseph Spiros <joseph...@ithinksw.com>
Rodrigo E. De León Plicet
Aug 28, 2009, 1:15:01 PM8/28/09
to zfs-...@googlegroups.com
Neat! Thanks!
Rudd-O
Aug 28, 2009, 3:19:48 PM8/28/09
to zfs-fuse
You have to learn no new tool. Just replace "hg" for "git". The rest
is exactly the same if you are not a developer.
On Aug 27, 8:47 am, "Georg-W. Koltermann" <geor...@googlemail.com>
wrote:
is exactly the same if you are not a developer.
On Aug 27, 8:47 am, "Georg-W. Koltermann" <geor...@googlemail.com>
wrote:
Rudd-O
Aug 28, 2009, 3:20:26 PM8/28/09
to zfs-fuse
git pull origin in the folder of the checkout pulls and updates.
> rdl@newage:~/src$ cat update_zfs.sh
> #!/bin/bash
> cd zfs
> hg pullhttp://git.rudd-o.com/zfs/
> rdl@newage:~/src$ cat update_zfs.sh
> #!/bin/bash
> cd zfs
Rudd-O
Aug 28, 2009, 3:30:17 PM8/28/09
to zfs-fuse
This is why I moved to git. You can git stash each individual patch,
or easily maintain an independent branch separate from the rest, to
take your extra cognitive load to ZERO.
--------------------------------
Let me explain how to work together with git.
First, you clone the repo. This gives you the master branch.
Second, you create a personal branch, call it "emmanuel". Apply your
personal patches there. You no longer have to remember them or manage
them manually.
Third, you publish your repo in some Web server or gitorious repo or
something like that. I can give you access and space too, should you
want it.
Now you periodically pull from origin to get the latest and greatest.
You pull while being in master, your master branch gets merged. You
pull while being in emmanuel, your emmanuel branch gets merged.
Fourth, now you do some interesting work in ZFS that you think may be
useful for others (and, might I interject, you sure well know that we
all love and appreciate your work). To share it with us, just commit
that work in the master branch of your repo (or commit it to your
personal branch, then git cherry-pick that specific commit ID from
emmanuel into master), then push that master branch to the public repo
that you got ahold of. That is IT. Then, all I have to type is "git
pull emmanuel" and all your commits come in then get merged in, with
SHA1 sums and proper credit due to you. The next time you pull from
origin, git will KNOW that your commit went through to origin and
won't apply it doubly.
Fifth, you can use giggle to navigate your history locally, visually,
with a nice tree. It is invaluable.
Sixth, you can amend any of your commits as long as you haven't pushed
anything to your public repo. Git commit --amend.
Seventh, you can stack your personal patches in your emmanuel branch
atop anything that has been published in in my master repo. You can
see with giggle which commits are not yet in the master branch.
I have condensed TONS of git functionality here. I am also
volunteering to help you do ANYTHING that you want to do with git.
Just drop me a line.
> So I am thinking about just stopping to send patches, there is not much
> reason for me to continue to try to sync my tree with yours after all (which
> would be different if more people were sending patches). I might continue to
> improve the code on my side later though.
> Anyway here is a last patch to revert the put_nvlist modification.
> For some reason this allows zfs-fuse to work correctly when there is a
> problem in a raidz array. Apparently put_nvlist was really intended to fail
> in this case, the previous patch prevented it from failing and was creating
> an endless loop.
> Now the big surprise is that even when you revert to the previous state (by
> applying the attached patch), the disappearing pools bug doesn't come back !
> I don't have time to investigate why for now, sorry, but it could be a good
> way to test git after all, just try to remove a lot of patches until the bug
> comes back and you'll have your culprit.
> So anyway even without the culprit the best option for now it to revert
> put_nvlist to what it was before by applying this patch.
This is precisely why we need git. For example, at the moment I have
no idea on what patch this patch depends, so I can't apply it. With
git, all you'd have to do is git push, and I would have to git pull,
and presto, it's done.
Word to the wise: stop juggling patches by hand. There is a reason
why the kernel developers use git.
or easily maintain an independent branch separate from the rest, to
take your extra cognitive load to ZERO.
--------------------------------
Let me explain how to work together with git.
First, you clone the repo. This gives you the master branch.
Second, you create a personal branch, call it "emmanuel". Apply your
personal patches there. You no longer have to remember them or manage
them manually.
Third, you publish your repo in some Web server or gitorious repo or
something like that. I can give you access and space too, should you
want it.
Now you periodically pull from origin to get the latest and greatest.
You pull while being in master, your master branch gets merged. You
pull while being in emmanuel, your emmanuel branch gets merged.
Fourth, now you do some interesting work in ZFS that you think may be
useful for others (and, might I interject, you sure well know that we
all love and appreciate your work). To share it with us, just commit
that work in the master branch of your repo (or commit it to your
personal branch, then git cherry-pick that specific commit ID from
emmanuel into master), then push that master branch to the public repo
that you got ahold of. That is IT. Then, all I have to type is "git
pull emmanuel" and all your commits come in then get merged in, with
SHA1 sums and proper credit due to you. The next time you pull from
origin, git will KNOW that your commit went through to origin and
won't apply it doubly.
Fifth, you can use giggle to navigate your history locally, visually,
with a nice tree. It is invaluable.
Sixth, you can amend any of your commits as long as you haven't pushed
anything to your public repo. Git commit --amend.
Seventh, you can stack your personal patches in your emmanuel branch
atop anything that has been published in in my master repo. You can
see with giggle which commits are not yet in the master branch.
I have condensed TONS of git functionality here. I am also
volunteering to help you do ANYTHING that you want to do with git.
Just drop me a line.
> So I am thinking about just stopping to send patches, there is not much
> reason for me to continue to try to sync my tree with yours after all (which
> would be different if more people were sending patches). I might continue to
> improve the code on my side later though.
> Anyway here is a last patch to revert the put_nvlist modification.
> For some reason this allows zfs-fuse to work correctly when there is a
> problem in a raidz array. Apparently put_nvlist was really intended to fail
> in this case, the previous patch prevented it from failing and was creating
> an endless loop.
> Now the big surprise is that even when you revert to the previous state (by
> applying the attached patch), the disappearing pools bug doesn't come back !
> I don't have time to investigate why for now, sorry, but it could be a good
> way to test git after all, just try to remove a lot of patches until the bug
> comes back and you'll have your culprit.
> So anyway even without the culprit the best option for now it to revert
> put_nvlist to what it was before by applying this patch.
no idea on what patch this patch depends, so I can't apply it. With
git, all you'd have to do is git push, and I would have to git pull,
and presto, it's done.
Word to the wise: stop juggling patches by hand. There is a reason
why the kernel developers use git.
Mike Hommey
Aug 27, 2009, 8:39:13 AM8/27/09
to zfs-...@googlegroups.com
Cool, I'll merge and rebase my patches, then, so that you can pull or
whatever.
Cheers,
Mike
Rudd-O
Aug 30, 2009, 6:34:04 AM8/30/09
to zfs-fuse
YES! :-D Let me know when you're ready to push your work to a public
repo, and where, so I can cherry-pick or merge directly from you.
repo, and where, so I can cherry-pick or merge directly from you.
Mike Hommey
Sep 1, 2009, 1:51:21 AM9/1/09
to zfs-...@googlegroups.com
On Sun, Aug 30, 2009 at 03:34:04AM -0700, Rudd-O wrote:
>
> YES! :-D Let me know when you're ready to push your work to a public
> repo, and where, so I can cherry-pick or merge directly from you.
>
> YES! :-D Let me know when you're ready to push your work to a public
> repo, and where, so I can cherry-pick or merge directly from you.
The repo is already public, expect that it's outdated, now. (though the
commits might still be cherry-pickable).
You can clone git://git.debian.org/~glandium/zfs-fuse.git and take a look
at the following "feature branches":
improve/atomic
improve/FHS
build/clean
build/optim
I might merge with your tree soonish, though.
Cheers,
Mike
Rudd-O
Sep 1, 2009, 4:18:26 PM9/1/09
to zfs-fuse
Will do so.
Joseph Spiros
Sep 19, 2009, 4:08:06 PM9/19/09
to zfs-...@googlegroups.com
Oddly enough, as this was composed as a reply to my mere support of the
move to git, I just found myself in need of the put_nvlist patch.
I had been running 2.6.26 on my Debian machine with the brcha zfs-fuse
package, and upon my upgrade to 2.6.30 I was experiencing freezes that
required a reboot. So, I cloned Rudd-O's git repository, and built a new
version. I was then unable to complete an import of my RAID-Z pool, with
the following syslog:
Sep 19 15:23:52 hylia zfs-fuse: put_nvlist: out of memory 3296 > 3280
Sep 19 15:24:23 hylia last message repeated 39 times
Sep 19 15:25:24 hylia last message repeated 72 times
Sep 19 15:26:08 hylia last message repeated 53 times
The message repeated until I canceled the import, which would
(seemingly) never complete. After applying the put_nvlist patch provided
by Emmanuel and rebuilding, the import succeeded (though it did syslog
the same message [put_nvlist: out of memory 3296 > 3280] once, and only
once), and so far, the pool is working fine.
It may, therefore, be worth considering including the patch in the
master branch.
-
On another note, I'd recommend making it more obvious where the master
git repository is located for future zfs-fuse development. Having to
search the mailing list to find it was somewhat frustrating, and anyone
searching (with Google, say) for zfs-fuse information is going to have
to look long and hard to figure out how to contribute. A URL that can be
linked to, with up-to-date information on zfs-fuse development, would be
very useful.
Perhaps GitHub? Gitorious? Even a gitweb installation on Rudd-o's
website would be helpful. Here's a quick guide for setting up gitweb
that I wrote, which you may find useful, Rudd-O (mind you, it presumes
Debian, but it should be obvious how to modify it for Fedora, which I
believe you use):
http://josephspiros.com/2009/07/26/configuring-gitweb-for-apache-on-debian
Also, I have gitweb, and redmine, setup at ithinksw.org, and I would be
more than willing to set up a project over there if you need it.
On 8/28/09 5:08 AM, Emmanuel Anne wrote:
> Ok, I am close to the limit of usability now, I have a diff of 300 lines
> between your repo and what I am currently using, it's increasingly time
> consuming to send patches in these conditions.
>
> So I am thinking about just stopping to send patches, there is not much
> reason for me to continue to try to sync my tree with yours after all
> (which would be different if more people were sending patches). I might
> continue to improve the code on my side later though.
>
> Anyway here is a last patch to revert the put_nvlist modification.
> For some reason this allows zfs-fuse to work correctly when there is a
> problem in a raidz array. Apparently put_nvlist was really intended to
> fail in this case, the previous patch prevented it from failing and was
> creating an endless loop.
> Now the big surprise is that even when you revert to the previous state
> (by applying the attached patch), the disappearing pools bug doesn't
> come back ! I don't have time to investigate why for now, sorry, but it
> could be a good way to test git after all, just try to remove a lot of
> patches until the bug comes back and you'll have your culprit.
>
> So anyway even without the culprit the best option for now it to revert
> put_nvlist to what it was before by applying this patch.
>
> 2009/8/28 Joseph Spiros <joseph...@ithinksw.com
> <mailto:joseph...@ithinksw.com>>
Joseph Spiros
iThink Software
joseph...@ithinksw.com
+1 (440) 707-6855
move to git, I just found myself in need of the put_nvlist patch.
I had been running 2.6.26 on my Debian machine with the brcha zfs-fuse
package, and upon my upgrade to 2.6.30 I was experiencing freezes that
required a reboot. So, I cloned Rudd-O's git repository, and built a new
version. I was then unable to complete an import of my RAID-Z pool, with
the following syslog:
Sep 19 15:23:52 hylia zfs-fuse: put_nvlist: out of memory 3296 > 3280
Sep 19 15:24:23 hylia last message repeated 39 times
Sep 19 15:25:24 hylia last message repeated 72 times
Sep 19 15:26:08 hylia last message repeated 53 times
The message repeated until I canceled the import, which would
(seemingly) never complete. After applying the put_nvlist patch provided
by Emmanuel and rebuilding, the import succeeded (though it did syslog
the same message [put_nvlist: out of memory 3296 > 3280] once, and only
once), and so far, the pool is working fine.
It may, therefore, be worth considering including the patch in the
master branch.
-
On another note, I'd recommend making it more obvious where the master
git repository is located for future zfs-fuse development. Having to
search the mailing list to find it was somewhat frustrating, and anyone
searching (with Google, say) for zfs-fuse information is going to have
to look long and hard to figure out how to contribute. A URL that can be
linked to, with up-to-date information on zfs-fuse development, would be
very useful.
Perhaps GitHub? Gitorious? Even a gitweb installation on Rudd-o's
website would be helpful. Here's a quick guide for setting up gitweb
that I wrote, which you may find useful, Rudd-O (mind you, it presumes
Debian, but it should be obvious how to modify it for Fedora, which I
believe you use):
http://josephspiros.com/2009/07/26/configuring-gitweb-for-apache-on-debian
Also, I have gitweb, and redmine, setup at ithinksw.org, and I would be
more than willing to set up a project over there if you need it.
On 8/28/09 5:08 AM, Emmanuel Anne wrote:
> Ok, I am close to the limit of usability now, I have a diff of 300 lines
> between your repo and what I am currently using, it's increasingly time
> consuming to send patches in these conditions.
>
> So I am thinking about just stopping to send patches, there is not much
> reason for me to continue to try to sync my tree with yours after all
> (which would be different if more people were sending patches). I might
> continue to improve the code on my side later though.
>
> Anyway here is a last patch to revert the put_nvlist modification.
> For some reason this allows zfs-fuse to work correctly when there is a
> problem in a raidz array. Apparently put_nvlist was really intended to
> fail in this case, the previous patch prevented it from failing and was
> creating an endless loop.
> Now the big surprise is that even when you revert to the previous state
> (by applying the attached patch), the disappearing pools bug doesn't
> come back ! I don't have time to investigate why for now, sorry, but it
> could be a good way to test git after all, just try to remove a lot of
> patches until the bug comes back and you'll have your culprit.
>
> So anyway even without the culprit the best option for now it to revert
> put_nvlist to what it was before by applying this patch.
>
> 2009/8/28 Joseph Spiros <joseph...@ithinksw.com
> <mailto:rud...@rudd-o.com>> wrote:
> > I have now moved the repo to Git. Mercurial ultimately pushed me
> into
> > a no-solution corner, so I just migrated everything.
> >
> > Hope this is OK with you guys.
>
>
>
> >
--
> > I have now moved the repo to Git. Mercurial ultimately pushed me
> into
> > a no-solution corner, so I just migrated everything.
> >
> > Hope this is OK with you guys.
>
>
>
> >
Joseph Spiros
iThink Software
joseph...@ithinksw.com
+1 (440) 707-6855
Rudd-O
Sep 21, 2009, 6:21:08 PM9/21/09
to zfs-fuse
The master git repo is linked in the Web page of the project which is
the current "official" one:
http://rudd-o.com/new-projects/zfs
I haven't had time to set up gitweb yet, but I believe I will be doing
so in a few days. It's been hectic with the move and the preparations
for a trip but I will get there.
> http://josephspiros.com/2009/07/26/configuring-gitweb-for-apache-on-d...
> > <mailto:joseph.spi...@ithinksw.com>>
> +1 (440) 707-6855
the current "official" one:
http://rudd-o.com/new-projects/zfs
I haven't had time to set up gitweb yet, but I believe I will be doing
so in a few days. It's been hectic with the move and the preparations
for a trip but I will get there.
>
> Also, I have gitweb, and redmine, setup at ithinksw.org, and I would be
> more than willing to set up a project over there if you need it.
>
> On 8/28/09 5:08 AM, Emmanuel Anne wrote:
>
>
>
> > Ok, I am close to the limit of usability now, I have a diff of 300 lines
> > between your repo and what I am currently using, it's increasingly time
> > consuming to send patches in these conditions.
>
> > So I am thinking about just stopping to send patches, there is not much
> > reason for me to continue to try to sync my tree with yours after all
> > (which would be different if more people were sending patches). I might
> > continue to improve the code on my side later though.
>
> > Anyway here is a last patch to revert the put_nvlist modification.
> > For some reason this allows zfs-fuse to work correctly when there is a
> > problem in a raidz array. Apparently put_nvlist was really intended to
> > fail in this case, the previous patch prevented it from failing and was
> > creating an endless loop.
> > Now the big surprise is that even when you revert to the previous state
> > (by applying the attached patch), the disappearing pools bug doesn't
> > come back ! I don't have time to investigate why for now, sorry, but it
> > could be a good way to test git after all, just try to remove a lot of
> > patches until the bug comes back and you'll have your culprit.
>
> > So anyway even without the culprit the best option for now it to revert
> > put_nvlist to what it was before by applying this patch.
>
> > 2009/8/28 Joseph Spiros <joseph.spi...@ithinksw.com
> Also, I have gitweb, and redmine, setup at ithinksw.org, and I would be
> more than willing to set up a project over there if you need it.
>
> On 8/28/09 5:08 AM, Emmanuel Anne wrote:
>
>
>
> > Ok, I am close to the limit of usability now, I have a diff of 300 lines
> > between your repo and what I am currently using, it's increasingly time
> > consuming to send patches in these conditions.
>
> > So I am thinking about just stopping to send patches, there is not much
> > reason for me to continue to try to sync my tree with yours after all
> > (which would be different if more people were sending patches). I might
> > continue to improve the code on my side later though.
>
> > Anyway here is a last patch to revert the put_nvlist modification.
> > For some reason this allows zfs-fuse to work correctly when there is a
> > problem in a raidz array. Apparently put_nvlist was really intended to
> > fail in this case, the previous patch prevented it from failing and was
> > creating an endless loop.
> > Now the big surprise is that even when you revert to the previous state
> > (by applying the attached patch), the disappearing pools bug doesn't
> > come back ! I don't have time to investigate why for now, sorry, but it
> > could be a good way to test git after all, just try to remove a lot of
> > patches until the bug comes back and you'll have your culprit.
>
> > So anyway even without the culprit the best option for now it to revert
> > put_nvlist to what it was before by applying this patch.
>
> > <mailto:joseph.spi...@ithinksw.com>>
>
> > This is great. I love git.
>
> > On Aug 27, 8:19 am, Rudd-O <rud...@rudd-o.com
> > <mailto:rud...@rudd-o.com>> wrote:
> > > I have now moved the repo to Git. Mercurial ultimately pushed me
> > into
> > > a no-solution corner, so I just migrated everything.
>
> > > Hope this is OK with you guys.
>
> --
> Joseph Spiros
> iThink Software
> joseph.spi...@ithinksw.com
> > This is great. I love git.
>
> > On Aug 27, 8:19 am, Rudd-O <rud...@rudd-o.com
> > <mailto:rud...@rudd-o.com>> wrote:
> > > I have now moved the repo to Git. Mercurial ultimately pushed me
> > into
> > > a no-solution corner, so I just migrated everything.
>
> > > Hope this is OK with you guys.
>
> --
> Joseph Spiros
> iThink Software
> +1 (440) 707-6855
Reply all
Reply to author
Forward
0 new messages