4 ms·

The author identifies the problem which I think is a fundamental failure of the git model which is that commits aren't associated with branches. But proposes

by derriz 5y ago

The author identifies the problem which I think is a fundamental failure of the git model which is that commits aren't associated with branches. But proposes a different solution. I wonder why they didn't decide to attach a branch identifier to each commit. 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. The topological view can help but the lack of notion of a branch as anything but a pointer to one commit means you effectively do loose history unless you go for a burdensome tagging scheme.

zeroimpl 5y ago
But commits change branches. None of the commits started on the "master" branch, they started on some developer's branch (which might also be called "master" in a different repo, but is still separate).
- derriz 5y ago
  I'm not sure I understand your point? Say for example, I'm looking at a freshly cloned repo. There's a first commit and most-recent commit on master - I can identify them with git-log. The problem is that I cannot view the path of commits between these two if I'm only interested in the commits made when the current branch was master (which is generally the case unless I want to drill into a feature branch). Disallowing merges makes the problem go away but that removes a lot of options in terms of work-flow.
  - jhardy54 5y ago
    Would `git log --merges` solve this? Assuming you use a merge-based workflow this would show only merge commits without any of the details of each individual commit from the merged branch.
  - zeroimpl 5y ago
    I don't follow - If you are on a freshly cloned repo, none of the commits were made when the current branch was master, they were made on another user's git repo before your repo existed.
  - jlokier 5y ago
    > I'm only interested in the commits made when the current branch was master When I'm working none of the commits are made when the current branch was master. They are made on branches, where commits are finalised, tested and signed, and then master is fast-forwarded to match the branch tip commit (or something intermediate if I'm satisfied with that). Conflicts are detected by the fast-forward and reconciled locally in the branch, re-tested and signed off again. It's rare that the current branch is master, and no commits are created while on master. So what would you like to see?
AtNightWeCode 5y ago
On the contrary, once people realize that a commit hash is something that spans across all branches the real beauty of GIT emerges. You can than and there make decisions on a branch level or at a commit level. The real failure of GIT in my opinion is that people think that they need branches when commits suffice and thereby making things very complicated with zero benefits. #onlywinersdownvote Edit: Garbage people downvoting as expected. Are you selling garbage to control the garbage or what is wrong with you?
- mnouquet 5y ago
  Don't worry, any contrarian/conservative view is being downvoted in general. The general mantra is that criticize and deconstruction of establish standard, put under the umbrella of "progressivism", is paramount. That why the HN crowd loves every new fads so much.
- dang 5y ago
  Please don't break the site guidelines by going on about downvoting like that. It just invites more downvotes—this time, correct ones, however unfair they were in the first place. It's true that bad downvotes occur, but it's also true that fair-minded users give corrective upvotes to reverse them: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sort=byDate&type=comment&query=corrective%20upvote https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor.... This would have been a perfect case for that, if you hadn't spoiled the post by venting about downvotes. It's true that they can be annoying sometimes, but that's not a good reason to make the thread worse.
  - AtNightWeCode 5y ago
    Most western communities does not rely on dark patterns. Reddit is probably the only site besides HN that have dark patterns when it comes to voting. Downvotes does not promote what you think it does. Go look at the stats if you have them. Edit: I would also downvote your garbage input if it possible.
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 ago
  Every 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

by derriz 5y ago

zeroimpl 5y ago

But commits change branches. None of the commits started on the "master" branch, they started on some developer's branch (which might also be called "master" in a different repo, but is still separate).

derriz 5y ago
I'm not sure I understand your point? Say for example, I'm looking at a freshly cloned repo. There's a first commit and most-recent commit on master - I can identify them with git-log. The problem is that I cannot view the path of commits between these two if I'm only interested in the commits made when the current branch was master (which is generally the case unless I want to drill into a feature branch). Disallowing merges makes the problem go away but that removes a lot of options in terms of work-flow.
- jhardy54 5y ago
  Would `git log --merges` solve this? Assuming you use a merge-based workflow this would show only merge commits without any of the details of each individual commit from the merged branch.
- zeroimpl 5y ago
  I don't follow - If you are on a freshly cloned repo, none of the commits were made when the current branch was master, they were made on another user's git repo before your repo existed.
- jlokier 5y ago
  > I'm only interested in the commits made when the current branch was master When I'm working none of the commits are made when the current branch was master. They are made on branches, where commits are finalised, tested and signed, and then master is fast-forwarded to match the branch tip commit (or something intermediate if I'm satisfied with that). Conflicts are detected by the fast-forward and reconciled locally in the branch, re-tested and signed off again. It's rare that the current branch is master, and no commits are created while on master. So what would you like to see?

AtNightWeCode 5y ago

On the contrary, once people realize that a commit hash is something that spans across all branches the real beauty of GIT emerges. You can than and there make decisions on a branch level or at a commit level. The real failure of GIT in my opinion is that people think that they need branches when commits suffice and thereby making things very complicated with zero benefits. #onlywinersdownvote Edit: Garbage people downvoting as expected. Are you selling garbage to control the garbage or what is wrong with you?

mnouquet 5y ago
Don't worry, any contrarian/conservative view is being downvoted in general. The general mantra is that criticize and deconstruction of establish standard, put under the umbrella of "progressivism", is paramount. That why the HN crowd loves every new fads so much.
dang 5y ago
Please don't break the site guidelines by going on about downvoting like that. It just invites more downvotes—this time, correct ones, however unfair they were in the first place. It's true that bad downvotes occur, but it's also true that fair-minded users give corrective upvotes to reverse them: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sort=byDate&type=comment&query=corrective%20upvote https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor.... This would have been a perfect case for that, if you hadn't spoiled the post by venting about downvotes. It's true that they can be annoying sometimes, but that's not a good reason to make the thread worse.
- AtNightWeCode 5y ago
  Most western communities does not rely on dark patterns. Reddit is probably the only site besides HN that have dark patterns when it comes to voting. Downvotes does not promote what you think it does. Go look at the stats if you have them. Edit: I would also downvote your garbage input if it possible.

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 ago
Every 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