git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Zorba" <cr@altmore.co.uk>
To: git@vger.kernel.org
Subject: Re: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-) [Scanned]
Date: Wed, 31 Dec 2008 12:17:00 -0000	[thread overview]
Message-ID: <gjfnsb$5ph$4@ger.gmane.org> (raw)
In-Reply-To: alpine.LNX.1.00.0812302236190.19665@iabervon.org

Ok, now I'm following you, cos I just "broke" checkout again by deleting 
files from working dirs before running it.

git-checkout takes into account the state of the working tree in the commit 
it is run FROM, as well as the commit it is checking out.

It relies on the working tree being in synch with the commit it is run from.
If I delete files, I screw around with this initial state.
Files that git-checkout is relying on to be there are not copied in by it, 
so if I've deleted (or modified) those files, hard luck.

I remember s/o saying git minimizes file I/O, and this whats happening here.

It puts a big demand on the user, to keep their index & working dir in synch 
with whats in the commit.

Ah,

$ git checkout .

will restore the state of the working dir to be in synch with the CURRENT 
commit, so it will be safe to checkout other branches

BINGO !!
what I need to do is run the sequence

$ git checkout .                    // tidy up current commit
$ git checkout <version>     // roll back

n'est pas ?


"Daniel Barkalow" <barkalow@iabervon.org> wrote in message 
news:alpine.LNX.1.00.0812302236190.19665@iabervon.org...
> On Tue, 30 Dec 2008, Daniel Barkalow wrote:
>
>> On Wed, 31 Dec 2008, Conor Rafferty wrote:
>>
>> > -----Original Message-----
>> > wtf is wrong with
>> >
>> > git checkout <something>
>> >
>> > ??
>> >
>> > ** It doesn't reliably put the files that were in that revision into 
>> > the
>> > working directory - a fairly major flaw, for what I'm using SCM for 
>> > (and
>> > 80% of the market IMHO)
>>
>> It certainly does for me; I rely on it pretty much constantly. Can you
>> give a sequence of commands (ideally the whole sequence from the "git
>> init") that leads to a difference?
>
> Actually, I know what you must be doing:
>
> $ git tag versionD
> $ git checkout versionA
> (versionA in the working directory)
> $ rm *.*
> (versionA with ABC.txt and AC.txt deleted)
> $ git checkout versionB
> (versionB with ABC.txt and AC.txt deleted)
>
> If you've made any changes (including deleting files), "git checkout" (no
> pathes) will preserve them. On the other hand, it will remove files that
> are in the commit you're leaving and not in the commit you're going to. So
> just don't remove the working directory files and you should be all set.
>
> In order to get them back if you have removed them, you can do:
>
> $ git checkout .
>
> This will discard all of the changes you've made only to the working
> directory; i.e., it'll recover the deleted files. You should also try "git
> status" whenever anything's mysterious, because it will tell you what's
> going on.
>
> -Daniel
> *This .sig left intentionally blank* 

  reply	other threads:[~2008-12-31 12:18 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-31  2:27 for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-) [Scanned] Conor Rafferty
2008-12-31  2:35 ` Jeff Whiteside
2008-12-31  2:56 ` Boyd Stephen Smith Jr.
2008-12-31  3:10 ` Daniel Barkalow
2008-12-31  3:49   ` Daniel Barkalow
2008-12-31 12:17     ` Zorba [this message]
2008-12-31 13:48       ` Sitaram Chamarty
2008-12-31 16:24       ` Daniel Barkalow
2008-12-31 16:33         ` Sitaram Chamarty
2008-12-31 12:03   ` Zorba
2008-12-31 13:37     ` Sitaram Chamarty
  -- strict thread matches above, loose matches on Subject: below --
2008-12-31 11:10 Conor Rafferty
2008-12-31 16:00 ` Daniel Barkalow
2008-12-31 10:59 Conor Rafferty
2008-12-31  2:30 Conor Rafferty
2008-12-31  3:40 ` Boyd Stephen Smith Jr.
2008-12-31  4:48   ` Junio C Hamano
2008-12-31  5:21     ` Daniel Barkalow
2008-12-31  6:07       ` Junio C Hamano
2008-12-31 15:14     ` Boyd Stephen Smith Jr.
2008-12-30 22:55 Conor Rafferty
2008-12-31  0:12 ` Boyd Stephen Smith Jr.
2008-12-31  2:22 ` Sitaram Chamarty
2008-12-30 22:36 Conor Rafferty
2008-12-30 23:31 ` Boyd Stephen Smith Jr.
2008-12-31  0:15 ` Daniel Barkalow
2008-12-31  2:22   ` Jeff Whiteside

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='gjfnsb$5ph$4@ger.gmane.org' \
    --to=cr@altmore.co.uk \
    --cc=git@vger.kernel.org \
    /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).