git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Theodore Tso <tytso@mit.edu>
To: Ingo Brueckl <ib@wupperonline.de>
Cc: Jakub Narebski <jnareb@gmail.com>, git@vger.kernel.org
Subject: Re: question concerning branches
Date: Wed, 19 Aug 2009 16:39:17 -0400	[thread overview]
Message-ID: <20090819203917.GH27206@mit.edu> (raw)
In-Reply-To: <4a8c51f5@wupperonline.de>

On Wed, Aug 19, 2009 at 09:45:00PM +0200, Ingo Brueckl wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
> 
> > 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

  parent reply	other threads:[~2009-08-19 20:39 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-19 17:33 question concerning branches Ingo Brueckl
2009-08-19 18:07 ` Bruce Stephens
2009-08-19 18:07 ` Avery Pennarun
2009-08-19 18:31   ` Ingo Brueckl
2009-08-19 19:08     ` Jakub Narebski
2009-08-19 19:45       ` Ingo Brueckl
2009-08-19 19:50         ` Avery Pennarun
2009-08-20  7:57           ` Matthieu Moy
2009-08-19 19:53         ` Jacob Helwig
2009-08-19 20:01         ` Jakub Narebski
2009-08-19 20:39         ` Theodore Tso [this message]
2009-08-19 20:57           ` Jakub Narebski
2009-08-20 17:37             ` Theodore Tso
2009-08-19 21:51         ` Linus Torvalds
2009-08-20  3:01           ` Randal L. Schwartz
2009-08-20 12:46           ` Ingo Brueckl
2009-08-20 13:47             ` Johannes Sixt
2009-08-20 14:59               ` Jakub Narebski
2009-08-19 18:35 ` Junio C Hamano
2009-08-19 19:21   ` Ingo Brueckl
2009-08-20  7:33     ` Andreas Ericsson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090819203917.GH27206@mit.edu \
    --to=tytso@mit.edu \
    --cc=git@vger.kernel.org \
    --cc=ib@wupperonline.de \
    --cc=jnareb@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).