Re: pull into dirty working tree

From: Bill Lear <rael@zopyra.com>
Date: Jun 13, 2007, 14:45 UTC
Message-ID: <18032.776.784080.321044@lisa.zopyra.com>
In-Reply-To: <20070613143845.GD5311@artemis.intersec.eu>

[Pierre writes:]

Show 16 quoted lines

>  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