All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Witten <mfwitten@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Markus Elfring <Markus.Elfring@web.de>
Subject: Re: Better cooperation between checkouts and stashing
Date: Mon, 01 Mar 2010 10:14:56 -0800 (PST)	[thread overview]
Message-ID: <4b8c0420.5544f10a.2eb2.ffffb4c4@mx.google.com> (raw)
In-Reply-To: <7v1vg4ufas.fsf@alter.siamese.dyndns.org>

On Mon, Mar 1, 2010 at 11:23, Junio C Hamano <gitster@pobox.com> wrote:
> Your "checkout" needs a bit better error checking.  For example, you
> don't want to "reset --hard" when stash failed for whatever reason.

Yes, you are correct.

However, in my defense, the goal was just to illustrate the gist
of the desired functionality.

> For performance and cleanliness reasons, it should first try a branch
> switch, and only after seeing it fail due to local changes, perform your
> stash-unstash magic.  You would probably want to use the usual "stash
> save", as you will be consuming the stashed change yourself as its first
> user, and "pop" will clear it if things resolve cleanly, or the stash will
> be left as the first element to make it easy to re-attempt the conflict
> resolution.  No need for stash-id nor special casing of detached HEAD
> situation.
>
> And it should do all that only under "-m" option, i.e. when the user
> indicated that s/he is willilng to face conflict resolution while
> switching.  That would be a genuine improvement compared to the current
> system (and I suspect it would be easier to implement).  "checkout -m" so
> far has been as bad as "CVS/SVN update" in that it can get you into an
> unresolvable mess without a chance to go back and retry.  autostash will
> remedy that.

You've still got the wrong problem in your head (though you're
solving a more useful issue).

Markus Elfring's goal (I think) is to associate local modifications with
a particular branch, *not* carry them across branches; that is, the goal
is to stash local modifications away when we leave a branch and only pop
them off the stash when we RETURN to that same branch.

Here's an example using the previously defined custom `checkout' function
(don't bother trying to follow the file modifications exactly; what's
important is how the stash is used during `checkout'):

  $ git init repo
  Initialized empty Git repository in /home/michael/repo/.git/


  $ cd repo
  $ echo 0 > file_0
  $ git add file_0
  $ git commit -m 0
  [master (root-commit) 26ea762] 0
   1 files changed, 1 insertions(+), 0 deletions(-)
   create mode 100644 file_0


  $ echo 1 > file_1
  $ git add file_1
  $ git commit -m 1
  [master 2faaa55] 1
   1 files changed, 1 insertions(+), 0 deletions(-)
   create mode 100644 file_1


  $ echo 2 > file_0
  $ echo 3 > file_1
  $ git add file_1


  $ git branch branch
  $ checkout branch               # Note: That's the custom 'checkout'
  Switched to branch 'branch'


  $ git stash list | cat
  stash@{0}: On master: e2f0bfbd9de98acd4941a1842e4bc55f


  $ echo 4 > file_0
  $ checkout HEAD^
  Note: checking out 'HEAD^'.
  
  You are in 'detached HEAD' state. You can look around, make experimental
  changes and commit them, and you can discard any commits you make in this
  state without impacting any branches by performing another checkout.
  
  If you want to create a new branch to retain commits you create, you may
  do so (now or later) by using -b with the checkout command again. Example:
  
    git checkout -b new_branch_name
  
  HEAD is now at 26ea762... 0


  $ git stash list | cat
  stash@{0}: On branch: 3e4d8fe5cbdcf73b9272ad21b4510424
  stash@{1}: On master: e2f0bfbd9de98acd4941a1842e4bc55f


  $ echo 5 > file_0 


  $ checkout master
  HEAD is now at 26ea762 0
  Previous HEAD position was 26ea762... 0
  Switched to branch 'master'
  # On branch master
  # Changes to be committed:
  #   (use "git reset HEAD <file>..." to unstage)
  #
  #	modified:   file_1
  #
  # Changed but not updated:
  #   (use "git add <file>..." to update what will be committed)
  #   (use "git checkout -- <file>..." to discard changes in working directory)
  #
  #	modified:   file_0
  #
  Dropped stash@{1} (6871afd660a5814a1caffe5275a9c145dba3c85a)


  $ git stash list | cat
  stash@{0}: On branch: 3e4d8fe5cbdcf73b9272ad21b4510424


  $ checkout branch
  Switched to branch 'branch'
  # On branch branch
  # Changed but not updated:
  #   (use "git add <file>..." to update what will be committed)
  #   (use "git checkout -- <file>..." to discard changes in working directory)
  #
  #	modified:   file_0
  #
  no changes added to commit (use "git add" and/or "git commit -a")
  Dropped stash@{1} (f6ecf1ceed97c760cb2b3279bbb39fc1cd16f052)


  $ git stash list | cat
  stash@{0}: On master: e2f0bfbd9de98acd4941a1842e4bc55f


  $ checkout master
  Switched to branch 'master'
  # On branch master
  # Changes to be committed:
  #   (use "git reset HEAD <file>..." to unstage)
  #
  #	modified:   file_1
  #
  # Changed but not updated:
  #   (use "git add <file>..." to update what will be committed)
  #   (use "git checkout -- <file>..." to discard changes in working directory)
  #
  #	modified:   file_0
  #
  Dropped stash@{1} (46a64d63441a924d9684c8a733a9fae4c7aa4b92)


  $ git stash list | cat
  stash@{0}: On branch: 3e4d8fe5cbdcf73b9272ad21b4510424

  $ git diff | cat
  diff --git a/file_0 b/file_0
  index 573541a..0cfbf08 100644
  --- a/file_0
  +++ b/file_0
  @@ -1 +1 @@
  -0
  +2

  $ git diff --staged | cat
  diff --git a/file_1 b/file_1
  index d00491f..00750ed 100644
  --- a/file_1
  +++ b/file_1
  @@ -1 +1 @@
  -1
  +3

etc.

  reply	other threads:[~2010-03-01 18:15 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-01 18:50 Better cooperation between checkouts and stashing Markus Elfring
2010-02-01 20:40 ` Junio C Hamano
2010-02-01 21:57   ` Markus Elfring
2010-02-01 22:44     ` Eugene Sajine
2010-02-02  1:36       ` Petr Baudis
2010-02-02 10:26         ` Markus Elfring
2010-02-02 11:04           ` Petr Baudis
2010-02-09 19:20   ` Markus Elfring
2010-02-09 20:06     ` Junio C Hamano
2010-02-09 21:01       ` Markus Elfring
2010-02-18 17:43       ` Markus Elfring
2010-02-18 20:09         ` Junio C Hamano
2010-02-27 21:33   ` Markus Elfring
2010-02-27 21:51     ` Junio C Hamano
2010-02-28 13:55       ` Markus Elfring
2010-02-28 22:57         ` Michael Witten
2010-03-01 10:50       ` Markus Elfring
2010-03-01 17:02         ` Michael Witten
2010-03-01 17:23           ` Junio C Hamano
2010-03-01 18:14             ` Michael Witten [this message]
2010-03-01 18:29               ` Markus Elfring
2010-03-01 19:44               ` Junio C Hamano
2010-03-01 21:20                 ` Markus Elfring
2010-03-02  1:41                   ` Michael Witten
2010-03-02  9:35                     ` Markus Elfring
2010-03-02 17:50                       ` Junio C Hamano
2010-03-03 15:55                         ` Markus Elfring
2010-03-04  7:46                           ` Michael Witten
2010-03-04 19:55                             ` Markus Elfring
2010-03-02  9:45               ` Markus Elfring
2010-03-02 18:05                 ` Junio C Hamano
2010-03-03 16:00                   ` Markus Elfring
2010-03-17 16:35           ` [PATCH] Clarification for the command "git checkout <branch>" Markus Elfring
2010-03-17 16:44             ` Avery Pennarun
2010-03-17 17:00               ` Markus Elfring
2010-03-17 17:58               ` Junio C Hamano
2010-03-17 18:21                 ` Markus Elfring
2010-03-17 18:37                   ` Junio C Hamano
2010-03-17 18:50                     ` Michael Witten
2010-03-17 19:23                       ` Junio C Hamano
2010-03-18 10:11                 ` Markus Elfring
2010-03-18 16:36                   ` Avery Pennarun
2010-03-18 17:19                     ` Michael Witten
2010-03-18 17:33                       ` Avery Pennarun
2010-03-19  8:28                         ` Markus Elfring
2010-03-19 17:17                           ` Avery Pennarun
2010-03-20  6:00                             ` Markus Elfring
2010-03-19  8:15                       ` Markus Elfring
2010-03-30 15:57                         ` Markus Elfring
2010-03-30 22:13                           ` Junio C Hamano
2010-03-31  3:58                             ` Ramkumar Ramachandra
2010-04-01  4:52                               ` Junio C Hamano
2010-04-01 13:09                                 ` Ramkumar Ramachandra
2010-04-01  6:38                             ` Markus Elfring
2010-04-10 13:30                             ` Markus Elfring
2010-04-10 22:31                               ` 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

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

  git send-email \
    --in-reply-to=4b8c0420.5544f10a.2eb2.ffffb4c4@mx.google.com \
    --to=mfwitten@gmail.com \
    --cc=Markus.Elfring@web.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.