{"thread":{"id":"18973","subject":"problem with cherry picking","startedAt":"2009-04-20T20:07:20Z","lastAt":"2009-04-20T22:20:41Z","messageCount":2,"participants":["John Dlugosz","Andreas Ericsson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"111775","messageId":"450196A1AAAE4B42A00A8B27A59278E70ACE0021@EXCHANGE.trad.tradestation.com","threadId":"18973","inReplyTo":null,"subject":"problem with cherry picking","fromName":"John Dlugosz","fromEmail":"jdlugosz@tradestation.com","sentAt":"2009-04-20T20:07:20Z","receivedAt":"2009-04-20T20:07:20Z","isPatch":false,"sender":{"key":"jdlugosz@tradestation.com","avatar":null},"body":"Someone at work here jumped the gun and committed something before\nfetching an amended branch.  Typical stuff -- now his work and the\nrepo's work diverged.  His change was purely new files, no big deal.  In\ngitk, reset his dev to origin/remote/dev, then cherry-pick his new\ncommit.\n\nBut it barfed all over the place.  One problem was read-only files.  But\neven after purging those, it had the same complaint, something about\nuntracked file would be modified.  What's the deal here?\n\nI talked him through accomplishing it another way -- reset hard back to\nhis new commit, reset mixed to the proper ancestor, and re-doing the\ncommit.\n\nBut I want to understand what the issue is here.\n\n--John\n\n\nTradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.\n  If you received this in error, please contact the sender and delete the material from any computer.\n"},{"id":"111790","messageId":"49ECF539.3030701@op5.com","threadId":"18973","inReplyTo":"450196A1AAAE4B42A00A8B27A59278E70ACE0021@EXCHANGE.trad.tradestation.com","subject":"Re: problem with cherry picking","fromName":"Andreas Ericsson","fromEmail":"exon@op5.com","sentAt":"2009-04-20T22:20:41Z","receivedAt":"2009-04-20T22:20:41Z","isPatch":false,"sender":{"key":"exon@op5.com","avatar":null},"body":"John Dlugosz wrote:\n> Someone at work here jumped the gun and committed something before\n> fetching an amended branch.  Typical stuff -- now his work and the\n> repo's work diverged.  His change was purely new files, no big deal.  In\n> gitk, reset his dev to origin/remote/dev, then cherry-pick his new\n> commit.\n> \n> But it barfed all over the place.  One problem was read-only files.  But\n> even after purging those, it had the same complaint, something about\n> untracked file would be modified.  What's the deal here?\n> \n> I talked him through accomplishing it another way -- reset hard back to\n> his new commit, reset mixed to the proper ancestor, and re-doing the\n> commit.\n> \n> But I want to understand what the issue is here.\n> \n\nWhen he first reset back to the pre-modified state, the newly created\nfiles were not removed from the working directory (this happens on soft\nor mixed resets, fe, or when a branch is moved).\n\nThe files were untracked by git as seen from the commit he reset to, and\nso git rightly refuses to apply another patch that introduces them, as\nthat would mean overwriting files git knew nothing about (again, at the\ntime of the commit he reset back to).\n\n/Andreas\n"}]}