Whenever I push changes to gerrit that contain multiple files (I believe the threshold is over 10) gerrit doesn't display the modified files for review, it only displays the "commit message".
If the changes are approved, the code is properly merged, but in order to be reviewed the commit needs to be broken down so the files can be seen.
Is there a setting on Gerrit to limit the maximum number of files to display?
I noticed these warnings when pushing to gerrit, which I wonder if is enough for it lose track of the files:
remote: (W) ad2789b: commit subject >65 characters; use shorter first paragraph
remote: (W) ad2789b: too many commit message lines longer than 70 characters; manually wrap lines
This is what I see on gerrit:
Any help is greatly appreciated
This is not related with the number of changed files. This is happening because you're selecting "Auto Merge" at "Diff against" option. It seems that it's a merge commit done automatically so there're no differences between the "auto merge" and it. This is the default behaviour when you perform a merge without resolving conflicts.
Do some tests changing the "Diff against" option to "Parent 1" or "Parent 2" and see what happens.
Related
I merged 2 branches and there are no conflicts. I saw that there are no conflicts and immediately unchecked the auto resolution of conflicts.
I merged the branches again and still there are no conflicts.
After I opened the pending changes, I saw this. I think there should generally be a button or link for conflicts. But there is no such thing.
I have a lot of conflicting code. It is just keeping my version whenever I think there should be a conflict.
Can somebody tell me in their experience why conflicts are not shown to resolve even when there is conflicting code. Can I use another source control like GIT to perform the merge ? Is it possible?
All of your changes have already been merged in your local workspace. As you can see in the pending changes list all changes there are marked with [merge, ...].
If you want to perform the merge again, without any automatic merging you will have to first undo the pending changes. Then ensure that auto-merge is turned off, then perform the merge action again.
Given that the automatic merge succeeded, I'd expect that you still won't find any conflicts. It looks like TFVC is able to figure out all of your merges on its own based on the fact that the auto merge succeeded.
There is another possibility... If in the past you have merged with this branch and have chosen "Keep mine" then TFVC registers this choice and will keep this in mind in future merges. This can cause unexpected behaviour later if you weren't aware this was happening. The only way to undo these so-called "merge tickets" is to perform a Rollback on those previous merges. Without undoing these merge tickets you have one more option to force a merge on contents only, you'll need to perform the merge from the commandline and supply the force switch:
tf vc merge /recursive /force /noautoresolve $/Project/BranchA $/Project/BranchB
I'm new to github and have been working on a group project for school. Recently it turned out we were missing some stuff and nothing was organized (every file was just uploaded into the main directory) so I removed everything using a command in the github shell. Then I proceeded to make files and organize all the code and re-upload and store everything in there.
However, when I did this, I had to keep committing every time I made a new folder and stored a bunch of files in it. I would like to keep the changes made during those commits (because I created folders and re-uploaded the stuff), but I want to remove those commits from the history because they are cluttering up the project.
Is this possible, and if so can you please walk me through the steps. Also I'm new to github so I don't know much.
Here is a picture of the ones I want to remove from my history because they are cluttering up the screen (see red marks):
Thanks :)
EDIT: PLEASE NOTE: I don't want to revert the changes, I just want all those history to be removed because they are cluttering up the commit history.
You should use:
git rebase -i HEAD~14
To rebase and squash your unwanted commits. Just use p to mark the last commit and use f to mark the unwanted commits for squashing it with the previous commits. This will remove it from commit log keeping the changes.
More info: https://git-scm.com/book/gr/v2/%CE%94%CE%B9%CE%B1%CE%BA%CE%BB%CE%B1%CE%B4%CF%8E%CF%83%CE%B5%CE%B9%CF%82-%CF%83%CF%84%CE%BF-Git-Rebasing
When reviewing code in eclipse using EGit plugin, before merging it to the develop branch, you switch to the branch and see what files changed with the commits on that branch. For this I would like to see -only- the commits to the current checked out branch. When using Team -> Show in History, I get the complete history across all branches.
How can I view only the commits to the current checked out branch, instead of having to search trough the complete GIT history to find the relevant commits?
Using review tools like Gerrit are not an option.
You can check the filter button in the History View:
All Branches
This toggle activates the "All Branches" mode.
By default, only those commits are shown in the commit log that can be reached from the currently checked out commit, i.e. the Commit Graph ends with the currently checked out commit and newer commits are not shown.
If this button is down, all commits will be shown in the commit log.
This is illustrated in the following picture from our example. The branch "beforeSplit" is currently checked out; by activating the toggle, the newer branches will become visible:
And you need to combine that with:
"Additional Refs" toggles the visibility of certain Refs created during actions like fetch, rebase, merge, for example FETCH_HEAD, ORIGIN_HEAD... This can be helpful to remove clutter from the history view.
You might need to un-check the "Additional Ref" option. please see the attached image.
We need to change to a new VCS system. I can't seem to find one that tracks change comments both per file and per change-set. Currently when we view file history in our present VCS it shows the various check-ins and the comments for the file on that check in and the over-all check-in comment. We are currently evaluating hg and like it, but can't find how to implement this behavior. Can anyone suggest how to do it in hg - or what VCS would allow this feature? Thanks so much.
You can run
$ hg log your-file
with Mercurial to get the history of just that file. It also works for directories or multiple files where you get a log of changesets changing either of the specified files.
Mercurial is actually very efficient for this: despite having repository-wide changesets, it stores the deltas on a per-file basis and this makes it very easy for Mercurial to show you the per-file history.
Hg's commit works on either the changed files you specify or all the files that it finds have changed. That group of files then makes up the changeset and the same commit message will then be applied all. It sounds like you are looking for a super commit to wrap several commits into one bigger commit.
Named branches are the intended method for something like this. You can then have commits with comments that are specific to certain files and the overall branch name is the feature you are grouping together. Through the command line or Tortoise Hg you can select what files are part of each commit.
I am looking forward to merge my code which I developed in a branch of SVN to the trunk. I am using Eclipse and I have been using Team->Commit to commit my updates to the SVN. But I haven't done a merge before. Please help me with this.
First of all make sure you are up to date. Update your working copy of the target branch, ie. where you are merging into. In this example we're working on the trunk of "core" and we want to grab the changes that have happened in the maintenance branch and merge them.
Resolve any conflicts. There should be no conflicts at this stage between the working copy and the repository.
Select the SVN merge option on the working copy. In Eclipse this is going to be found under the "Team" menu and called "Merge Branch".
SVN: Merging in Eclipse
Change the From URL to the specific branch you want to be merged into your working copy. In this example we're looking for the p400 maintenance branch (./core/branches/p400).
Change the From Revision to the last revision that was merged into the target branch. Essentially you don't want to keep merging the whole branch history, you just want to include those changes since the last time you merged. There is no easy way to determine the last merge point at this time in Subversion. You have to review your message log and look for the last commit that talks about merging. If you are disciplined about the commit messages you use for merging this should be easy (see below). Make a note of what that revision is -- you'll need this later when you commit your changes.
SVN: Merge with Eclipse
Change the To Revision to the latest (i.e. head). Make a note of what that revision is -- you'll need this later when you commit your changes.
Click Merge and wait. Depending on how big the differences are this may be quick or Eclipse my just fall over. If you have such an enormous change that you can't get it done in Eclipse you may need to make the range of revisions you are merging smaller. Or you may even have to skip certain revisions and do them manually if they are massive. We've had this problem from time to time when updating large third-party libraries. The vast majority of the time you will be fine.
Review changes and resolve conflicts. Once the merge is complete, look through the changes made to your working copy and make sure you address any conflicts you find.
Once all the changes have been resolved in the target working copy, check them in with a single commit. The reason you're not doing lots of commits is that these are changes that should have been documented in the branch from which you merged. The commit message needs to be in a specific format that details the merge and is easy to find in the future. We use the following format, but you can use anything that works for you -- as long as you stick to it.
Merging [source] to [target]; [repository]. Merge rev [start]:[end]
Enjoy!
In eclipse we have an option to merge. Right click the project , you will see "Team" option and on clicking it you will see merge option. There are three different options you can see in the merge.
To successfully merge the changes from the branch to the trunk, we need to switch the local workspace to the trunk (but make sure all the changes are committed to the branch before that). Once we do that we can use merge option and select "2 URLs" option. I put url for trunk as url 1 and the branch I wanted to merge as url 2. I could see all the incoming changes I selected "OK". All the changes are in my local now (at this point my workspace is linked to the trunk). Then I committed my changes to the trunk and hence merge from branch to the trunk was successful.
I would like to add for Point 8 .Review changes and resolve conflicts. ---
When working on conflicts manually- when you do copy from right to left on chunks of code - Be careful
Sometimes chunk of code gets added, sometimes it properly replaces the chunk.
Make sure there is no duplicate chunk of code.
Also, this is helpful-- What is the proper way to do a Subversion merge in Eclipse?