merging unmanaged working tree

merging unmanaged working tree

[Łukasz Stelmach]

Hello.

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.

-- 
Miłego dnia,
Łukasz Stelmach

Re: merging unmanaged working tree

[Daniel]

> Hello.
> 
> 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.
> 
> -- 
> Miłego dnia,
> Łukasz Stelmach
> --

Does "git-merge --squash" do what you want? You still need to have
the other tree managed by git (even for a while).

-- 
Daniel

Re: merging unmanaged working tree

[Łukasz Stelmach]

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

Re: merging unmanaged working tree

[Avery Pennarun]

2010/3/15 Łukasz Stelmach <lukasz.stelmach@iem.pw.edu.pl>:
> 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

You have a few options that I can think of.

a) Look at 'git clone --depth' so you can clone only the most recent
version of the files, not the *entire* repo.  This lets you do commits
on any computer you want with the pen drive plugged in, but saves
space.

b) Keep your .git directory on your main PC's disk, and the working
tree on your pen drive.  Look at the GIT_DIR environment variable in
'man git'.  Then when you bring the pen drive back to your PC, you
have the full repo available.  (If you use 'git clone --reference'
when making the new repo, the extra .git directory should take only
minimal space.)

c) Make a clone of your repo on the PC, then rsync the non-git parts
of that clone's work tree to and from your pen drive.  (This option is
the most error-prone since you have to make sure you never rsync in
the wrong direction at the wrong time.  But it's maybe the easiest to
understand.)

Hope this helps.

Have fun,

Avery

Re: merging unmanaged working tree

[Łukasz Stelmach]

Avery Pennarun <apenwarr@gmail.com> writes:

> 2010/3/15 Łukasz Stelmach <lukasz.stelmach@iem.pw.edu.pl>:
>> 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
>
> You have a few options that I can think of.
>
> a) Look at 'git clone --depth' so you can clone only the most recent
> version of the files, not the *entire* repo.  This lets you do commits
> on any computer you want with the pen drive plugged in, but saves
> space.

I've tried this one. It works (but why the --depht 1 gives two
revisions?) but even thoug the main repository and the portable one have
common commits I can't pull changes back from the mobile to the main
one. Is there any wise trick to make git try a little harder?

> b) Keep your .git directory on your main PC's disk, and the working
> tree on your pen drive.  Look at the GIT_DIR environment variable in
> 'man git'.  Then when you bring the pen drive back to your PC, you
> have the full repo available.  (If you use 'git clone --reference'
> when making the new repo, the extra .git directory should take only
> minimal space.)

This one's nice and seems to be most space efficient as far as flash
space is concerned. However, I'd be able to sync only with the machine
that holds the portable GIT_DIR while the previous method, if only
there was a way to make git work with shallow clones, could work with
different hosts if I synec my No1 desktop with them too.

> c) Make a clone of your repo on the PC, then rsync the non-git parts
> of that clone's work tree to and from your pen drive.  (This option is
> the most error-prone since you have to make sure you never rsync in
> the wrong direction at the wrong time.  But it's maybe the easiest to
> understand.)

Doesn't look good. As easy to under as to mess up.

I've just invented yet another method. Push the content to the pendrive:

$ git commit -am branching
$ git archive --format tar HEAD | tar -C /media/pendrive/project -xf -
$ git log -1 > /media/pendrive/project/HEAD # to remember 

Now you can make some changes to both the local and the portable copies.
You commit the only local changes. Next you retrieve the branching point
into a temporary directory

$ git archive --prefix sync-prj/ --format tar \
  $(head -1 /media/pendrive/project/HEAD | cut -f 2 -d ' ') | \
  tar -C  /tmp -xf -

# run diff3 on ./* /tmp/sync-prj/* /media/pendrive/project/*
# fix conflicts
$ git commit -a merged

The biggest drawback, at the moment, seems to be the fact that I need
some space for the branching point archive. And diff3 can't compare
directories like diff -uNr does. But in the end it seems quite robust
and might actually work with multiple hosts (as long as you can find the
commit from /media/pendrive/project/HEAD on each of them).

Thanks.

-- 
Miłego dnia,
Łukasz Stelmach

Re: merging unmanaged working tree

[Avery Pennarun]

2010/3/15 Łukasz Stelmach <lukasz.stelmach@iem.pw.edu.pl>:
> Avery Pennarun <apenwarr@gmail.com> writes:
>> a) Look at 'git clone --depth' so you can clone only the most recent
>> version of the files, not the *entire* repo.  This lets you do commits
>> on any computer you want with the pen drive plugged in, but saves
>> space.
>
> I've tried this one. It works (but why the --depht 1 gives two
> revisions?) but even thoug the main repository and the portable one have
> common commits I can't pull changes back from the mobile to the main
> one. Is there any wise trick to make git try a little harder?

I don't know; I haven't used shallow clones (ie. --depth) very much.
git's implementation of them seems a bit half-hearted.  The man page
says "A shallow repository has a number of limitations (you cannot
clone or fetch from it, nor push from nor into it), but is adequate if
you are only interested in the recent history of a large project with
a long history, and would want to send in fixes as patches."  There is
no technical reason for this limitation, as far as I know.

It does give a hint as to what you could do instead of push/pulling,
however: you could use git format-patch to extract the changes from
your shallow copy, and git am to import the patches back into your
main copy.  Seems like a pain though.

>> b) Keep your .git directory on your main PC's disk, and the working
>> tree on your pen drive.  Look at the GIT_DIR environment variable in
>> 'man git'.  Then when you bring the pen drive back to your PC, you
>> have the full repo available.  (If you use 'git clone --reference'
>> when making the new repo, the extra .git directory should take only
>> minimal space.)
>
> This one's nice and seems to be most space efficient as far as flash
> space is concerned. However, I'd be able to sync only with the machine
> that holds the portable GIT_DIR while the previous method, if only
> there was a way to make git work with shallow clones, could work with
> different hosts if I synec my No1 desktop with them too.

Maybe you could do something like:

      git clone -s ~/myrepo /pendrive/myrepo

This will give you a .git dir in /pendrive/myrepo, but all the
*objects* in the git repo will actually be borrowed from ~/myrepo.
This will make git virtually unusable on /pendrive/myrepo *unless* you
mount the disk on a PC that has ~/myrepo in the original location.  On
any such computer, you could be able to do normal git operations in
/pendrive/myrepo, including pulling changes from there to ~/myrepo.

As you do git operations on /pendrive, /pendrive/myrepo/.git will
slowly accumulate objects that you might have to clear out over time
(ie. after pushing them to the parent repo).

> I've just invented yet another method. Push the content to the pendrive:
>
> $ git commit -am branching
> $ git archive --format tar HEAD | tar -C /media/pendrive/project -xf -
> $ git log -1 > /media/pendrive/project/HEAD # to remember
> [...]

Yeah, I guess you could do that, but at that point you're basically
not using git anymore.

Have fun,

Avery

Re: merging unmanaged working tree

[Chris Packham]

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.

Re: merging unmanaged working tree

[Avery Pennarun]

2010/3/15 Chris Packham <judge.packham@gmail.com>:
> 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.

If you have this problem, you might want to look at the core.fileMode
option.  (See 'man git-config').

Have fun,

Avery

Re: merging unmanaged working tree

[Łukasz Stelmach]

Chris Packham <judge.packham@gmail.com> writes:

> 2010/3/15 Łukasz Stelmach <lukasz.stelmach@iem.pw.edu.pl>:
>> 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