Re: pull into dirty working tree

[Bill Lear <rael@zopyra.com>]

[Pierre writes:]
>  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.

I know, but I can't throw git purity at them as an explanation, they
won't understand.  And they would disagree about the "need" to pull.
That's for them to say: they WANT to pull without having to move aside
the makefile that they modified to add the '-wingit' option to the
compile line and just get on with their work without having to run 14
different git commands.

I'm not trying to justify their habits, but to try to see if there is
any clinching reason why this habit is not only "bad", but positively
harmful.


Bill