Re: pull into dirty working tree

On Wed, Jun 13, 2007 at 09:45:28AM -0500, Bill Lear wrote:

[Pierre writes:]

quoted

 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.

  If it's because they have local modifications that match their use and
are not meant to be commited then I'd say that leaving it as "unclean"
work is a bad idea, because one day or the other they will have to
modify this Makefile to add a thing to commit for real. and then, 99
times over 100 they will commit their local modification too. _that_ is
harmful. And usually there is very soon a new commit to remove the local
change.

  I have a project where we had .htaccess that people had to customize
to have their local checkout work in the devel web server setup. It was
always commited (wrongly). We weren't using git.

  To solve those issues, there is many ways, not all are very handy, but
it works. The simplest way is to use a repository with a tool like
guilt, and each time you commit, you:

  guilt pop -a (remove your changes)
  ... do the stuff ...
  guilt push -a (push your changes again).

  Maybe you can also have a local branch where you store those local
changes. But that's still a bit awkward to use. Maybe someone will come
with a better workflow for this.

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