Say, I committed some code, created a pull request, then someone requested changes.
If I go to diff, I can see those comments. However if I make changes and commit, those comments won't show up. Is there a way to keep them there? Sort of like Atlassian's Crucible does.
Cause it would be a lot easier to see what was actually changed here and for what reason
Related
tl;dr I created a PR in someone's stead. Now I can't submit a review. Is there a way around?
The other developer messed up and merged a feature to the target branch, so I reverted their changes, fixed the issues, squashed and rebased their work while still keeping their authorship on the commit and I created a new pull request. Now, when I want to submit a review, it prevents me to Request changes, because now I am the author of the PR. How can I change it so that the other developer is responsible and receives the review?
You cannot change the author of a pull request or create one in somebody else's name. GitHub doesn't allow this because it would permit people to forge pull requests and let another person receive negative feedback. For example, if I opened a PR in your name containing something wildly inappropriate (say, a racist slur), you'd be blamed for it unfairly. Moreover, in some regulated environments, keeping an accurate record of who contributed code is very important for legal reasons, which is another reason why this isn't permitted.
In most cases, if a commit gets reverted, then just have the original author open a new PR. Clearly they'd wanted to submit the code in the first place. You can even create the branch for them with their commit squashed and prepared, as long as they open the PR. This is a case where a helpful conversation with another contributor goes a long way, and presumably you'd want to let them know in a kind way that they made a mistake and that you reverted it anyway. Since there's no way to create a repository on behalf of another user, you should close your PR and ask them original submitter to open it instead.
I think it's obvious why you can't approve your own PRs. I can see that this is a situation where requesting changes might be useful, but I suppose the rationale is that you wouldn't have opened the PR if you thought it needed improvements, and if you later learned that, you certainly would revise it instead of merging it.
Although bk2204's answer is correct and explains why there isn't a one-button solution, it doesn't address the actual question of:
How can I change it so that the other developer is responsible and receives the review?
The only way to that is to close out the PR you opened and have them open it instead.
On a Github project, I see a guy made a pull request in Pull Requests section, but I find he made many mistakes so his code need to be corrected. Instead of asking him to change his code, is it possible to do it by myself (that is, I want to correct his code by myself)? and how?
I'm also a member of that project, and I'm new :)
Enabling repository maintainer permissions on existing pull requests
Pull request creators can give these permissions on each of their pull requests when they initially create a pull request from a fork or after they have created the pull request.
On GitHub, navigate to the main page of the upstream repository of your pull request.
In the list of pull requests, navigate to the pull request that you'd like to allow commits on.
In the right sidebar of your pull request, select Allow edits from maintainers. You can change these permissions at any time by unselecting this option.
More details on github help page: Allowing changes to a pull request branch created from a fork
TL;DR
Author of PR can modify an existing pull request to let repository maintainers make commits to your branch.
In order to allow you to make commits to others PR - the author has to set checkbox from the left:
Assuming the original author is responsive enough, it’s always better to ask them to fix it (unless the change is an obvious typo fix, maybe). They might have a reason for writing it the way they did.
If the author isn’t responsive and you’re deciding whether to fix it in place or with a new commit, ask yourself which way the history reads more clearly. If the commit would introduce a regression, you should probably fix it in place (to avoid breaking bisectability). If it handles some cases and you just want to add more cases without significantly changing the existing code, it might be better to add a new commit.
If you do amend the existing commit in any way, make sure to leave a note in the commit message explaining what you changed. One typical style is to leave a note in square brackets, grouped with any Signed-off-by: lines (if applicable):
[your.email#example.com: Refactor new cases into a function for clarity]
For example: linux.git commit b44129b3.
via https://www.quora.com/GitHub-Is-it-bad-etiquette-to-change-someones-pull-request-before-committing
We are working on a single project, and also committing code at the end of day on SVN so that can get all update project. But issues is very often our code getting errors while committing code and projects get empty if someone get update at that time. So my question is are there any set of rules which we've to follow on committing so that every one go on straight path and no one get in trouble and save a lot time from these errors.
Thanks in advance. Cheers
Search Google, something similar to "source control best practices".
Top result has several tips. Sounds like the biggest problem you're facing is integrating with others' changes. Perhaps look into the following sections:
Incorporate others' changes frequently
Share your changes frequently
Coordinate with your co-workers
Investigate why you get errors. Blind application of rules is not good.
For example:
person A committed a code producing compilation error
why?
he finished his task, but hasn't checked build before committing to the trunk
why?
the entire build it too slow
solution: speed-up build, set up continuous build system which will check every commit and notify developers about problems as soon as possible
Another example:
person B committed a code which breaks the build
why?
he wanted to store his changes, but the task is not finished
solution: advice him to create a branch, when the task is finished it can be merged to the trunk (if branch lives for long time, merge changes from trunk to it periodically, then the merge will not be a problem)
There possible other scenarios. With more details you will be able to ask more precise question on StackOverflow and get better answers.
In case of use of SVN co-ordination is must between the team.
Make sure whenever you commit the code you have a idea about what are you committing.
The golden rule is "One developer One class".
If at all two different developers are working on same class. Ask them to maintain a document on what changes they have made. And, most important to mark a comments in a class it self.
There are some important things which need to be followed while committing the code. Whenever you see a conflict in your local files and server files. Make sure you go through every conflict and select the appropriate action.
Understand one important thing, whenever SVN is used one persons mistake can affect everyone.
Whenever possible, don't edit the same line of code as someone else
Leave meaningful comments on your commit messages
Comment your code
Make sure that all the code you commit compiles and runs as it should
Commit when appropriate ie: are passing off part of your code to be used by others or are done working on a feature
Make sure to communicate with other team members
If you find code that you don't know what it does, ask the author
If you're making major changes that will take a while to implement, use a branch and then merge it back in
I spent all morning in GitHub reviewing a pull request, writing detailed comments on many lines in the Diff view on the pull-request page.
I individually saved every line-by-line comment, and they all appeared in their correct places. I left the pull-request page, and when I returned to it, all my line-by-line comments were gone!
I have no idea why they disappeared, where they went, whether other users can see them and I can't, what any of this means, and whether I can trust myself going forward using GitHub, or whether I just have to go back to the telephone and fax for remote collaboration!
I did some web searches such as "how to view line comments in GitHub" for info about this, but could not find anything to relieve my panic. I will be grateful for advice and clues.
This is top result for "Can't view github comments" in google.
If you're here because you've left comments, and can see your own comments, but others cannnot, then check for a yellow pending label on your comments. Others cannot see your comment until you've completed the review process and selected whether you want to request changes. Once you click through a full review, then others will see your comments.
Note: I'm answering a slightly different question than the O.P., but I have a feeling that lots of other devs with this issue are hitting this stackoverflow question. I'm just hoping to help them. I myself had this issue and couldn't find a more relevant answer than this thread. :)
The line-comments depend on the commit that were made on.
If the person that made the pull request rebased that commit then you're not looking at what you were previously looking. It's a different commit, thus there are no comments.
Look on the 'Your Actions' tab and find a line in the actions' history were you commented on that commit, click that commit and you'll see the comments are still there.
If the commit was rebased, you wont find that commit were it used to be (some branch) and not on any repo probably (if it's not on another branch). It is just cached by git and github, until the garbage collector kicks in.
The old answer doesn't work for me because I don't see Your Actions or Public Actions now.
My pending comments disappeared after I started typing into what I thought was a comment I'd opened for editing. It wasn't open, and one of my keys may have been a shortcut. I could still see the button to finish my review (including the count of my pending comments) but the comments had disappeared.
I eventually got them back by navigating to the pull request, then to the commit I was reviewing.
I struggled asking that question but here it is.
I am using source control since several years for multiple projects using different systems (svn, hg, git) and I learned how to improve my messages by following guidelines etc.
But as far as I can remember I never ever had a look at them afterwards.
So ... how do you profit from your own commit messages? When I need to go back because I smashed something and need a fresh start, I usually just go back to the latest "node" (where I started or merged a branch). Do I write those messages just for people monitoring the project who are curious what is going on?
Regards
You write them as an aid to your future self, and others on the team. To give you some background of when I have found them useful:
I used to work on a project where commit messages were invaluable - on more than one occasion I used them to track down code that was years old. On that project our bug tracking system was also integrated with our VCS (ClearCase). So when you checked in a change, it would record the bug number in the commit comments. This was very helpful to allow you to trace back exactly what was changed and why.
So to sum it up, although commit messages may seem pointless if you are just starting out (especially if you are the only one working on the project), they become invaluable once you have a successful product that is supported in production by multiple developers.
Update
Another useful feature of commit messages is that they require you to review and summarize the changes you just made. Even if I remember what I have changed, I will often do a quick diff of a file before checking it in. I will briefly read it all over again to make sure there are no typo's, that I changed everything I meant to, etc. This is a simple way to review your code for those small little bugs that would otherwise find their way into your code. Anyway, after doing this I have a clear picture of what changed, so I use this to write a concise summary of the change when checking in the file. This is a simple habit that helps increase code quality with little effort on your part.
"Send me a list of the things you did in the past two weeks" - Boss
Your messages are more for other users than yourself. Although I make sure to place good commit messages even on personal repos as well. Helps when you get sidetracked on a project and visit it months down the line to get a handle of the recent work done on a project.
One thing I've found is that the commit messages are a good way to keep myself from not committing often enough. If I can't put the changes into a short commit message I probably should have committed the changes earlier.
In the best case, a commit is bound to a work item in a feature/bug tracker. That way you will be able to easily see which feature/bug has been implemented/fixed. This is not only useful to know if a certain revision contains a feature or bug fix but also to easily create a release note.
What would be the point of a commit without a note to tell you what it is? It's like asking 'Why do books have titles on the sides?', or perhaps 'Why do books have indexes and page numbers?'. It seems to me that a source control log that didn't have a description for each change wouldn't be very useful.
Reasons you may need to refer to the commit message include
A bug has surfaced and you want to find when that part of the code was changed last
You decide to undo some changes and need to decide which revision to revert to
For either of these possibilities, without good commit messages, you would be left looking through the diffs for every single commit until you found what you were looking for in the code.