Binary files in a linear repository

> 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?

>
> 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?

> 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).

> On 2009.11.02 18:48:31 +0300, Dmitry Potapov wrote:
> > 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).
> 
> 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.

> 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:
> > > 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