help with git usage

help with git usage

[Daniel Quinlan]

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

Re: help with git usage

[Daniel Barkalow]

On Tue, 29 Apr 2008, Daniel Quinlan wrote:

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

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 merge home/master

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

$ git checkout HEAD -- <filename>

(And you can use any commit instead of HEAD to get other versions)

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

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*

Re: help with git usage

[Jakub Narebski]

Daniel Barkalow <barkalow@iabervon.org> writes:

> On Tue, 29 Apr 2008, Daniel Quinlan wrote:
>
> > 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:

Many of answers to your questions can be found on GitFaq,
http://git.or.cz/gitwiki/GitFaq
 
> > 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)

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

> 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 merge home/master

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?"
http://git.or.cz/gitwiki/GitFaq#head-46de97a5ac549d3adf406c22674b3325ae25d09c

> > 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).
>
> $ git checkout HEAD -- <filename>
> 
> (And you can use any commit instead of HEAD to get other versions)

See also "How to revert file to version from current commit?"
http://git.or.cz/gitwiki/GitFaq#head-f2ac5ecb3db6c54e9977bf969c0456091ac332a3
 
> > 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.
> 
> 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.

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-00fbd1ac45fe93dac4653cad3639b3df73d8657e

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

Re: help with git usage

[Richard Quirk]

On Tue, Apr 29, 2008 at 7:37 PM, Daniel Quinlan <danq@brtt.com> wrote:

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

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.

Re: help with git usage

[Jakub Narebski]

"Richard Quirk" <richard.quirk@gmail.com> writes:

> On Tue, Apr 29, 2008 at 7:37 PM, Daniel Quinlan <danq@brtt.com> wrote:
> 
>> 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.
> 
> 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.

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

Re: help with git usage

[Richard Quirk]

On Wed, Apr 30, 2008 at 12:39 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>
>  > If you use Vim, I'd recommend the vcscommand plugin - see
>  > http://code.google.com/p/vcscommand/
>
>  Could you add infomration about this to Git Wiki
>
>   http://git.or.cz/gitwiki/InterfacesFrontendsAndTools
>  somewhere in "Editors and IDE integration" subsection?
>

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

Re: help with git usage

[Matt Graham]

On Tue, Apr 29, 2008 at 2:07 PM, Daniel Barkalow <barkalow@iabervon.org> wrote:
> On Tue, 29 Apr 2008, Daniel Quinlan wrote:
>
>  > 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)
>
>  You shouldn't push to a non-bare repository.

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

Re: help with git usage

[Andreas Ericsson]

Matt Graham wrote:
> On Tue, Apr 29, 2008 at 2:07 PM, Daniel Barkalow <barkalow@iabervon.org> wrote:
>> On Tue, 29 Apr 2008, Daniel Quinlan wrote:
>>
>>  > 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)
>>
>>  You shouldn't push to a non-bare repository.
> 
> Is there any reason it wouldn't be appropriate to make git refuse to
> push to non-bare repositories?


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

Re: help with git usage

[Daniel Quinlan]

[-- Attachment #1: Type: text/plain, Size: 1656 bytes --]

Thanks for your earlier responses, they were very helpful.

On Apr 30, 2008, at 1:39 AM, Jakub Narebski wrote:

> Daniel Barkalow <barkalow@iabervon.org> writes:
>
>> On Tue, 29 Apr 2008, Daniel Quinlan wrote:
>>
>>> 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:
>
> Many of answers to your questions can be found on GitFaq,
> http://git.or.cz/gitwiki/GitFaq

I should have read this earlier.  I don't really understand the
details, but I get the idea:  make the central repository bare.

>

>>> 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.
>>
>> 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.
>
> 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-00fbd1ac45fe93dac4653cad3639b3df73d8657e
>

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.


[-- Attachment #2: gtkdiff --]
[-- Type: application/octet-stream, Size: 616 bytes --]

: # use perl
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" ;
 

[-- Attachment #3: Type: text/plain, Size: 573 bytes --]





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

-- danq

Re: help with git usage

[Julian Phillips]

On Wed, 7 May 2008, Daniel Quinlan wrote:

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

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

-- 
Julian

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

Re: help with git usage

[Dirk Süsserott]

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



Daniel Quinlan schrieb:
> Thanks for your earlier responses, they were very helpful.
>
> On Apr 30, 2008, at 1:39 AM, Jakub Narebski wrote:
>
>> Daniel Barkalow <barkalow@iabervon.org> writes:
>>
>>> On Tue, 29 Apr 2008, Daniel Quinlan wrote:
>>>
>>>> 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:
>>
>> Many of answers to your questions can be found on GitFaq,
>> http://git.or.cz/gitwiki/GitFaq
>
> I should have read this earlier.  I don't really understand the
> details, but I get the idea:  make the central repository bare.
>
>>
>
>>>> 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.
>>>
>>> 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.
>>
>> 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-00fbd1ac45fe93dac4653cad3639b3df73d8657e 
>>
>>
>
> 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.
>
>
>
>
>
> 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 hash.
>
> -- danq
>
>

Re: help with git usage

[Jakub Narebski]

Dnia czwartek 8. maja 2008 00:41, Daniel Quinlan napisał:

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

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