threads / discuss / 13320

help with git usage

Subject: help with git usage

## tl;dr

12 messages between Apr 29, 2008 and May 8, 2008.

replies: 11people: 8as markdown or json

Daniel Quinlan· Apr 29, 2008, 17:37 UTC · lore

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

Daniel Barkalow· Apr 29, 2008, 18:07 UTC · re: Daniel Quinlan · lore

Re: help with git usage

On Tue, 29 Apr 2008, Daniel Quinlan wrote:
Show 15 quoted lines
> 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
Show 5 quoted lines
> 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)
Show 5 quoted lines
> 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*
Jakub Narebski· Apr 30, 2008, 07:39 UTC · re: Daniel Barkalow · lore

Re: help with git usage

Daniel Barkalow <barkalow@iabervon.org> writes:
Show 5 quoted lines
> 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
 
Show 7 quoted lines
> > 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.

Show 12 quoted lines
> 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

Show 9 quoted lines
> > 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
 
Show 9 quoted lines
> > 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
Daniel Quinlan· May 7, 2008, 22:41 UTC · re: Jakub Narebski · lore

Re: help with git usage

Thanks for your earlier responses, they were very helpful.
On Apr 30, 2008, at 1:39 AM, Jakub Narebski wrote:
Show 10 quoted lines
> 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.

>
Show 16 quoted lines
>>> 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
Julian Phillips· May 8, 2008, 00:16 UTC · re: Daniel Quinlan · lore

Re: help with git usage

On Wed, 7 May 2008, Daniel Quinlan wrote:
Show 13 quoted lines
> 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.
Dirk Süsserott· May 8, 2008, 20:01 UTC · re: Daniel Quinlan · lore

Re: help with git usage

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:
Show 66 quoted lines
> 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
>
>
Jakub Narebski· May 8, 2008, 23:07 UTC · re: Daniel Quinlan · lore

Re: help with git usage

Dnia czwartek 8. maja 2008 00:41, Daniel Quinlan napisał:
Show 5 quoted lines
> 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
Matt Graham· Apr 30, 2008, 12:02 UTC · re: Daniel Barkalow · lore

Re: help with git usage

On Tue, Apr 29, 2008 at 2:07 PM, Daniel Barkalow <barkalow@iabervon.org> wrote:
Show 19 quoted lines
> 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?

Andreas Ericsson· Apr 30, 2008, 13:09 UTC · re: Matt Graham · lore

Re: help with git usage

Matt Graham wrote:
Show 23 quoted lines
> 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
Richard Quirk· Apr 30, 2008, 08:22 UTC · re: Daniel Quinlan · lore

Re: help with git usage

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

Jakub Narebski· Apr 30, 2008, 10:39 UTC · re: Richard Quirk · lore

Re: help with git usage

"Richard Quirk" <richard.quirk@gmail.com> writes:
Show 13 quoted lines
> 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
Richard Quirk· Apr 30, 2008, 11:50 UTC · re: Jakub Narebski · lore

Re: help with git usage

On Wed, Apr 30, 2008 at 12:39 PM, Jakub Narebski <jnareb@gmail.com> wrote:
Show 9 quoted lines
>
>  > 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.

← back to recent threads