Chris Packham <judge.packham@xxxxxxxxx> writes: > 2010/3/15 Łukasz Stelmach <lukasz.stelmach@xxxxxxxxxxxxx>: >> 1. There is a repository (non-bare one) with all changes >> commited. Commit A. >> >> 2. I take some files put them on my pendrive. I take a note that they come >> from commit A. I don't clone the repository. >> >> 3. I make changes here (in the repository) and commit them (commits B, >> C, D) and there (on my pendrive). >> >> 4. I want to merge things with something like this >> >> $ git diff3 file1.c(D) file1.c(A) /media/project/file1.c >> >> * file1.c(D) is the lates version in my repository and working tree >> * file1.c(A) is the point where I branched >> * /media/project/file1.c is the unmanaged version of the file with changes >> I made on the go. > One option, assuming you do record "Commit A" every time you do this, > would be to use a short lived branch to merge your changes back in. > > e.g. > > git checkout -b work_from_home <sha of commit a> > cp /media/... . > git status # at this point you can check that what you about to commit > is what you intended, and > git commit -a # if it is good > git checkout master > git merge work_from_home # this is where any conflicts would be resolved > git branch -d work_from_home It seems to be the most obvious and straightforward worflow. I keep my x-bits off with proper mount options ;-) Thanks. -- Miłego dnia, Łukasz Stelmach -- 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