> ^^^^^^^ see that shit? it says the words 'working directory clean' but it > lies.
No, it doesn't lie. You are holding it wrong. If a merge can proceed without conflicts, it will commit automatically, so your working copy *is* clean. If you don't want to perform this final commit automatically add --no-commit. https://www.kernel.org/pub/software/scm/git/docs/git-merge.html Dawid On Fri, Jan 3, 2014 at 4:13 AM, Robert Muir <[email protected]> wrote: > It happens with 1.8 too. I'm not really concerned what the technical > explanation is (i'm sure someone will say: you are holding it wrong). > > one of the most important things about version control is being able > to track changes. if 'status' tells me my working directory is clean, > but then 'push' does something, that tells me its not ready for prime > time :) > > step 1: make a commit to branch A > > rmuir@beast:~/bogus$ git checkout master > Switched to branch 'master' > rmuir@beast:~/bogus$ ls > foo > rmuir@beast:~/bogus$ touch bar > rmuir@beast:~/bogus$ git add bar > rmuir@beast:~/bogus$ git commit -m "blahblah" > [master 1463733] blahblah > 1 file changed, 0 insertions(+), 0 deletions(-) > create mode 100644 bar > rmuir@beast:~/bogus$ git push origin master > Counting objects: 3, done. > Delta compression using up to 8 threads. > Compressing objects: 100% (2/2), done. > Writing objects: 100% (2/2), 241 bytes | 0 bytes/s, done. > Total 2 (delta 0), reused 0 (delta 0) > To [email protected]:rmuir/bogus.git > 9f54f3b..1463733 master -> master > > > step 2: merge to branch B > rmuir@beast:~/bogus$ git checkout feature > Switched to branch 'feature' > rmuir@beast:~/bogus$ git merge master > Updating 9f54f3b..1463733 > Fast-forward > bar | 0 > 1 file changed, 0 insertions(+), 0 deletions(-) > create mode 100644 bar > rmuir@beast:~/bogus$ git status > # On branch feature > nothing to commit, working directory clean > > ^^^^^^^ see that shit? it says the words 'working directory clean' but it > lies. > > rmuir@beast:~/bogus$ git push origin feature > Total 0 (delta 0), reused 0 (delta 0) > To [email protected]:rmuir/bogus.git > 9f54f3b..1463733 feature -> feature > rmuir@beast:~/bogus$ git --version > git version 1.8.3.2 > > > On Thu, Jan 2, 2014 at 9:09 PM, Benson Margulies <[email protected]> > wrote: >> On Thu, Jan 2, 2014 at 7:22 PM, Robert Muir <[email protected]> wrote: >>> is 1.7.10.2 considered old? It still happens to me with that. I use >>> git at work every day. >> >> i honestly wouldn't have called that ancient, but I can't recall when >> I used a version before 1.8. >> >> i have no quick answer to the phenomenon that afflicts you. Feel free >> to ping me off-list on the off chance that I can think of something >> useful by asking you 20 questions that the rest of this list doesn't >> want to read. >> >>> >>> I think there are two reasons why i see this: >>> 1) I always like to run 'svn status' (actually followed by svn diff, >>> too), before committing as a final review to make sure i'm changing >>> what i'm thinking i'm changing. I must be able to do this with git >>> too. >>> >>> 2) After a merge, I like to run tests to ensure I won't actually break >>> things. I do this with svn too (e.g. run all tests after merge >>> --reintegrate). Tests can take some time. The phone might ring, i >>> might have to walk the dog, i might go get a beer. When i come back, >>> god forbid I run step 1 again to see what my current state is, or >>> re-run tests too. >>> >>> >>> On Thu, Jan 2, 2014 at 7:04 PM, Benson Margulies <[email protected]> >>> wrote: >>>> I've never seen anything like this with any modern version of git. We >>>> use it at work, we have many branches. >>>> >>>> On Thu, Jan 2, 2014 at 6:46 PM, Robert Muir <[email protected]> wrote: >>>>> My final biggest complaint with git is the bugginess of 'git status'. >>>>> After >>>>> operations like merging (which can get complex), it will lie to you and >>>>> tell >>>>> you your checkout is clean, when in fact its not: if you then type git >>>>> push >>>>> it will push lots of commits. This is a real problem if you work on many >>>>> repositories, it means you must fall back to using patches and such >>>>> anyway... Aka... Git does not really work >>>>> >>>>> On Jan 2, 2014 3:52 PM, "Mark Miller" <[email protected]> wrote: >>>>>> >>>>>> bzr is dying; Emacs needs to move >>>>>> >>>>>> >>>>>> http://lists.gnu.org/archive/html/emacs-devel/2014-01/msg00005.html >>>>>> >>>>>> Interesting thread. >>>>>> >>>>>> For similar reasons, I think that Lucene and Solr should eventually move >>>>>> to Git. It's not GitHub, but it's a lot closer. The new Apache projects I >>>>>> see are all choosing Git. It's the winners road I think. I don't know >>>>>> that >>>>>> there is a big hurry right now, but I think it's inevitable that we >>>>>> should >>>>>> switch. >>>>>> >>>>>> -- >>>>>> - Mark >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
