IMHO the most convenient place is to look in the git history, this also 
works if you don't currently have internet access for starters. The 
git-trac script implements this:

$ git trac find 4f8b380
Commit has been merged in 6.4.rc1.
commit 24c666295fcc1c157503fc212057c27253825099
Merge: 28c5157 b7a04f7
Author: Release Manager <rele...@sagemath.org>
Date:   Thu Oct 30 22:30:11 2014 +0000

    Trac #17257: GCD_list should return zero for an empty list
    
    The function `GCD_list` from `sage.rings.integer` returns one instead of
    zero for an empty list.
    
    URL: http://trac.sagemath.org/17257
    Reported by: slelievre
    Ticket author(s): Samuel Lelièvre
    Reviewer(s): Vincent Delecroix, Peter Bruin


If you want me to update the "merged in" field on trac then post a PR to 
the git-trac script (which includes the release management scripts).



On Saturday, November 15, 2014 8:01:07 AM UTC, Clemens Heuberger wrote:
>
> Am 2014-11-13 um 17:46 schrieb kcrisman: 
> > Unfortunately, we no longer use the "Merged in" part of Trac, which was 
> a VERY 
> > efficient way to find this out.  Searching through git history and then 
> trying 
> > to forward to the next release is something for git wizards, no doubt 
> some 
> > command using tag... amazingly, I found something relevant. 
> > 
> > $ git tag --contains 4f8b380 
> > 6.4.rc1 
> > 6.4.rc2 
>
> I'd use 
> $ git name-rev --tags 4f8b380 
> 4f8b380 tags/6.4.rc1~7^2~1 
>
> so 4f8b380 was followed by one more commit before being merged into 
> develop, 7 
> commits prior to 6.4.rc1. 
>
> (More precisely: start at 6.4.rc1 (6.4.rc1), go 7 commits backwards (~7), 
> take 
> the second predecessor (^2) (it is a merge, so the branch which was 
> merged), go 
> one commit backwards (~1).) 
>
> > It should not be necessary for people to spend time figuring this out, 
> though; 
> > you should be able to work it out without using Trac or searching 
> through 
> > sage-release - indeed, without knowing about "commits" at all, because 
> many 
> > people who want to know what version of Sage has such-and-such fixed 
> won't be 
> > developers, just users. 
>
> I have missed the discussion which led to not using the field "merged in" 
> anymore. What were the reasons? Simply lack of manpower to write a script 
> modifying the "merged in" fields once a new develop release is made? Or 
> not 
> wanting to feed redundant information into trac when it is visible on the 
> git 
> command line, anyway? 
>
> Regards, 
>
> CH 
>
>

-- 
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/d/optout.

Reply via email to