There are many questions on stackoverflow that are similar to this question. Most discuss single files, diff files, or filenames. Very few discus GUIs for viewing the diff of two hashes for an entire git repository (ALL directories, subdirectories, and files). The one or two comments I've seen mention tools only available on Windows (like araxis merge) or OS/X.
What about linux? Meld is my preferred tool so I've tried:
git show <hash1> <hash2> > /tmp/clownshoes.diff
then opened that in meld. No luck. Meld sees it as one single giant.
Take a look at git's list of gui clients, I think smart git will do what you are looking for.
Related
My request may look strange but it'd make more sense after I explain why I'm doing it.
So I have my person projects under /path/to/myprojects. Underneath maybe C, Perl, Shell, Tcl, etc. Now I want to put those project groups (C, Perl, etc) under git, but in different location, e.g., /path/to/mygits/.
The reason that I want to do this is that, traditionally I backup my /path/to/myprojects to other locations by rar them first. Since they are all text based, rar them up will yield excellent compression ratio. Now I want to keep the same practice, even I've introduced git. Thus I need to keep the binary git repository out of the way of my text base folder into a separate binary base folder.
All my findings on stackoverflow indicate impossible, or I "have to use submodules which can be quite painful":
Git: Different Working Directory and Repository location,
git repository with folders in different locations,
Add Separate Directories/Projects/Files to Git Repository
However, there is one answer that says it is possible to decouple the git working directory and git repository directory:
how do I change the location of a Git repository
but it says something about git reset --hard which I want to know the details.
Also Using GIT_DIR seems to be another solution.
Anybody can help?
Thanks
Alright, enough waiting, let me answer my own question.
As DCoder has pointed out, the answer is at Can I store the .git folder outside the files I want tracked?.
I.e., there are many git based solutions listed there, all needs some extra
git configuration. You might have to do them if under Windows. However, under Linux, symlinking the .git directory to somewhere else is the easiest and cleanest solution.
The default patch file viewer is messy (ie. no side by side diff view etc). I tried setting the path of beyondCompare exe in "Settings->Unified Diff Viewer->custom", but beyond compare also behaves same as default diff tool.
Is there a way to atleast allow side by side diff in patch files ? If so, what is the method ?
My aim is to allow emailing of changes so that they can be reviewed before I commit them :)
Mishal
I've never found any, but the solution that I usually use is to simply apply the patch file to a pristine checkout of the tree, and then do a "regular" diff (my preferred tool is diffuse) to review the changes in context.
The problem with "raw" patch files is that they only provide a few lines of context before and after the change, which often isn't enough.
If you don't like the patch, simply revert the changes and don't commit!
Beyond Compare 4 allows you to view patch files created by SVN. The top window in Beyond Compare is a tree structure, allowing you to navigate folders and files by name. Revision numbers are present in the left and right diff windows.
Create the patch
svn diff -r 5922:6116 > CodeReview.patch
Open the patch in Beyond Compare 4
SVN 1.7 I think was released since this answer was posted, and I landed here because I wanted to show my newly created patch file with syntax coloring, a la view unified diff in TortoiseSvn.
It turns out that Notepad++ automatically syntax colors my file correctly if I give it the filetype of "patch"!
Patches have been around a long time but SVN is now supporting them more fully.
See for example the documentation;
http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-patch.html
For how to create a patch file, see this nice document that describes various methods including mine, WinMerge;
http://docs.moodle.org/dev/How_to_create_a_patch#Creating_a_patch_using_WinMerge
If you have access to a Mac OS X machine, PatchViewer sounds like it might do what you're looking for:
http://appledeveloper.com.au/products/patchviewer/
(Disclaimer: I am the author of PatchViewer.)
You can view a diff file (a patch generated by diff tool) using Kompare from KDE environment. I used it before on Linux, but today I found how to install it on Windows. Here is an installation instruction from a blog "Kompare - the only valuable diff for M$Windows":
Go to gnuwin32 diffutils, download and install.
Download kdewin installer and launch it.
After installing kde4win - start kompare and in "Diff" section show him where your diff.exe (from gnuwin32 diffutils) is located.
Restart Kompare and it's ready to use!
You can also add an association with .diff file format and now you can view any diff files. For me it works great.
I like to use KDiff3, it's packed with functions, very user friendly and available for all popular platforms. It can also integrate with TortoiseSVN.
GitExtensions, my favorite Git GUI, also has an option to "View patch file":
Problem: 2 projects shared trunk and were updating some of the same files. Now one project needs to be released, so a new branch was created from a checkpoint before the projects started.
I have a list of just my changelist numbers from the mainline. Using that I can generate a list changed files and diff output using a script with a series of 'p4 describe #' commands.
Can I reformat that output and apply it to the new branch somehow?
Response to the title: "Is it possible to create a patch using a set of changelists?"
Yes.
p4 diff2 -u //path_to_your_sources/...#cln_minus_1 //path_to_your_sources/...#cln > /tmp/cln.patch.
You can then use /tmp/cln.patch as input to the patch utility. Here, 'cln' is the submitted change list number that you want to create a patch for.
I've just spent two hours struggling with this. Using cygwin patch, I had to munge the paths until they were recognised.
In the end, the magic incantation looked like this (broken across lines):
p4 diff2 -u //depot/foo/main/...#100003 //depot/foo/main/...#100000 |
sed 's#//depot/#E:/Source/#g' |
sed '/^+++\|---/s#/#\\#g' |
patch
That is:
Use p4 diff2 to get a unified diff (-u) of part of the depot between the two revisions that I care about. The second changelist is the one before the first one I want, otherwise it's not included in the diff.
Use sed to change the //depot/ to E:/Source/, which is where my workspace lives.
Change forward slashes to double backslashes (this seems to make it work).
Pipe the results through patch.
Cygwin patch is smart enough to check files out of Perforce, but I'm not sure how to get it to do it silently. It prompts with Get file 'e:\Source\foo\whatever' from Perforce with lock?.
This is with p4 version 2010.1, a fairly recent installation of Cygwin, running on PowerShell.
Oh, and after this, patch wrote out Unix-style line endings, so I used u2d to fix those up.
Perforce will let you cherry-pick changelists for integration, which may be easier than trying to generate and apply a patch. Perforce will keep track of what revisions you've integrated where, which may make future integrations easier.
Let's assume you used to have one trunk:
//depot/mycode/trunk
And you checked in all of your changes there. You branched trunk at some point in the past to:
//depot/mycode/rel
And you have a list of changelists on trunk to merge. From a client spec that maps rel, integrate each changelist:
p4 integrate //depot/mycode/trunk/...#1234,1234 //depot/mycode/rel/...
where 1234 is the changelist number. Resolve after each integration. You may also wish to build, test, and commit your integrations at various checkpoints during your integration, if you can identify good points to do so. (Perforce can handle multiple integrations per commit, but if you make a mistake you'll need to revert to the last version checked in and redo the intermediate integrations and resolves.)
p4 describe -S -du <CL number>
is the shorter and most concise command, in my opinion.
I've got a file and a patch for it. I'd like to visually apply the patch, t.i. see how the changes proposed by the patch look in context, make some corrections, and save the resulting file.
What tool can do that?
Neither of the visual diff tools (i.e. meld, diffuse, diffmerge) do what I want: they don't work with patches, they merely merge whole files.
I really like Kompare. It is just a (very nice) graphical interface for diff.
http://www.caffeinated.me.uk/kompare/
sudo apt-get install kompare
Creating and applying patches
Kompare is able to create a patch file
which lists only the differences
between two compared text files A and
B. Further, Kompare can apply a patch
file which was created this way to an
original file A and, in this manner,
recompute the contents of the
corresponding file B. This is a
comfortable utility for passing a
corrected version of a file to a
friend who already has an older
version of the same file, because only
the (relatively small) patch file has
to be delivered and the receiver can
generate the corrected file by
applying the patch to the original
file.
The patches created and applied by
Kompare are compatible to patch files
generated or applied by the command
line interface diff utility, because
Kompare is in fact merely a graphical
front end to diff and the patches are
created and applied by patch, which
gets called by Kompare.
See use vimdiff with a diff file.
gvim original.file +'vert diffpa the.patch'
This will open GVim and split the window, with the original on the left and the patch applied on the right. You can then add, remove, or change hunks, and save the changes. (Well, if you want to create a new.patch you'll have to run diff again, but that's not difficult.)
You may use the emacs ediff mode.
It lets you see and validate each chunk interactively.
For what it's worth, I have this handy script in my ~/bin directory:
#!/bin/bash
if [ "$1" == "--text" ] ; then shift; fi
if diff --brief $1 $2 ; then
exit 0
else
emacs -fn 8x13bold --eval '(ediff-files "'$1'" "'$2'")'
fi
Another option: if you use Eclipse, you can generate and apply patches visually.
The idea with visual diff tools is that you can:
make a backup copy of the patched file (or a new pristine checkout of the whole tree)
apply the patch
use the visual diff tool to review the changes in context
make any desired change to the patched file within the visual diff tool.
Some tools, such as meld or diffuse will automatically diff against the previous committed version of the files.
The key insight is that you CAN apply the patch, they discard everything you don't like as long as you have a backup copy, or if you are working on a clean checkout.
If you feel more comfortable with reading and modifying unified diffs, and just want to have more context for the diff, emacs has a fairly unique feature, which is next-error-follow-mode while viewing a diff file (diff major mode). That shows the context of a diff line in the target file.
On platforms where Kompare (a fairly nice piece of software if KDE is your cup of tea), I agree that Eclipse is a great option.
I have consistently been a reluctant Eclipse user AND I am consistently impressed by how well the tools work (once the platform finally starts up).
On Fedora, I've got just about every front end installed for each of the main version control engines (SVN - also serving my Windows machines, Mercurial, git, etc.);
Meld is quite nice (no patch interface though).
Submerge works well also.
But since Eclipse does know how to apply patches and Working Copy project created itself once I figured out to create the project in the folder containing my working copy, it may become my favorite SVN front end.
I normally use GitExtensions (.NET and Mono) which also supports applying patches interactively. I hope you are already familiar with git.
Edit: Everything mentioned below this line doesn't seem to be available directly in KDiff3. And as I mentioned before: I haven't tried it yet.
GitExtension normally uses KDiff3 as diff tool, which is able to view patches.
http://kdiff3.sourceforge.net/doc/kpart.html
Using it for patches it has only a two window view, (edit) and doesn't support merging :( but it also supports 3 way diff on complete folders etc.
Actually I never tryed it with patches.
Does xxdiff do what you are looking for?
I'd use meld.
Create two copies of the files, one without and another with the patch. Use meld to compare them, and you can see exactly what the patch is changing and make changes as necessary.
Seriously, why is this so hard?
How can I figure out the state of the files in my client, I want to know if the file needs an updated, or patched, or modified etc. In CVS, I used to simply run "cvs -n -q update . > file". Later look for M,U,P,C attributes to get the current status of the file.
In perforce, "p4 sync -n" doesn't give output like "cvs -n -q update". How can I see the current status of files, in case of Perforce?
To my knowledge, there isn't a command that will give you exactly what you want. In looking what the update command does, there is no single alternative in Perforce. I think that the closest that you will come will be to use the 'p4 fstat' command and parse the output from there to get the information that you need.
You might find this page helpful.
I also found this link to a p4wrapper that claims to wrap in come CVS commands (including update) into a script. There might be others like this one around as well.
I also wanted to comment that the answer to this question is like many with Perforce when asking "how do I do...". The answer usually comes down to writing a script to take the output from perforce commands to get the results that you need. Their philosophy is to provide bare bones commands and have developers build off of the basic functionality. Love it or hate it, that's the basic model. Many good scripts can be found in the Perforce Public Depot here.
Not sure if this is what you're looking for, but the p4 diff command has a few useful options. From the usage:
-sa Opened files that are different from the revision
in the depot, or missing.
-sb Opened for integrate files that have been resolved
but have been modified after being resolved.
-sd Unopened files that are missing on the client.
-se Unopened files that are different from the revision
in the depot.
-sl Every unopened file, along with the status of
'same, 'diff', or 'missing' as compared to its
revision in the depot.
-sr Opened files that are the same as the revision in the
depot.
Full disclosure: I work for Perforce
There will be a 2 new commands "p4 status" and "p4 reconcile" in the up-coming 2012.1 release. See the following for more details:
http://www.perforce.com/blog/120126/new-20121-p4reconcile-p4status
Not quite sure what you mean. If you are talking about seeing what files need "resolving" (in perforce language) then you can use:
p4 resolve -n
See the p4 command line manual website here:
http://www.perforce.com/perforce/doc.current/manuals/cmdref/resolve.html#1040665
Also P4V has a nice feature to highlight unsubmitted and dirty files, if you use that client. Right-click on a fodler in the workspace view, and select "reconcile offline work." After a bit of processing you'll get a list of files that are out of sync with the depot.
Hope this helps.