Re: [sage-devel] "git trac" command
On Thursday, December 26, 2013 5:12:13 PM UTC-8, R. Andrew Ohana wrote: > > On Wed, Dec 25, 2013 at 12:36 PM, Volker Braun > > > wrote: > > I've been working on a "git trac" subcommand to complement the git suite >> with trac integration instead of the separate UI that the sage -dev scripts >> present. This project is the basis for my release management scripts, so I >> have been eating my own dog food for a while now. I think it is now in a >> state where it would be useful to others, so I propose to integrate it as a >> standard spkg. Obligatory vote: >> >> [ ] Yes, please >> [X ] Make it optional >> [ ] No, you stink >> >> http://trac.sagemath.org/ticket/15587 >> > > IMO, I think for developers who are using git directly that they should be > installing this under /usr/local (or some other prefix that they include in > their paths). In particular, I think it is a very bad idea to integrate the > codebase into the sage codebase for two reasons: > > 1. It will make it more difficult to get to install the tools in > /usr/local (e.g.), as you will have to hunt down in the sage source code to > find the appropriate setup.py. > 2. We will run into the issue of the tools suddenly having a different > feature set while switching between branches (this was incredibly > frustrating for the dev scripts). > > -- > Andrew > I concur with Andrew on this! Anne -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] "git trac" command
I vote for making this an extension to git, as it makes interacting with trac easier while also allowing developers to learn git if they did not already know it. If we think about the previous development process using mercurial, I am pretty sure that very few people used the sage-wrapped functions such as hg_sage once there was a simple tutorial on mercurial queues to get them started. I understand Volker's good point that right now it is easier to have this as an optional add-on since otherwise the functionality gets lost when you switch to a branch which does not have it. But that issue will fade away soon enough. John On 29 December 2013 02:36, Volker Braun wrote: > I've been taking some bits and pieces from the sage -dev scripts, so its not > entirely unrelated. Mostly, there is a philosophical difference: The dev > scripts implement an alterative UI to git, and the git trac command extends > git. The arguments for it aren't exactly new, and boil down to > > * A lot of thought went already into the git user experience > * Working knowledge of git is a skill that is also valuable outside of Sage > * Much simpler codebase for a narrow task > > vs. > > * The dev scripts make it easy to use git without having to learn it > > I don't think there is necessarily a winner. Of course I have a personal > favorite. At this point we don't really benefit from picking one or the > other, we can just offer both and see which one works out better in the long > run. > > -- > You received this message because you are subscribed to the Google Groups > "sage-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sage-devel+unsubscr...@googlegroups.com. > To post to this group, send email to sage-devel@googlegroups.com. > Visit this group at http://groups.google.com/group/sage-devel. > For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] "git trac" command
I've been taking some bits and pieces from the sage -dev scripts, so its not entirely unrelated. Mostly, there is a philosophical difference: The dev scripts implement an alterative UI to git, and the git trac command extends git. The arguments for it aren't exactly new, and boil down to * A lot of thought went already into the git user experience * Working knowledge of git is a skill that is also valuable outside of Sage * Much simpler codebase for a narrow task vs. * The dev scripts make it easy to use git without having to learn it I don't think there is necessarily a winner. Of course I have a personal favorite. At this point we don't really benefit from picking one or the other, we can just offer both and see which one works out better in the long run. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] "git trac" command
Yo ! > What's the relation between this and ./sage -dev? Because I don't think we should have this "git trac" command and also "./sage -dev" with lots of overlapping functionality. So I would vote for Jeroen, let me tell you that I *LOVE* the way you rewrite the questions. > [X] Integrate "git trac" in sage -dev (or the converse) I also think that sage -dev and git trac are twice the same thing, and I believe that we should only support what the developper will use, as all other codes end up being broken and unreliable. And I'd vote fo "git trac" :-P Nathann -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] "git trac" command
On 2013-12-25 21:36, Volker Braun wrote: I've been working on a "git trac" subcommand to complement the git suite with trac integration instead of the separate UI that the sage -dev scripts present. This project is the basis for my release management scripts, so I have been eating my own dog food for a while now. I think it is now in a state where it would be useful to others, so I propose to integrate it as a standard spkg. Obligatory vote: [ ] Yes, please [ ] Make it optional [ ] No, you stink http://trac.sagemath.org/ticket/15587 What's the relation between this and ./sage -dev? Because I don't think we should have this "git trac" command and also "./sage -dev" with lots of overlapping functionality. So I would vote for [X] Integrate "git trac" in sage -dev (or the converse) -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] "git trac" command
I agree that it shoud be installed separately, though of course we want to make it easy for people to try it out. But just running "sage -f git_trac" ought to be easy enough, so lets go with that. And the current branch is not set to build by default anyways. So as soon as somebody presses the positive review button we can ship it... On Friday, December 27, 2013 1:12:13 AM UTC, R. Andrew Ohana wrote: > > On Wed, Dec 25, 2013 at 12:36 PM, Volker Braun > > > wrote: > > I've been working on a "git trac" subcommand to complement the git suite >> with trac integration instead of the separate UI that the sage -dev scripts >> present. This project is the basis for my release management scripts, so I >> have been eating my own dog food for a while now. I think it is now in a >> state where it would be useful to others, so I propose to integrate it as a >> standard spkg. Obligatory vote: >> >> [ ] Yes, please >> [X ] Make it optional >> [ ] No, you stink >> >> http://trac.sagemath.org/ticket/15587 >> > > IMO, I think for developers who are using git directly that they should be > installing this under /usr/local (or some other prefix that they include in > their paths). In particular, I think it is a very bad idea to integrate the > codebase into the sage codebase for two reasons: > > 1. It will make it more difficult to get to install the tools in > /usr/local (e.g.), as you will have to hunt down in the sage source code to > find the appropriate setup.py. > 2. We will run into the issue of the tools suddenly having a different > feature set while switching between branches (this was incredibly > frustrating for the dev scripts). > > -- > Andrew > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] "git trac" command
On Wed, Dec 25, 2013 at 12:36 PM, Volker Braun wrote: I've been working on a "git trac" subcommand to complement the git suite > with trac integration instead of the separate UI that the sage -dev scripts > present. This project is the basis for my release management scripts, so I > have been eating my own dog food for a while now. I think it is now in a > state where it would be useful to others, so I propose to integrate it as a > standard spkg. Obligatory vote: > > [ ] Yes, please > [X ] Make it optional > [ ] No, you stink > > http://trac.sagemath.org/ticket/15587 > IMO, I think for developers who are using git directly that they should be installing this under /usr/local (or some other prefix that they include in their paths). In particular, I think it is a very bad idea to integrate the codebase into the sage codebase for two reasons: 1. It will make it more difficult to get to install the tools in /usr/local (e.g.), as you will have to hunt down in the sage source code to find the appropriate setup.py. 2. We will run into the issue of the tools suddenly having a different feature set while switching between branches (this was incredibly frustrating for the dev scripts). -- Andrew -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] "git trac" command
I've been working on a "git trac" subcommand to complement the git suite with trac integration instead of the separate UI that the sage -dev scripts present. This project is the basis for my release management scripts, so I have been eating my own dog food for a while now. I think it is now in a state where it would be useful to others, so I propose to integrate it as a standard spkg. Obligatory vote: [ ] Yes, please [ ] Make it optional [ ] No, you stink http://trac.sagemath.org/ticket/15587 Usage - * Print the trac ticket information using ``git trac get ``. $ git trac get 12345 == Trac #12345: Title of ticket 12345 ... == Alternatively, you can pass a remote branch name, in which case trac is searched for a ticket whose (remote) "Branch:" field equals the branch name. If that fails, the ticket number will be deduced from the branch name by scanning for a number. If you neither specify a ticket number or branch name, the local git branch name is used: $ git branch /u/user/description $ git trac get == Trac #n: Title Description Status: Status Component: Component ... Branch: u/user/description == * Checkout a remote branch: $ git trac checkout 12345 Will automatically pick a local branch name ``t/12345/description`` based on the remote branch name. If you want a particular local branch name, you can specify it manually: $ git trac checkout -b my_brach 12345 * Create a new ticket on trac, and a new local branch corresponding to it: $ git trac create "This is the summary" This will automatically create a local branch name ``t/12345/this_is_the_summary``. You can specify it manually if you prefer with: $ git trac create -b my_branch "This is the summary" * Pull (= fetch + merge) from the branch on a ticket: $ git trac pull 12345 You can omit the ticket number, in which case the script will try to search for the ticket having the local branch name attached. If that fails, an attempt is made to deduce the ticket number from the local branch name. * Push (upload) to the branch on a ticket, and set the trac "Branch:" field accordingly: $ git trac push 12345 You can omit the ticket number, in which case the script will try to search for the ticket having the local branch name attached. If that fails, an attempt is made to deduce the ticket number from the local branch name. * Log of the commits for a ticket: $ git trac log 12345 * Find the trac ticket for a commit, either identified by its SHA1 or branch/tag name. $ git log --oneline -1 ee5e39e ee5e39e Allow default arguments in closures $ git trac find ee5e39e Commit has been merged by the release manager into your current branch. commit 44efa774c5f991ea5f160646515cfe8d3f738479 Merge: 5fd5442 679310b Author: Release Manager Date: Sat Dec 21 01:16:56 2013 + Trac #15447: implement evaluation of PARI closures Too Long, Didn't Read - To fix a bug, start with $ git trac create "Fix foo" This will open the ticket and create a new local branch ``t//fix_foo``. Then edit Sage, followed by $ git add $ git commit Repeat edit/commit as necessary. When you are finished, run $ git trac push It will take the ticket number out of the branch name, so you don't have to specify it. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
