git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Petr Baudis <pasky@ucw.cz>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] git stash: Avoid data loss when saving a stash
Date: Sun, 30 Jun 2013 12:14:26 -0700	[thread overview]
Message-ID: <7vppv3jtrh.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <20130630132017.GQ12252@machine.or.cz> (Petr Baudis's message of "Sun, 30 Jun 2013 15:20:17 +0200")

Petr Baudis <pasky@ucw.cz> writes:

>   Hi!
>
> On Fri, Jun 28, 2013 at 11:39:16AM -0700, Junio C Hamano wrote:
>> Thanks.  I'll queue it with a pair of fix-up commits on top, so that
>> they can later be squashed in.
>> 
>> The result of squashing the fix-ups would look like this.
>
>   Thanks! I agree with all of your changes.
>
>> -- >8 --
>> From: Petr Baudis <pasky@ucw.cz>
>> Date: Fri, 28 Jun 2013 17:05:32 +0200
>> Subject: [PATCH] git stash: avoid data loss when "git stash save" kills a directory
>
>   Hmm, it's a pity that the note that `git reset --hard` itself should
> perhaps also abort in that case got lost. I don't insist on mentioning
> it in the commit message, though.

I do not agree with your `git reset --hard` at all.  With the
command, the user demands "no matter what, I want get rid of any
funny state in my working tree so that I can start my work from that
specified commit (default to HEAD)".

Imagine that this is you did to arrive that "funny state":

	$ git rm foo ;# foo used to be tracked and in HEAD
        $ cp /somewhere/else/foo foo
	$ cp /somewhere/else/bar bar ;# bar is not in HEAD
	$ cp /somewhere/else/bar baz ;# baz is in HEAD
        ... do various other things ...

and then "git reset --hard".  At that point, "foo" and "bar" are not
tracked and completely unrelated to the project.  "baz" is tracked
and have unrelated contents from that of "HEAD".

In order to satisfy your desire to go back to the state of HEAD with
minimal collateral amage, we need to get rid of the updated "foo"
and "baz" and replace them with those from HEAD.  We do not have to
touch "bar" so we leave it as-is.

And the "killed" case is just like "foo" and "baz".  If the state
you want to go back to with "--hard" has a directory (a file) where
your working tree's funny state has a file (a directory), the local
cruft needs to go away to satisify your request.

I do not mind if you are proposing a different and new kind of reset
that fails if it has to overwrite any local changes (be it tracked
or untracked), but that is not "reset --hard".  It is something else.

> On Fri, Jun 28, 2013 at 02:30:15PM -0700, Junio C Hamano wrote:
>> -- >8 --
>> Subject: treat_directory(): do not declare submodules in index to be untracked
>
>   Oh, you are truly awesome! I admit that properly reviewing this patch
> is a little out of my depth right now as I'm not familiar with this
> infrastructure. I'd just like to note...
>
>>  	case index_gitdir:
>>  		if (dir->flags & DIR_SHOW_OTHER_DIRECTORIES)
>>  			return path_none;
>> -		return path_untracked;
>> +		return path_none;
>
> ...that the if-test can be removed now as both branches are the same.

Thanks for noticing.  What was queued on 'pu' should already have
fixed that one.

  reply	other threads:[~2013-06-30 19:14 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-28 15:05 [PATCH] git stash: Avoid data loss when saving a stash Petr Baudis
2013-06-28 18:39 ` Junio C Hamano
2013-06-30 13:20   ` Petr Baudis
2013-06-30 19:14     ` Junio C Hamano [this message]
2013-07-06 14:42       ` Petr Baudis
2013-06-28 19:37 ` Junio C Hamano
2013-06-28 21:30   ` Junio C Hamano
2013-07-01 21:59 ` [PATCH v2 0/2] Safety for "stash save" Junio C Hamano
2013-07-01 21:59   ` [PATCH v2 1/2] treat_directory(): do not declare submodules to be untracked Junio C Hamano
2013-07-01 21:59   ` [PATCH v2 2/2] git stash: avoid data loss when "git stash save" kills a directory Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7vppv3jtrh.fsf@alter.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=pasky@ucw.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).