-
Notifications
You must be signed in to change notification settings - Fork 143
builtin/blame.c: bit field constants into bit shift format #382
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Welcome to GitGitGadgetHi @harry-hov, and welcome to GitGitGadget, the GitHub App to send patch series to the Git mailing list from GitHub Pull Requests. Please make sure that this Pull Request has a good description, as it will be used as cover letter. Also, it is a good idea to review the commit messages one last time, as the Git project expects them in a quite specific form:
It is in general a good idea to await the automated test ("Checks") in this Pull Request before contributing the patches, e.g. to avoid trivial issues such as unportable code. Contributing the patchesBefore you can contribute the patches, your GitHub username needs to be added to the list of permitted users. Any already-permitted user can do that, by adding a PR comment of the form Once on the list of permitted usernames, you can contribute the patches to the Git mailing list by adding a PR comment After you submit, GitGitGadget will respond with another comment that contains the link to the cover letter mail in the Git mailing list archive. Please make sure to monitor the discussion in that thread and to address comments and suggestions. If you do not want to subscribe to the Git mailing list just to be able to respond to a mail, you can download the mbox ("raw") file corresponding to the mail you want to reply to from the Git mailing list. If you use GMail, you can upload that raw mbox file via: curl -g --user "<EMailAddress>:<Password>" --url "imaps://imap.gmail.com/INBOX" -T /path/to/raw.txt |
/allow |
User harry-hov is now allowed to use GitGitGadget. |
You could put this into the commit message, as "This addresses #357". That would make it easier for reviewers on the Git mailing list (who do not necessarily frequent GitHub let alone this here fork), and it would also close the ticket automatically once the Git maintainer merges the patch into |
This made me chuckle :-) I know you meant "Turning", not https://en.wikipedia.org/wiki/Alan_Turing. The commit message could possibly repeat a little bit from the ticket that inspired you. If you look around in Git's commit history, we really like detailed commit messages. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it would be fine for contributing as-is, but of course you could always improve the commit message (not only the typo, but also a more detailed explanation, e.g. explaining how this helps type safety, concretely) and you could use the 1<<0
style for the constants and align them.
Also keep in mind that the PR description will be sent as cover letter.
Thanks, @dscho for the suggestions and comments. |
Oh. I see that you made How about rebasing your commit to |
52f7a4a
to
988033e
Compare
Hey @dscho! |
@dscho resolved those comments |
builtin/blame.c
Outdated
#define OUTPUT_LINE_PORCELAIN 01000 | ||
#define OUTPUT_COLOR_LINE 02000 | ||
#define OUTPUT_SHOW_AGE_WITH_COLOR 04000 | ||
#define OUTPUT_ANNOTATE_COMPAT (1<<0) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, I should have been clearer: I meant to align the values (i.e. 1<<0
, 1<<1
, etc), with spaces, and not the keys. There should not be more than one single space between the #define
and the OUTPUT_ANNOTATE_COMPAT
and friends.
1e4e65d
to
5dc8543
Compare
Hey @dscho PS:- Sorry for bothering you again and again. |
Sure. The patch is in a good shape, now let's focus on the commit message:
These seem to be slightly incomplete sentences with little power to explain the motivation behind the patch. Maybe a better way would be to say that we are looking at bitfield constants, and elsewhere in the Git source code, such cases are handled via bit shift operators rather than octal numbers, which also makes it easier to spot holes in the range (if, say, |
Thanks @dscho |
Looks good! |
BTW if you are as puzzled as I was why the "shipit" emoji is a squirrel: https://www.quora.com/On-GitHub-what-is-the-significance-of-the-Ship-It-squirrel |
No doubt why you are popular amongst Git Contributors 😄 |
Hi, Thanks for your comments. I've modified the patch. Regards |
/submit |
Submitted as pull.382.v2.git.1571334411.gitgitgadget@gmail.com |
Hi @dscho |
I tried to describe it a little bit in https://github.com/gitgitgadget/gitgitgadget/wiki/ReplyToThis (you will see this in every mirrored response linked as "(reply to this)"). There are also instructions for command-line nerds at the bottom of every public-inbox page, see e.g. https://public-inbox.org/git/xmqqr23b7ref.fsf@gitster-ct.c.googlers.com |
This branch is now known as |
This patch series was integrated into pu via git@0926ab8. |
This patch series was integrated into pu via git@2a11dc1. |
This patch series was integrated into pu via git@ce72ff0. |
This patch series was integrated into pu via git@76c5e9d. |
This patch series was integrated into pu via git@136476c. |
This patch series was integrated into next via git@bc84aae. |
This patch series was integrated into pu via git@70a25b5. |
This patch series was integrated into pu via git@aba629c. |
This patch series was integrated into pu via git@ed8ceb6. |
This patch series was integrated into pu via git@bc27da4. |
This patch series was integrated into pu via git@4feb4a6. |
This patch series was integrated into pu via git@04454b5. |
This patch series was integrated into pu via git@c93af32. |
This patch series was integrated into pu via git@d6a9d32. |
This patch series was integrated into pu via git@d40095a. |
This patch series was integrated into pu via git@8f40d89. |
This patch series was integrated into master via git@8f40d89. |
Closed via 8f40d89. |
we are looking at bitfield constants, and elsewhere in the Git source code, such cases are handled via bit shift operators rather than octal numbers, which also makes it easier to spot holes in the range (if, say, 1<<5 was missing, it is easier to spot it between 1<<4 and 1<<6 than it is to spot a missing 040 between a 020 and a 0100).
Also, bit shifts lead to low-level optimizations because they require fewer calculations for the CPU.
Special Thanks to @dscho for helping me out throughout the process.