[git-users] Re: git merge --abort deleted my files!

2014-09-15 Thread André Hänsel
On Monday, September 15, 2014 4:22:39 AM UTC+2, Rick Umali wrote:
>
> On Sunday, September 14, 2014 5:04:18 AM UTC-4, André Hänsel wrote:
>>
>> I ran git merge to merge a branch. There were some conflicted files. 
>> Although they were automatically resolved by git rerere, I still had to add 
>> them. I accidentally ran "git add ." instead of "git add -u". I noticed my 
>> mistake and ran "git merge --abort" to start over. To my dismay all my 
>> untracked files are gone! Any way to get them back?
>>
>
> The "git add ." should have created Git objects for these untracked files. 
> When you did the "git merge --abort", you reset the working directory, 
> deleting those files, but the Git objects should still be hanging around. 
> At least this is what I observed trying to reproduce your issue. 
>
> If you felt like plumbing the depths of the .git/object  directory, try to 
> sort the files in that directory in reverse chronological order. The most 
> recent files are probably the files that were deleted. You can confirm this 
> by using the git show command. 
>

Indeed there they are, thank you. :)

I'd consider it a bug that they were deleted in the first place.

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[git-users] git merge --abort deleted my files!

2014-09-14 Thread André Hänsel
I ran git merge to merge a branch. There were some conflicted files. 
Although they were automatically resolved by git rerere, I still had to add 
them. I accidentally ran "git add ." instead of "git add -u". I noticed my 
mistake and ran "git merge --abort" to start over. To my dismay all my 
untracked files are gone! Any way to get them back?

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[git-users] git diff -w --name-only does not work

2014-06-09 Thread André Hänsel
When I run "git diff -w --name-only" I get a file listed. When I then run 
"git diff -w filename" I get no output. When I run "git diff filename" I 
see that there are whitespace changes.

How do I get the names of files with non-whitespace changes? Aren't -w 
--name-only the correct options?

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[git-users] Re: git reset with staged changes

2014-06-03 Thread André Hänsel
On Tuesday, June 3, 2014 2:16:44 PM UTC+2, Pierre-François CLEMENT wrote:
>
> It seems logical to me that git-reset 's 
> --hard option resets everything, what's staged, what's not, etc. I see it 
> as a *"make my working dir in the exact same state as this commit"* 
> command, which I believe it is. If you don't want it to reset your index or 
> working dir or both, see git-reset 's 
> other modes.
>

Well, that's the point. Currently it's *not* a "make my working dir the 
exact same state" tool, as far as untracked files are concerned. It always 
leaves untracked files alone, there's not even an option to delete them. I 
feel the staged file should be left alone, too. (Just the index should be 
reset, so then it's unstaged again.)

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [git-users] git reset with staged changes

2014-06-03 Thread André Hänsel


On Tuesday, June 3, 2014 9:08:02 AM UTC+2, Philip Oakley wrote:
>
>  
> - Original Message - 
>
> *From:* André Hänsel  
> *To:* git-...@googlegroups.com  
> *Sent:* Monday, June 02, 2014 7:48 AM
> *Subject:* [git-users] git reset with staged changes
>
> I just learned painfully that git reset --hard deletes any previously 
> untracked files that have been staged. I had to recover them one by one 
> using git fsck. 
>
> Before I did the reset I actually checked the list of files and saw them 
> but I assumed that after the reset those files would be unstaged and 
> untracked again. It just seemed the most natural bahavior.
>
> Is this a missing feature or is it in fact more logical to delete them?
>
>  
> An alternative question would be, "Could the man page be improved so that 
> what you ned was spotted sooner?". 
>  
> I ask because a similar discussion is happening on the developers list? 
> (Aside: what reference material do you normally check in these cases?)
>  
> Philip
>

I had merged a feature branch into master to see the result and noticed 
that a prerequisite in master was missing (a database migration), so I 
added and staged it. I wanted to have it in master before the merge, so I 
was going to undo the merge by resetting. As usual I made sure that I had 
no uncommited changes. There were only a few untracked files laying around 
and my untracked (so I thought) but staged file, so I felt safe to reset. I 
was expecting to see my migration file as untracked afterwards, ready to be 
staged again.

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[git-users] git reset with staged changes

2014-06-02 Thread André Hänsel
I just learned painfully that git reset --hard deletes any previously 
untracked files that have been staged. I had to recover them one by one 
using git fsck.

Before I did the reset I actually checked the list of files and saw them 
but I assumed that after the reset those files would be unstaged and 
untracked again. It just seemed the most natural bahavior.

Is this a missing feature or is it in fact more logical to delete them?

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.