From: r.ductor@gmail.com
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: On the behavior of checkout <branch> with uncommitted local changes
Date: Tue, 24 Sep 2013 11:25:23 +0200 [thread overview]
Message-ID: <1753009.aAamh0ufex@ipht-ia-004976> (raw)
In-Reply-To: <xmqq1u4jp0bw.fsf@gitster.dls.corp.google.com>
Dear Juno
Thanks for your answer.
My fair criticism in my previous emails (and below) is just to try to convince you that with a few short sentences you risk to transmit only vague ideas, while a serious user is interested to understand the behavior of git in any occurrence, with no ambiguity. Once more, in my view a short pseudo code -- or its equivalent in words -- would be a useful compromise among simplicity and accuracy.
I'm attacking git checkout but I guess that what I say is a general problem of the git official documentation (i.e git stash in my experience has problems).
Each undocumented feature (simulated by my dumb questions) enforces the loss of a significant percentage of the users.
Lacking details, a hurried user will not use the feature, or if they are brave enough, they will use it without understanding (i.e. risking data loss one day or the other)...
Lacking details, a serious user will have to waste their time in trials or in studing the sources.
Do not fear that giving details in a man page would scare newbyes: as a git newbye I can say that what scares me is the lack of information, not the complexity(=power) of a program (*)
Do not waste your precious time in explaining me/us general ideas, we can find them in the tens of pedagogic tutorials/books out there, please give us those details that nobody out there seems to know and that man (un)intentionally hides!
I would be happy to submit a patch for the man git-checkout but I'm not sure that my understanding of git checkout (as encoded in the pseudocode I submitted) is correct.
My friendly regards,
ric
(*) of course you're allowed to discard my suggestions pretending that I'm not a representative user ;)
On Friday 20 September 2013 15:58:27 Junio C Hamano wrote:
> The principle is that we allow you to check out a different branch
> when you have local changes to the working tree and/or to the index,
> as long as we can make the index and the working tree pretend as if
> you reached that locally modified state, starting from a clean state
> of the branch you are checking out.
Of course I understand the idea, but if I try to grasp the details I'm in trouble: the problem in this statement is the ambiguity of "change" and "pretend as".
In plain english I can start from any content and change it to any other content, so in this semantics your statement is empty, or worse.
If I assume that change means "differences with N lines of unchanged context" I must still guess differences with respect to what? head-index, index-work, head-work ???? ... and how much is N? 3, 4, 1028?
Then, in order to understand I (a user) make the trials below, and concludes that also the nice principle stated above is somewhat incomplete....
git-test15$ echo -e 'a\n1\n2\n3\n4\n5\nb\n6\n7\n8\n9\n10\n'>f; cat f;git init; git add f; git commit -a -m 'ab'; git checkout -b dev; echo -e 'A\n1\n2\n3\n4\n5\nb\n6\n7\n8\n9\n10\n'>f;cat f;git commit -a -m 'Ab'; echo -e 'A\n1\n2\n3\n4\n5\nB\n6\n7\n8\n9\n10\n'>f;cat f;git add f; git checkout master
a
1
2
3
4
5
b
6
7
8
9
10
Initialized empty Git repository in /home/git-test15/.git/
[master (root-commit) 46d19ab] ab
1 file changed, 13 insertions(+)
create mode 100644 f
Switched to a new branch 'dev'
A
1
2
3
4
5
b
6
7
8
9
10
[dev bb852db] Ab
1 file changed, 1 insertion(+), 1 deletion(-)
A
1
2
3
4
5
B
6
7
8
9
10
error: Your local changes to the following files would be overwritten by checkout:
f
Please, commit your changes or stash them before you can switch branches.
Aborting
#####################################################################################
#### why abort the change w.r.t. dev was just b -> B and that patch was admissible in master ... I start questioning the principle ####
#####################################################################################
git-test15$ mkdir ../gittest16
git-test15$ cd ../gittest16
gittest16$ echo -e 'a\n1\n2\n3\n4\n5\nb\n6\n7\n8\n9\n10\n'>f; cat f;git init; git add f; git commit -a -m 'ab'; git checkout -b dev; echo -e 'A\n1\n2\n3\n4\n5\nb\n6\n7\n8\n9\n10\n'>f;cat f;git commit -a -m 'Ab'; echo -e 'a\n1\n2\n3\n4\n5\nB\n6\n7\n8\n9\n10\n'>f;cat f;git add f; git checkout master
a
1
2
3
4
5
b
6
7
8
9
10
Initialized empty Git repository in /home/gittest16/.git/
[master (root-commit) 7d7febe] ab
1 file changed, 13 insertions(+)
create mode 100644 f
Switched to a new branch 'dev'
A
1
2
3
4
5
b
6
7
8
9
10
[dev 143db1d] Ab
1 file changed, 1 insertion(+), 1 deletion(-)
a
1
2
3
4
5
B
6
7
8
9
10
error: Your local changes to the following files would be overwritten by checkout:
f
Please, commit your changes or stash them before you can switch branches.
Aborting
gittest16$
#####################################################################################
#### why abort? the change w.r.t. master was just b -> B and that patch was admissible in master ... I start questioning the principle ####
#####################################################################################
prev parent reply other threads:[~2013-09-24 9:22 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-19 9:23 On the behavior of checkout <branch> with uncommitted local changes r.ductor
2013-09-19 17:43 ` Junio C Hamano
2013-09-20 13:33 ` r.ductor
2013-09-20 22:58 ` Junio C Hamano
2013-09-24 9:25 ` r.ductor [this message]
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=1753009.aAamh0ufex@ipht-ia-004976 \
--to=r.ductor@gmail.com \
--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 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 NNTP newsgroup(s).