From: Jakub Narebski <jnareb@gmail.com>
To: Ingo Bruecki <ib@wupperonline.de>
Cc: Avery Pennarun <apenwarr@gmail.com>, git@vger.kernel.org
Subject: Re: question concerning branches
Date: Wed, 19 Aug 2009 12:08:39 -0700 (PDT) [thread overview]
Message-ID: <m33a7noc3u.fsf@localhost.localdomain> (raw)
In-Reply-To: <4a8c4425@wupperonline.de>
ib@wupperonline.de (Ingo Brueckl) writes:
> Avery Pennarun <apenwarr@gmail.com> writes:
>
> > You seem to have forgotten the "git commit" step before switching back
> > to master.
>
> No, I passed over the commit in my example. I know that after the commit the
> things are as they ought to be, but what if I can't do a commit because I am
> in the middle of coding and have to have a break?
Then you use git-stash. It was invented for that.
> > You have a modified file in your repository; what did you *want* to happen
> > when you switched branches?
>
> I want an unchanged file in master if I switch there (because I worked in a
> different branch) and a changed version in the test branch.
>
> Why is the *master* different depending on whether my work in test in still
> going on or committed?!
Branches are about commits. State of a working directory doesn't
belong to a branch (in Git). Learning concepts behind Git would help
you in understanding it (Git is very consistent), which in turn would
help in using it.
What about untracked files? Do you want to lose them when you switch
branches?
>
> Actually, I cannot image how branches are practicable if I always have to
> have in mind possibly still uncommitted work. Shouldn't it be git's work
> to ensure that master will remain it was when branching?
>
> Without git I'd make a copy for testing new features. With git, it seems that
> I have to do the same (a clone). This is what I don't understand.
You finish old work (or stash it away), _then_ you begin new work.
>
> > (Many people find the current behaviour very convenient.)
Take the following example. You started coding some feature on
'master' branch, then you realized that this feature is more
complicated than you thought at first, so it should be developed in
separate topic branch. You do "git checkout -b featureA", and voila
you are now coding on feature branch 'featureA'.
> > You might also want to look at the "git stash" command.
>
> Yes, but isn't it annoying to leave the test branch always either with stash
> or commit in order to have an unchanged master?!
No, it isn't.
--
Jakub Narebski
Git User's Survey 2009: http://tinyurl.com/GitSurvey2009
next prev parent reply other threads:[~2009-08-19 19:08 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-19 17:33 question concerning branches Ingo Brueckl
2009-08-19 18:07 ` Bruce Stephens
2009-08-19 18:07 ` Avery Pennarun
2009-08-19 18:31 ` Ingo Brueckl
2009-08-19 19:08 ` Jakub Narebski [this message]
2009-08-19 19:45 ` Ingo Brueckl
2009-08-19 19:50 ` Avery Pennarun
2009-08-20 7:57 ` Matthieu Moy
2009-08-19 19:53 ` Jacob Helwig
2009-08-19 20:01 ` Jakub Narebski
2009-08-19 20:39 ` Theodore Tso
2009-08-19 20:57 ` Jakub Narebski
2009-08-20 17:37 ` Theodore Tso
2009-08-19 21:51 ` Linus Torvalds
2009-08-20 3:01 ` Randal L. Schwartz
2009-08-20 12:46 ` Ingo Brueckl
2009-08-20 13:47 ` Johannes Sixt
2009-08-20 14:59 ` Jakub Narebski
2009-08-19 18:35 ` Junio C Hamano
2009-08-19 19:21 ` Ingo Brueckl
2009-08-20 7:33 ` Andreas Ericsson
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=m33a7noc3u.fsf@localhost.localdomain \
--to=jnareb@gmail.com \
--cc=apenwarr@gmail.com \
--cc=git@vger.kernel.org \
--cc=ib@wupperonline.de \
/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).