Re: pull into dirty working tree

On Wed, Jun 13, 2007 at 09:14:32AM -0500, Bill Lear wrote:

We have some CVS users who complain that they cannot do a pull
into a dirty working tree, as they could under CVS.  Here is
their scenario: they make a few changes to their code and want
to test it out; someone else pushes changes to the central repo
that they then want to add to their working tree to test also;
they then want to pull in these changes and test everything, as
if they had done 'mv stuff stuff-; git pull; mv stuff- stuff'.

They would like an option (perhaps a config option) to do a "dirty
pull".

The git-merge documentation states:

  You may have local modifications in the working tree files. In other
  words, git-diff is allowed to report changes. However, the merge uses
  your working tree as the working area, and in order to prevent the
  merge operation from losing such changes, it makes sure that they do
  not interfere with the merge. Those complex tables in read-tree
  documentation define what it means for a path to "interfere with the
  merge". And if your local modifications interfere with the merge,
  again, it stops before touching anything.

But my colleagues are still wondering: why can't git just do it as
CVS does?

I know there are workarounds: I myself documented a set of commands
to "put things on a shelf", but they still are whining.

I need a convincing argument: not a technical one, but one that is
practical (e.g. where CVS would do harm that git is preventing).

So, any explanation that I can give them why we can't have a 'git pull
--dirty' that moves things out of the way, then does the merge, then
moves thing back, aside from that it is stupid?

  I suppose the following way would work:

  $ git commit -a -m "temporary commit"  # save current work
  $ git branch -f dirty                  # ..in a separate branch
  $ git reset --hard HEAD~1              # unwind this commit
  $ git pull                             # perform a clean pull
  $ git rebase master dirty              # rewrite the work
  <you may have to fix some conficts here>
  $ git reset master                     # "undo" the commit

  So that's definitely doable.

  Though, in git, if you really work in a "pure" git environment, you
never pull until your work in your topic branch is ready for a merge.
It's a very bad habit to do otherwise: you don't _need_ to pull until
you have a clean slate.

-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org