From: Shawn Pearce <spearce@spearce.org>
To: Andy Whitcroft <apw@shadowen.org>
Cc: Lars Hjemli <hjemli@gmail.com>,
git@vger.kernel.org, Junio C Hamano <junkio@cox.net>
Subject: Re: [RFC] git-branch: add options and tests for branch renaming
Date: Tue, 28 Nov 2006 10:39:04 -0500 [thread overview]
Message-ID: <20061128153904.GC28337@spearce.org> (raw)
In-Reply-To: <456C4FCE.6090306@shadowen.org>
Andy Whitcroft <apw@shadowen.org> wrote:
> Ok, I have been feeling uneasy about rename and reflogs for a while now.
> About removing reflogs too for that matter.
>
> In my mind the ref log is about tracking what a ref points to. So I
> want to be able to say "what was next, yesterday". Do I care if its not
> there now? Perhaps I want a rename to just put a rename from in the top
> of the new reflog and leave the old there.
>
> Yep, no idea how we would clean them up with this model. But ...
You use a global reflog instead of a ref specific log. There are
of course huge problems with that idea, but it is probably the
simplest way to solve what you want.
Though I'm not sure why you care that much. To me a ref is just
as transient as the name of the working directory the repository is
housed in. I could care less what I called that directory last week,
just that it exists and has the content I expect. On the other
hand, once I'm in that directory I *do* want the history of it.
That's where git comes in. Likewise for a ref once I am speaking
about a given ref, I want the history of it, and that's where git's
reflog comes in.
Although I just realized this paticular case:
git branch -D next
git fetch origin next:next
...
git fetch origin next:next
git branch -M next bob
...
... 2 days go by ...
...
git fetch origin next:next
... arrgh next is no good! ...
git log next@{2.days.ago}
and there's nothing there, as the log for next just started in
the last fetch. Yet you had a next that you renamed to bob, and
that next has the log.
Though this can be easily dealt with by reading the RENAME_LOG.
If you scan both this ref's log and the RENAME_LOG and switch to
scanning another ref's log when you find that this ref was renamed
to another ref, then you get what you expect above. Except if you
deleted the rename destination branch.
I can't say I would use that feature though, despite how handy I
find reflogs to be.
--
next prev parent reply other threads:[~2006-11-28 15:39 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-28 14:47 [RFC] git-branch: add options and tests for branch renaming Lars Hjemli
2006-11-28 15:03 ` Andy Whitcroft
2006-11-28 15:39 ` Shawn Pearce [this message]
2006-11-28 16:10 ` Lars Hjemli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20061128153904.GC28337@spearce.org \
--to=spearce@spearce.org \
--cc=apw@shadowen.org \
--cc=git@vger.kernel.org \
--cc=hjemli@gmail.com \
--cc=junkio@cox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).