#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 mmezzarobba):
(It looks like you got most of this sorted out, based on you posts on
sage-git. I'm replying anyway just in case; please feel free to ask for
more detail!)
Replying to [comment:8 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.
Yes. These are rather minor issues that are handled elsewhere.
> > 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.
Yes:
{{{
git remote add trac ssh://[email protected]:2222/sage.git
}}}
(With this setup, `git fetch trac` will automatically download copies of
all branches available on the trac server. This will likely mean hundreds
of branches when everyone switches to git. They don't live in the same
namespace as your local branches and don't pollute the output of most
commands. But if you don't like that behaviour, you can use `-t` to limit
the subset of branches to track.)
> > 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.
* fetch = synchronize your local repository's view of the branches on trac
(!= your local branches) with their remote state:
{{{
git fetch trac
}}}
* checkout = get the contents of a given revision in the form of actual
files in your working directory:
{{{
git checkout -b my_local_review_branch -t
trac/u/mmezzarobba/coerce_embeddings
}}}
* The last command also sets up a local branch for you to work on (e.g.,
to prepare a reviewer patch). If you only want to have a look at some
remote branch, you can omit the `-b` and `-t` options. git will issue a
scary warning about detached heads. That "detached head state" is when you
don't have anywhere to commit your changes if you make any.
If you want to prepare a reviewer patch, you will need to:
* Make your changes.
* Commit them to your local review branch (`git commit -a` to commit
everything).
* (Repeat if there are several unrelated changes.)
* Once you are happy with your local changes, push them somewhere on trac:
{{{
git push trac my_local_review_branch:trac/u/SimonKing/coerce_embeddings
}}}
* Tell me about the new branch you created on trac, or just put its name
in the Branch: field.
> 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,
A git branch is just a pointer to a commit (and thus implicitly to
everything that precedes it history-wise). So in some sense it every
branch spans the whole history of sage, but otherwise a branch cannot
really span several tickets.
(There are several other kinds of "pointers to commits" in git. Branches
are pointers to commit that move up automatically when new commits are
added "on" them.)
> 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.
I agree, and that's why I started this thread...
--
Ticket URL: <http://trac.sagemath.org/ticket/14982#comment:11>
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.
