From: Linus Torvalds <torvalds@osdl.org>
To: "Nicolas Vilz 'niv'" <niv@iaglans.de>
Cc: git <git@vger.kernel.org>
Subject: Re: several quick questions
Date: Tue, 14 Feb 2006 09:05:16 -0800 (PST) [thread overview]
Message-ID: <Pine.LNX.4.64.0602140845080.3691@g5.osdl.org> (raw)
In-Reply-To: <43F20532.5000609@iaglans.de>
On Tue, 14 Feb 2006, Nicolas Vilz 'niv' wrote:
>
> i wonder, how i revoke a straight forward merge of two trees... I
> actually wanted to be look like somewhere in the git-repository, where
> some branches are merged back with the master tree, but i think, that
> wasn't "cg-merge -c <tree to merge with the actual one>"...
>
> my result was that my master tree has now the same sha1-sum as my
> development-tree and gitk visualisation differs from that what i saw in
> the git-repository. (Several Arrows headed into back into one line...)
>
> maybe that was because i didn't do anything in my master tree in the
> meantime.
>
> And another thing, is there no posibility to get back to some commits or
> tags? I realized you can rebranch tags... what, if i want to switch back
> to git version 1.1.6 in the git repository? Or a certain commit?
Both of these can be solved with "git reset".
Before going into any more detail on that, let's go over the other related
"basic operations" too:
- "git branch". This creates a new branch of development at an arbitrary
point (that defaults to "current state").
Example:
git branch development-trial v1.1.6
This will create a new branch called "development-trial", which starts
at the v1.1.6 state. NOTE! It will _not_ check it out - your old active
state is left totally alone, and you still stay on whatever branch you
used to be on.
- "git checkout". This switches to another branch. As a shorthand, you
can also choose to create the branch at the same time, but normally
you'd just do like this example:
git checkout development-trial
which will switch to the branch you just created and check that out.
- "git reset". This will reset the current branch state to something
else. This is what you would use if you want to undo a commit,
for example: you can "reset" the current branch to before the commit
happened.
NOTE! When you do this, you also have to choose what you want to do
about your checked-out working tree. For example, when undoing the last
commit, you normally want to totally undo all the working tree changes
too, but you might also want to just undo the commit, and leave the
actual changes you committed alone, so that you can re-commit them with
a fixed commit message, for example.
Example:
git reset --hard HEAD^
this will undo the last commit (more exactly: it will select the first
parent of HEAD to be the new top-of-development, so if the last thing
you did was a merge, it will reset to the previous state). The "--hard"
means that you want to reset the working tree too.
Other example:
git reset --hard v1.1.6
This will just reset the current branch to a particular known state (ie
1.1.6 in this case).
Without the "--hard", it will _not_ change the working tree, but just
update the index (and branch pointer, of course) to the new state, and
tell you which files are "dirty" in that new state. This is great for
undoing just a "git commit", but leaving the tree in the state is was
before you committed. It's not so great if you expected to revert
everything, and are now confused because "git diff" shows lots of
changes ;)
Finally, let's go over the difference between "git fetch" and "git pull":
- "git fetch" is what you want to do if you want to _update_ another
branch. For example, if you want to track what Junio is doing in his
git repository (assuming that was what you cloned for), doing
git fetch origin
will update the "origin" branch, but will _not_ touch the current
branch itself. This is very useful for seeing what Junio has been
doing, without actually affecting your own work in any way.
- "git pull" is really just "git fetch" + "git merge". It will fetch the
state you asked for, and then merge that into your current branch. So
it's important to rmember that this actually _changes_ what you have
checked out and have worked on.
One very special case of "git pull" is when you only use the repository
to track another branch, and you never do any changes at all, and you
never switch branches around, and you always pull from the same source.
In that case, "git pull" will basically boil down to just a read-only
tracking mechanism (ie you could think of this particular usage as
being the git equivalent of "anoncvs" access)
The reason people may get confused is that they start out using "git pull"
as a read-only tracking mechanism, and it's not necessarily obvious that
"git pull" really fundamentally is a very powerful operations - much MUCH
more complex and powerful than just "track that other branch". Which is
why I try to make the distinction between "git fetch" and "git pull"
clear.
Linus
next prev parent reply other threads:[~2006-02-14 17:05 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-14 16:28 several quick questions Nicolas Vilz 'niv'
2006-02-14 17:03 ` Andreas Ericsson
2006-02-14 21:30 ` Nicolas Vilz 'niv'
2006-02-14 17:05 ` Linus Torvalds [this message]
2006-02-14 17:47 ` Kenneth Johansson
2006-02-14 18:08 ` Andreas Ericsson
2006-02-14 18:21 ` Kenneth Johansson
2006-02-14 18:26 ` Linus Torvalds
2006-02-14 18:10 ` Carl Worth
2006-02-14 18:34 ` Linus Torvalds
2006-02-14 20:10 ` Carl Worth
2006-02-14 20:27 ` Petr Baudis
2006-02-14 20:37 ` Johannes Schindelin
2006-02-14 20:41 ` Junio C Hamano
2006-02-14 20:54 ` Johannes Schindelin
2006-02-14 20:55 ` Petr Baudis
2006-02-14 20:40 ` Linus Torvalds
2006-02-14 21:19 ` Petr Baudis
2006-02-14 21:53 ` Carl Worth
2006-02-14 22:39 ` Junio C Hamano
2006-02-23 20:31 ` [PATCH] New git-seek command with documentation and test Carl Worth
2006-02-24 0:18 ` J. Bruce Fields
2006-02-24 1:01 ` [PATCH] git-seek: Eliminate spurious warning. Fix errant reference to git-bisect in docs Carl Worth
2006-02-24 6:02 ` Junio C Hamano
2006-02-24 10:00 ` [PATCH] New git-seek command with documentation and test Andreas Ericsson
2006-02-24 11:38 ` Junio C Hamano
2006-02-24 14:23 ` Carl Worth
2006-02-24 21:48 ` Johannes Schindelin
2006-02-24 21:57 ` J. Bruce Fields
2006-02-14 21:30 ` several quick questions Josef Weidendorfer
2006-02-14 21:40 ` Junio C Hamano
2006-02-14 22:17 ` Josef Weidendorfer
2006-02-14 22:26 ` Junio C Hamano
2006-02-15 19:22 ` [PATCH] More useful/hinting error messages in git-checkout Josef Weidendorfer
2006-02-14 23:00 ` several quick questions Andreas Ericsson
2006-02-14 23:23 ` Johannes Schindelin
2006-02-15 0:08 ` Andreas Ericsson
2006-02-15 0:34 ` Junio C Hamano
2006-02-15 6:27 ` Junio C Hamano
2006-02-15 9:06 ` Andreas Ericsson
2006-02-15 9:21 ` Junio C Hamano
2006-02-14 21:41 ` Petr Baudis
2006-02-14 18:44 ` Carl Worth
2006-02-14 19:00 ` Linus Torvalds
2006-02-14 19:38 ` Andreas Ericsson
2006-02-14 20:34 ` Johannes Schindelin
2006-02-14 20:14 ` Carl Worth
2006-02-14 18:55 ` Keith Packard
2006-02-14 19:04 ` Linus Torvalds
2006-02-14 19:39 ` Keith Packard
[not found] ` <20060214220154.GJ31278@pasky.or.cz>
[not found] ` <1139960934.4341.93.camel@evo.keithp.com>
[not found] ` <20060215000737.GF9573@pasky.or.cz>
[not found] ` <1139963183.4341.117.camel@evo.keithp.com>
2006-02-15 1:12 ` Cogito turbo-introduction Petr Baudis
2006-02-15 1:32 ` Petr Baudis
2006-02-15 4:11 ` several quick questions Martin Langhoff
2006-02-15 5:25 ` Keith Packard
2006-02-15 8:21 ` Carl Worth
2006-02-14 19:13 ` Junio C Hamano
2006-02-14 19:46 ` Petr Baudis
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.64.0602140845080.3691@g5.osdl.org \
--to=torvalds@osdl.org \
--cc=git@vger.kernel.org \
--cc=niv@iaglans.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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).