On Mon, Aug 20, 2007 at 01:28:31AM -0700, Junio C Hamano wrote:
> I do not think of anything that would barf offhand (we already
> do that in FETCH_HEAD), but this would definitely be carefully
> audited.
I didn't say it up front, but I think this is definitely post-1.5.3
material. :)
> > 2. It looks like doing an anonymous 'git-pull' leaves GITHEAD_* as the
> > commit sha1, which means you will end up with that sha1 rather than
> > 'REMOTE', which is less nice than the current behavior.
>
> Much less nice indeed.
I think this is a failing of git-merge, though, for not including that
nice human-readable information. We can fix it with something like this:
-- >8 --
diff --git a/git-merge.sh b/git-merge.sh
index e899801..742e15d 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -477,7 +477,14 @@ then
else
for remote
do
- echo $remote $(eval echo \$GITHEAD_$remote)
+ friendly_name=$(eval echo \$GITHEAD_$remote)
+ if echo $friendly_name | egrep -q '[0-9a-f]{40}'; then
+ friendly_name=$(
+ sed -ne "s/$friendly_name //p" \
+ <"$GIT_DIR/FETCH_HEAD" 2>/dev/null
+ )
+ fi
+ echo $remote "$friendly_name"
done >"$GIT_DIR/MERGE_HEAD"
printf '%s\n' "$merge_msg" >"$GIT_DIR/MERGE_MSG"
fi
-- 8< --
But probably it should wait for a better communications channel for
cross-command state.
> It would be very nice, and I would encourage any wannabe
> Porcelain writers to go wild on this. One worry I have is if we
> would need to support nested states. "I was in the middle of
> 'foo' and then had to go sideways to do 'bar' which I am now in
> the middle of" kind of thing.
It's just a stack, so I think you could implement it as a linked
list, with STATE being the head of the list, and each STATE file you
write pointing to the previous one (which you rename when pushing).
I might try to work on this, but definitely not tonight.
-Peff
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
