From: Dima Kagan <dima.kagan@gmail.com>
To: Jakub Narebski <jnareb@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: Git branches - confusing behavior
Date: Sun, 11 May 2008 14:58:34 +0300 [thread overview]
Message-ID: <4826DF6A.2070306@gmail.com> (raw)
In-Reply-To: <m31w495apd.fsf@localhost.localdomain>
Jakub Narebski wrote:
> Dima Kagan <dima.kagan@gmail.com> writes:
>
>> I'm currently evaluating git for doing some local work without
>> depending on the main subversion server. I started with the following
>> steps:
>>
>>> git-svn clone http://svn.test.org/test/trunk
>>> cd trunk
>>> git branch test_branch
>>> git checkout test_branch
>>> vi somefile
>> Now, when I run 'git status' I get:
>> # On branch test_branch
>> # Changed but not updated:
>> # (use "git add <file>..." to update what will be committed)
>> #
>> # modified: somefile
>> #
>> no changes added to commit (use "git add" and/or "git commit -a")
>
> And now you have 'somefile' in the working arew, which state isn't
> saved anywhere git knows of.
>
>> This is what I expect of course. However, when I execute 'git checkout
>> master', I get:
>> M somefile
>> Switched to branch "master"
>
> Git tries hard to preserve your modifications. If you don't want to
> commit changes to test_branch, you can use git-stash to stash them
> away.
>
> Note that the above is possible only in the trivial merge case.
> Otherwise you would need to use "git checkout -m" (to merge), or
> "git checkout -f" (to force checkout, possibly losing changes).
>
So if I am working on more than one branch at a time I need to commit my changes every time before I do
'git checkout <branch>'?
>> And after running 'git status' on master I get:
>> # On branch master
>> # Changed but not updated:
>> # (use "git add <file>..." to update what will be committed)
>> #
>> # modified: somefile
>> #
>> no changes added to commit (use "git add" and/or "git commit -a")
>>
>> Basically I see that the same file I edited on the 'test_branch'
>> branch appears to be modified on the 'master' branch as well. This
>> behavior is unwanted, of course.
>>
>> Can someone please tell me, what am doing wrong? Or is this git's
>> normal behavior?
>
> This is normal, and wanted, behavior.
>
That's a subjective point of view :) I'm coming from the SVN world and uncommitted changes on one branch don't affect other branches. Is there a way I can achieve this behavior with git?
next prev parent reply other threads:[~2008-05-11 11:59 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-11 11:31 Git branches - confusing behavior Dima Kagan
2008-05-11 11:42 ` Jakub Narebski
2008-05-11 11:58 ` Dima Kagan [this message]
2008-05-11 12:06 ` David Symonds
2008-05-11 12:11 ` Dima Kagan
2008-05-11 12:13 ` David Symonds
2008-05-11 12:17 ` Dima Kagan
2008-05-11 12:20 ` Steve Frécinaux
[not found] ` <f35478f50805110513h15aa462bs9ee35ed4738d3009@mail.gmail.com>
2008-05-11 12:21 ` Dima Kagan
2008-05-11 13:40 ` Jakub Narebski
2008-05-11 12:33 ` Dima Kagan
2008-05-11 12:57 ` Björn Steinbrink
2008-05-11 13:04 ` Dima Kagan
2008-05-11 13:27 ` Björn Steinbrink
2008-05-11 13:39 ` Dima Kagan
[not found] ` <4826F72D.2070205-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2008-05-11 15:25 ` Patrick Aljord
2008-05-11 15:39 ` Teemu Likonen
2008-05-12 7:49 ` Miles Bader
2008-05-11 14:03 ` Theodore Tso
-- strict thread matches above, loose matches on Subject: below --
2008-06-30 7:23 Matt Seitz (matseitz)
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=4826DF6A.2070306@gmail.com \
--to=dima.kagan@gmail.com \
--cc=git@vger.kernel.org \
--cc=jnareb@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 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.