git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Re: How to create & switch to a branch after changes have already been made?
@ 2007-07-03  3:05 linux
  0 siblings, 0 replies; 5+ messages in thread
From: linux @ 2007-07-03  3:05 UTC (permalink / raw)
  To: wpdster; +Cc: git

The magic you're looking for is "git checkout -b <branch>"

You can do that even with uncommitted changes hanging around.
Because you don't specify a commit to check out, it just "checks out
the HEAD again", which does nothing.  The only thing left is the
part that creates and switches to a new branch.

Now, if you've already created the branch, you can either do:
git checkout <newbranch>
which, since <newbranch> equals HEAD, just switches the HEAD symlink
without actually changing the checked-out commit.

Or, if you want to be really low-level,

git-update-ref HEAD <newbranch>

Which is the underlying tool that git checkout uses.
It bypasses all the safety checkes, but it might be easiest to understand.


Now, if you've already committed, you can just do:

git checkout -b <newbranch>
git branch -f <oldbranch> HEAD^


Admittedly, I sometimes with for a "git commit -b <branch>" shortcut.

^ permalink raw reply	[flat|nested] 5+ messages in thread
* How to create & switch to a branch after changes have already been made?
@ 2007-07-03  2:18 Patrick Doyle
  2007-07-03  2:49 ` Patrick Doyle
  0 siblings, 1 reply; 5+ messages in thread
From: Patrick Doyle @ 2007-07-03  2:18 UTC (permalink / raw)
  To: git

Suppose, hypothetically speaking, one were a long time user of CVS who
converted to subversion in the last 18 months or so, and who never
really understood branches and merging because the syntax was so
obtuse and because the projects this hypothetical person had worked
were short lived enough that (s)he never really needed to create a
branch.

Now suppose this hypothetical person was working on a new project,
decided to use git as the project's version control system, got
halfway through changing a bunch of files, wanted to commit them as
they were, since they worked, but were ugly as sin, and wanted to
clean them up before committing them back to the main line of
development.

I would tell that hypothetical person, "Gee, it sounds like a branch
is exactly what you need here".  Unfortunately I don't know how to
tell the person to do the equivalent of a "svn switch" when the local
repository has been modified.

$ git branch newbranch
 that works, but
$ git checkout newbranch
complains that an untracked file would be overwritten by the merge
(since one of the things that this hypothetical person may have done
would have been to do a "git mv somefile someotherfile").

What would you suggest I say to this person other than "get in the
habit of creating a new branch _any_ time you start something new".

--wpd

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2007-07-03 14:04 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-07-03  3:05 How to create & switch to a branch after changes have already been made? linux
  -- strict thread matches above, loose matches on Subject: below --
2007-07-03  2:18 Patrick Doyle
2007-07-03  2:49 ` Patrick Doyle
2007-07-03 11:10   ` Johannes Schindelin
2007-07-03 14:04     ` Patrick Doyle

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).