Skip to content
This repository was archived by the owner on Jun 18, 2020. It is now read-only.

Conversation

@kcrisman
Copy link
Member

I do not know what I am doing at all, but apparently this will take the patches at Trac 12299 and make them look nice for Github. I sure hope it works.

I have to say that this is really, really ridiculous; patches already exist, but because of the web-based interface, I could not find any way to do this than to apply them by hand and then use the (very slow) Mac Github app to send the request here. Way too many steps, I really struggled with this.

And what happens if it's decided back at Trac 12299 that the patches need work still? Horrible workflow for newbies, and no one who know what they're doing has been open to simply taking these patches and "Gitifying" them. Disappointing.

kcrisman added 2 commits June 13, 2012 15:20
Attempt to make changes from trac_12299_adv_jmol_nb.patch at Trac 12299
a pull request.
Attempt to make trac_12299_old_wksht.patch work in a pull request
@kcrisman
Copy link
Member Author

The hope is that this would solve #54

@gutow
Copy link
Contributor

gutow commented Jun 13, 2012

Karl-Dieter,
Thank you for doing this. I hope it works...I know people seem to like this and hg. But I must say I have found SVN much easier to use and less prone to messed up patches.

@jasongrout
Copy link
Member

Thanks Karl-Dieter! We've all been working like crazy here, so your help is greatly appreciated.

@jasongrout
Copy link
Member

If the patches still need work, you just commit again. Your pull request is automatically updated. No uploading more patches, figuring out order, etc. Other people just pull your current branch and get the updated changes.

@kini
Copy link
Collaborator

kini commented Jun 14, 2012

I have to say that this is really, really ridiculous; patches already exist, but because of the web-based interface, I could not find any way to do this than to apply them by hand and then use the (very slow) Mac Github app to send the request here. Way too many steps, I really struggled with this.

Github's web-based interface is not meant to replace git. If you want to use Github effectively, and in particular if you want to do sagenb development effectively, please use git. It is not difficult. I have to say I really don't appreciate this FUD you're spreading about it.

And what happens if it's decided back at Trac 12299 that the patches need work still? Horrible workflow for newbies, and no one who know what they're doing has been open to simply taking these patches and "Gitifying" them. Disappointing.

Assuming that by people "who know what they're doing" you include me, I find it interesting that on Sage trac #12299 I am mentioned three times as someone to ask for help, yet I have not actually been asked to help (i.e. been CC'd to the ticket). What's going on? Please CC me to a ticket if you want me to do something on a ticket. I would have been glad to have made this pull request for you, had I known it even needed creating.

Anyway, as Jason said, thanks for making the vast effort to do this pull request entirely by hand. Hopefully one of us can review it soon.

@kini
Copy link
Collaborator

kini commented Jun 14, 2012

I recreated this pull request directly from @gutow's patches at #64. I really wish someone had CC'd me to the ticket since this was about 5 minutes' work.

@kini kini closed this Jun 14, 2012
@kcrisman kcrisman mentioned this pull request Jun 14, 2012
@kcrisman
Copy link
Member Author

Not FUD, but FUDGE - fear, uncertainty and doubt granting energy. And I do think that I've been asking people to read my mind a bit much, so I apologize for that, Keshav.

I don't apologize for the Github workflow criticisms - putting code on Github does at this point make it very hard for a newbie to understand how to take a working Sage NB install and turn changes in it into something that can be put on the official Sage NB Github site. It's not like there's a place to attach a patch or something, much less download one - the only way to alert people to "I have a change, and here's the code" seems to be to fork a repository, make the same changes you made in your actual sagenb install there (because it's not at all obvious how to take one's sagenb install and just take these changes independently). It was a lot different with Trac; the patches are these independent things, and I was even pleasantly surprised that applying a patch with git, though the documentation was far more impenetrable than HG's, is more or less the same command as in HG (well, within about 5 times epsilon).

As to Jason's comment, the "updated pull" does me little good when the entire git (or Github) structure is opaque. This issue is closed, so I guess further discussion of it is pointless. But believe me, I searched stackoverflow and other sites like a demon to find ways to do all this (which is where I found out that the .patch files from the original commits even exist), more or less without avail. It's not that I wasn't trying. My sense is that Github very much != git, and maybe it would be nice to have a parallel sagenb world that doesn't require use of Github.

@kini
Copy link
Collaborator

kini commented Jun 14, 2012

Not FUD, but FUDGE - fear, uncertainty and doubt granting energy.  And I do think that I've been asking people to read my mind a bit much, so I apologize for that, Keshav.

I don't apologize for the Github workflow criticisms - putting code on Github does at this point make it very hard for a newbie to understand how to take a working Sage NB install and turn changes in it into something that can be put on the official Sage NB Github site.

As we have discussed before, it's natural that sagenb is going to be
less newbie-friendly than the sage library. The Sage library has a lot
of experienced mathematicians who are unexperienced as programmers but
have a lot to contribute. The Sage notebook, on the other hand, is a
web app.

It's not like there's a place to attach a patch or something, much less download one

You say that like creating a patch and sending it to someone is
somehow a natural thing for a newbie to do. I feel you are biased by
your long experience with using patches. I think the snapshot-centered
paradigm of git and mercurial is equally intuitive as the
diff-centered paradigm of patches, darcs, etc. Maybe even more
intuitive.

the only way to alert people to "I have a change, and here's the code" seems to be to fork a repository, make the same changes you made in your actual sagenb install there (because it's not at all obvious how to take one's sagenb install and just take these changes independently).

That's because we currently (for some reason) ship the sagenb spkg
with a mercurial repository instead of a git repository, which is
totally useless since you can't do any development on it now that
we're on github. I just spent the last couple of days on pull request
#63, which should alleviate this, when combined with trac #12229
(which I still think should be written carefully from scratch instead
of via some autogenerated thing - I would have thought you would care
about that more than I do, Karl).

After #63 is merged, the sagenb SPKG will install a git repo into
$SAGE_ROOT/devel/sagenb with a remote pointing at
github.com/sagemath/sagenb and the master branch set to track our
(github.com/sagemath/sagenb 's) master for convenience. #12229 should
give information about how to add remotes for other users, how to
create a pull request, and even how to apply patches from Trac, though
hopefully the need for that will diminish in time.

It was a lot different with Trac; the patches are these independent things, and I was even pleasantly surprised that applying a patch with git, though the documentation was far more impenetrable than HG's, is more or less the same command as in HG (well, within about 5 times epsilon).

git's documentation is very detailed. Maybe it's impenetrable to a
beginner, but it's a lot nicer for someone who wants to know all the
corner cases and the exact behavior of commands. Another thing is that
git just has a lot more options for obscure things that people don't
usually need to do, but that, for example, I have found missing in
Mercurial when I went looking for them. Basically, grep is your
friend...

As to Jason's comment, the "updated pull" does me little good when the entire git (or Github) structure is opaque.  This issue is closed, so I guess further discussion of it is pointless.

By all means feel free to continue the discussion on #64 if you wish,
or even here. I just closed this because #64 supersedes this pull
request, not because I wanted to shut anyone up.

But believe me, I searched stackoverflow and other sites like a demon to find ways to do all this (which is where I found out that the .patch files from the original commits even exist), more or less without avail.  It's not that I wasn't trying.

The question is, what are you trying at? What you should be trying
to do is to learn how to use git, not to google how to make a pull
request out of patches, or whatever you googled. All will be clear
once you have digested these concepts and played around with git a
bit: http://sitaramc.github.com/gcs/

My sense is that Github very much != git, and maybe it would be nice to have a parallel sagenb world that doesn't require use of Github.

We don't require the use of Github by contributors. You could as
easily have hosted your git repo somewhere else, pushed your branch to
it, and emailed a link to that branch to sage-notebook, if you so
desired. Or you could have even sent a patch stream to sage-notebook
using git send-email. People would probably complain about you being
difficult, but would also be able to convert that form of contribution
into a pull request in a couple minutes, so it wouldn't be such a big
deal.

But I suspect you would be searching stackoverflow and google like a
demon for even longer than you did, trying to figure out how to do
those things. The fact is that for git, like for most tools,
sometimes just sitting down and reading the manual can make your life
a lot easier. A good place to start is the site I linked above, which
I was trying to tell you about at SD40.5.

@kcrisman
Copy link
Member Author

My goodness, I really was trying to end this conversation because we weren't in person. I didn't think you were trying to shut me up, naturally #64 supersedes this. Ah, the internet. I will follow up further via private message; probably no one else wants to hear our disagreement - my apologies to those who read it.

@kini kini mentioned this pull request Jun 21, 2012
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants