On Tue, Nov 17, 2020 at 6:10 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Felipe Contreras <felipe.contreras@xxxxxxxxx> writes: > > > If we already know "origin/HEAD" is very likely pointing to the > > integration branch, then why do we need to know what that branch is > > called in that particular project? > > > > Just refer to that branch as "origin/@", or just "origin". > > "git merge origin" turns into "git merge origin/HEAD", I think, and > we had it for quite some time. > > But repositories may not even have any origin to begin with. The > one I am typing this message in certainly does not. And we need > some fallback default when origin/HEAD cannot be used anyway, and > that is where the convention comes in again. You cannot escape from > it, and ... I did not say the convention can be escaped, I said the convention can be minimized. Since apparently there's already support for "origin/HEAD", a lot of documentation can avoid the term "origin/master", and simply use "origin". However, we need to make sure users have a properly set up "origin/HEAD", and at least in my case none of my remotes have set it up. Looking at the code, it seems: git clone URL test Is different than: git init test git remote add origin URL git fetch origin git checkout -b $favorite origin In the latter there is no origin/HEAD, and I don't see why that should be the case. Cheers. -- Felipe Contreras
