6 ms·

Here's an example of a blame on a previous commit of a file. https://gitlab.com/gitlab-org/gitlab-ce/blame/57ce7c655cc58ee793cf6514fae590fa53850884/.gitlab-ci.

Here's an example of a blame on a previous commit of a file. https://gitlab.com/gitlab-org/gitlab-ce/blame/57ce7c655cc58ee793cf6514fae590fa53850884/.gitlab-ci.yml https://gitlab.com/gitlab-org/gitlab-ce/blame/57ce7c655cc58e... Did you have some particular feature request beyond this view?

chinhodado 9y ago
The use case is to be able to repeatedly blame on the previous revision of the change that was made to a line. This is especially useful when you're dealing with diffs resulted from code formatting, whitespace changes, etc. in a file and you want to see what is the "original" commit that the change was made. This has been available on GitHub for a while now (see https://help.github.com/articles/tracing-changes-in-a-file/ https://help.github.com/articles/tracing-changes-in-a-file/)
- victorwu 9y ago
  Thank you for the explanation. I've created an issue. Feel free to continue the discussion there. https://gitlab.com/gitlab-org/gitlab-ce/issues/44553 https://gitlab.com/gitlab-org/gitlab-ce/issues/44553
  - tmuir 9y ago
    Does this mean that gitlab doesn't generally employ people to simply learn their competitors products, to keep informed of their offerings?
    - yashap 9y ago
      This is a highly unfair criticism, you’re never going to have total feature parity with your competitors, nor is that even a good thing to strive for.
      - deleted 9y ago
        [deleted]
      - tmuir 9y ago
        Mine is a perfectly valid criticism. You do nobody any favors by conflating the goal of total feature parity with the general concept of business intelligence, and understanding your direct competitor's key features. The strawman you float is the complete opposite of what I asked. It simply occurred to me as strange that there are features that meet all of the following requirements: 1. Available on github for quite sometime 2. Long enough in fact to get a dedicated article in their knowledgebase 3. A popular enough feature to possibly gate the entire calculus for users to switch services. 4. Obviously useful feature, as evidenced by the gitlab triage engineer being convinced to add an issue with a single paragraph plea. 5. Gitlab is seemingly unaware of this publicly available information, to the trivially rectified detriment of their own bottom line.
        parent5446 9y ago
        You seem pretty worked up about this one feature. > 3. A popular enough feature to possibly gate the entire calculus for users to switch services. I'd say GitLab's CI/CD system is a lot more useful of a feature. At the very least you can use the actual git blame or another git UI as a workaround. Good luck setting up a replacement CI/CD system. > 4. Obviously useful feature, as evidenced by the gitlab triage engineer being convinced to add an issue with a single paragraph plea. That's not how triage works. Just because a bug is filed doesn't mean it's "obviously useful". If the employee had immediately given it a high importance, a release date, and assigned it to somebody, that'd be a different story. > 5. Gitlab is seemingly unaware of this publicly available information, to the trivially rectified detriment of their own bottom line. Well, since there is another bug already filed for this feature more than six months ago, [0] I'd say they are quite aware, they just don't consider it as important as you do. The particular person that replied to you just didn't know about it (not surprising when they have more than 10k bugs open). [0] https://gitlab.com/gitlab-org/gitlab-ce/issues/37135 https://gitlab.com/gitlab-org/gitlab-ce/issues/37135
        9y ago

chinhodado 9y ago

The use case is to be able to repeatedly blame on the previous revision of the change that was made to a line. This is especially useful when you're dealing with diffs resulted from code formatting, whitespace changes, etc. in a file and you want to see what is the "original" commit that the change was made. This has been available on GitHub for a while now (see https://help.github.com/articles/tracing-changes-in-a-file/ https://help.github.com/articles/tracing-changes-in-a-file/)

victorwu 9y ago
Thank you for the explanation. I've created an issue. Feel free to continue the discussion there. https://gitlab.com/gitlab-org/gitlab-ce/issues/44553 https://gitlab.com/gitlab-org/gitlab-ce/issues/44553
- tmuir 9y ago
  Does this mean that gitlab doesn't generally employ people to simply learn their competitors products, to keep informed of their offerings?
  - yashap 9y ago
    This is a highly unfair criticism, you’re never going to have total feature parity with your competitors, nor is that even a good thing to strive for.
    - deleted 9y ago
      [deleted]
    - tmuir 9y ago
      Mine is a perfectly valid criticism. You do nobody any favors by conflating the goal of total feature parity with the general concept of business intelligence, and understanding your direct competitor's key features. The strawman you float is the complete opposite of what I asked. It simply occurred to me as strange that there are features that meet all of the following requirements: 1. Available on github for quite sometime 2. Long enough in fact to get a dedicated article in their knowledgebase 3. A popular enough feature to possibly gate the entire calculus for users to switch services. 4. Obviously useful feature, as evidenced by the gitlab triage engineer being convinced to add an issue with a single paragraph plea. 5. Gitlab is seemingly unaware of this publicly available information, to the trivially rectified detriment of their own bottom line.
      - parent5446 9y ago
        You seem pretty worked up about this one feature. > 3. A popular enough feature to possibly gate the entire calculus for users to switch services. I'd say GitLab's CI/CD system is a lot more useful of a feature. At the very least you can use the actual git blame or another git UI as a workaround. Good luck setting up a replacement CI/CD system. > 4. Obviously useful feature, as evidenced by the gitlab triage engineer being convinced to add an issue with a single paragraph plea. That's not how triage works. Just because a bug is filed doesn't mean it's "obviously useful". If the employee had immediately given it a high importance, a release date, and assigned it to somebody, that'd be a different story. > 5. Gitlab is seemingly unaware of this publicly available information, to the trivially rectified detriment of their own bottom line. Well, since there is another bug already filed for this feature more than six months ago, [0] I'd say they are quite aware, they just don't consider it as important as you do. The particular person that replied to you just didn't know about it (not surprising when they have more than 10k bugs open). [0] https://gitlab.com/gitlab-org/gitlab-ce/issues/37135 https://gitlab.com/gitlab-org/gitlab-ce/issues/37135
        9y ago