Re: [PATCH v2] branch -D: allow - as abbreviation of '@{-1}'

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi, and thanks for the quick reroll.

A small advice: don't hesitate to reply to reviewers in the thread for
v1. As a reviewer, I appreciate a quick reply like "OK, will do in v2",
or even "I disagree, I think my version is better because: ..." (I'm not
_always_ right ;-) ).

Elena Petrashen <elena.petrashen@xxxxxxxxx> writes:

> Signed-off-by: Elena Petrashen <elena.petrashen@xxxxxxxxx>
> ---
> This micro-patch is meant to allow “-“ as a short-hand for
> “@{-1} for branch -D (Cf. $gmane/230828):
>
> * based on the discussion on the previous version of the patch,
> added the advice on how to restore the deleted branch using
> git branch deleted_name sha1 - to ensure safety and 
> newbie-friendliness
>
> * git branch (-d | -D) is not supposed to accept any other
> arguments except for branch name so it makes sense to replace
> the argv[i] with @{-1}. We will not lose the opportunity to
> use it for something different for other git branch uses if
> we will decide it’s required.

As much as possible, try to distinguish new things in this version and
general remarks on your patch. Here, the first point is new and could
appear below "Changes since v1". The second is not new, I think you can
either consider that it is a followup to previous discussion (as Eric
interpreted it in v1) and remove the comment from v2, or consider it as
a justification of why your patch is sensible and include it in the
commit message (what I suggested in v1, but Eric more or less convinced
me that I was wrong).

> * if there’s no previous branch in the repository yet, a
> specific warning message is given

As I said in v1, I think this is a separate topic and should be moved to
a separate patch. As I said above, you are free to disagree (and it's
not terribly important), but avoid leaving discussions open.

One point in favor of splitting the patch is that it's a good exercice
for a newcommer ;-).
> +	if (!strcmp(argv[dash_position], "-")){

Style: space between ) and {.

> @@ -213,7 +223,8 @@ static int delete_branches(int argc, const char **argv, int force, int kinds,
>  	for (i = 0; i < argc; i++, strbuf_release(&bname)) {
>  		const char *target;
>  		int flags = 0;
> -
> +		if (expand_dash_shortcut (argv, i))
> +			dash_shortcut = 1;

Nit: the blank line removal is not needed.

> +			if (dash_shortcut == 1)
> +			       printf( _("\nIf that happened by mistake, you may want to restore"

Style: no space after (.

> +				" it with:\n\ngit branch %s %s\n"), bname.buf,
> +				find_unique_abbrev(sha1, DEFAULT_ABBREV));

I think the message is overly long (4 '\n', and I think "If that
happened by mistake" is not needed, just "to restore the branch,
run ..." would be enough).

A rule that is usually applied for messages with Git:

* If the message is triggered by a user-error, then it's OK to have a
  long and possibly scary message: advanced users are not supposed to
  see it.

* If the message is seen by normal users in daily usage, then

  - we try to keep it as short as possible.

  - if it's not short enough, we allow disabling it with an advice.*
    configuration variable.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]