More problems with diff

[John Cremona]

I successfully checked out ticket #8723 and ran "make". In order to
review the changes I need to know what the changes are on this ticket.
As I discovered elsewhere, the instruction in the developer's guide
to give the command "./sage -dev diff" does not work as suggested
there, it gives 0 output, and what instead you have to do is ./sage
-dev diff --base master. Well, I just did tat and the output is 38137
lines long. That's right, nearly forty thousand lines.

I tried using git log to give a git hash instead of the branch name
"master" but all that I tried gave the error message that the has was
not a valid branch on the remote system. But using plain git I could
do

git diff 0c6fcdf462e329c80eeaf2841ac1659308

having guessed from git log that this hash was a reasonable place to
start from, and that did give a sensible output, as did

git diff HEAD^

and similar. But to review a ticket we need to know how far back to
go in this, and how do we do that?

I am tempted to kill this branch, and do some real work, and get back
to Sage development when it is easier to use. I do realise that
several people have spent hundreds of hours on this over the last
year, but the system is not yet ready for use by others, it seems.
But surely we need more people to try out the new system -- other than
the ones who wrote the new system -- and give feedback, which is what
I have been trying to do. So I will remain optimistic and hope that
my comments will be taken as a constructive contribution, which is how
they are intended!

John

[Nathann Cohen]

Yoooooooooooooooooooooooo !!

> and similar. But to review a ticket we need to know how far back to
> go in this, and how do we do that?

I use "tig" a lot. It's a command-line software that shows you the git
history. You can move around through patches and see what you like.
Install it and try it it's very cool ! Marc Mezzarobba was the first
to tell me about it I think and it really made a difference for me :-)

> I am tempted to kill this branch, and do some real work, and get back
> to Sage development when it is easier to use. I do realise that
> several people have spent hundreds of hours on this over the last
> year, but the system is not yet ready for use by others, it seems.
> But surely we need more people to try out the new system -- other than
> the ones who wrote the new system -- and give feedback, which is what
> I have been trying to do. So I will remain optimistic and hope that
> my comments will be taken as a constructive contribution, which is how
> they are intended!

HMmm.... I am afraid I can't help, I try to keep my interactions with
the dev scripts to a minimum. But using the normal git commands with
Sage feels natural after a while, and much cooler than HG ;-)

Nathann

[John Cremona]

On 17 December 2013 12:12, Nathann Cohen <nathan...@gmail.com> wrote:
> Yoooooooooooooooooooooooo !!
>

Hello Nathan!

>> and similar. But to review a ticket we need to know how far back to
>> go in this, and how do we do that?
>
> I use "tig" a lot. It's a command-line software that shows you the git
> history. You can move around through patches and see what you like.
> Install it and try it it's very cool ! Marc Mezzarobba was the first
> to tell me about it I think and it really made a difference for me :-)

I don't know tig. I am happy using git itself, but it seems that we
are telling developers that they have a choice: learn git and just use
it, or just use the sage-dev interface which will provide all you need
(or almost all) if you don't want to learn git. If we do keep that
choice, then the second option has to work, be documented, and do
everything which is needed. (Such as: tell me what changes are
introduced by the commits on this ticket, so that I can review the
ticket.)

If the current state of affairs is that the dev scripts are still
under construction, so that for the time being Sage development is
only possible by using git directly, then this needs stating very
clearly. I was under the impression that the dev scripts were ready
for use, and was testing this proposition by trying to use them.

>
>> I am tempted to kill this branch, and do some real work, and get back
>> to Sage development when it is easier to use. I do realise that
>> several people have spent hundreds of hours on this over the last
>> year, but the system is not yet ready for use by others, it seems.
>> But surely we need more people to try out the new system -- other than
>> the ones who wrote the new system -- and give feedback, which is what
>> I have been trying to do. So I will remain optimistic and hope that
>> my comments will be taken as a constructive contribution, which is how
>> they are intended!
>
> HMmm.... I am afraid I can't help, I try to keep my interactions with
> the dev scripts to a minimum. But using the normal git commands with
> Sage feels natural after a while, and much cooler than HG ;-)

I am sure that you are right, and have no problems using plain git
myself (though I am not such an expert), though I could imagine myself
having a little "cheat sheet" reminding me how to gram a ticket for
review, etc.

John

>
> Nathann
>
> --
> You received this message because you are subscribed to the Google Groups "sage-git" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sage-git+u...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

[Jeroen Demeyer]

On 2013-12-17 13:08, John Cremona wrote:
> But to review a ticket we need to know how far back to
> go in this, and how do we do that?

+1, very good question. I also think that this is a major missing
feature from sage-git. With the obsolete system of patches on Trac, at
least one could easily see the code belonging to a given ticket.

Jeroen.

[Nathann Cohen]

Yooooooooooo !

> I don't know tig. 

Try it, it's cool !

> I am happy using git itself, but it seems that we
> are telling developers that they have a choice: learn git and just use
> it, or just use the sage-dev interface which will provide all you need
> (or almost all) if you don't want to learn git.  If we do keep that
> choice, then the second option has to work, be documented, and do
> everything which is needed.  (Such as: tell me what changes are
> introduced by the commits on this ticket, so that I can review the
> ticket.)

Yesyes you are totally right, I just tried to help with what I could, considering that I don't know them and use git directly.

Personally, I don't think that those dev scripts are a very good idea, for I don't think they simplify a lot of things and that people may encounter bugs who can only be solved by using git directly. Plus there is something I learned from the notebook, and from Sage code as well too : you can *NEVER* trust any tool that the developpers do not use for themselves.

At some point we discovered stupid bugs in the notebook that appeared when you wanted to print matrices, and that was during Sage days, the only moment when the developpers seem to use the notebook. And well, whatever the developpers use for themselves will be improved over time, and I really believe that what they only provide for users and not for themselves will always be broken, or unreliable.

Actually, this all means that I will only believe in the usefulness of the dev scripts if we end up using them. In this case they can become totally cool things indeed. But well. Right now, the dev scripts have (necessarily) been developped by experiences git users, as a service to all others ^^;

> If the current state of affairs is that the dev scripts are still
> under construction, so that for the time being Sage development is
> only possible by using git directly, then this needs stating very
> clearly.  I was under the impression that the dev scripts were ready
> for use, and was testing this proposition by trying to use them.

Well. You trying them can only help I guess. I mean. All the bugs that they *might* contain will have to be found and fixed, and doing so quickly can only help.

Nathann

[Jeroen Demeyer]

On 2013-12-17 14:37, Nathann Cohen wrote:
> Personally, I don't think that those dev scripts are a very good idea

What I like most is the automatic interaction with Trac, that's very cool.

[Nathann Cohen]

> +1, very good question. I also think that this is a major missing feature from sage-git. With the obsolete system of patches on Trac, at least one could easily see the code belonging to a given ticket.

Well, here is my attempt at bringing this topic up, though you can see what happened :-P

https://groups.google.com/d/topic/sage-git/ZC5QB1o1JlE/discussion

Seeing the dependencies right now it terribly tricky if not totally impossible. I now always add the trac number in the commit messages so that this could be a bit clearer :
http://trac.sagemath.org/ticket/15521

But for the older tickets, i.e. before I thought of doing this, knowing what there is to review and what belongs to another ticket is...
Well, hell :
http://trac.sagemath.org/ticket/15288
(in the list of commits, all those which are older than "Orthogonal arrays" belong to other tickets)

Nathann

[Nathann Cohen]

> What I like most is the automatic interaction with Trac, that's very cool.

Well, then I definitely have to try them. I quite enjoy the fact that
"git push" updates the ticket and adds a comment with a new commit
already :-)

Nathann

[Volker Braun]

git diff ^master

should be equivalent to

sage -dev diff --base master

Make sure that your master branch is up-to date by pulling from the git repo first. If the above has too much stuff then it is pretty clear that you haven't updated master. It is a fundamental goal of git to be able to develop without having a network connection, and a side-effect of that is that changes in the remote repo are only available after you download them.

[John Cremona]

On 17 December 2013 13:42, Nathann Cohen <nathan...@gmail.com> wrote:
>> +1, very good question. I also think that this is a major missing feature
>> from sage-git. With the obsolete system of patches on Trac, at least one
>> could easily see the code belonging to a given ticket.
>
> Well, here is my attempt at bringing this topic up, though you can see what
> happened :-P
>
> https://groups.google.com/d/topic/sage-git/ZC5QB1o1JlE/discussion

I did read that discussion. My own situation was very much simpler,
since the ticket has no dependencies and the patch (if I may call it
that) only affected one file. I had also previously (4 months ago)
looked at the ticket when there was only one commit on it; now there
are 3. So I suppose one possibility is to look at all the commits
which are mention on that ticket and compare each with its parent.
For example

git diff 94e3516^ 94e3516

shows me (I think) what changes were made by one of the commits. So
as long as I can find out which commits are relevant, I can do it. On
this ticket #8723 there are three commits and I just looked at each
one's diff from its predecessor, and I can see what the author did.
That's a good start!

John

>
> Seeing the dependencies right now it terribly tricky if not totally
> impossible. I now always add the trac number in the commit messages so that
> this could be a bit clearer :
> http://trac.sagemath.org/ticket/15521
>
> But for the older tickets, i.e. before I thought of doing this, knowing what
> there is to review and what belongs to another ticket is...
> Well, hell :
> http://trac.sagemath.org/ticket/15288
> (in the list of commits, all those which are older than "Orthogonal arrays"
> belong to other tickets)
>
> Nathann
>

[Stefan van Zwam]

I looked at what the Trac website has to offer for this ticket. Turns out the links under the "branch" field show only one commit (or only the difference between the second-last and last commits, I think). This is not very informative...

[John Cremona]

I agree, I looked there (and all over the ticket) but while come
commits are meentioned with visible hashes, not all are. I was able
to determine the relevant 3 commits using "git log", but this was a
relatively simple case.

Is it unreasonable or impossible to provide a single list of the
commits (their hashes) on the ticket, jsut as there used to be a list
of attached patches (I just stopped myself from saying "in the good
old days").

John

[Ralf Hemmecke]

> git diff ^master
>
> should be equivalent to
>
> sage -dev diff --base master

I don't know much about the plan for "sage -dev", but I generally think,
it's a bad idea to maintain two interfaces for the same task.

Why should git-savvy people learn the "sage -dev"-way? Why waste time
documenting the "sage -dev" way?

Git is a collection of scripts, so it would equally well be possible to
provide git related things through calling git. For example, I've
written a script git-snapshot which commits all files in the current
directory to a branch called "snapshot" but does otherwise not change
anything. That script lies under $HOME/bin, i.e. is in my PATH and thus
I can easily call it via

git snapshot

just as any other command.

Just my 2 cents.

Ralf

[Volker Braun]

On Tuesday, December 17, 2013 2:33:54 PM UTC, Ralf Hemmecke wrote:

I don't know much about the plan for "sage -dev", but I generally think,
it's a bad idea to maintain two interfaces for the same task.

I tend to agree, though there is something to be said for scripting the interaction with the trac server. For now, this is what we have. You are welcome to work on a better solution. I'm using and working on https://github.com/sagemath/git-trac-command for a "git trac" subcommand that just implements the trac interaction without trying to reinvent the wheel. 

[Volker Braun]

Correction: If you want to use plain git, you need to first merge with master (otherwise you don't just get the diff of what was added in the ticket, but also what was added to master since the ticket branch was forked).

git checkout my_ticket

git merge master

git diff ^master

git reset --hard HEAD~

The dev script would do that for you except that #8723 was forked off before the dev scripts were implemented. So once you checkout the ticket, you lose the dev scripts. But for new tickets "sage -dev diff --base master" should work.

[John Cremona]

On 17 December 2013 14:47, Volker Braun <vbrau...@gmail.com> wrote:
> Correction: If you want to use plain git, you need to first merge with
> master (otherwise you don't just get the diff of what was added in the
> ticket, but also what was added to master since the ticket branch was
> forked).
>
> git checkout my_ticket
> git merge master
> git diff ^master

OK so far -- I did those three and I am seeing the diffs I was expecting!

> git reset --hard HEAD~

This made me very nervous and I read some man pages before doing it,
but then did it anyway. After doing it, git diff ^master no longer
showed just the changes from the ticket but a vast amount of other
stuff. I am not sure this is where I want to be.

John

>
> The dev script would do that for you except that #8723 was forked off before
> the dev scripts were implemented. So once you checkout the ticket, you lose
> the dev scripts. But for new tickets "sage -dev diff --base master" should
> work.
>

[Volker Braun]

On Tuesday, December 17, 2013 3:09:18 PM UTC, John Cremona wrote:

> git reset --hard HEAD~

This made me very nervous and I read some man pages before doing it,
but then did it anyway.  After doing it, git diff ^master no longer
showed just the changes from the ticket but a vast amount of other
stuff.  I am not sure this is where I want to be.

That just undid the merge, so you are back on the ticket where the diff contains a lot of stuff that was added to master that is not yet in the ticket. 

The last step is optional, if you just want to review the ticket then you can just discard the merged branch when you are finished. 

If you want to make changes to the ticket and upload them then you should not commit the merge to the ticket, as it will make the ticket history confusing to read. However, if it makes it easier for you to keep the merge (e.g. because it pulls in dev scripts that you depend on) then it is not strictly forbidden either.

[Nathann Cohen]

Yoooooooo !!

> I did read that discussion.  My own situation was very much simpler,
> since the ticket has no dependencies and the patch (if I may call it
> that) only affected one file.   I had also previously (4 months ago)
> looked at the ticket when there was only one commit on it; now there
> are 3.  So I suppose one possibility is to look at all the commits
> which are mention on that ticket and compare each with its parent.
> For example
>
> git diff 94e3516^ 94e3516
>
> shows me (I think) what changes were made by one of the commits.  So
> as long as I can find out which commits are relevant, I can do it.  On
> this ticket #8723 there are three commits and I just looked at each
> one's diff from its predecessor, and I can see what the author did.

Oh. Then I guess Volker's command "git diff ^master" does the job. But it you allow me to insist, running "tig" would make it infinitely easier ! You can navigate and inspect each commit easily... Really really, it's a cool thing ! :-P

Nathann

[John Cremona]

On 17 December 2013 15:20, Volker Braun <vbrau...@gmail.com> wrote:
> On Tuesday, December 17, 2013 3:09:18 PM UTC, John Cremona wrote:
>>
>> > git reset --hard HEAD~
>>
>> This made me very nervous and I read some man pages before doing it,
>> but then did it anyway. After doing it, git diff ^master no longer
>> showed just the changes from the ticket but a vast amount of other
>> stuff. I am not sure this is where I want to be.
>
>
> That just undid the merge, so you are back on the ticket where the diff
> contains a lot of stuff that was added to master that is not yet in the
> ticket.

I see: so were proposing that if I wanted to see just the changes made
by the ticket, I should merge, look at the changes, and then unmerge
(in effect).

>
> The last step is optional, if you just want to review the ticket then you
> can just discard the merged branch when you are finished.

Of course. But if I did want to make some "reviewer changes" then I
should continue with the unmerged branch, correct?

>
> If you want to make changes to the ticket and upload them then you should
> not commit the merge to the ticket, as it will make the ticket history
> confusing to read. However, if it makes it easier for you to keep the merge
> (e.g. because it pulls in dev scripts that you depend on) then it is not
> strictly forbidden either.

OK. I guess an alternative would be to use git rebase to rebase the
ticket branch onto the current master branch; then upload that to the
ticket, whcih would make it easier for others to look at it (until
master changes again, of course). But pehaps it should be the ticket
author, rather than the reviewer, who does any rebasing.

John

[Volker Braun]

On Tuesday, December 17, 2013 3:32:58 PM UTC, John Cremona wrote:

OK.  I guess an alternative would be to use git rebase to rebase the
ticket branch onto the current master branch;  then upload that to the
ticket, whcih would make it easier for others to look at it (until
master changes again, of course).  But pehaps it should be the ticket
author, rather than the reviewer, who does any rebasing.

Don't rebase branches that are out in the open, that is, attached to trac tickets for everybody to see. Somebody might have branched off from there already, and by rebasing (rewriting history) you would invalidate their branch.

[John Cremona]

That is a good point. But what a pity. It might make it impossible
for a branch to be properly tested and given a positive review! It is
not enough for me to be happy with new code and test that it works on
top of some months-old version of master, surely a positive review
could only be given to something which could be merged with the
current master, just as in the old system a patch could only get a
positive review if it applied to the current Sage version?

It is rather tempting to say, instead, to anyone basing work on a
branch which is still in a experimental state, that it is the second
brancher's responsibility to ensure that their work is consistent with
merged branches. Isn't anything else going to completely stifle
development? How can I continue to work on a branch after pushing it
to a trac ticket, if I am not allowed to make changes that might
affect anyone who has branched off of that?

[Ralf Hemmecke]

> git checkout my_ticket
> git merge master
> git diff ^master
> git reset --hard HEAD~

I guess you want to use

git diff master...ticket

https://www.kernel.org/pub/software/scm/git/docs/git-diff.html

Ralf

[Volker Braun]

On Tuesday, December 17, 2013 3:59:42 PM UTC, John Cremona wrote:

That is a good point.  But what a pity.  It might make it impossible
for a branch to be properly tested and given a positive review!

 

You can merge with the current master and then build the ticket to check that it still builds. There is no point in checking in the merge as the release manage will have to merge the ticket either way, the extra merge just clutters the history.

Review mostly means reading the code and check that it is of good quality. Of course that includes running it and verifying that it produces the desired result. But checking that it still works with the most recent version is IMHO better done by the computer, that is what the patchbot / buildbot are good for.

development?  How can I continue to work on a branch after pushing it
to a trac ticket, if I am not allowed to make changes that might
affect anyone who has branched off of that?

You can (and are encouraged to) keep working on it, just add more commits. Git is a system to join the resulting directed-acyclic graph of commits back into a consistent source tree. 

[Jeroen Demeyer]

On 2013-12-17 17:13, Volker Braun wrote:
> the extra merge just clutters the history.

Interesting point. Is that something that should be actively avoided?

Let me explain why I ask this: I am currently working (with Peter Bruin)
on various tickets related to PARI. At some point I merged one branch
into another. I could have developed this branch independently, but I
was afraid there could be conflicts because both branches touch the same
file. It turns out there were no conflicts, but that's hard to tell
without doing the merge.

Jeroen.

[Nathann Cohen]

Yoooooooooooooo !!

> Interesting point. Is that something that should be actively avoided?
>
> Let me explain why I ask this: I am currently working (with Peter Bruin) on
> various tickets related to PARI. At some point I merged one branch into
> another. I could have developed this branch independently, but I was afraid
> there could be conflicts because both branches touch the same file. It turns
> out there were no conflicts, but that's hard to tell without doing the
> merge.

I think Volker just had merging with a more recent Sage release in mind. In many cases you are forced to merge unreviewed branches into the one you are developping. Because you may need many tickets to implement a big feature, or just because you notice bugs by writing new code, and that you cannot use the new code without fixing the bugs at the same time (in another ticket).

Nathann

[Volker Braun]

On Tuesday, December 17, 2013 4:20:53 PM UTC, Jeroen Demeyer wrote:

On 2013-12-17 17:13, Volker Braun wrote:
> the extra merge just clutters the history.
Interesting point. Is that something that should be actively avoided?

Yes. Just don't do it.

Slightly longer answer: only make commits if you have a reason (which then goes into the commit message). Just because there might be a conflict is not a reason (having an actual conflict of course is). Its trivial to check that there is no conflict in case you are worried. Also, git is very good at resolving conflicts later so its not a big deal if there happens to be a conflict with another ticket.

 

[Jeroen Demeyer]

On 2013-12-17 17:32, Volker Braun wrote:
> Its trivial to check that there is no conflict in case you are worried.

OK, how?

[Volker Braun]

For example, by merging and then throwing away the merge.

Another way of "throwing away" the merge (besides the "git reset --hard HEAD~") is to do it in an anonymous branch, that is, on a "detached head":

git checkout --detach my_branch

git merge master

... do whatever you want on the detached head ...

git checkout my_branch   # leave detached head mode

[John Cremona]

I have been reviewing #8723 where there are a few commits based on a
rather old version of master (before the dev scripts). I found some
things which needed fixing so I made a new commit (based on the last
commit already on the ticket). Now I want to push the changes back to
trac. I cannot use "sage -dev push" since on this branch there are no
dev scripts. I tried plain "git push trac" but got this:

jec@atkin:~/sage (branch: ticket/8723)$ git push trac ticket/8723
X11 forwarding request failed on channel 0
Counting objects: 13, done.
Delta compression using up to 64 threads.
Compressing objects: 100% (7/7), done.
Writing objects: 100% (7/7), 841 bytes, done.
Total 7 (delta 6), reused 0 (delta 0)
remote: FATAL: W refs/heads/ticket/8723 sage cremona DENIED by fallthru
remote: error: hook declined to update refs/heads/ticket/8723
To ssh://g...@trac.sagemath.org:2222/sage.git
! [remote rejected] ticket/8723 -> ticket/8723 (hook declined)
error: failed to push some refs to 'ssh://g...@trac.sagemath.org:2222/sage.git'

Any idea why that did not work? I would like my commit to get added
there since it solves a problem I have reported on there.

John

[Volker Braun]

You only have write permissions for branches named u/cremona/... or public/... 

To push the current local branch to u/cremona/8723 (or pick a better description if you want):

git push trac HEAD:u/cremona/8723

This is also in the developer guide SAGE_ROOT/src/doc/output/html/en/developer/manual_git.html under "Pushing Your Changes to a Ticket".

[Marc Mezzarobba]

John Cremona wrote:
>> Don't rebase branches that are out in the open, that is, attached to
>> trac tickets for everybody to see. Somebody might have branched off
>> from there already, and by rebasing (rewriting history) you would
>> invalidate their branch.
>
> That is a good point. But what a pity. It might make it impossible
> for a branch to be properly tested and given a positive review!

Quite the opposite IMHO: refraining from rebasing code that is up for
review makes it easy for people to maintain personal sage trees (or
unofficial public trees) in which the code is tested for an extended
period of time.

--
Marc

[John Cremona]

On 17 December 2013 17:25, Volker Braun <vbrau...@gmail.com> wrote:
> You only have write permissions for branches named u/cremona/... or
> public/...
>
> To push the current local branch to u/cremona/8723 (or pick a better
> description if you want):
>
> git push trac HEAD:u/cremona/8723
>
> This is also in the developer guide
> SAGE_ROOT/src/doc/output/html/en/developer/manual_git.html under "Pushing
> Your Changes to a Ticket".
>

OK, my mistake, sorry. (That part of the manual should be renamed to
something other than "Git the hard way" !!)

Your instructions worked, at leadst in the sense that the output from
the git command suggested that it had done the right thing, but I
cannot see the new branch (called u/cremona/8723) on the trac ticket.
I guess that is something extra which the dev script would have seen
to? Do I need to do more? Should I manually change the ticket fields
branch (to u/cremona/8723) and commit (to
1fec98388ed6689f1ec86c9b32f5bf298122c320) ?

Thank you for your patience.

John

[Volker Braun]

You need to manually change the Branch: field on the ticket. Trac can't know yet that you want to attach that newly-created branch to the ticket. The commit field is filled out automatically for you.

[John Cremona]

On 17 December 2013 17:48, Volker Braun <vbrau...@gmail.com> wrote:
> You need to manually change the Branch: field on the ticket. Trac can't know
> yet that you want to attach that newly-created branch to the ticket. The
> commit field is filled out automatically for you.

Thanks, I have now done that. To expand: after the manual changes to
the Branch field are saved, trac automatically updates the Commit
field. Neither happens just by pushing a new commit to trac. I
suppose that is because with a plain git command, the trac repository
cannot know which ticket is the relevant one; and that was one thing
which the sage-dev version could do more cleverly.

The upshot is that I have (at last!) completed by first ever review
using the git system, including adding some reviewer's fixups. And
perhaps all my questions about this should have been on sage-devel
rather than sage-git. Too bad.

John

>
>
>
> On Tuesday, December 17, 2013 5:42:16 PM UTC, John Cremona wrote:
>>
>> On 17 December 2013 17:25, Volker Braun <vbrau...@gmail.com> wrote:
>> > You only have write permissions for branches named u/cremona/... or
>> > public/...
>> >
>> > To push the current local branch to u/cremona/8723 (or pick a better
>> > description if you want):
>> >
>> > git push trac HEAD:u/cremona/8723
>> >
>> > This is also in the developer guide
>> > SAGE_ROOT/src/doc/output/html/en/developer/manual_git.html under
>> > "Pushing
>> > Your Changes to a Ticket".
>> >
>>
>> OK, my mistake, sorry. (That part of the manual should be renamed to
>> something other than "Git the hard way" !!)
>>
>> Your instructions worked, at leadst in the sense that the output from
>> the git command suggested that it had done the right thing, but I
>> cannot see the new branch (called u/cremona/8723) on the trac ticket.
>> I guess that is something extra which the dev script would have seen
>> to? Do I need to do more? Should I manually change the ticket fields
>> branch (to u/cremona/8723) and commit (to
>> 1fec98388ed6689f1ec86c9b32f5bf298122c320) ?
>>
>> Thank you for your patience.
>>
>> John
>

[Robert Bradshaw]

On Tue, Dec 17, 2013 at 5:41 AM, Jeroen Demeyer <jdem...@cage.ugent.be> wrote:
> On 2013-12-17 14:37, Nathann Cohen wrote:
>>
>> Personally, I don't think that those dev scripts are a very good idea
>
> What I like most is the automatic interaction with Trac, that's very cool.

+1

IMHO, sage -dev should be primarily cover trac interaction, and not
try to duplicate/wrap what can be done with raw git (which can easily
enough be learned, especially with a sage-specific cheat sheet, and
provides a smoother path into advance usage and transfers to other
domains).

- Robert

[Robert Bradshaw]

On Tue, Dec 17, 2013 at 5:36 AM, Jeroen Demeyer <jdem...@cage.ugent.be> wrote:
> On 2013-12-17 13:08, John Cremona wrote:
>>
>> But to review a ticket we need to know how far back to
>> go in this, and how do we do that?
>
> +1, very good question. I also think that this is a major missing feature
> from sage-git. With the obsolete system of patches on Trac, at least one
> could easily see the code belonging to a given ticket.

git log ticket ^master

will give you the list of commits in ticket not in master

git log ticket ^master ^dep1 ^dep2 ...

will also exclude commits that occur in the dependencies. git log -p
will give each diff. It would be really nice if this were
automatically computed and links to each commit diff was given on trac
in a standard location. Also

git diff $(git merge-base master ticket) ticket

will the consolidated diff of ticket against the master branch at the
point it was branched off (or the last merge). If there's a single
dependency, substitute that for master. If there are many
(non-transitive) dependencies you'd probably have to merge all the
deps into a common branch first, e.g.

git checkout -b all_deps dep1
git merge dep2
...
git diff $(git merge-base all_deps ticket) ticket

I think this is the sage -dev gather.

- Robert