23 ms·
> This would solve the problem as I see it as you could truly view a branch history; typically for example you'd be asking for logs of the "master" branch histo
by cesarb 5y ago
> This would solve the problem as I see it as you could truly view a branch history; typically for example you'd be asking for logs of the "master" branch history.
Which "master"? Since git is fully distributed, there's no central repository which contains the true "master" branch. It's perfectly valid to have two independent lines of development, both naming its current branch "master" (in separate clones of the repository), and later merge one of them into the other. As another example, consider the branch named "for-linus"; take a look at the Linux kernel git history, and see how many independent branches all named "for-linus" are merged on each release.
- Too 5y agoEvery remote could have its own list of "revs that were on branch". Gitlab, or whatever is your server of choice, would then automatically record this on merges. Most code review tools already has this information stored in their databases outside of git. It would need to be transferred on the side and not in the commits themselves to not rewrite commits in case of merges from other remote. Similar to tags, but instead of only pointing to single commit it could be a list, let's call them labels. Git log would then add option like --labeled-by=origin/merged-on-master