git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Clement Mabileau <mabileau.clement@gmail.com>
To: Junio C Hamano <gitster@pobox.com>,
	ClementMabileau via GitGitGadget <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH v2] branch: improve error log on branch not found by checking remotes refs
Date: Thu, 23 Mar 2023 16:51:22 +0100	[thread overview]
Message-ID: <cffce108-c39d-f13f-9fb6-60624f7e7cea@gmail.com> (raw)
In-Reply-To: <xmqq355wctjq.fsf@gitster.g>


On 22/03/2023 23:25, Junio C Hamano wrote:
> "ClementMabileau via GitGitGadget" <gitgitgadget@gmail.com> writes:
> 
>> From: ctmbl <mabileau.clement@gmail.com>
> 
> This "name <address>" should match what is on "Signed-off-by:".  I
> offhand do not know where GitGitGadget gets the information, but I
> suspect the original commit object you created records ctmbl as the
> author name, not "Clement Mabileau"?  I can fix it for this single
> time, but if you plan to contribute to the project in an ongoing
> basis, you may want to fix your .git/config (or $HOME/.gitconfig)
> with a "[user] name = ..." entry.

Well maybe it got it from the original commit or from my GitHub
username, I can't know for sure. But sorry for that :/ , I'll make
sure it's fixed it for potential future contribution!

> If the user said "git branch -d frotz", we would have 'frotz'
> there, right?  Then we apply FMT_REMOTES (Yuck, now I have to go
> scroll up, see that it is set to "refs/remotes/%s", and hope or
> verify that its value hasn't been changed in the meantime---in
> short, don't introduce that variable.  A macro might be OK, but I do
> not see much point here) and we get "refs/remotes/frotz" back.
> 
> So, we check "refs/remotes/frotz" here ...
> 
>> [...]
> 
> ... but why should we?  If your workflow interacts with the original
> repository you cloned from, you would have remote-tracking branches
> like "refs/remotes/origin/frotz" and it may be plausible that you
> meant to remove with "git branch -d frotz" the remote-tracking
> branch "refs/remotes/origin/frotz".  But the new code makes no
> effort to figure out the name of the remote (e.g. 'origin') here,
> and I am not sure what value it adds to check and try to tell the
> user about "refs/remotes/frotz".  Or are we assuming that the user
> would say "git branch -d origin/frotz" in such a case?

Before fixing anything about the code maybe I should first address your
last point which is the interest of the patch in the first place (and I
should have started with that...).

A few months earlier, for the first time, I had to delete a remote ref
(because of a fork I fetched but no longer wanted: maybe a designed
solution exists but I'm not aware of it). However, despite being used to
git I had a hard time figuring out how to do it, I tried different
things, one was `git branch -d origin/<branch>` (I recently discovered
that it was written in `git branch --help` but I didn't find it at the
time). Even googling it proved difficult (because of a poor keyword
choice I must confess), most results was dealing with deleting remote
branches, such as `git push remote :branch`.
In the end, I finally understood that I needed that `--remote` flag and
really regretted that there wasn't an hint message to head me towards
the solution when I was getting close to it.

Now I hope you'll understand why I suggested this patch. Maybe I'm the
only one that ended up in this situation, in this case I'd understand
that you would no longer be interested in the patch!
However if you still are, I'll be happy to make the modification you
asked for.

>> +				if (virtual_target)
>> +					error(_(MISSING_BRANCH_HINT_MSG), bname.buf);
>> +				else
>> +					error(_(MISSING_BRANCH_ERROR_MSG), bname.buf);
>> +			}
> 
> Are you leaking virtual_target here?

Yeah probably, I'll fix it along with the other.

Thanks for reviewing this!

  reply	other threads:[~2023-03-23 15:51 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-22  9:42 [PATCH 0/2] branch: improve error log on branch not found by checking remotes refs ClementMabileau via GitGitGadget
2023-03-22  9:42 ` [PATCH 1/2] " ctmbl via GitGitGadget
2023-03-22  9:42 ` [PATCH 2/2] Fix mem leak in branch.c due to not-free newly added virtual_name variable ctmbl via GitGitGadget
2023-03-22 16:52   ` Junio C Hamano
2023-03-22 20:00     ` Clement Mabileau
2023-03-22 20:52       ` Junio C Hamano
2023-03-22 20:03 ` [PATCH v2] branch: improve error log on branch not found by checking remotes refs ClementMabileau via GitGitGadget
2023-03-22 22:25   ` Junio C Hamano
2023-03-23 15:51     ` Clement Mabileau [this message]
2023-04-04 13:30       ` Clement Mabileau
2023-04-04 16:24         ` Junio C Hamano
2023-04-05  9:15           ` Clement Mabileau
2023-04-05 11:43   ` [PATCH v3] " ClementMabileau via GitGitGadget

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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cffce108-c39d-f13f-9fb6-60624f7e7cea@gmail.com \
    --to=mabileau.clement@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=gitster@pobox.com \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).