1–7 of 7 posts
1) CICD
2) Merge requests
3) Collaboration ( tickets, discussions )
4) Code highlighting
5) Something else
I like that is keeps track of the diffs and changes for code review comment threads so you can see what changed inbetween multiple git push --forces to fix stuff.
That struck me the other day as not a native git feature but an actual novel thing github/gitlab do.
When you merge request and then need to make changes, at least they way i do it is git push --force to push to overwrite the branch state on remote (gitlab/github etc.) I like that is keeps track of the diffs and changes for code review comment threads so you can see what changed inbetween multiple git push --forces to fix stuff. That struck me the other day as not a native git feature but an actual novel thing githu…
When you merge request and then need to make changes, at least they way i do it is git push --force to push to overwrite the branch state on remote (gitlab/github etc.) I like that is keeps track of the diffs and changes for code review comment threads so you can see what changed inbetween multiple git push --forces to fix stuff. That struck me the other day as not a native git feature but an actual novel thing githu…
Usually once MR is merged , no need to change existing branch and people usually just create a new one to push more changes or I miss something ?
No, nothing is merged yet I'm talking about during code review when changes are requested by the reviewer, you force push to overwrite your previous commits, the brand history does not know this by design in git, but gitlab/github understands this workflow and keeps track of it so a pre vs post git push --force is diffable.
Earlier quoted context omitted.
Usually once MR is merged , no need to change existing branch and people usually just create a new one to push more changes or I miss something ?
> Usually once MR is merged No, nothing is merged yet I'm talking about during code review when changes are requested by the reviewer, you force push to overwrite your previous commits, the brand history does not know this by design in git, but gitlab/github understands this workflow and keeps track of it so a pre vs post git push --force is diffable.
However, if another hosting system is done, there some other ideas of some possible things to do:
- Mirroring tickets/discussions as well as the repository (in both directions)
- Support for X.509 client certificate chains for authentication
- Ability to view without JavaScripts and CSS (having JavaScripts and CSS for enhancement is OK, but do not require it and do not add a message to say it is required)
- Support any character sets, including ones not compatible with Unicode (this will not always be displayable in web pages, but will still be usable with some other stuff, such as API using a format other than JSON (e.g. DER))
- Read-only access to public files should not require TLS but should still allow TLS; write access, and access to private files, should require TLS
- A compatible API with GitHub (and possibly others) so that software that works with those API are usable