From: Junio C Hamano <hidden> Date: 2016-06-15 22:50:16
Maaartin [off-list ref] writes:
However, when I use my git-autocom script, those files get marked as deleted.
This is quite strange, especially because of them still existing. I'd strongly
prefer git-autocom to behave just like git commit (i.e., tracking the files).
The relevant part of my script follows:
export GIT_INDEX_FILE=.git/autocom.tmp
git add -A &&
If you really want "just like commit", then it would be more like "make a
commit object out of the current index, and put that somewhere outside the
current branch", and will not involve any "git add", no?
A useful goal would be "as if I said 'git add -u && git commit' from the
current state" (alternatively, you could say s/-u/-A/).
If this autocom.tmp starts out empty, "add" will of course honor what you
wrote in .gitignore hence would not add ignored files. You may have '*.o'
in the ignore mechanism to exclude usual build products. Until you
somehow tell git that you care about a vendor-supplied binary blob file
"binblob1.o" even though it has a name for usual ignored ones, you don't
want to get it tracked, and once you have done so with "git add -f", you
do want to get it tracked from that point. But your script cannot be
clever enough to selectively say "add -f" for such a file.
The "from the current state" part of the sentence of your goal (clarified
by the second paragraph above) fundamentally means you need to start from
your real index, so "cp -p .git/index $TMP_INDEX" is both appropriate and
inevitable for your script.
However, when I use my git-autocom script, those files get marked as
deleted.
quoted
This is quite strange, especially because of them still existing. I'd
strongly
quoted
prefer git-autocom to behave just like git commit (i.e., tracking the
files).
quoted
The relevant part of my script follows:
export GIT_INDEX_FILE=.git/autocom.tmp
git add -A &&
If you really want "just like commit", then it would be more like "make a
commit object out of the current index, and put that somewhere outside the
current branch", and will not involve any "git add", no?
You're right, I was using the wrong term, what I wanted was to take a SNAPSHOT
of the current working dir (this is called "commit" in csv/svn but not in git,
I know).
A useful goal would be "as if I said 'git add -u && git commit' from the
current state" (alternatively, you could say s/-u/-A/).
Yes, I wonder why it wasn't already implemented. I do something like
make all; git snapshot; send_the_executable_to_the_customer
which is IMHO needed quite often.
If this autocom.tmp starts out empty, "add" will of course honor what you
wrote in .gitignore hence would not add ignored files. You may have '*.o'
in the ignore mechanism to exclude usual build products. Until you
somehow tell git that you care about a vendor-supplied binary blob file
"binblob1.o" even though it has a name for usual ignored ones, you don't
want to get it tracked, and once you have done so with "git add -f", you
do want to get it tracked from that point. But your script cannot be
clever enough to selectively say "add -f" for such a file.
The "from the current state" part of the sentence of your goal (clarified
by the second paragraph above) fundamentally means you need to start from
your real index, so "cp -p .git/index $TMP_INDEX" is both appropriate and
inevitable for your script.
Yes, I wonder why it wasn't already implemented. I do something like
make all; git snapshot; send_the_executable_to_the_customer
which is IMHO needed quite often.
Perhaps it's wise to just use a separate repository on the same
repository. Maybe make it more convenient using some little
shell functions. I'm also using that for backup purposes, where
the repo lies outside the to-be-backed-up tree.
cu
--
----------------------------------------------------------------------
Enrico Weigelt, metux IT service -- http://www.metux.de/
phone: +49 36207 519931 email: weigelt@metux.de
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
----------------------------------------------------------------------
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------
Yes, I wonder why it wasn't already implemented. I do something like
make all; git snapshot; send_the_executable_to_the_customer
which is IMHO needed quite often.
Perhaps it's wise to just use a separate repository on the same
repository. Maybe make it more convenient using some little
shell functions. I'm also using that for backup purposes, where
the repo lies outside the to-be-backed-up tree.
I considered using a separate repository, too, but having "all in one" feels
somehow better. It allows me to push everything to a single remote repo and
compare the snapshots to ordinal commits, etc.
I let the snapshot point to the current head, which is where I get a problem now:
git show-ref HEAD
returns nothing,
git show-ref --head
returns HEAD and all branches and tags. Isn't it a bug? How can I get the HEAD
reference? I'm using git version 1.7.2.3 on cygwin.
From: Jakub Narebski <hidden> Date: 2016-06-15 22:50:17
Please try to not cull Cc list (use 'reply via email', if possible)
Maaartin [off-list ref] writes:
I let the snapshot point to the current head, which is where I get a problem now:
git show-ref HEAD
returns nothing,
git show-ref --head
returns HEAD and all branches and tags. Isn't it a bug? How can I get the HEAD
reference? I'm using git version 1.7.2.3 on cygwin.
You can use `git rev-parse --verify HEAD`, for example. Generally
scripted commands (including those in contrib/examples/) are good
sources of inspiration. Or if you want symbolic name, you can use
`git symbolic-ref HEAD` or `git rev-parse --symbolic-full-name HEAD`.
As for `git show-ref HEAD` - git-show-ref uses its own way of pattern
matching; in new enough version of git-show-ref manpage you can read
that:
<pattern>...::
Show references matching one or more patterns. Patterns are matched from
the end of the full name, and only complete parts are matched, e.g.
'master' matches 'refs/heads/master', 'refs/remotes/origin/master',
'refs/tags/jedi/master' but not 'refs/heads/mymaster' nor
'refs/remotes/master/jedi'.
So `git show-ref HEAD` would match 'refs/.../HEAD`, e.g. `refs/remotes/origin/HEAD`,
but not `HEAD` which is outside `refs/`.
I tripped over strange git-show-ref <pattern> semantic too.
P.S. there is also git-for-each-ref.
--
Jakub Narebski
Poland
ShadeHawk on #git