Thanks Konstantin,
both for this answer and the linked one.
I'll have to accept the logic and to be very careful on my (and other) git 
behaviour, knowing when to be careful.
I've studied and tested git for personal use in the last months, now that 
we're using in a group things get more interesting, and complicated.

I think the commit WIP will be my right way of working.


On Thursday, February 14, 2013 2:11:04 PM UTC+1, Konstantin Khomoutov wrote:
> On Thu, 14 Feb 2013 01:02:29 -0800 (PST) 
> Fabrizio Cioni < <javascript:>> 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. 

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 
For more options, visit

Reply via email to