Hi, On Wed, 13 Jun 2007, Bill Lear wrote: > I wonder, also, if there could be a way to alert users that their > working tree is dirty before all the git pull blather comes out, scaring > their poor little souls? Well, it's their fault, isn't it? > So, instead of this: > > % git pull > remote: Generating pack... > remote: Done counting 122 objects. > remote: Result has 90 objects. > remote: Deltifying 90 objects. > remote: 100% (90/90) done > Unpacking 90 objects > remote: Total 90 (delta 59), reused 41 (delta 10) > 100% (90/90) done > * refs/remotes/origin/master: fast forward to branch 'master' of > git://source/sc > old..new: 171b65f..0be3472 > * refs/remotes/origin/v1.0: fast forward to branch 'v1.0' of > git://source/sc > old..new: a9de9dd..efa3a73 > Updating 717d9f6..0be3472 > src/fs/testsuite/fs.tst/gettest: needs update > src/nl/EocCompiler.cc: needs update > src/nl/EocCompiler.hh: needs update > src/nl/Nl.cc: needs update > fatal: Entry 'src/netlist/EocCompiler.cc' not uptodate. Cannot merge. Sorry, this is the first time Git can realize that the dirty working directory conflicts with the changes about to be applied. For example, I run "git pull" very often with a modified Makefile. If the merge would not touch the Makefile, it would succeed. No need to do anything fancy. If you do have to shut the (otherwise useful) messages up, you can always have an alias (using the advanced technique illustrated in another post in this thread). > % git pull > Sorry, I can't pull, as you have a dirty working tree. Please commit > your changes or move your files before you pull. These are the > files that are preventing this: > > src/fs/testsuite/fs.tst/gettest > src/nl/EocCompiler.cc > src/nl/EocCompiler.hh > src/nl/Nl.cc As far as I can see, gettest is not responsible, so this would be wrong. Ciao, Dscho - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
