Am 13.07.2015 um 20:10 schrieb Aaron Meurer:
- Greatly increases the complexity of git for new users.
Agreed. I would recommend it only for people who are willing to write it.
- You can create commits that don't do what they say they do.
Yes for non-interactive rebases.
For an interactive rebase, you can and should review the commit comment.
- You can lose data
<https://asmeurersympy.wordpress.com/2009/06/22/how-to-permanently-lose-data-with-git-and-then-retrieve-it-again/>
.
- git rebase puts your repository in a rebase "mode", which, unless
you have the right tools in your prompt, you may forget you are in
(this is how I lost a lot of data using it).
Yeah, I can feel that pain.
"git status" is your friend for that. I made a habit of doing that
before starting to work on anything, and before committing, pushing, or
about any other git command (well, not every single command, but you get
the drift). That has been working quite well for me.
- Rebasing requires you to force push, which gives you bad habits
(particularly, the bad habit of force pushing).
True.
Not a real issue for pushing PRs.
I *think* if I had write access I'd use a separate directory for updates
to the master repo. I'd probably want to configure git so that it
refuses to force-push from that directory, so that any bad habit can't
have a consequence.
- Rebased branches are more difficult to review on GitHub. Normally, you
see new commits at the bottom of the discussion, but when the branch is
rebased, all commits are new commits. If the rebase squashes commits, you
have no hope of seeing only the new changes.
The bottom discussion always survives.
I *think* I saw code lines discussions survive, too, in those cases
where a chunk of lines survived the rebase. I'm not sure about when
exactly that works and when it does not.
Essentially, a rebase requires another round of review to check that all
the things discussed are still in there. Maybe there's a way to diff the
rebase result against the state of the last commit on GitHub (there
certainly is on a local git but that's going to be too much burden on
the reviewer). In general, the policy should be "do not change anything
under a rebase".
- Merge conflicts are more difficult to deal with when rebasing.
I thought so myself, until I changed my approach to rebasing within my
working branch first, merge commits until each piece of code isn't
modified by more than one commit, *then* rebase with master.
So far, the net result was just the kind of conflicts that I'd have
gotten with a merge.
- Most fundamentally, rebasing *changes the revision log*. This completely
negates the whole purpose of using a version control system, which is to
*track* *the revision log*.
If this were true, Linus wouldn't have allowed rebasing in git.
I think the revision log is a means to an end. The end being the ability
to reproduce previous revisions, and keep a record of decisions. Cutting
out decisions that were dead ends, misunderstandings, and multiple
iterations on less important stuff (PEP8 comes to mind) is a good thing;
we do not need the interim versions, and there are no relevant decisions
worthy of logging.
Furthermore, git handles "non-clean" history just fine:
- Use git log --graph when viewing history. Or use a tool that shows the
history as a graph like gitk or gitx.
I'm not nervous about the branches themselves.
What I find hard to read is long-running branches at the merge point;
I'm getting all the changes all at once; if I don't understand them, I
have to go back on the side branch, mentally rewinding to the point in
time when the side branch forked off. In the end, when I understand what
the side branch did and why, I usually find I forgot what I was
investigating, so I have to mentally rewind again.
I find this hard enough for two branches. If more than two branches are
involved, I expect that to become virtually impossible.
Rebasing rearranges things into a linear history. I never have to
rewind; if I find something uninteresting, I can mentally skip ahead.
- git bisect does handle merge commits. It only doesn't know what to do
when there is an ambiguity (that is, the bad change comes from the merge
resolution itself), which is rare.
The more you merge the more often it will happen.
A lot depends on how many long-running branches are in existence I think.
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/55A4145F.9000403%40durchholz.org.
For more options, visit https://groups.google.com/d/optout.
