On Nov 5, 2007, at 3:33 PM, Junio C Hamano wrote:

quoted text
> Aghiles <aghilesk@gmail.com> writes:
>
>> Is there an "easier" way to pull into a dirty directory ? I am
>> asking this to make sure I understand the problem and not
>> because I find it annoying to type those 4 commands to perform
>> a pull (although some of my colleagues do find that annoying :).
>
> You need to switch your mindset from centralized SVN workflow.

I don't think wanting to pull in the middle of one's work has anything  
to do with centralized vs. decentralized, actually, though I do agree  
that it's a question of workflow.

For maybe 80% of my work, I do things "the git way" (lots of little  
local commits) and only sync up with other people when I've reached a  
good stopping point. Those are cases where I'm working in isolation on  
a new feature or a fix and will publish it as a whole unit when I'm  
done.

But the other 20% of the time, I'm working closely with another  
person. For example, I might be working with a front-end developer who  
is writing some nice snazzy JavaScript or Flash UI code to talk to my  
server-side code. And in that case, I really do want to be able to  
pull down his latest changes while I'm still in the middle of working  
on my own stuff, not least because it's only by testing with the real  
client -- where the button to invoke a particular piece of code on my  
side has just been added in the last 2 minutes -- that I can decide  
whether my work in progress is actually functional or not. (Unit tests  
only get you partway there.)

In other words, for traditional open-source-style distributed  
development where each repository is an isolated island that goes off  
and does its own thing, ignoring the outside world, the recommended  
git workflow is totally appropriate. It's also appropriate for a lot  
of in-house non-distributed development.

But for some classes of collaboration, where two or more people are  
essentially editing the same code base to work on the same feature and  
their changes are highly interdependent, that workflow is next to  
useless. There *is* no "I've gotten my code working and am ready to  
look at other people's changes now" stage until pretty late in the  
game. This kind of workflow happens a lot in commercial development in  
my experience.

Before git-stash, I did a lot of "commit; fetch; rebase; reset"  
sequences to support this kind of tight collaboration. Now it's  
"stash; fetch; rebase; unstash" which is the same number of commands  
but is semantically clearer. "fetch; rebase --dirty" or "pull --dirty - 
s rebase" will be nicer.

-Steve
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html