git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Cláudio Lourenço" <pt.smooke@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Leila <muhtasib@gmail.com>,
	konglu@minatec.inpg.fr, git@vger.kernel.org,
	Renato Neves <nevrenato@gmail.com>
Subject: Re: Help understanding git checkout behavior
Date: Mon, 11 Jun 2012 21:48:06 +0100	[thread overview]
Message-ID: <CAMUXYmUg12z8LUcFKwjH0Utrvxx0fa5Sne0u9adgoZ=oooBbig@mail.gmail.com> (raw)
In-Reply-To: <7vaa097k3q.fsf@alter.siamese.dyndns.org>

First of all, thank you all for your attention.
The link for alloy is http://alloy.mit.edu/alloy/  Feel free to take a
look, but this is not the point. We just want to understand what are
the pre-conditions that have to be satisfied to perform checkout.

We have done some tests and we concluded that it is possible to checkout if:

for each file that is on index, but not on the last commit, we have
two cases when it is possible to checkout (from master) to branch b

   first: the file is not on the commit pointed by branch b

   second: the file is on the commit pointed by branch b, and it has
the same content as the file on index, or, the file of both commits
(master and b) have the same content

The deleted files from index, are just ignored (we think the bug comes
from here).

Are our assumptions corrects? Is there any place were we can see such
specifications?



On Mon, Jun 11, 2012 at 7:56 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Leila <muhtasib@gmail.com> writes:
>
>> When you create a branch, it will contain everything committed on the
>> branch you created it from at that given point. So if you commit more
>> things on the master branch like you have done (after creating b),
>> then switch to branch b, they won't appear. This is the correct
>> behavior. Does that answer your question?
>
> If there were "git commit" immediately before the "git checkout b"
> to check out the branch "b", then something/f1 would be among the
> data committed to the branch "master", and it is perfectly fine to
> remove it in order to check out branch "b" that does not have the
> directory "something" or file in it "something/f1".
>
> But if there is "something/f1" that is not yet committed, the
> command should have refused to check out the branch "b", which I
> think is what Cláudio is talking about.  It looks like a bug to me.
>
>>
>>
>> On Mon, Jun 11, 2012 at 2:21 PM,  <konglu@minatec.inpg.fr> wrote:
>>>
>>> Cláudio Lourenço <pt.smooke@gmail.com> a écrit :
>>>
>>>
>>>> The project was going pretty fine, till we start modeling the checkout
>>>> operation. We are with some problems finding useful information about
>>>> the properties that have to be satisfied when the "git checkout" is
>>>> performed. We have concluded that if everything that is on index is
>>>> commited then we have no problems making checkout.
>>>> The problem is when we have something on index that is not updated
>>>> with the last commit. We cannot find a general property that says when
>>>> checkout can be performed. We have even found some files that are
>>>> lost, like in this case:
>>>>
>>>> smooke  teste $ git init
>>>> Initialized empty Git repository in /home/smooke/Dropbox/teste/.git/
>>>> smooke  teste $ touch f
>>>> smooke  teste $ echo a > f
>>>> smooke  teste $ git add f
>>>> smooke  teste $ git commit -m 'first commit'
>>>> [master (root-commit) dab04b9] first commit
>>>>  1 files changed, 1 insertions(+), 0 deletions(-)
>>>>  create mode 100644 f
>>>> smooke  teste $ git branch b
>>>> smooke  teste $ touch something
>>>> smooke  teste $ echo b > something
>>>> smooke  teste $ git add something
>>>> smooke  teste $ git commit -m 'something added'
>>>> [master 9f2b8ad] something added
>>>>  1 files changed, 1 insertions(+), 0 deletions(-)
>>>>  create mode 100644 something
>>>> smooke  teste $ git rm something
>>>> rm 'something'
>>>> smooke  teste $ mkdir something
>>>> smooke  teste $ cd something/
>>>> smooke  something $ touch f1
>>>> smooke  something $ echo c > f1
>>>> smooke  something $ cd ..
>>>> smooke  teste $ git add something/f1
>>>> smooke  teste $ git checkout b
>>>> Switched to branch 'b'
>>>> smooke  teste $ ls
>>>> f
>>>> smooke  teste $ git checkout master
>>>> Switched to branch 'master'
>>>> smooke  teste $ ls
>>>> f  something
>>>> smooke  teste $ cat something
>>>> b
>>>
>>>
>>> What do you mean by "lost files" ? Are you talking about "something"
>>> that doesn't appear on branch 'b' ?
>>>
>>>
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe git" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2012-06-11 20:48 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-11 16:52 Help understanding git checkout behavior Cláudio Lourenço
2012-06-11 17:07 ` Konstantin Khomoutov
2012-06-11 18:21 ` konglu
2012-06-11 18:34   ` Leila
2012-06-11 18:55     ` Jeff King
2012-06-11 18:56     ` Junio C Hamano
2012-06-11 20:48       ` Cláudio Lourenço [this message]
2012-06-11 21:04         ` Junio C Hamano
2012-06-11 21:34           ` Junio C Hamano
2012-06-11 21:47             ` Jeff King
2012-06-11 21:58               ` Jeff King
2012-06-11 22:45               ` Junio C Hamano
2012-06-11 18:52 ` Vincent van Ravesteijn

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='CAMUXYmUg12z8LUcFKwjH0Utrvxx0fa5Sne0u9adgoZ=oooBbig@mail.gmail.com' \
    --to=pt.smooke@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=konglu@minatec.inpg.fr \
    --cc=muhtasib@gmail.com \
    --cc=nevrenato@gmail.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).