Could you please tell me how to fetch a single file?

[Rambo]

Git documentation is useless, I don't know how to do the same as "svn update <file>" with git. No one mentions it and I'm desperate because I fucked up something in production and don't know how to fix it.

Thanks.

[radovan bast]

$ git checkout <file>

there is very good git documentation out there.

radovan

[Phlip]

> Git documentation is useless

+1.

Someone needs to assume that some people here don't want to work
full-time with git, and learn all its tiny details just to get
anything done. I'm aware of the various tutorials and cheat-sheets out
there, but there's just nothing that sketches every path between two
points. And gods help you if you want to revert some kind of complex
multi-branch merge. I always just git clone the revision I need into a
scratch folder, then copy all the source over. Sheesh...

--
  Phlip
  http://c2.com/cgi/wiki?ZeekLand

[David Aguilar]

what are you doing to improve the situation?

what documentation, specifically? git-scm.com has good links and
progit is quite comprehensive. are there points that can be improved?
helpful criticism helps to improve the situation instead of
complaining into the abyss.
>

please help the community help you.

[radovan bast]

i agree with David - i find it a bit unfair to say that Git documentation
is useless.
as i said there is excellent documentation out there written by people
in their free time.
of course i understand that not everybody can invest time in Git details
but i also think that you don't need many commands to survive
with everyday Git situations - i bet you can live a fulfilled Git life
with 10 commands.
it is possible that there may not be many ultracompact Git tutorials.
but only we can change that: the community.
r.

[Rambo]

git checkout file reverts the file... I need to UPDATE the file from a remote repository. i don't get why everyone I ask tells me the same, it does not work for me.

Documentation says git checkout works for branches, it does NOTHING about pulling file updates...

[radovan bast]

let's say you want it from origin/master:

$ git checkout origin/master <file>

and you are welcome,
radovan

[Rambo]

I did that and nothing happens, no log, nothing... what's that supposed to mean? the file did not update either...

[Adam Prescott]

If you're asking "how do I pull only one specific file from the remote server", I think the short answer is: you can't, Git is not SVN. However, if you're against doing a full pull, you could do `git fetch origin; git checkout origin/master -- file`. This will do a full "update" from the origin server, but leave your master branch untouched, since there's no merge.

[Andy Hardy]

On 01/11/2011 18:44, Rambo wrote:
> Git documentation is useless, I don't know how to do the same as "svn
> update <file>" with git. No one mentions it

probably because talking about 'checkout' is boring?

I guess that you'd find out about git checkout in the same way that you
found out about svn update...

[Rambo]

That worked, but I don't know why, as any git command I don't understand what it does.

When I do "git fetch", where does everything do? It stays flying somewhere until I merge with my branch?

[tombert]

Hi,

I agree that git and its doc is a bit hard to learn - I had my fights
too. The point is: where cvs and svn is pretty straight forward, git
needs time to learn.

"git fetch" updates your local database, but the "local database" is
not the same as in svn or cvs. In git you have a local and a remote
database and neither the local nor remote database does/needs not
contain any files you work on (the remote database is mostly a "bare"
database) - you have to checkout from that local database first to
access your files.

So:
"git pull" retrieves the remote branch (you currently working on) to
your local database.
"git fetch" retrieves all branches to your local database.
"git checkout" updates the local files from your local database.

For my department I created a "Git cheat sheet" which contains our
usual workflows - which is maybe the best way if not everybody has
time to invest in git.

Please have a look here that explains it: http://progit.org/blog.html

[Rambo]

Thanks, your post is more useful than the whole git documentation. I think I get it now.

[Adam Prescott]

In git, there are local and remote branches. A local branch is created by doing something like `git branch` or `git checkout -b`. You can checkout local branches.

By which I mean: you can check them out and have the branch update simply by doing a commit.

 

Suppose you know that a file on origin/master has been updated, and you want to update only that file in your checkout.

"In your checkout" here, to point out that you have to `git fetch` before you can do `git checkout foo -- bar`, since that was already explained in a previous email. :) 

[Adam Prescott]

On Wed, Nov 2, 2011 at 07:40, tombert <tom...@live.at> wrote:

"git fetch" updates your local database, but the "local database" is
not the same as in svn or cvs. In git you have a local and a remote
database and neither the local nor remote database does/needs not
contain any files you work on (the remote database is mostly a "bare"
database) - you have to checkout from that local database first to
access your files.

I think introducing the term "database" just makes this more complicated than it needs to be, if you remember a few basics about git.

In git, there are local and remote branches. A local branch is created by doing something like `git branch` or `git checkout -b`. You can checkout local branches. Remote branches are in some sense references to branches which are local to some other machine. So "master" is your local branch, and "origin/master" is a reference to the "master" branch on "origin".

In this situation, a subset of the history might look something like

o (master, origin/master) | o | o

Suppose you know that a file on origin/master has been updated, and you want to update only that file in your checkout. A `git fetch origin` looks to see if origin/master points to a new commit, and if it does, any unseen commits (and other objects), are downloaded from the "origin" remote. With just `fetch`, there is no merge into your local "master" branch. So that after the fetch, the history might look like

o (origin/master) | o (master) | o | o

With the working copy left untouched, and the current checked-out branch being "master". `git checkout <commit> -- <file>` checks out only <file> from <commit>. So `git checkout origin/master -- file` looks to "origin/master", which is just a reference to some commit, and gets the given file and updates the working copy.

Hopefully that gives you some insight into what's going on. It helps to have a few of the basics of git down, such as the model you're working in. Git is not SVN!

[Konstantin Khomoutov]

Quit repeating this bullshit already.

The fact you're stupid or lazy has nothing to do with Git
documentation. And books on it. I bet you did not bother to read about
the concepts before blindly bashing Git with your Subversion-molded
forehead. That's not how normal developers approach their new tools.

[Thomas Ferris Nicolaisen]

Regarding the "git sucks" thingie, I like to think of if like this*:

There's simple stuff, and there's easy stuff.

Simple means the opposite of complex. Easy, on the other hand, means it's very close to the stuff you already know. Git is "simple". Subversion is "easy".

Git is *a lot* of features in one tool (think of the 100+ git plumbing commands). Each feature is simple, but learning to use them together is good bit of work. As soon as you've understood the model (eureka!), the tool never fails you, and you find it more and more fun to use the more you learn. This is why there are so many git enthusiasts.

Subversion has a very limited set of features.It also turns awfully complex when you want to do stuff like merging. Actually the more I learned about Subversion, and the more I used it, the more frustrating I found it to use.

Long story short: Use the right tool for the job. If Git is too a heavy investment for you right now, use something you know already.

Rambo: If you are a Git-beginner, and you want direct answers on what to do with a certain problem, this mailing list is a great place to ask (also the #git IRC channel). But please don't start with insulting the documentation that the community has produced. 

By the way, this sounds like a good start for a user coming from SVN like you: http://git.or.cz/course/svn.html

* This categorization is stolen from Rich Hickey's talk here: http://www.infoq.com/presentations/Simple-Made-Easy

[tombert]

@Adam: for me sentences like "... So you can have local and remote
branches ..." is more confusing (thats from the SVN crash course).
"Database" is more widely known and understood by the public. Fact is
that every "brain" works different.

@Konstantin: please don't be so harsh - people feel better if they let
of steam. Sometimes they need a kick in the right direction :) as you
already gave me very often :) thx for that!

thomas

[Konstantin Khomoutov]

On Thu, 3 Nov 2011 04:13:02 -0700 (PDT)
tombert <tom...@live.at> wrote:

[...]

> @Konstantin: please don't be so harsh - people feel better if they let
> of steam.

Well, while I felt acute dislike about that first spit in the face of
Git developers that started the thread, I decided not to flame back.
After all, if a person feels like exposing their own silliness, let
them do that. But the second spit with the same wording was over the
top in my eyes, so I felt someone should cut that crap.

> Sometimes they need a kick in the right direction :)

Others kindly provided the necessary kicks in this case, so my mail
addressed just one particular issue with the thread starter.

> as you already gave me very often :) thx for that!

I appreciate this, thanks.