Daniel <mjucde@xxxxx> writes: >> Is there a method to (dry?) run git-merge to detect conflicts >> on: >> >> * current HEAD (or working tree) >> * selected previous revision (the one used to "branch") >> * directory tree (or a single file) "branched" with git-archive >> >> I'd like to synchronize portable working tree but don't want to keep >> history in it. > Does "git-merge --squash" do what you want? You still need to have > the other tree managed by git (even for a while). Not really. Well, what I want is abit odd so let me try another way 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. Does git allow to retrieve (to stdout) a particular revision of a single file? If so I could use "<(git retrieve A file1.c)" bash trick. Or (this is my goal) is there another way not to keep the whole history of my repository on the pendrive? Just the changes I made since the brnaching point. And then clean (yeah squash, but it's not the same I am afraid) everything after merging. -- 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