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
Date: Thu Oct 30 22:30:11 2014 +
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.
