Re: [PATCH 0/3] Fixing volatile HEAD in push.default = current

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

Re: [PATCH 0/3] Fixing volatile HEAD in push.default = current

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:57:23

Ramkumar Ramachandra [off-list ref] writes:
There's still a lot to think about.
Is there?  I do not think "volatile" is particularly a good
description for this, but showing what is pushed as a concrete
branch name feels like a good improvement to me, at least in
principle.

I haven't picked them up, and I won't be picking them up today, as I
suspect this series may conflict with the pre-2.0 preparation and
2.0 transition patches and I may end up having to fix conflicts
unnecessarily (resolving is eventually needed before 2.0 happens,
but resolving them, or even having to worry about the possibility
that I may have to do so, do not have to steal time from me today).

Thanks.
[3/3] is the big itch: [1/2] and [2/2] are just setup patches.

Ramkumar Ramachandra (3):
  push: factor out the detached HEAD error message
  push: fail early with detached HEAD and current
  push: don't push the volatile HEAD with current

 builtin/push.c | 20 +++++++++++++-------
 1 file changed, 13 insertions(+), 7 deletions(-)

Re: [PATCH 0/3] Fixing volatile HEAD in push.default = current

From: Ramkumar Ramachandra <hidden>
Date: 2016-06-15 22:57:23

Junio C Hamano wrote:
Is there?  I do not think "volatile" is particularly a good
description for this, but showing what is pushed as a concrete
branch name feels like a good improvement to me, at least in
principle.
Okay.  I used "volatile", because push does not lock HEAD when the
operation begins, even though it performs a super-late resolution (in
the transport-layer); HEAD is not guaranteed to remain invariant in
that time.  Suggest nicer wording?
I haven't picked them up, and I won't be picking them up today, as I
suspect this series may conflict with the pre-2.0 preparation and
2.0 transition patches and I may end up having to fix conflicts
unnecessarily (resolving is eventually needed before 2.0 happens,
but resolving them, or even having to worry about the possibility
that I may have to do so, do not have to steal time from me today).
We're at 1.8.3; isn't it a little early to be thinking of 2.0?  Is it
conflicting with jc/push-2.0-default-to-simple in pu?  I should
re-send after this topic graduates to master in 2.0?

I have no problems re-sending at a convenient time (provided you tell
me how to determine that convenient time), but reviews don't have to
wait: it's fresh in my memory now.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help