Binary files in a linear repository

Hello all,

currently I'm planning a frontend tool which makes use of only a  
small subset of git. The repo's contents is all binary (think of  
pictures). Accordingly, I can't merge in a meaningful way, making  
branches of very limited use.

The situation I'm trying to solve is:

- A revision earlier than the latest one is checked out.

- Files of this earlier commit are modified.

- I want to record this earlier commit along with it's modifications  
as a new commit on top of master, ignoring intermediate commits:

com005  <-- master
com004
com003  <-- HEAD, files modified
com002
com001 (initial commit)

One solution to do this is to move all files somewhere else, check  
out master, deleting all checked out files, placing the moved away  
files back into place and committing the result as com006. Obviously,  
this is a pretty complex operation, just waiting to exploit coding  
mistakes. Additionally, this will be slow.

Now I'm thinking about a much simpler solution: Simply declare the  
current set of files as (a modified) master/com005 and commit them. A  
"cp $GIT_DIR/master $GIT_DIR/HEAD" followed by a commit would do it.

Now my question: Is it safe to tweak the files in $GIT_DIR this way  
or will this corrupt the repository?


Thanks for any opinions,
Markus

On 2009.11.02 16:08:25 +0100, Markus Hitter wrote:

The situation I'm trying to solve is:

- A revision earlier than the latest one is checked out.

- Files of this earlier commit are modified.

- I want to record this earlier commit along with it's modifications
as a new commit on top of master, ignoring intermediate commits:

com005  <-- master
com004
com003  <-- HEAD, files modified
com002
com001 (initial commit)

One solution to do this is to move all files somewhere else, check
out master, deleting all checked out files, placing the moved away
files back into place and committing the result as com006.
Obviously, this is a pretty complex operation, just waiting to
exploit coding mistakes. Additionally, this will be slow.

Instead of doing "git checkout com003", which detaches HEAD, you could
do:
git read-tree -u --reset com003

Which will update the index and working tree to reflect the contents of
com003. The modify stuff, add, commit, done.

Now I'm thinking about a much simpler solution: Simply declare the
current set of files as (a modified) master/com005 and commit them.
A "cp $GIT_DIR/master $GIT_DIR/HEAD" followed by a commit would do
it.

Now my question: Is it safe to tweak the files in $GIT_DIR this way
or will this corrupt the repository?

Ignoring that $GIT_DIR/master is the wrong path, that 'cp' would (at
best) act like detaching HEAD.

Björn

On Mon, Nov 02, 2009 at 04:08:25PM +0100, Markus Hitter wrote:

Now I'm thinking about a much simpler solution: Simply declare the  
current set of files as (a modified) master/com005 and commit them. A  
"cp $GIT_DIR/master $GIT_DIR/HEAD" followed by a commit would do it.

Now my question: Is it safe to tweak the files in $GIT_DIR this way or 
will this corrupt the repository?

You probably should use 'git update-ref' if you want to change HEAD
manually. But it seems to me that you do not need even that. All what
you need is:

$ git reset --soft master

and then commit your changes (git reset --soft does not touch the index
file nor the working tree at all).


Dmitry

On 2009.11.02 18:48:31 +0300, Dmitry Potapov wrote:

On Mon, Nov 02, 2009 at 04:08:25PM +0100, Markus Hitter wrote:

quoted

Now I'm thinking about a much simpler solution: Simply declare the  
current set of files as (a modified) master/com005 and commit them. A  
"cp $GIT_DIR/master $GIT_DIR/HEAD" followed by a commit would do it.

Now my question: Is it safe to tweak the files in $GIT_DIR this way or 
will this corrupt the repository?

You probably should use 'git update-ref' if you want to change HEAD
manually. But it seems to me that you do not need even that. All what
you need is:

$ git reset --soft master

and then commit your changes (git reset --soft does not touch the index
file nor the working tree at all).

But then you still have to do:
git checkout master
git merge HEAD@{1}

To actually update the "master" branch head. The reset doesn't re-attach
HEAD.

Björn

On Mon, Nov 02, 2009 at 05:09:03PM +0100, Björn Steinbrink wrote:

On 2009.11.02 18:48:31 +0300, Dmitry Potapov wrote:

quoted

On Mon, Nov 02, 2009 at 04:08:25PM +0100, Markus Hitter wrote:

quoted

Now I'm thinking about a much simpler solution: Simply declare the  
current set of files as (a modified) master/com005 and commit them. A  
"cp $GIT_DIR/master $GIT_DIR/HEAD" followed by a commit would do it.

Now my question: Is it safe to tweak the files in $GIT_DIR this way or 
will this corrupt the repository?

You probably should use 'git update-ref' if you want to change HEAD
manually. But it seems to me that you do not need even that. All what
you need is:

$ git reset --soft master

and then commit your changes (git reset --soft does not touch the index
file nor the working tree at all).

But then you still have to do:
git checkout master
git merge HEAD@{1}

To actually update the "master" branch head. The reset doesn't re-attach
HEAD.

You are right... I forgot about that somehow. So, it should be

$ git reset --soft master
$ git checkout master

and only then

$ git commit


Dmitry

On 2009.11.02 19:52:15 +0300, Dmitry Potapov wrote:

On Mon, Nov 02, 2009 at 05:09:03PM +0100, Björn Steinbrink wrote:

quoted

On 2009.11.02 18:48:31 +0300, Dmitry Potapov wrote:

quoted

On Mon, Nov 02, 2009 at 04:08:25PM +0100, Markus Hitter wrote:
You probably should use 'git update-ref' if you want to change HEAD
manually. But it seems to me that you do not need even that. All what
you need is:

$ git reset --soft master

and then commit your changes (git reset --soft does not touch the index
file nor the working tree at all).

But then you still have to do:
git checkout master
git merge HEAD@{1}

To actually update the "master" branch head. The reset doesn't re-attach
HEAD.

You are right... I forgot about that somehow. So, it should be

$ git reset --soft master
$ git checkout master

and only then

$ git commit

That would do, but:
git checkout <commit>
*make changes*
git reset --soft master
git checkout master
git commit

seems unnecessarily complicated, when you could as well do:
git read-tree -u --reset <commit>
*make changes*
git commit

Björn

On Mon, Nov 02, 2009 at 06:01:06PM +0100, Björn Steinbrink wrote:

That would do, but:
git checkout <commit>
*make changes*
git reset --soft master
git checkout master
git commit

seems unnecessarily complicated, when you could as well do:
git read-tree -u --reset <commit>
*make changes*
git commit

I thought Markus *already* had made changes on that commit, but
maybe I misread what he wrote...


Dmitry

On 2009.11.02 20:45:46 +0300, Dmitry Potapov wrote:

I thought Markus *already* had made changes on that commit, but
maybe I misread what he wrote...

Hm, I understood that the described scenario is one he wants to
implement in his front-end, and that he was asking for advice how to
do it. I guess only Martin can tell for sure, so let's see :-)

Björn