On Nov 5, 2007, at 3:33 PM, Junio C Hamano wrote:
Aghiles <aghilesk@xxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
