Short version
When I compare two forks on Github, it does not compare the latest states, but the current state of the base fork with the last common commit (or am I wrong?); so how can I compare the latest states/heads on Github?
Longer version
I am trying to compare two repositories on Github.
It does not seem to compare the latest states of both repository. Instead, it compares:
the base fork as it was when both repositories where identical (last common commit?)
with
the head fork as it is now.
You can see this in the Github's fork comparison example, it says there are no changes between those two repositories, but there are now very different.
How can I compare the latest states/heads on Github?
https://github.com/github/linguist/compare/master...gjtorikian:master
github:master is up to date with all commits from gjtorikian:master.
Try switching the base for your comparison.
It means that all commits from gjtorikian/liguist are part of github/linguist.
The reverse is not true:
https://github.com/gjtorikian/linguist/compare/master...github:master
That would give all (1866) commits from github/linguist which are not part of gjtorikian/linkguist.
This is triple-dot '...' diff between the common ancestor of two branches and the second branch (see "What are the differences between double-dot “..” and triple-dot “…” in Git diff commit ranges?"):
In the first case github/linguist:master...gjtorikian/linguist:master, the common ancestor and gjtorikian/linguist:master are the same! O commits.
In the second case gjtorikian/linguist:master...github/linguist:master, github/linguist:master has 1866 commits since the common ancestor (here, since gjtorikian/linguist:master).
As a side note, the compare of forks can be reached from the compare page.
Say your project is Zipios:
https://github.com/Zipios/Zipios
What you want to do is add the .../compare to that URL:
https://github.com/Zipios/Zipios/compare
On that page, you can select two branches but if you look closely, at the top there is a link that says: compare across forks.
Once you clicked on that link, it shows you two extra dropdowns with your main branch and the list of forks.
What I have yet to discover is how to go from the main page of a project to the Compare page. Maybe someone could shed light on that part?
From #somerandomdev49:
To go to the compare page, go to the "Pull Requests" tab and click the "Create Pull Request" button.
Related
As in not only the major changes maybe the installed dependencies and all before a release without checking one by one?
Since Git won't know which commits are important to you, you'll have to first define your own set of guidelines/format on how you write your commit messages, which you can then use later on to easily differentiate all the commits made for a particular development period.
For example:
If it's a bug fix, prepend the commit message with a "[bugfix]"
If it's a new feature, prepend the commit message with a "[feature]"
If it's a project setup change, prepend the commit message with a "[migration]"
Then, once all the branches have been merged to the main branch (let's say it's develop), checkout the develop branch and use git log --grep=<PATTERN> to identify a specific set of commits.
For example, if you only need the bug fix commits, do a:
git log --grep="bugfix"
which will show you all the commits with "bugfix" in the commit message.
If you only need the commits for a specific period, you can use the --since=<date> option:
git log --since="2017-06-01" --grep="bugfix"
If you want a formatted list (something that you can easily output to some sort of release notes, I assume), you can use the --format=<format> option:
git log --since="2017-06-01" --grep="bugfix" --format="(%ci) %h : %s"
The command above will give you something like this:
(2017-06-18 18:26:36 +0800) 63f330f : [bugfix] prevent crash when dialog is sent to background
(2017-07-01 10:03:40 +0800) cdcbd91 : [bugfix] remove extra row at the end of the list
You can check out the other format options from the complete git log docs.
Basically, it will all depend on your commit message format.
As a tip, you can look into using a commit.template to make it easier to format your commit messages.
commit.template
If you set this to the path of a file on your system,
Git will use that file as the default message when you commit. For
instance, suppose you create a template file at ~/.gitmessage.txt that
looks like this:
subject line
what happened
[ticket: X]
Here's the scenario:
User1, Branch1: adds "abc.def"; commits.
User2, Branch2: adds "abc.def" (same file name, but more details in the file); commits.
Now User1 wants to merge the updated version of the "abc.def" file. So (using TortoiseSVN 1.7.10), User1 starts in the Working Copy of Branch1, selects Merge... -> Reintegrate a Branch, then chooses Branch2 and selects Merge. Predictably, a "Tree Conflict" results, with this text:
The last merge operation tried to add the file 'abc.def' from Branch2, but the file was already added locally.
How do you want to resolve this conflict?
But the only choice is a single button labelled Keep the local file. There is no option to choose the remote file, which is the one that User1 really wants.
What am I doing wrong here, and how do I fix it? More specifically, how do I get User2's version of the file into Branch1?
(Of course, I'm sure User1 could manually delete the file prior to merging, but that obliterates any history that User1 may have wanted to preserve. Plus it's just a clunky workflow, particularly when there are numerous files in this predicament.)
Unfortunately, this scenario isn't even mentioned in the TortoiseSVN documentation on Tree Conflicts
UPDATE:
In addition to choosing "Reintegrate a Branch" I have also tried "Merge a Range of Revisions" and "Merge two different trees". For the latter case, I chose the remote branch (Branch2) as the "Start" and the local branch as the target (Branch1; choosing the Revision prior to the addition of the file.) I got the same result in all cases: Tree Conflict with no option to select the User2 version of the file.
UPDATE #2:
According to the documentation, there should be "a checkbox in the merge progress dialog called Merge non-interactive", which, if unchecked, supposedly opens the "Merge Conflict Callback Dialog" during the Merge. However, I cannot find any such checkbox in the merge process. Where is it?
I was able to merge from one branch to another in version 1.9 of TortoiseSVN with the following procedure.
Setup
With a test repository, I did the following steps:
Create a branch, "first"
Create a file "doc.txt" with contents "FIRST" in the new branch
Add and commit the file to the new branch
Create a branch, "second"
Create a file "doc.txt" with contents "SECOND" in that branch
Add and commit the file to the new branch
So my structure looks like:
branches/
first/
doc.txt => "FIRST"
second/
doc.txt => "SECOND"
Merging
In this example, my goal is to get the contents of second/doc.txt into the first branch.
Right-click on the first branch folder, and select TortoiseSVN > Merge...
Select "Merge two different trees"
Fill in the "From" box with the URL for /branches/first, and the "To" box with the URL for /branches/second.
(This is where I got tripped up originally - I thought it would be the opposite! The docs explain: "This may sound wrong, but remember that the trunk is the start point to which you want to add the branch changes.")
Hit Next and try a test merge if you want. It should show that "doc.txt" is replaced, with no tree conflicts. For this example the default merge options were fine.
Do the merge and check the contents of first/doc.txt - it should now read "SECOND".
Run an update and then commit the first folder to save the merge to the repository!
Complete log:
Reintegrate a branch vs merge a range of revision
I think what you want to do is merge a range of revisions first and then merge the branch back into the tree.
There is a dialog called
Merge Conflict Callback Dialog
Relating this issue:
the Merge Conflict Callback Dialog should come up
- when merging multiple revisions via "Merge a range of revisions"
- when merging via "Reintegrate a branch"
at the moment the Merge Conflict Callback Dialog only comes up in the
first case.
It will be included in the upcoming 1.6.0 release.
That allows to you to select the repository change instead yours
Consider my local repository contains more than one file, while doing checkout for a particular commit of a file, other files in the repository got deleted.
I am using following API (git is the instance of git repository)
git.checkout().setName(commitId).call()
Is this correct way to check out a particular commit of a particular file?
The JavaDoc of setName() says
When only checking out paths and not switching branches, use setStartPoint(} to specify from which branch or commit to check out files.
And for addPath() it states:
If this option is set, neither the setCreateBranch() nor setName() option is considered. In other words, these options are exclusive.
Therefore I think you should use
git.checkout().addPath( ... ).setStartPoint( ... ).call();
Your call reset the index (and can remove files no longer present in the new commit you check out)
You can look for a more precise example in jgit/porcelain/RevertChanges.java
// revert the changes
git.checkout().addPath(fileName).call();
In your case:
git.checkout().setname(commitId).addPath(fileName).call()
If i got a task (ie HT-4949311) and i
fix the bug
and change the javadoc
... in the same File.
And i like to seperate these two changes by two different comments:
"HT-4949311: bugfix."
"HT-4949311: javadoc."
... i need to:
revert the javadoc-change,
commit the bugfix,
write the javadoc-change again,
commit the javadoc-change.
Is there a better way to do so?
Or is there any feature that lets me simple commit the selected lines only?
Generally,our fixes/patches for any bugs involves changes in multiple files and we will commit all these files in a single shot.
In SVN, for each commit (may involve multiple files),it will increment revision number of whole repository by one. So, we can easily link all the multiple files that went in a single commit.
Now the difficulty with the same case in CVS is that it will increment the revision numbers of all the files individually. Let's say if a commit involves the following files:
file1.c //revision assigned as part of this commit..1.5.10.2
file2.c //revision assigned as part of this commit..1.41.10.1
and the comment given for this commit is "First Bug Fix".
Now, the only way to get all files checked-in as part of this commit is by searching through all the cvs logs for comment "First Bug Fix" and hopefully it will return only the two file revisions mentioned above.
Please share your views on if there is any better way in CVS to keep track of all files checked-in in a single commit instead of relaying on comment given as part of commit.
I think CVSps might do what you are looking for.
"CVSps is a program for generating 'patchset' information from a CVS repository. A patchset in this case is defined as a set of changes made to a collection of files, and all committed at the same time (using a single 'cvs commit' command). This information is valuable to seeing the big picture of the evolution of a cvs project. While cvs tracks revision information, it is often difficult to see what changes were committed 'atomically' to the repository."
This cvsps relies on cvs client. Make sure you have proper version of cvs which supports rlog command (1.1.1)
CVS does not have inherent support for "transactions".
You need some additional glue to do this. Fortunately, this has all been done for you and is available in a very nice extension called "cvszilla".
The home page is here:
http://www.nyetwork.org/wiki/CVSZilla
This also ties in to CVSweb, which is a great way to browse through your CVS modules via a web-based GUI.
Perhaps the ANT CvsChangeLog Task is another choice. See http://ant.apache.org/manual/Tasks/changelog.html . It provides date and time for a checkin message. You can produce nice reports with XSLT - try the example at the bottom of the ANT manual page.
I know it's late for an answer, but perhaps other users come across this like I did (searching) and appreciate the ANT integration.
OK, I just installed cvsps and ran it from the top level. Here's a sample of the output... this is one of the few hundred patch sets on my module. Note that indeed this does work across different directory trees.
---------------------
PatchSet 221
Date: 2009/04/22 22:09:37
Author: jlove-ext
Branch: HEAD
Tag: LCA_v1_0_0_0_v6
Log:
Bug: 45562
Check the length of strings in messages. Namely:
* Logical server IDs cannot be more than 18 characters (forcing a
TCSE protocol requirement).
* Overall 'sid' (filter) search string length cannot be more than
500 (this is actually more than the technical maximum messages are
allowed, but is close).
Alarm messages and are now not going to crash either as the alarm text
is shortened if necessary by the LCA.
Members:
catalogue/extractCmnAlarms.pl:1.2->1.3
programs/ldapControlAgent/LcaCommon.h:1.18->1.19
programs/ldapControlAgent/LcaUtils.cc:1.20->1.21
programs/ldapControlAgent/LcaUtils.h:1.6->1.7
programs/ldapControlAgent/LdapSession.cc:1.61->1.62
tests/cts-45562.txt:INITIAL->1.1
So, this may indeed do what you want. Nice one, Joakim. However, as mentioned, CVSzilla does much more than this:
Web-browsable CVS repositories (via CVSweb).
Web-browsable transactions.
Supports transactions across modules.
Generates CVS commands (using 'cvs -j') to merge patchsets onto other branches.
Integration with bugzilla (transactions are automatically registered against bugs).
If all you want is just the patchset info, go with cvsps. If you're looking to use CVS on large projects over a long period of time and are thinking about using bugzilla for your bug-tracking, then I would suggest looking into CVSzilla.
This also could be useful:
http://code.google.com/a/eclipselabs.org/p/changelog/