#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 vdelecroix):
Replying to [comment:29 tscrim]:
> Replying to [comment:20 vdelecroix]:
> > Please, have a look at http://git-scm.com/book/en/Git-Tools-Rewriting-
History
> >
> > It does not makes sense to cancel commits by adding another commit!!
>
> Yes it does; it is good git workflow in order to see what has done. I
strongly encourage it. It is bad to rewrite history in released branches
that people might have pulled. This includes forced pushes (the `-f`
option).
If somebody pulled it, he might have noticed that the history is dirty! My
claim was about how people should write commits '''before''' submission to
trac. You have the right to make a mistake and to change it. Nevertheless
the branch has not disappeared from git so people are free to use it. If
anybody has based his work on the last commit of a development branch
without acknowledging the author it was just a stupid idea.
I mostly agree with [http://www.mail-archive.com/dri-
[email protected]/msg39091.html] about clean history.
> Again, the proper way to use git is to make more commits which revert
changes!!
No. The timeline of a ticket is most of the time the timeline of a commit
(except very exceptional cases). Reverting changes can be done at home
(and it is good to do it) but not on trac.
If I pull I really do not want to see
{{{
commit 1: make a change in toto.py
commit 2: make a change in foo.py
commit 3: cancel a change from commit 1
commit 4: cancel a change from commit 2
commit 5: redo some changes introduced from commit 3
...
}}}
perhaps you do, but personally I will not review a ticket with 10+
commits.
> > EDIT: and you should not merge a beta release if there is no need to.
There is a need only if there is a non-trivial conflict. Now there are 10+
commits in this ticket and there are completely screwed up by several
merge of beta releases...
>
> There is, it's a PITA to rebuild sage when switching branches and the
merge commits do not hurt anything. Look at the differences between the
beta versions using `git diff`. There are also easy options to see the
commits which are not in `develop` by
> {{{
> git log --no-merges ^develop
> }}}
I agree that it is a PITA. But, it is not because of git but because of
the build system. There is nothing wrong during the review process to
merge '''locally''' the branch you are reviewing into the develop branch.
> Quit thinking commits are like patches, they are not. Git workflow
actually recommends lots of little logical commits (I'm actually somewhat
bad about this).
I agree but they should reflect the logic of the code implemented and
'''not''' the author workflow.
Vincent
--
Ticket URL: <http://trac.sagemath.org/ticket/16331#comment:31>
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.
