On Thu, 14 Feb 2013 01:02:29 -0800 (PST)
Fabrizio Cioni <fabrizio.ci...@gmail.com> wrote:

> Example:
> 1) I'm working on branch "newfeatures" and i've edited some files
> 2) the customer call and warn me of a bug requiring a quick fix
> 3) i switch from "newfeatures" to "master" and i create a branch
> "fix_2000" from master; while doing this i forget to commit on
> "newfeatures", what i'm working on doesn't conflict with master so
> i'm allowed to carry my editing to "fix", and then commit a mixed up
> bag with horrible results.
> I know that when i switch from a branch to another i get a list of
> the pending changes but... is there a config to set so that i can
> block "git checkout" while there is at least a change pending (being
> it added file - modified  or deleted) ?

I think there isn't.
What you can do, is to create a special Git alias (or simply a script)
which would first check to see if there are pending uncommitted changes
and fail, if there are.  Deciding if the work tree is dirty is a
somewhat philosophical question (does presence of untracked files
makes the work tree dirty?) but in either case parsing the result of
`git status --porcelain` should be enough to decide.

> I don't understand why the existing logic allows it,

Because uncommitted changes does not belong to any branch.  Yes, it
looks like they do but actually they're only (usually) based on the tip
commit of a branch but do not belong to that branch.

This problem comes up here from time to time.

> but i clearly see how a distracted/in a rush/sleepless developer can
> make a mess of it; still recoverable but very time-consuming when you
> find it x days later.

I would say you're overestimating the scale of this problem a bit.
I hardly can imagine a developer who does not run `git status` before
starting to mess with a new feature/bug fix.  It's a working habit.
The same applies to committing: running `git diff` before making a
commit is a good working habit because you should ensure you're about
to commit what you're really intending to commit.  Some people do even
commit using `git commit -v` to actually see the diff of their changes
embedded into their editor window.

So I would really advise you to better develop the habit of checking
what you're doing.
On the other hand, dealing with uncommitted changes mechanically is not
really *that* hard: either run `git stash` or just make a
"work-in-progress" commit before switching branches to work on a new
feature/implement a bug fix.

I have written a rather wordy reply [1] to someone having a problem
similar to yours.  It elaborates on both points touched in this
message so you might consider reading it.

1. http://thread.gmane.org/gmane.comp.version-control.git.user/3632/focus=3633

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to