I made sweeping changes to 2 projects (call it Project A and B) in my team's repository in this PR *. After getting through testing, review, and getting comments resolved, I found out that a different team is working on conflicting changes to project A on a different PR and those changes need to go to staging first. Now I can't merge my PR because it has changes to A, but my changes to Project B need to be merged ASAP. Now the obvious answer is probably to abandon the PR, do a soft reset and start again with two branches, but my team wants to keep the comment threads on both A and B because they showcase a month of work and important design decisions made by multiple teams during the reviewing process. Is there a way to split my changes to Projects A and B into two separate PR's without losing all the comments?
My current solution is branch a new branch off the current one, manually undo my changes to Project A from the branch, push, and leave the comments to A dangling (I think there will be some comment view that the file reference is deleted), merge. Then create a new PR of the newest branch, copy and paste each of the 50+ dangling comments over to their respective files, resolve all, and merge. This is obviously not great because I lose some context and it will take hours. Other solutions I've seen on here will delete all existing comments altogether and I can't have that.
*Yes, I definitely shouldn't have done that.
There is no out of the box solution for this.
I would suggest to use Azure DevOps APIs, and even that isn’t a walk in the park.
Modus operandi
Choose your language, PowerShell, js, c#, etc and start exploring. Below a suggestion where to start:
Start with getting the original PR using the getbyid api
Since you mention the comments are the most import part, the next thing is to retrieving list with thread comments API.
Optional: Per comment iterate through the thread with the next get api, because the docs state: Represents a comment which is one of potentially many in a comment thread.
From this point, retrieve more info you need or start building the copy of the PR with, create PR and adding comments and other part you need to reuse.
Again, this is not easy and maybe retrieving and saving this in another format already helps you.
I did tried to find a solution for you online, but did find it (yet). Found other handy stuff like this quick and dirty js script to search through comments.
Related
I'm working on a project that has a large number of json files that are never reviewed in pull requests but occasionally need to be changed. Recently we had to make minor changes to them, and github isn't allowing me to create a pull request with those changes. Instead it gives me:
This comparison is taking too long to generate.
Unfortunately it looks like we can’t render this comparison for you right now. It might be too big, or there might be something weird with your repository.
I checked the diff locally and the actual code changes are pretty minor (maybe 200 lines changed), but there are millions of changed lines in these json files. Is there any way to tell Github to ignore them? Right now I am unable to make a PR so the changes can't go through our normal company review process.
I've tried using the .gitattributes file with *.json linguist-generated=true unfortunately that had no effect.
Edit: As suggested in the accepted answer, I contacted github support about this case. Their suggestion was to create a new branch with a small commit, create the PR, and then merge the actual branch that I want to deploy into it. This will update the PR, and while the diff still won't display, it will let me create a PR.
I have just been able to solve this problem via the gh command line tool!
gh pr create
Maybe this option did not exist when the original question was posted, but I'll definitely be doing this in future.
When you compare two branches on GitHub, GitHub has to go compute the diff for those changes using Git and then render it for you. In your case, you have millions of lines of changes, and Git doesn't perform very well in this case because the algorithm that's used to compute diffs is O((N + M)D). Thus, if you have a number of differences proportional to the number of lines, the algorithm is essentially O(N²). Having a large N makes that even worse.
GitHub has a limit on long a request can take, so your large number of changes are just not going to render in the interface. It may be possible to choose the branches you want even though the diff won't render and still open the pull request. If not, you may need to resort to using the API, which won't generate the diff for rendering and therefore is likely to work a little better.
I would encourage you to let GitHub Support know about this, if you haven't been able to find a way to do it through the UI, since they can notify someone to make sure the interface is usable to create a PR even if the diff can't render. You probably aren't the first person to encounter this.
You may also want to store these files outside of Git on some sort of artifact server and pull them down to your repository based on hash, in which case you wouldn't have this pathological case.
I am studying how to use GitHub to collaborate with other people.
I have already set up Collaborators for one of my project and they have been able to download it.
But I don't know how to go for the next step. In other words, after they make their contribution; how are they supposed to upoad the result of their work, so that I can get it?
Yes indeed, by following the guides I have been able to make an update to a test project.
But everything is not quite clear yet.
I follow the process of creating-a-branch -> editing-something -> creating-a-pull-request -> merging-the-branch.
Then I delete the branch since it is no more needed. Apparently it works, but I can still see the deleted branch after, so it doesn't seem to be really deleted.
Starting July 2019, using GitHub Desktop, as part of its epic "branch pruning" and its 2.1.0 release, will prune those remote tracking branches for you.
Branches that have been merged and deleted on GitHub.com will now be pruned after two weeks.
See desktop/desktop issue 750:
We decided in taking a very conservative posture that we would only delete branches that aren't actively in use (hence the 14 days requirement) and don't have anything on them that's ahead of the default branch on GitHub. This combination, in addition to the branch being deleted on GitHub.com, seems relatively uncontroversial, but we're definitely going to listen to feedback we receive in the weeks and months after this ships to make sure it aligns with people's expectations and isn't overly aggressive.
Because we've taken an extremely conservative approach here, we don't intend to provide the ability to toggle it as a setting.
If you use a particularly branch frequently, this will never prune that branch, and it's restricted only to branches where there is no additional work that hasn't been merged into the default branch on GitHub.
In other words, we set this up intentionally such that users should never lose any work, which is our primary concern when deleting things. Hope that makes sense, and appreciate the feedback.
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
My team recently switched to all three technologies in the past several months and have worked hard to get it up and running. Next step is automating our changelogs. We have JIRA set up look for the tags (ex. TAG-123) in github commit messages. Jenkins monitors the GitHub commits on a 5 minute timer, pulls, builds, etc.
What I would like to see is a changelog generated automatically when a build is marked as "Promoted to Production." I would like to see it do something akin to the following:
Query Jenkins for the previous build marked as a production release and get the corresponding git commit SHA1.
Run a diff in between the current Git commit and the previous commit
Find all JIRA tickets that are referenced
Compile a list of JIRA titles
Have list export to a text file and placed in build drop (bonus if it can be accessed directly through Jenkins as well)
Whether this flow is followed as written or not is irrelevant--I'm after the end result and am not looking to re-invent the wheel.. Surely somebody done something like this before?
As far as reinvention goes, I was able to find https://wiki.jenkins-ci.org/display/JENKINS/Promoted+Builds+Plugin which allows somebody to piggy-back on the Promote to Production action and run a separate script. It would then be a matter of gathering functionality to accomplish the above. (I also noticed Jenkins can tag the current GitHub commit, which my team would likely do in addition.)
Anything closer to accomplishing this would be greatly appreciated.
Thank you!
Since nobody on our team had excess time to devote to this, we ended up throwing together a quick solution.
The Process
Install and setup the All Changes plugin for Jenkins.
When we release, we use "build promotion" system which puts stars next to the previous build, so we can easily see the build# looking at the history.
Copy and paste the relevant output from All Changes into something like notepad++ (human-diff'ing ftw!)
Run a regex find/replace. Search on the regex string, replace with an empty string. (below -- there's the big-bang option or its broken up for understandability.)
Manually organize and release in whatever form is the current agreed up standard.
Everything at once
(\s*\(commit:\s[a-z0-9]{40}.\s..detail)|([\r][\n]#.*\B[\r][\n][\r][\n])|(^[ \t]*)
Remove commit hash\s*\(commit:\s[a-z0-9]{40}.\s..detail
Remove time and surrounding line breaks[\r][\n]#.*\B[\r][\n][\r][\n]
Removing leading whitespace: ^[ \t]*
The Analysis
Pros:
Effective overall
Relatively quick to implement
Cons:
Not fully automated.
Need to revert to commit id if you release from multiple Jenkins jobs.
All Changes history only appears to go back as far as the Jenkins job (I could be mistaken about the specifics of this--I just remember minor grievances with something like this at one point.)
As a whole, the cons are somewhat "the nature of the beast." I'd love to read some other solutions. (For when we have that elusive thing called Time, of course!)
Alternative to dependancy on issue trackers could be to purely use the pull requests themselves. For us they had enough context to generate release notes and we used labels for categorisation. I created PullRequestReleaseNotes and you can try it. It supports GitHub, GitLab, BitBucket and TFS and it can generate release notes in markdown from merged pull requests and its labels and optionally post it to an Atlassian Confluence page and post it to a Slack channel as a post. It can be run as part of continuous integration. Here is a sample:
1.2.1 (MASTER) - XX XXX 2016
Enhancements
Category A
Awesome new feature #1854
Fixes
Category Z
Fixed problem with widget #1792
Category Y
Fixed problem with widget #1792
Fixed exception with view layout #1848
I have a set of work items that are completed and I am ready to move their changes to our production branch. Is it possible to find the changesets that are attached to them and selectively merge them with the target branch?
Not easily is the short answer.
Currently there is no real link between work items and code promotion. You can associate a changeset with a work item on check-in (or indeed at any time), but that is about as far as things go.
Basically you would have to do this by hand using the provided UI in Visual Studio (i.e. look up the work items, get the changeset ID's and then do (possibly several) merges by selecting the appropriate changeset ranges. If this is a regular way of working then you could write a program in .NET that used the Microsoft TFS API to talk to the work item tracking component to get the changesets required and then either did the merges programatically or kicked off the command line client (tf) to bring up appropriate UI for the merges.
Sorry it's not a more helpful answer. I know that the team at Microsoft have heard this scenario a few times now however I've not heard of any plans to have it better supported "out the box" in the current or the next release of TFS. That said, there are a lot of improvements to the branching ad merging stuff in TFS2010 so it is possible that something is/will be in there that might help you. It may be worth you logging some feedback on http://connect.microsoft.com/VisualStudio for this feature if it is important to you.
Good luck,
Martin.