"Bence Ferdinandy" <bence@xxxxxxxxxxxxxx> writes: > On Wed Sep 11, 2024 at 00:29, Junio C Hamano <gitster@xxxxxxxxx> wrote: >> Bence Ferdinandy <bence@xxxxxxxxxxxxxx> writes: >> >> > What is missing for sure is: >> > - documentation >> > - tests (if needed) >> >> What change does not need tests? > > Fair enough, for the next iteration I'll look into tests as well! In this project, tests are written not because we want to demonstrate the shiny new feature we just invented. We write tests so that the invention we are shipping to our end users will keep behaveing in the way we originall intended without getting broken by future careless developers. The tests serve as watching eyes while the original author of the feature is not watching ;-) And that is why we also write tests that a feature does not trigger when it should not, as well as it triggers when it should. >> * One thing we MUST be careful about is that some remotes may not >> have ANY remote tracking branches (i.e. you only want to use the >> remote mechanism to give you a shorthand for URL, but you do not >> have fetch refspec at all). Even if refs/remotes/$repo/HEAD is >> missing for such a remote, we should *not* attempt to create it, >> as we are not populating refs/remotes/$repo/master and friends at >> all in such a case. > > You mean that somebody does git init && git remote add origin $remote, but > never does calls fetch? No. If the remote HEAD does not exist, we may still not want to create it. Imagine [remote "his"] url = https://git.kernel.org/pub/scm/git/git push = refs/heads/maint push = refs/heads/master push = refs/heads/next push = +refs/heads/seen without any refspec for the fetching side. "git fetch his master" may learn where the remote HEAD is, and it may even be pointing at their 'master' branch, but because we do not maintain any remote tracking information for their 'master' (in other words, refs/remotes/his/master is not updated by this 'fetch' and there is no configuration to make future 'fetch' to do so). Thanks.
