[Insight-developers] some useful git commands for ITK

Gaëtan Lehmann gaetan.lehmann at jouy.inra.fr
Tue Aug 3 06:10:43 EDT 2010


Le 2 août 10 à 18:18, Brad King a écrit :

> On 08/02/2010 11:05 AM, Gaëtan Lehmann wrote:
>
>> # to use the same ssh key to commit to itk.org from different hosts
>> # the key can be generated with ssh-keygen -t rsa -N "" -f ~/.ssh/
>> id_git_itk
>> scp marvin:.ssh/id_git_itk ~/.ssh/id_git_itk
>> echo "Host itk.org" >> ~/.ssh/config
>> echo "  IdentityFile=~/.ssh/id_git_itk" >> ~/.ssh/config
>
> Good.
>
> This is not just a convenience, but a requirement.  We allow at most
> one public key per developer.  You must share the private key among
> all machines from which you want to push.  (Of course you can always
> push privately to your own single computer with that private key and
> then use that one to push to "git at itk.org:ITK.git".)
>
> Use a passphrase; ssh-agent is not that hard ;)

yes - just a bad habit

>
>> # get ITK and its submodules
>> git clone git://itk.org/ITK.git
>> cd ITK
>> git submodule update --init
>
> Even simpler with Git 1.6.5 or higher:
>
>  git clone --recursive git://itk.org/ITK.git
>
> I updated the Wiki's clone instructions:
>
>  http://www.itk.org/Wiki/ITK/Git#Cloning

good to know ! The shorter the better

>
>> # get the hooks to run locally
>> cd .git/hooks
>> git init
>> git pull .. remotes/origin/hooks
>> cd ../..
>
> Good.

I have a problem on solaris, where /bin/sh is actually sh, not bash.
Some expressions like $() doesn't seem to be supported.

As a quick fix, I've changed the shell bang in

   #!/usr/bin/env bash

which should work almost everywhere.

Can you commit that in the hooks?

>
>> # to update the repository
>> git pull --rebase

if they are local uncommitted changes, the following sequence may be  
required:

git stash
git pull --rebase
git stash pop

>
> This works if your current local branch is "master" but will not if
> you're on a local topic branch.  If you avoid doing commits directly
> in master and always work on a topic, then you should never need to
> "update" the repository during development.  Instead use
>
> git checkout master
> git pull
> git checkout -b my-new-topic
>
> to start new work.  To continue old work just do
>
> git checkout my-old-topic
>
> See here for an explanation of why constant merging from upstream
> with Git should not be done:
>
>  http://public.kitware.com/Wiki/Git/Workflow/Topic#Urge_to_Merge

yes, this is only to mimic the cvs behavior - it can still be useful  
for quick bug fixes

>
>> git diff HEAD # both indexed and non-indexed changes
>
> In practice it looks like the aggregate of the indexed and non-indexed
> changes, but strictly speaking this is a diff between the HEAD commit
> and your work tree.  The contents of the index are irrelevant.

good to know

>
>> # to revert all the changes - recorded patch are not lost
>> git reset --hard  # revert all the changes - indexed and non indexed
>
> Good.  Be careful with this one ;)
>
> FYI, once you've done "git add" to stage something then it is in the
> local repository.  Even after a hard reset you can recover it if you
> know how.

git is still surprising me, because it is very powerful and yet still  
quite difficult to use.
With darcs we have darcs revert and darcs unrevert commands to do that  
- quite simple to use and to remember.
I hope git will continue to be enhanced on the UI side. It has been  
greatly improved on that side since my last check, but there is still  
some room for improvement.

>
>> # to revert the changes in specific file(s)
>> git checkout -- a_file # do NOT revert the indexed changes (with git
>> add)
>
> Yes, this copies the file from the index to the work tree.
> You can also do
>
> git checkout HEAD -- a_file
>
> to copy the file from the HEAD commit to the index and work tree
> (or from any commit in place of HEAD).

great - this one goes in my notes as well :-)

>
>> git log a_file # on a single file
>
> Good.  You can also do
>
>  git log --follow -- a_file
>
> to follow its log through renames.

nice - git is even capable to follow the files which were moved from  
Code/Review to Code/BasicFilters with cvs :-)

>
>> git show patch_id # the content of a patch
>
> Good.  Replace "patch_id" with "commit-ish" to use Git terminology.
> ("Patch-id" actually means something different internally to Git.)

ok

Thanks for all those details!

Gaëtan


-- 
Gaëtan Lehmann
Biologie du Développement et de la Reproduction
INRA de Jouy-en-Josas (France)
tel: +33 1 34 65 29 66    fax: 01 34 65 29 09
http://voxel.jouy.inra.fr  http://www.itk.org
http://www.mandriva.org  http://www.bepo.fr

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 203 bytes
Desc: Ceci est une signature ?lectronique PGP
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20100803/3a06cae7/attachment.pgp>


More information about the Insight-developers mailing list