I'm going to run periodically a process which uses the current working tree and
I'd like to protocol what happens. As a part of the protocol I need the exact
state of the working tree and that's what is git good for, right? But it must
neither disturb my normal workflow nor interfere with my ordinal commits. I
could probably use something like
GIT_DIR=a_special_git_dir
git reset --soft a_special_branch
git add -A
git commit -m "automatic"
git push
where the push would go to my ordinary external repository (used as a backup
here). I'm quite a beginner and unsure what problem should I expect here.
Even if there were no problems, it's not very nice. It uses an additional
repository which is quite strange. Moreover, there's no way to find out how the
saved working tree snapshot is related to existing ordinal commits.
PS: I don't want to post separate "thank you" messages, so let me thank to
everybody now. I've already had three questions and got three times a very
helpful answer in a very short time, just fantastic.
Hi Maartin,
Maaartin writes:
I'm going to run periodically a process which uses the current working tree and
I'd like to protocol what happens. As a part of the protocol I need the exact
state of the working tree and that's what is git good for, right? But it must
neither disturb my normal workflow nor interfere with my ordinal commits. I
could probably use something like
GIT_DIR=a_special_git_dir
git reset --soft a_special_branch
git add -A
git commit -m "automatic"
git push
Instead of doing it by hand, I'd recommend using something nicer like
Flashbake to do this [1].
where the push would go to my ordinary external repository (used as a backup
here). I'm quite a beginner and unsure what problem should I expect here.
I suppose you can create another branch without common ancestry and
keep committing there. I'd suggest using contrib/git-new-workdir to
keep a working copy of that branch and using flashbake to commit to it
without interrupting your working branch.
Even if there were no problems, it's not very nice. It uses an additional
repository which is quite strange. Moreover, there's no way to find out how the
saved working tree snapshot is related to existing ordinal commits.
The additional repository is eliminated now. You can use the complete
Git infrastructure to play with the commits in your working branch and
your flashbake branch.
-- Ram
[1] http://bitbucketlabs.net/flashbake/
On Fri, Sep 24, 2010 at 22:43, Maaartin [off-list ref] wrote:
I'm going to run periodically a process which uses the current working tree and
I'd like to protocol what happens. As a part of the protocol I need the exact
state of the working tree and that's what is git good for, right? But it must
neither disturb my normal workflow nor interfere with my ordinal commits. I
could probably use something like
...
Even if there were no problems, it's not very nice. It uses an additional
repository which is quite strange. Moreover, there's no way to find out how the
saved working tree snapshot is related to existing ordinal commits.
Try using low-level git commands (the "plumbing").
Take a look at GIT_INDEX_FILE environment variable and
"git write-tree", "git commit-tree" and "git update-ref", in
addition to "git add".
I.e. (untested):
$ (
export GIT_INDEX_FILE=.git/myindex
git add . &&
tree=$(git write-tree) &&
commit=$(date |git commit-tree $tree -p protocol) &&
git update-ref -m autolog protocol $commit
)
On 10-09-25 12:05, Alex Riesen wrote:
On Fri, Sep 24, 2010 at 22:43, Maaartin [off-list ref] wrote:
quoted
I'm going to run periodically a process which uses the current working tree
and
quoted
I'd like to protocol what happens. As a part of the protocol I need the exact
state of the working tree and that's what is git good for, right? But it must
neither disturb my normal workflow nor interfere with my ordinal commits. I
could probably use something like
Try using low-level git commands (the "plumbing").
Take a look at GIT_INDEX_FILE environment variable and
"git write-tree", "git commit-tree" and "git update-ref", in
addition to "git add".
I.e. (untested):
$ (
export GIT_INDEX_FILE=.git/myindex
git add . &&
tree=$(git write-tree) &&
commit=$(date |git commit-tree $tree -p protocol) &&
git update-ref -m autolog protocol $commit
)
Based on this, I've created a simple script "git-autocom" which seems to work
somehow. In order to test it place both attachments in a new directory and run
"test-git-autocom". The test creates a new working tree with a repository and
some commits and then invokes "git-autocom".
A branch autocom gets created, but I'm quite unsure if it's correct. I see a
problem in case the script runs with the branch autocom checked out. Maybe a
tag could be better or whatever.
I see I can attach no files here in http://post.gmane.org
So I placed them in
http://dl.dropbox.com/u/4971686/101010/git-autocom
and
http://dl.dropbox.com/u/4971686/101010/test-git-autocom
and copied them here as well (I hope there's a better way).
====== git-autocom
#!/bin/sh
message="autocom $(date)"
head=$(git show-ref -s --head HEAD)
# the first parent should be autocom
parent1="-p $(git show-ref -s refs/heads/autocom)"
# needed for the very first use
test -f .git/refs/heads/autocom || parent1=""
# the second parent should be the current head
parent2="-p $head"
# make sure not giving the same parent twice
test "$parent1" = "$parent2" && parent1=""
#temporary index
export GIT_INDEX_FILE=.git/autocom.tmp
git add -A &&
tree=$(git write-tree) &&
commit=$(echo "$message" | git commit-tree $tree $parent1 $parent2) &&
git update-ref -m "$message" refs/heads/autocom $commit
====== test-git-autocom
#!/bin/sh
/bin/rm -fR testtree 2>/dev/null
mkdir testtree &&
cd testtree &&
git init &&
echo a > a &&
git add -A && git commit -m "a" &&
echo b > b &&
git add -A && git commit -m "b" &&
echo c > c &&
/bin/rm b &&
git add -A &&
/bin/rm a &&
echo "preparation OK" &&
../git-autocom &&
echo "autocom OK" &&
git log &&
git log autocom
======