Merge/diff tool that can show authors (supports blame or annotate) in files under version control - version-control

When merging files it will be helpful (as for me) to show an author of each line. Is there any diff or merge tool supporting that?

The bundled gitk tool is not really a merge tool, but it shows conflicted lines with red and blue and "+"'s in front, and you can Rightclick->"Show origin of this line" on any of them, to go to the commit which introduced the line:
You can run your mergetool, or just a text editor with diffmarks in parallel

So what you really want is a tool that can easily identify your changes
relative to other's changes in a merge conflict, rather actually identify
the author of each line (which would be a mean to achieve that), right?
If I understood you correctly, I have some relatively good news: It
can be done with git + kdiff3. For merging you can just use git mergetool
(which you can configure to use kdiff3). But it is not supported natively
if you get a merge conflict when doing interactive rebase, so for that
some manual scripting is required.
Instead of making up my own simple merge conflict example, I will use
http://www.gitguys.com/topics/merging-with-a-conflict-conflicts-and-resolutions/
as an basis. Follow that page to git merge test. From after the merge
command I diverge a bit from that example by running different commands
(but basically doing the same job). I'll do all the manuall steps first.
So we have a merge conflict and git has inserted content from both
contributing sources into the file in this <<<<<<<...>>>>>>> format,
which I really do not like at all and never consider even looking at it.
Instead I use my favourite merge tool, kdiff3.
First we need to find which versions that are involved.
$ git ls-files -u
100644 b0ed415d15862ac5582b51e4de65528e86934cd2 1 README
100644 56300e3ac4e4521c3500618a301bb2ab2d6a52f5 2 README
100644 9585db7d9c2d9ca05075f67a878f2554886d7b1a 3 README
$
Basted that information we can perform a three way merge:
$ git cat-file blob b0ed415d15862ac5582b51e4de65528e86934cd2 > v1
$ git cat-file blob 56300e3ac4e4521c3500618a301bb2ab2d6a52f5 > v2
$ git cat-file blob 9585db7d9c2d9ca05075f67a878f2554886d7b1a > v3
$ kdiff3 -o merge_result v1 v2 v3 &
[2] 18394
$
Which gives the following view where you can select from which ancestor
you want to merge from.
Afterwords (if you are satisfied with the merge result)
you need to
$ rm v1 v2 v3
$ mv merge_result README
$ git add README
All the manual steps above are done automatically with git mergetool.
So why showing all that then? Well, because if you get a corresponding
conflict during git rebase -i, then it has to be done that way (before running git rebase --continue).
In this small example there is only one conflict
line, so it does not show the more typical case where a lot of lines
are automatically resolved, leaving you to just manually resolve the
ones that was not done automatically.
A more real life example might look more like the following:
Notice that in the merge result you now clearly see the origin of the C lines that
were automatically resolved. I think this is sort of what you were asking for when asking for getting the author for each line, right?
That information is completely absent in the <<<<<<<...>>>>>>> text (and it is difficult/impossible to spot that you should update the printed string in the hello function).
I cannot recommend kdiff3 highly enough. Using a graphical merge tool like that compared to some lines from both sources mixed inline in the file is like using an excavator versus a spade.

No. And, I think, never will be - when we merge, we think about content, not authorship

Related

Importing existing files in repo to new LFS storage (using SourceTree and Git LFS)

TL;DR: What is the least intrusive way of migrating existing files to the LFS storage, once LFS has been initialized on the repository, and a suitable .gitattributes file has been prepared but not yet pushed, for a Unity project using Github, Git LFS and SourceTree?
Software/services used:
Unity 2020 LTS
Github
Git LFS, which is part of Github
SourceTree
Links I'm using:
Githubs own migration tutorial
Githubs documentation for the migrate command
A .gitattributes file, which handles casing-differences in extensions using RegEx (I think).
Another answered question very much like this one.
I also took a look at BFG Repo-cleaner, but it seems a bit much for this task.
Motivation for posting
I've been trying to find a guide describing the best way to do this, but most seem to be out-dated or don't include enough information for me to be confident in firing these import-commands on my repo. Others focus a lot on how to set up LFS using a specific server backbone, like Bitbucket Cloud, but I can't find any focusing on Git LFS and SourceTree.
SourceTree has direct integration with Git LFS, but there seems to be no UI-implementation of the migration process for existing files in the repository, so I think I have to rely on the terminal for this part (which I honestly haven't had to use in years, so there's that).
I also have a question about a command for this that I don't see mentioned in my contexted searches: --fixup
The setup
It's not a huge repo; it's a main branch with a few dead branches that don't matter. I just want all the files with certain extensions converted to LFS. My initial thought was to do the migrate-command with --norewrite, because I liked the idea of compacting all the changes into one commit and have no changes to the commit history, but when I realized that means the files would have to stay in the repo for posterity, I changed my mind. I want the repo to shrink, as well, which means I want to replace the files with pointer-files back through the commit history, in order to eliminate the actual files from the repo completely, so they only exist in the LFS-storage.
My questions and options, as I see them
In that other answered question I linked to, a full answer isn't given, but it's very close. Though the answer is very informative, it doesn't answer these questions:
How to handle case-sensitivity surrounding extensions when writing migrate-commands with --include and --exclude options? Do I need to either go through all existing files in the repo and ensure a similar casing in order to do one-liners, or alternatively fire a separate line for each permutation of the extension I find in the repo? (ignore this question, if --fixup understands the casing-format mentioned in 2. and works for my purposes).
I see that there is a --fixup option for the migrate command, which isn't mentioned in the search results I'm getting with the given context, except in Githubs documentation for the migrate-command. It says:
"Infer --include and --exclude filters on a per-commit basis based on the .gitattributes files in a repository. In practice, this option imports any filepaths which should be tracked by Git LFS according to the repository's .gitattributes file(s), but aren't already pointers."
Is there some reason why the --fixup option isn't recommended anywhere, when it seems to do exactly what I need? Does it not rewrite the history, or something?
I hope it works, because since --fixup reads the .gitattributes files, it should be able to read the different casing-options from the casing-format in the .gitattributes files. Then I don't have to worry about missing files due to different casings, like when using the --include option.
This is the casing-format used in the .gitattributes file (example for .wav files):
*.[Ww][Aa][Vv]
It works for .gitattributes' normal workings, but doesn't work when you use the format for the --include or --exclude options for the migrate-command, e.g.:
git lfs migrate import --include="*.[Ww][Aa][Vv]"
...does not work. This is what gives the casing-issue mentioned in 1.
I have LFS initialized. I have my .gitattributes file (uncommitted) at the root of the project. So, committing and pushing .gitattributes, and then doing 2. seems to be what I want, right? I should be able to open the terminal in SourceTree, and put in this line:
git lfs migrate import --fixup
or do I need --everything, in order to affect all branches?:
git lfs migrate import --everything --fixup
Also, if --fixup doesn't work, is it just a bunch of these?:
git lfs migrate import --everything --include="*.WAV"
git lfs migrate import --everything --include="*.wav"
...followed by a:
push --force
or
push --force --full
???
That's about where I'm at. I'm not entirely sure which way to go here, or how each of these commands affect the result. I'd appreciate any input on what would be the best course here. If anything, I've tried to be as informative as I can and include the best sources I've found on the subject, to help anyone else asking the same questions.
EDIT: I found this issue at the Git LFS repository, which describes a caveat with the --fixup option; it takes into account when the existing files were added to the repo, and if they were added before the changes to the .gitattributes-file, then they aren't included. So, it is recommended to either rebase, or use filter-branch or filter-repo, in order to add/change the .gitattributes file at the root commit, so that the --fixup option will register the files. The issue deals with some more caveats, like having to uninstall LFS first, but eventually found that solution. This is all just to avoid having to do separate calls for each extension-casing permutation. I don't want to do any of those suggestions, since some seem to run into trouble with them, and I can't get --fixup to work with info, meaning I can't preview what it'll change, so I'm going with --include calls, and just searching up all the current permutations of the extensions of the existing files, and doing --include calls for those. Please, if you do have any good information on the subject, I (and probably many others) would love to hear some easier solutions to this problem.
Thanks in advance and best regards, Jonas Tingmose.

Avoid Git to do any merge to a certain filetype

I am working on a quite big project versioned on a Git repositories that have several file of different types versioned. Among those, we use the QM Modelling tool that uses .qm files, which are actually xml files with a certain structure.
The structure of the .qm and the meaning of its content makes it unadvisable to use a merging tool to merge any change.
What I would like to do is have git issue a conflict in case it finds changes to any qm file even if it could merge those changes ( even if it could, the result is not guaranteed to be meaningful ), so that I can manually merge them using the tool.
Pros if the same is true if I perform a rebase instead of a merge.
Ok, answering myself as I found a solution.
I found this answer and modified it a little bit. I added a new merge strategy that basically takes the file as it is in the incoming branch and uses it untouched, then marks the file as with conflict.
So i created this script:
#!/bin/bash
# ${1} is the base common file
# ${2} is the file as modified by the base branch, and where the results must be
# ${3} is the file as modified by the incoming branch
# ${4} is the path of the file being merged
# ${4%.qm*} is the path without extension
# ${4##*.} is the extension of the path
# makes a backup of the original file to ease edits comparison
cat "${2}" > "${4%.qm*}.bk.${4##*.}"
cat "${3}" > "${2}"
exit 1
which uses the incoming file as a result as it is, and returns 1 to mark it as conflict.
Then I added in the .gitattributes the option to use this strategy for my .qm file, so that when I merge two branches, I take the incoming version as it is and use the graphical tool to modify and integrate my changes.
I'm going to leave this question as unresolved to see if anybody got another solution that would enable me to use both rebase and merge.
EDIT: I updated the script, I added a few lines to take the version of the local branch and make a backup of it, so that it is available to use in a comparison tool to identify my changes more easily.

svn2git broken pipe error

I use svn2git but it fails always on the same line:
My command:
svn2git https://my-svn/proj/ --revision 1000:1001 --username xxx
After one houre this command stoped running and it fails with:
Broken pipe at /usr/lib64/perl5/vendor_perl/SVN/Ra.pm line
623.
What would cause this issue?
For a one-time migration git-svn is not the right tool for conversions of repositories or repository parts. It is a great tool if you want to use Git as frontend for an existing SVN server, but for one-time conversions you should not use git-svn, but svn2git which is much more suited for this use-case.
There are plenty tools called svn2git, the probably best one is the KDE one from https://github.com/svn-all-fast-export/svn2git. I strongly recommend using that svn2git tool. It is the best I know available out there and it is very flexible in what you can do with its rules files.
The svn2git tool you use is based on git-svn and thus suffers from most of the same drawbacks.
You will be easily able to configure svn2gits rule file to produce the result you want from your current SVN layout and you can also tell it to keep empty directories by giving it a commandline option that causes it to put empty .gitignore files in the directories to keep them.
If you are not 100% about the history of your repository, svneverever from http://blog.hartwork.org/?p=763 is a great tool to investigate the history of an SVN repository when migrating it to Git.
Even though git-svn (or the svn2git you used) is easier to start with, here are some further reasons why using the KDE svn2git instead of git-svn is superior, besides its flexibility:
the history is rebuilt much better and cleaner by svn2git (if the correct one is used), this is especially the case for more complex histories with branches and merges and so on
the tags are real tags and not branches in Git
with git-svn the tags contain an extra empty commit which also makes them not part of the branches, so a normal fetch will not get them until you give --tags to the command as by default only tags pointing to fetched branches are fetched also. With the proper svn2git tags are where they belong
if you changed layout in SVN you can easily configure this with svn2git, with git-svn you will loose history eventually
with svn2git you can also split one SVN repository into multiple Git repositories easily
or combine multiple SVN repositories in the same SVN root into one Git repository easily
the conversion is a gazillion times faster with the correct svn2git than with git-svn
You see, there are many reasons why git-svn is worse and the KDE svn2git is superior. :-)
From what I can tell, the "broken pipe" error is due to a problem receiving a file. It might be really big or there may be something else odd about it.
If you run into the error, fortunately in most cases you can simply re-run the git svn clone command or other related command and usually it can seamlessly resume from where it left off.
If you are using git-svn to do a one time migration of an SVN repo to Git, just be sure to follow Atlassian's guide. They have a tool for properly converting the SVN tags to Git tags, but it is a destructive process and you won't be able to use the git repo to sync with SVN anymore, so only do this when you're finally ready to abandon the SVN repo.

How to retrieve cvs commits by commentaries

In my development team we use requirements management to control the expected behavior and functions of our products and a bug report tool to track 'problem reports' (PR). Any change in the requirements is done by a 'change proposal' (CP) which acts much like a commit on a code repository.
In order to make any commit that changes the final product one must supply on the CVS commit commentary a trace which can be either a CP (this means that the change on your code reflects a change in the product) or a PR (which means the changes in the code are being made to correct a problem). CPs and PRs are numbered so that one can link changes in code to the causing item (CP or PR).
Sample commentaries
Error correction commit commentary:
Kind: Error Correction
Trace: PR-015 Crashing upon startup
Description: Edited file foo.c in order to verify uninitialized variables.
Product change commit commentary:
Kind: Development
Trace: CP-053 New login mechanism
Description: Added login mechanism with library X and blablabla.
My problem here is that I don't have any easy way of retrieving all the files that were changed for a specific CP or PR neither can I retrieve all the changes made to the code.
I have tried to use regexp (RE from python) in order to parse the log but it has been a little tough to cover all possible logs. My regular expressions failed to retrieve the list here and there even after adapting it some times.
So, I've been thinking if there isn't any easier way or any project or product or even a CVS built-in feature that might help me here.
The objective question: How do I retrieve the list of modified files in a commit which is identifiable by a well-formed tag (the CP or PR)? Is there an easier way or should I stick to log parsing?
Environment details:
OS: Windows XP
CVS server: cvsnt
CVS client: tortoise / cvsnt
Didn't want to answer my own question but I think it may be helpful for future reference for people with the same problem.
Well, I managed to perform a search within the 'log messages' (cvs term for the commit commentaries) filtering by the content of the text in the log message and group the files changed on that commit.
As pointed out by 'Joakim Elofsson' here, cvsps is a good tool for grouping commit information in 'patch sets' which are individual commits with references to all the files changed in those commits.
I used the version of cvsps packed for cygwin as at this moment there's no port for windows.
Just install the cygwin with the internet setup available here and, when choosing packages, search for cvsps and cvs, install both.
I couldn't manage to use the checked out files on my system (through the /cygdrive/c folder) so I checked them out from the cygwin shell.
BEGIN Obs for tortoise users
You'll need to setup CVSROOT environment var to the current CVSROOT of your repository by the command:
export CVSROOT="Your CVSROOT string here"
Usually, if check the properties page of any file of your checked out code base there will be a tab named CVS. There'll be your CVSROOT string. (if you're using :sspi: to connect to your remote repository as I do, you may try to switch it to :pserver:, it did work for me but I don't know exactly why).
END Obs for tortoise users
Well, after checking out your repository use command:
cvsps
This will create the cvsps patchset base for your requests. Then use:
cvsps -l "Some regexp code"
It will search the patch sets for log messages matching the input regexp.
This is a sample from using cvsps -lP100-PR-FEX` on my database (changed some filenames and paths for being able to make it public...):
PatchSet 71
Date: 2012/10/25 11:30:44
Author: GUARITA
Branch: HEAD
Tag: (none)
Branches:
Log:
Kind: Error correction
Trace: P100-PR-FEX145
Description:
Corrections of the TRUE and FALSE conventions used by the C++ (true:everything but 0, false:0) P100 interface to the VB6 (false:0, true:-1 or 'all bits set to 1 which is -1 in 2's complement') P100Interface ActiveX object.
P100 Panel Version increment.
Members:
SidePanels/P100.wimp:1.2->1.3
SidePanels/Calcs/P100Interface/private/P100Interface.cpp:1.2->1.3
You may also use it to compare changes between tags (which I use to control releases) with cvsps -r <tag1> -r <tag2>.

Mercurial workflow for updating with uncommitted changes?

So i've made the switch from CVS to mercurial for my website.
The biggest issue I am having is that if i'm working on some files that I don't want to commit, I just save them.. I then have other files I want to push to the server, however if someone else has made changes to the repository, and I pull them down.. It asks me to merge or rebase.. either of these options will cause me to lose my local changes that I have not committed.
I've read that I should clone the repository for each project on my local host and merge it into the live when it's ready to do so. This not only seems tedious, but also takes a long time as it's a large repository.
Are there better solutions to this?
I would have hoped that Mercurial would see that I haven't committed my changes (even though I have changed the file from what's on the server) so it'd just overlook the file.
Any input on this would be greatly appreciated. Thank you!
Also, i'm using the hg eclipse plugin to work on my files and push/pull from the server.
hg shelve is your friend here I think.
which comes from the shelve extention (maybe - see below)
from the overview:
The shelve extension provides the
shelve command to lets you choose
which parts of the changes in a
working directory you'd like to set
aside temporarily, at the granularity
of patch hunks. You can later restore
the shelved patch hunks using the
unshelve command.
The shelve extension has been adapted
from Mercurial's RecordExtension.
or maybe its the attic extension
This module deals with a set of
patches in the folder .hg/attic. At
any time you can shelve your current
working copy changes there or unshelve
a patch from the folder.
it seems to have the same syntax as the shelve extension, so I'm not certain which one I've used
I second #Sam's answer. However, if you prefer to use standard Mercurial, a simple workflow is to
save your working dir changes in a temporary file,
sync your working dir with a specific revision, then
push, pull, merge .. whatever you want to do and which requires a clean working copy, and
get back your changes from the temporary file into the working dir.
For instance:
$ hg diff > snapshot.patch # save your uncommited changes
$ hg up -C # get a clean working copy
$ hg pull # do things ..
$ hg merge # .. you need a clean ..
$ hg commit -m "merge" # .. working copy for
$ hg import snapshot.patch # get back your uncommited work
First, are you working from the commandline, or using something like Tortoise?
If you're working from the commandline, and you've done a pull, mercurial will not ask you to do anything, as it merely updates your local repository.
If you then do an hg update and have local changes, it should do what you're used to from CVS. It will update to the tip of the current branch, and attempt to merge your outstanding changes in. There are some caveats to that, so refer to the official docs at http://www.selenic.com/mercurial/hg.1.html#update.
Also, for temporarily storing changes, I would recommend MQ over shelve. Shelve only provides one storage area, whereas MQ provides as many as you need. MQ takes some getting used to, but worth the investment.