Daniel Barkalow <barkalow@xxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
