Thread (15 messages) flat view 15 messages, 7 authors, 2016-06-15

Re: question concerning branches

From: Theodore Tso <tytso@mit.edu>
Date: 2016-06-15 22:47:17

On Wed, Aug 19, 2009 at 09:45:00PM +0200, Ingo Brueckl wrote:
Jakub Narebski [off-list ref] writes:
quoted
You finish old work (or stash it away), _then_ you begin new work.
Ok, this helps me a little bit to understand.

The branches aren't designed to split my work, but rather something to
collect the different parts of my work.

But as software development often is something where you are coding on
several issues at the same time which can't be committed immediately, it
sounds that 'stash' is the developer's best friend.
Context switching has overhead; so it's usually better to try to
complete one task before switching to another.  Granted, sometimes it
can't be done, but it's something you should really try to do.

Also, commits are easier to review if they are kept small; if you
localize changes into separate commits, it's often easier to detet
problems when doing "git bisect", for example.  So if you are often
needing to switch while leaving something that isn't ready to be
committed, you might want to ask yourself if you are putting too many
changes into a single ocmmit.

Personally, in the cases where I can't finish a commit before I need
to switch away to another branch, my preference is to not use "git
stash", but instead to create a topic branch, and then check in a
partially completed change on the topic branch, which I can later
ammend using "git commit --amend" (or if I have multiple commits on
the topic branch, "git rebase --interactive").  This is because I can
use the commit description to leave myself some notes about what still
needs to be done before the commit can be finalized.

						- Ted
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help