Re: pull into dirty working tree

From: Pierre Habouzit <madcoder@debian.org>
Date: Jun 13, 2007, 14:38 UTC
Message-ID: <20070613143845.GD5311@artemis.intersec.eu>
In-Reply-To: <18031.64456.948230.375333@lisa.zopyra.com>

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

Show 34 quoted lines

> 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