Re: merging unmanaged working tree

[Chris Packham <judge.packham@gmail.com>]

2010/3/15 Łukasz Stelmach <lukasz.stelmach@iem.pw.edu.pl>:
> Daniel <mjucde@o2.pl> 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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

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

The downside with this is that it is very likely that your files will
pick up an executable bit from the file system on your pen drive which
will need to be fixed up before you commit them.