From mboxrd@z Thu Jan  1 00:00:00 1970
From: Nick Dokos <nicholas.dokos@hp.com>
Subject: Re: Invalid function: with-parsed-tramp-file-name with Perl
Date: Sat, 22 Sep 2012 01:05:38 -0400
Message-ID: <4308.1348290338@alphaville>
Reply-To: nicholas.dokos@hp.com
Return-path: <emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org>
Received: from eggs.gnu.org ([208.118.235.92]:35299)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <nicholas.dokos@hp.com>) id 1TFHuS-0002HB-UH
	for emacs-orgmode@gnu.org; Sat, 22 Sep 2012 01:05:45 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <nicholas.dokos@hp.com>) id 1TFHuR-0004FY-7R
	for emacs-orgmode@gnu.org; Sat, 22 Sep 2012 01:05:44 -0400
Received: from g4t0015.houston.hp.com ([15.201.24.18]:16035)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <nicholas.dokos@hp.com>) id 1TFHuR-0004FU-0N
	for emacs-orgmode@gnu.org; Sat, 22 Sep 2012 01:05:43 -0400
List-Id: "General discussions about Org-mode." <emacs-orgmode.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/emacs-orgmode>,
	<mailto:emacs-orgmode-request@gnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/archive/html/emacs-orgmode>
List-Post: <mailto:emacs-orgmode@gnu.org>
List-Help: <mailto:emacs-orgmode-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/emacs-orgmode>,
	<mailto:emacs-orgmode-request@gnu.org?subject=subscribe>
Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org
Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org
To: Achim Gratz <Stromeko@nexgo.de>
Cc: emacs-orgmode@gnu.org

Achim Gratz <Stromeko@nexgo.de> wrote:

> Nick Dokos writes:
> > OK. Is there no way to fix that? That's pretty confusing.
> 
> If you already know the tag is on a merge commit on the wrong side:
> 
> git tag fixup release_7.8.11
> git tag -d release_7.8.11
> git tag release_7.8.11 fixup^2
> git tag -d fixup
> 

Does that have any undesirable consequences? If not, can this be done on
the repo?

I actually did the above in my clone and then fetched tags again which
reset the tag to the previous state, so it seems that once the change is
made in the repo, a `git fetch --tags origin' will fix up local copies.

> > And how can I tell that I have fallen into this trap?
> 
> Probably easiest to see in gitk.  Otherwise,
> 

Ah, yes - I keep forgetting about gitk. It's fairly obvious there (now
that you've explained it - I'm not sure I would have been able to see it
even there, if I didn't know what was going on already, but the fact
that the suspect commit does not appear in the range would have been a
big clue - plus the fact that there is only a handful of commits instead of
hundreds of them.)

> git --no-pager show release_7.8.11
> 
> tells you you are dealing with a merge and what the two parents are.
> 

OK - again, I don't think I could have figured out what was going on
without your previous explanation.

Thanks,
Nick