Re: [PATCH 3/3] rename_ref: replace empty deletion message in HEAD's log

2017-02-17 Thread Jeff King
On Fri, Feb 17, 2017 at 06:41:32PM -0500, Kyle Meyer wrote: > Junio C Hamano writes: > > [...] > > > Do we even want these "internal" delete_ref() invocations to be > > logged in HEAD's reflog? I understand that this is inside the > > implementation of renaming an old ref

Re: [PATCH 3/3] rename_ref: replace empty deletion message in HEAD's log

2017-02-17 Thread Junio C Hamano
Kyle Meyer writes: > Junio C Hamano writes: > > [...] > >> Do we even want these "internal" delete_ref() invocations to be >> logged in HEAD's reflog? I understand that this is inside the >> implementation of renaming an old ref to a new ref, and reflog >>

Re: [PATCH 3/3] rename_ref: replace empty deletion message in HEAD's log

2017-02-17 Thread Kyle Meyer
Jeff King writes: > On Fri, Feb 17, 2017 at 02:43:50PM -0500, Jeff King wrote: > >> Yes. I think the options are basically (in order of decreasing >> preference in my opinion): >> >> 1. Log a rename entry (same sha1, but note the rename in the free-form >> text). >> >>

Re: [PATCH 3/3] rename_ref: replace empty deletion message in HEAD's log

2017-02-17 Thread Kyle Meyer
Junio C Hamano writes: [...] > Do we even want these "internal" delete_ref() invocations to be > logged in HEAD's reflog? I understand that this is inside the > implementation of renaming an old ref to a new ref, and reflog > message given to delete_ref() would matter only

Re: [PATCH 3/3] rename_ref: replace empty deletion message in HEAD's log

2017-02-17 Thread Junio C Hamano
Jeff King writes: > Thinking on it more, we probably _do_ want two entries. Because the > operations are not atomic, it's possible that we may end up in a > half-way state after the first entry is written. And when debugging such > a case, I'd much rather see the first half of the

Re: [PATCH 3/3] rename_ref: replace empty deletion message in HEAD's log

2017-02-17 Thread Jeff King
On Fri, Feb 17, 2017 at 02:43:50PM -0500, Jeff King wrote: > Yes. I think the options are basically (in order of decreasing > preference in my opinion): > > 1. Log a rename entry (same sha1, but note the rename in the free-form > text). > > 2. Log a delete (sha1 goes to null) followed

Re: [PATCH 3/3] rename_ref: replace empty deletion message in HEAD's log

2017-02-17 Thread Jeff King
On Fri, Feb 17, 2017 at 09:50:54AM -0800, Junio C Hamano wrote: > > I see we actually already have a "logmsg" parameter. It already says > > "Branch: renamed %s to %s". Could we just reuse that? I know that this > > step is technically just the deletion, but I think it more accurately > >

Re: [PATCH 3/3] rename_ref: replace empty deletion message in HEAD's log

2017-02-17 Thread Junio C Hamano
Jeff King writes: > On Thu, Feb 16, 2017 at 10:58:00PM -0500, Kyle Meyer wrote: > >> When the current branch is renamed, the deletion of the old ref is >> recorded in HEAD's log with an empty message. Now that delete_refs() >> accepts a reflog message, provide a more descriptive

Re: [PATCH 3/3] rename_ref: replace empty deletion message in HEAD's log

2017-02-17 Thread Jeff King
On Thu, Feb 16, 2017 at 10:58:00PM -0500, Kyle Meyer wrote: > When the current branch is renamed, the deletion of the old ref is > recorded in HEAD's log with an empty message. Now that delete_refs() > accepts a reflog message, provide a more descriptive message. This > message will not be

[PATCH 3/3] rename_ref: replace empty deletion message in HEAD's log

2017-02-16 Thread Kyle Meyer
When the current branch is renamed, the deletion of the old ref is recorded in HEAD's log with an empty message. Now that delete_refs() accepts a reflog message, provide a more descriptive message. This message will not be included in the reflog of the renamed branch, but its log already covers