* someone changed the contents of my HEAD.
@ 2006-02-28 3:04 Dave Jones
2006-02-28 5:22 ` Junio C Hamano
0 siblings, 1 reply; 3+ messages in thread
From: Dave Jones @ 2006-02-28 3:04 UTC (permalink / raw)
To: git
I just tried to check in some changes to some trees
on master.kernel.org, and found after the first checkin
that git claimed..
fatal: Not a git repository
A lot of head-scratching later, I think I've figured out
what's happened. It seems there was a recent upgrade
to the version of git on m.k.o, which is incompatible
with the helper scripts I used before.
When checking in changes previously, I used this..
#!/bin/sh
export GIT_AUTHOR_NAME="$1"
export GIT_AUTHOR_EMAIL="$2"
tree=$(git-write-tree) || exit 1
commit=$(git-commit-tree $tree -p HEAD) || exit 1
echo $commit > .git/HEAD
and called it thus..
commit-as "Dave Jones" "<davej@redhat.com>"
Previously, this updated .git/HEAD to a ptr to the latest committed change.
All was well, as I only ever have one HEAD in my trees.
With the new .git however, when I clone a new tree, .git/HEAD
contains ref: refs/heads/master, so my script destroys the git metadata.
For my newly created repos, this isn't a problem, as I can fudge my
commit-as script to write to .git/refs/heads/master instead, but
my concern now is the unpulled changes in the existing repos
I have on master. Will Linus be able to pull those into his tree
with git 1.2.3, or will I have to recreate those repos with the
new-style .git/HEAD ?
Dave
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: someone changed the contents of my HEAD.
2006-02-28 3:04 someone changed the contents of my HEAD Dave Jones
@ 2006-02-28 5:22 ` Junio C Hamano
2006-02-28 5:58 ` Dave Jones
0 siblings, 1 reply; 3+ messages in thread
From: Junio C Hamano @ 2006-02-28 5:22 UTC (permalink / raw)
To: Dave Jones; +Cc: git
Dave Jones <davej@redhat.com> writes:
> When checking in changes previously, I used this..
>
> #!/bin/sh
> export GIT_AUTHOR_NAME="$1"
> export GIT_AUTHOR_EMAIL="$2"
> tree=$(git-write-tree) || exit 1
> commit=$(git-commit-tree $tree -p HEAD) || exit 1
> echo $commit > .git/HEAD
This has been deprecated for a looong time, but perhaps I should
have been louder. "git commit --author" should be fine -- I do
not think you do not even need such a wrapper.
> For my newly created repos, this isn't a problem, as I can fudge my
> commit-as script to write to .git/refs/heads/master instead, but
> my concern now is the unpulled changes in the existing repos
> I have on master. Will Linus be able to pull those into his tree
> with git 1.2.3, or will I have to recreate those repos with the
> new-style .git/HEAD ?
A .git/HEAD symlink pointing at refs/heads/master _is_ still
(and will be) supported, so either symlink or symref is fine.
Bare SHA1 object name in HEAD is not -- git would not know which
branch you are on, so "checkin" would not work after that.
Your refs/heads/master might be stale (one rev or more older
than what you replaced .git/HEAD with) but still should be a
proper ancestor. After making sure your refs/heads/master has
the right commit (you may have it there already if you have been
updating them using "git-push"), running "git-symbolic-ref HEAD
refs/heads/master" would fix things.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: someone changed the contents of my HEAD.
2006-02-28 5:22 ` Junio C Hamano
@ 2006-02-28 5:58 ` Dave Jones
0 siblings, 0 replies; 3+ messages in thread
From: Dave Jones @ 2006-02-28 5:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
On Mon, Feb 27, 2006 at 09:22:18PM -0800, Junio C Hamano wrote:
> > #!/bin/sh
> > export GIT_AUTHOR_NAME="$1"
> > export GIT_AUTHOR_EMAIL="$2"
> > tree=$(git-write-tree) || exit 1
> > commit=$(git-commit-tree $tree -p HEAD) || exit 1
> > echo $commit > .git/HEAD
>
> This has been deprecated for a looong time, but perhaps I should
> have been louder. "git commit --author" should be fine -- I do
> not think you do not even need such a wrapper.
I guess I wasn't paying attention :)
It's worked just fine up until a few days ago.
I can change my habits to use the preferred approach though.
> > For my newly created repos, this isn't a problem, as I can fudge my
> > commit-as script to write to .git/refs/heads/master instead, but
> > my concern now is the unpulled changes in the existing repos
> > I have on master. Will Linus be able to pull those into his tree
> > with git 1.2.3, or will I have to recreate those repos with the
> > new-style .git/HEAD ?
>
> A .git/HEAD symlink pointing at refs/heads/master _is_ still
> (and will be) supported, so either symlink or symref is fine.
> Bare SHA1 object name in HEAD is not -- git would not know which
> branch you are on, so "checkin" would not work after that.
>
> Your refs/heads/master might be stale (one rev or more older
> than what you replaced .git/HEAD with) but still should be a
> proper ancestor. After making sure your refs/heads/master has
> the right commit (you may have it there already if you have been
> updating them using "git-push"), running "git-symbolic-ref HEAD
> refs/heads/master" would fix things.
One scary thing fell out of this. Andrew did a pull on my trees
and found bogons in both of them. Both agpgart and cpufreq trees
contained partial (1 file) reverts of earlier commits in my last commit
to the head of each repo. I can't explain how that happened, and
I'm surprised my head-munging would be the reason.
I've just rebuilt those two repos as there was only 3-4 patches
in both, so it wasn't a big deal. Something to watch out for
though if anyone else has been doing something similar to how
I was doing checkins.
Dave
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2006-02-28 5:59 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-02-28 3:04 someone changed the contents of my HEAD Dave Jones
2006-02-28 5:22 ` Junio C Hamano
2006-02-28 5:58 ` Dave Jones
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).