I've had this discussion a lot of times, and while i understand why you
disagree, i'll be the fucking blunt german i am, and bow to the reality
that there is no polite way to say what i'll need to say: Some of your
disagreements come from a lack of experience, compared to the body of
experience i have gathered in by working in a team with (notably) mst and
most of the core and toolchain hackers of Perl and CPAN. Also, frankly,
you have in part overread things i stated.
Then again, me addressing the points in detail will probably help
enlighten the other readers, or cement my position as a german git nazi,
giving me a decent enough chance of an outcome i prefer, and a chance at
I always use 'git rebase' to keep my branches up to date.
I assume you mean "feature branches". And, as i stated, it's fine to
rebase if "you can accurately predict the result". For someone asking for
materials to explain rebase and friends the likelihood of this being true
trends towards zero.
Also important to note here is that rebase can easily silently break
things. A rebase will try to automatically resolve things, and the bigger
the drift between your branch and the target you're rebasing onto, the
higher the likelihood that git's algorithm misunderstands your intentions
and resolves a conflict in a manner you didn't intend to. Doing a rebase
means trusting the machine, and you can only truly trust the machine if
you understand what it does.
At the very least one must create a marker branch head on one's old branch
head (as indicated in the steps alternate to rebase), so one can compare
the two after the rebase to see if git broke something.
I always merge feature branches to master with a --no-ff merge as I want
the merge commit to indicate what commits were part of the feature.
This can be appropiate if you are, as i stated "absolutely and utterly
[...] desperate", meaning you have a feature branch whose history is so
amazingly complicated and old that neither rebase of cherry-pick will
allow a clean-up while retaining sanity. In that case a merge commit is a
good label of "dragons be here".
However if you do it casually, all you're doing is making the history
graph of a repo an unreadable mess and the life of anyone needing to dig
in it to figure out by which combination of commits a certain bug was
spawned, a living hell.
The most that is acceptable is to do a merge --no-ff, always prefixed by a
rebase, under these conditions:
- the branch you're trying to integrate is a cthulhic mess and while you
can rebase it, trying to clean it up would ruin your sanity
- the branch contains commits that, out of technical necessity, cannot be
made without breaking the test suite
- the merge commit is entirely free of any additional changes, on penalty
of application of practices confined to carribean islands that have been
separated from modern civilization for centuries
In those cases it's nice to have a standalone merge commit as a "here be
dragons" marker, while retaining a strictly linear history.
Again, unless you are desperate and can with utter confidence articulate
why you are desperate, don't merge.
'git pull --rebase' is also a good idea if others are pushing and you
are committing to master locally.
This is actually a good point. However, let me point out that i still
managed to mess up the explanation of git pull, and should've said the
recommended steps are:
git fetch && git reset && git cherry-pick
This should be plenty of an example to explain why a beginner should
refrain from using the shortcuts.
Also, of note, while `git pull --rebase` is a good idea, it is only a good
idea with the general restriction of rebase, being "only do it if you can
accurately predict the result". Even with a plain rebase that goes through
uncontested there's a good chance that git's algorithm messes up and fixes
conflicts in a way you didn't intend.
'git add' (with -p if needed)
Always with -p. There is no useful difference between `git add` as a
standalone and `git commit -a` when it comes to the risk of creating
useless commits.
It's good though that we did agree on a few points. :)
--
With regards,
Christian Walde
Ha.
I disagree with a lot of this. I always use 'git rebase' to keep my
branches up to date. I always merge feature >branches to master with a
--no-ff merge as I want the merge commit to indicate what commits were
part of the >feature. 'git pull --rebase' is also a good idea if others
are pushing and you are committing to master locally.
I do agree that extensive use of 'git diff' and 'git add' (with -p if
needed) is important and absolutely am against >'git commit -a'
--Tim Jenness
On Sun, Dec 14, 2014 at 3:48 PM, Christian Walde
Post by Christian WaldeI can't recommend a book since i learned git by using it, but i can
- always `git add -p`, any other type of add must be with the absolute
confidence that you know what you're >>doing
- if possible, use `git gui` to make commits
- don't `git pull`, it's a shortcut for `git fetch && git reset`,
unless you can accurately predict the result of a >>pull it's safer to
do those steps manually
- don't `git merge`, unless you know you want a merge commit (this is
something you only want in truly >>desperate situations, and i
absolutely and utterly mean desperate)
- don't `git rebase`, it's a shortcut for `git branch mark && git
reset <target> && git cherry-pick >><old_commits> && git branch -D
mark`, unless you can accurately predict the result of a rebase it's
safer to >>do those steps manually- if you'd really rather rebase than
cherry-pick, always use `git rebase -i`
- get something like tortoisegit to look at repo history. i think `git
gui` has a rudimentary one too. if nothing >>else is available, find a
http://stackoverflow.com/>>questions/1057564/pretty-git-branch-graphs
Finally, don't forget the man pages. You can find them online in nice
formatting.
--With regards,
Christian Walde
Post by David MertensPost by Christian WaldeOn Sun, 14 Dec 2014 22:25:58 +0100, David Mertens
Probably. I read Pro Git a number of years ago, and my git foo has
never really expanded beyond that. >>>Indeed, I probably didn't absorb
some of the latter parts of the book. Git rebasing was something that
I >>>never really understood or practiced. Any good references for
reading about git rebase best practices?
_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters