#16331: Game Theory: Build capacity to solve matching games in to Sage.
-------------------------------------+-------------------------------------
Reporter: vinceknight | Owner:
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-6.4
Component: game theory | Resolution:
Keywords: Game Theory, | Merged in:
Matching Games, | Reviewers:
Authors: | Work issues:
Report Upstream: N/A | Commit:
Branch: | 40d4cfaa662913ca6795a8a9a598b53cf931809c
u/vinceknight/game_theory__build_capacity_to_solve_matching_games_in_to_sage_|
Stopgaps:
Dependencies: |
-------------------------------------+-------------------------------------
Comment (by tscrim):
I know this will sound snarky/condescending, but I do honestly mean it.
You should probably learn more git in order to be a better reviewer.
There is a good reason to merge the latest develop version, you never know
what exactly has changed. Unless you're relying only on python (which I
highly doubt is the case), you can get into subtle changes which can break
your program (for example, output format was changed from a list into a
tuple; I've been bitten by this).
For the most part I don't look at the commit history when reviewing a
ticket, instead I look at the overall diff from develop/dependencies.
Afterwards if additional changes are made, then it's commits, but I'd
rather see the forest than tree by tree.
IMO, useless commits are ones which merge in individual unrelated tickets
(for example, one on elliptic curves), or merge in commits from a
dependency 1 by 1 which don't impact the current ticket.
From Vincent's example of undoing ''all'' changes immediately and pushed
to trac, then you can consider starting a new branch in those cases as
there is nothing inbetween (and changing the branch field on the ticket).
However if there are additional commits, you either might want to cherry-
pick them in or just continue on. Sometimes you realize things are
unneeded and having that in the history is a good note. Nevertheless
partial commit revisions deserve their own commits. As Nathann said, it's
the ''code'' you want the reviewer to read, not the ''history''. (Although
when it comes to design decisions, especially if the author is not around,
having the workflow in the history can give some insight.)
Again, commits are not the patches of Hg.
I'm happy to review of this ticket since I have no qualms about the
current branch (although if Vince can merge in develop and push, I'd
appreciate that).
--
Ticket URL: <http://trac.sagemath.org/ticket/16331#comment:36>
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/d/optout.
