I've been trying to use git for awhile now, (and I've read a lot of  
documentation, though maybe my
comprehension has not been high enough) but there are several  
operations which I
can't figure out:

1) After cloning a repository from work at home, making some changes  
and committing them,
I use "git push" to push them back to the work repository.  The  
changes seem to make it to the
work repository (I see the commit message in git log), but I can't  
figure out how to get the
changes into the working set at work.  (evidently not merge, checkout  
or reset -- seems like it
should be merge, but)

2) I can't figure out how to get back the latest (or any other)  
version of a file I've modified (or deleted)
in the working set.  (Well, I suppose I could checkout the whole tree  
somewhere else and copy the
relevant file, but I'm hoping there's something simpler).

3) Similarly, I can't use the little context diffs I can see in git- 
gui  -- I need to see side by side comparisons;
I've become accustomed to tkdiff.  It seems like git mergetool knows  
how to do that in some restricted
circumstances, but I want to do it outside the context of a merge.

Thanks,
-- danq

--

[ message continues ]

You shouldn't push to a non-bare repository. You should, instead, set up a 
bare repository for publishing your changes, and have all of the 
repositories you work in be clones of that. The issue is that git doesn't 
expect something outside of the repository to change the current branch 
(much like CVS doesn't expect something else to update CVS/Entries in your 
working directory). Another alternative is, from home, to do:

$ git push origin refs/heads/*:refs/remotes/home/*

Then, at work, you can do:


$ git checkout HEAD -- <filename>


This I don't know, but you can get particular files from particular 
commits output with "git show <commit>:<path>", and you can likely wire 
something up.

	-Daniel
*This .sig left intentionally blank*
--

[ message continues ]

Many of answers to your questions can be found on GitFaq,

What do you mean that reset doesn't work? "git reset --hard HEAD"
should update index and working tree, even if someone has updated
HEAD behingd git's back ;-)  NOTE, NOTE, NOTE: this is not a correct

And yet another alternative is, if possible, to always use "git pull"
(or "git fetch").

See also "Why won't I see changes in the remote repo after "git push"?"
http://git.or.cz/gitwiki/GitFaq#head-b96f48bc9c925074be9f95c0fce69bcece5f6e73
and "How would I use 'git push' to sync out of a firewalled host?"

See also "How to revert file to version from current commit?"

TkDiff doesn't have support for Git, although I think it wouldn't be
that hard to add.  Tkere is Google Summer of Code project to add DVCS
support, with Git as first example DVCS supported, to KDevelop so
perhaps KDiff3 would learn Git support.

From the various graphical comparison tools, Meld has supposedly Git
support (http://meld.sourceforge.net/).  Supposedly only because I
have not tested this; see
http://git.or.cz/gitwiki/InterfacesFrontendsAndTools#head-00fbd1ac45fe93dac4653cad3639...

BTW. I'm working in my spare time to add side-by-side diff, based on
TkDiff actually, to git-gui.

-- 
Jakub Narebski
Poland
ShadeHawk on #git
--

[ message continues ]

--Apple-Mail-45--35346685
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit

Thanks for your earlier responses, they were very helpful.


I should have read this earlier.  I don't really understand the

I found no mention of git on the meld man page or in the meld mailing  
list.

Here's a (perhaps naive) perl script which uses "git show" and wraps  
around
the original tkdiff.  Other cvs users might find it useful, though it  
can surely
be improved.


--Apple-Mail-45--35346685
Content-Disposition: attachment;
	filename=gtkdiff
Content-Type: application/octet-stream;
	x-unix-mode=0755;
	name="gtkdiff"
eval 'exec perl -S $0 "$@"'
if 0;

use strict ;

require "getopts.pl" ;
our($opt_r) ;
if ( ! &Getopts('r:nv') || @ARGV != 1 ) { 
    my $pgm = $0 ; 
    $pgm =~ s".*/"" ;
    die ( "Usage: $pgm [-r commit] filename\n" ) ; 
}


my $filename = shift ; 
if ( ! -f $filename ) { 
    die ( "$filename not found\n" ) ;
}

chomp(my $prefix = `git-rev-parse --show-prefix`) ;
$opt_r = "HEAD" if ! defined $opt_r ;
my $name = $filename ; 
$name =~ s".*/"" ;
my $tmpfile = "/tmp/$name" ;
system ("git show '$opt_r:$prefix$filename' > $tmpfile" ) ; 
system ( "tkdiff $tmpfile $filename" ) ;
unlink "$tmpfile" ;
 

--Apple-Mail-45--35346685
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit





I'm looking for a way to embed some identifying information about  
version
into compiled programs.  I hasten to add that I am not looking to  
expand RCS-like
tags.  Unlike CVS/RCS, git provides a single value that characterizes  
the whole
distribution, at least if everything is committed.  So, something like  
"git log | head -1 | awk '{print $2}'"
probably provides a value which I can embed into executables and  
libraries, tying
them to a particular source configuration.  I'm just curious if  
there's a better approach
to getting the commit ...
[ message continues ]

something like "git show-ref -s HEAD" perhaps?

-- 
Julian

  ---
The Kennedy Constant:
 	Don't get mad -- get even.
--

[ message continues ]

Hi,

what about using git-describe? At work we use sth. similar to the
following script. Let's call it 'git-stamp':

-------------
#!/usr/bin/bash

if [ "$(git rev-parse --is-inside-work-tree 2>/dev/null)" = "true" ]; then
    here=$(pwd)
    topdir=$(git rev-parse --show-cdup)
    cd ${topdir:-'./'}
    desc=$(git describe)
    if [ $(git diff-index --name-only HEAD | wc -l) -ne 0 ]; then
        desc="$desc-dirty"
    fi
    cd $here
    echo $desc
    exit 0;
else
    echo "Not inside a git working tree."
    exit 1;
fi
-------------

Basically it outputs the output of 'git-describe'. When something
whithin your working dir is currently *not* checked in, it outputs
"$(git-describe)-dirty".

Some sort of "-D$(git-stamp)" compiler switch would do the thing.
Depending on your makefile or scons-script this would yield to a
complete recompile of everything when only one file has changed.

In our environment we patch $(git-stamp) into some "version.c"
so the whole application only gets recompiled when version.c
has changed.

HTH,
    Dirk




--

[ message continues ]

Take a look how git, tig and Linux kernel does it with *VERSION* file 
and Makefile (you can take a look at Makefile and GIT-VERSION-GEN via 
gitweb web interface, e.g. at http://git.kernel.org or 
http://repo.or.cz).

In short: use git-describe output.
-- 
Jakub Narebski
Poland
--

[ message continues ]

Is there any reason it wouldn't be appropriate to make git refuse to
push to non-bare repositories?
--

[ message continues ]

It has several very valid uses. Newcomers who don't know what happens are
often better off not doing it, which is why it's not recommended. Making
git refuse would prevent the valid uses altogether though.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231
--

[ message continues ]

If you use Vim, I'd recommend the vcscommand plugin - see
http://code.google.com/p/vcscommand/ - which has fairly recently added
git support. Once installed :VCSVimDiff shows the diff side by side
between working copy and HEAD (by default, or whatever revision you
tell it) like a regular vimdiff between files.
--

[ message continues ]

Could you add infomration about this to Git Wiki
  http://git.or.cz/gitwiki/InterfacesFrontendsAndTools
somewhere in "Editors and IDE integration" subsection?

TIA
-- 
Jakub Narebski
GNU Emacs user
--

[ message continues ]

Certainly. I've added a note about it to the end of that section.
--

[ message continues ]