#14982: Coercion from rings with coerce_embedding into constructions over those
rings is broken
-------------------------------------------------+-------------------------
Reporter: mmezzarobba | Owner:
Type: defect | Status:
Priority: major | needs_review
Component: coercion | Milestone: sage-6.0
Keywords: embedding | Resolution:
Authors: Marc Mezzarobba | Merged in:
Report Upstream: N/A | Reviewers:
Branch: | Work issues:
u/mmezzarobba/coerce_embeddings | Commit:
Dependencies: | Stopgaps:
-------------------------------------------------+-------------------------
Comment (by SimonKing):
Replying to [comment:7 mmezzarobba]:
> If you already have a git-based installation of sage (i.e. you once did
something like `git clone https://github.com/sagemath/sage.git && git
checkout -b origin/build_system && make build`)
I have. But at least on one of my machines I get several doctest errors
with the latest git version.
> and a remote that refers to the trac server,
I did store my ssh keys on trac. But "having a remote" sounds like I need
to inform git about the existence of the trac server.
> you just need to fetch and checkout the branch
`u/mmezzarobba/coerce_embeddings` from trac
I hope the meaning and how-to of "fetch" and "checkout" will be clear to
me from the git-developer-guide.
> http://sagemath.github.io/git-developer-guide/
> (or ask!) in case you need more information on how to do that.
I saw this (or an old version) before, which made me register my ssh keys,
for example.
> All three commits need review, and none of them is part of any other
ticket. I am not sure if/where the ticket number should go in the commit
logs (perhaps it would make more sense to put it in the message associated
to the ''merge'' commit?). The last commit of the branch is also the one
that fixes the issue the ticket is about, so I put it here, but I can
rewrite history to add it to the two other commits if you want.
No idea about this. From the discussion on sage-git, it seems to me that
the git branches can be totally orthogonal to what one used to do with
patches. A branch may span over different tickets, and it is totally
unclear ''from the commits themselves'' which of them belong to a ticket
and which of them belong to a dependency. That's bad for reviewing. In the
old model, one would talk about a list of patches ''attached to the
ticket'', which makes it crystal clear what ticket a patch belongs to.
--
Ticket URL: <http://trac.sagemath.org/ticket/14982#comment:8>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/groups/opt_out.
