So, i'm doing the 'stash/pull/pop' dance that git forces me to go through
when pulling changes into a modified working tree, and it has come back
with a whole bunch of ' already exists, no checkout', 'could not
restore untracked files from stash'.
so now i'm screwed and extremely frustrated.
w
On Fri, Mar 08, 2013 at 01:06:04PM -0800, Piers H wrote:
> So, i'm doing the 'stash/pull/pop' dance that git forces me to go through
> when pulling changes into a modified working tree, and it has come back
> with a whole bunch of ' already exists, no checkout', 'could not
> restore untracked f
On Sat, Mar 09, 2013 at 02:51:16AM +0400, Konstantin Khomoutov wrote:
[...]
> I recall someone appearing here sharing their similar frustration with
> Git not doing file-level merging when bringing in "upstream" changes,
> with automatically making untracked files tracked, if the same-named
> file
On Tuesday, January 15, 2013 11:48:33 PM UTC+1, Carsten wrote:
>
>> My guess is that it has just always behaved that way, and changing it now
> would surprise too many users. Personally I would find it very disturbing
> if "merge" started modifying my index (the only commands that should modify
On Tuesday, January 15, 2013 11:48:33 PM UTC+1, Carsten wrote:
>
>
> Hi again,
>
> Am 11.01.2013 11:38, schrieb Carsten Fuchs:
> > [...]
> > So my real question is, why does Git not do something analogous?
> > (Afaics, update the HEAD, update the Index, but leave the working-copy
> edition al
well, thanks for your help. but, in the end i just blew away all my work
and started again from scratch.
not happy.
i seriously don't understand why it's so hard to do this seemingly simple
thing - bring me up-to-date. i just want it to get the changes, merge them
in and show me the conflicts.
