Im trying to get incremental inline diff working in Sublime text 3, but Show Diff Hunk is greyed out and not working. I'm in a branch trying to diff branch to master, for reference. I've set the setting at root level:
"git_diff_target":"master"
But its not working. Anyone know what I need to do to get this working?
This particular setting and feature don't work the way you think they do as far as the core is concerned (but see below).
The Incremental Diff feature that's core to the editor tracks changes to your file as you make them, based on either the state of the file as it exists on disk (for files not tracked by git) or, for files tracked by git, against the version of the file in the index or at the HEAD of the repository; it does not calculate deltas based on arbitrary branches.
In particular, the setting in question is:
// This setting determines whether tracked Git files should be diffed
// against the index or HEAD.
// Valid values are "index" or "head"
"git_diff_target": "index",
So your options are either to compare against the version of the file that you checked out originally to see what you changed, or the version of the file that you checked out to see what you changed, but anything you've staged for commit is not marked as different so you can work with changes that are still pending.
To get the functionality that you're after here, you need a package that alters the default functionality; an example of that is GitGutter, which has amongst its package settings a compare_against setting:
GitGutter compares the content of the view against the HEAD of the checked out branch by default. To change this default behaviour the compare_against setting can be changed to any tag, branch or commit hash git understands.
Related
Here's the scenario -
Development branch was created from mainline, with many thousands
of files in it
A couple of thousand files were modified.
Changes from mainline were "p4 integrated" into the branch.
Hopefully integrations always included the complete mainline as of a
known-good label, but I'm not sure of this
Steps 2 and 3 were repeated an unknown number of times - let's guess
a dozen integrates, and probably another 1000 or more changes,
usually to files already modified
I am now in the painful position of trying to code review this.
Are there any commands that can help me get the diffs for each modified file between the version last integrated to it, and the version in the branch?
Or do I need to write:
A script which will identify all locally changed files.
A script which will find the integration point for each file in the above list
Another script which will use (2) to purge the list in (1) of files with no net change
A wrapper on (2) that will issue an appropriate p4 diff2 command
FWIW, I basically know how to do this manually, file by file. It's the scale that's daunting. Also, there are changes still going into the branch, in response to code review feedback, so I'll probably be recreating my lists repeatedly.
If you know what the known-good label in the mainline was that was used to do the last integrate, this should just be:
p4 diff2 main/...#good-label dev-branch/...
since for each file "the version last integrated" will be #good-label. Files that weren't locally modified won't have any diffs, so there's no special need to filter them out.
FWIW if I were in your position I'd be making use of "p4 ichanges dev-branch/... main/..." and going through by changelist, since diffs make more sense when each is in the context of its changelist, rather than looking at one monster diff per file that each contains a dozen unrelated changes.
I'm a very fresh user of Perfoce, so please be patient!
I am trying to create a commit (I understand it that in Perforce it is called a changelist) of the files which have been changed. It sort of happens automatically in other VC systems, but there seems to be no easy way of doing it in p4... The problem is (maybe) that I'm not editing the files by hand, the files are generated (please don't ask me why do I have to check in the generated files...) so the whole directory tree is getting removed and then copied over with the new files. But Perforce acts as if nothing happened. In both my workspace and the depot it displays the updated files, but when someone will check them out on another machine, the files will be of the previous version.
I'm fine with doing it either through GUI or through the command line. I'd prefer the command line, because that would spare me the trouble in the long run, but it doesn't seem like it should be much hassle either way.
In other words, let's say, this is the workflow I'm used to from SVN or Git:
Run status to see what changed.
Stage / add to commit what you want to be in the next revision.
Commit and send it to the versioning server.
What I'm not able to do is the "stage" phase - because the changes are not discovered automatically.
EDIT
Ah, I think, I figured it out: reconciliation was what I needed... well, I guess if you don't marry, this word would hardly ever happen in your vocabulary :)
It appears that the proper command is reconcile. Also, as Bryan Pendleton suggested there should be status, but I must have an older version of Perforces, which doesn't have this command. This command is also available from context menu in either depot or workspace panels of Perforce graphical interface, when you click on the modified file.
I'm using TortoiseSVN 1.7 and want to create patch file between two revisions.
I've searched, but these threads How do I create a patch from diff between revisions using TortoiseSVN? Creating a patch between two revisions do not work for me, as Show changes as unified diff generates very simple file (not a patch file). Something like
Index: myfile.txt
===================================================================
I read in Viewing Differences that
If you want to see the changes made to all files in a particular
revision in one view, you can use Unified-Diff output (GNU patch
format). This shows only the differences with a few lines of context.
It is harder to read than a visual file compare, but will show all the
changes together. From the Revision Log dialog select the revision of
interest, then select Show Differences as Unified-Diff from the
context menu.
I want to create a single patch file (or many patch files according to modified files) that contains useful diff information (like the menu context TortoiseSVN -> Create patch ...)
If you use the "Show changes as unified diff" command, then TortoiseSVN shows all changes of the selected revision in a single file.
Now simply use the "File / Save as" command to save the changes to a ".patch" or ".diff" file and there you have your patch file.
I've been using Tortoise SVN + Visual SVN for about a year since left the corporate world to do my own startup. There's one feature in Tortoise SVN that I've never figured out:
How can I bundle up a bunch of changes into a PATCH or DIFF file and either: A) share them with my co-founder; or B) archive them into a standalone change that I can either "apply" or "revert" on my dev box?
At my previous employer, we used an internal tool that let us build so-called DPK files that contained a set of local changes. You could add changed files to the DPK and then share it with colleagues. They could either review the changes in a Diff tool or apply all the changes from the DPK to test your change on their box. After the review was complete, you could then check in these changes. You could also have multiple DPK's applied at the same time (provided you didn't have overlapping changes).
I want to achieve the same thing with Tortoise SVN + Visual SVN in the VS2010 IDE.
My real-world scenario is that I have some extensive change pending but uncompleted on my box. I want to ZIP up these changes and store them in a DIFF file, revert the changes, move on to something else, work on that, and in a few days reapply my changes from the archived DIFF file.
Reluctantly answering my own question. This feature is available with Tortoise SVN. Basically, you make a PATCH file, distribute it or archive it, and then you apply the PATCH. The only trick is to make sure you're in the right location in the WC (Working Copy) when you do the "apply". When you apply, you'll get a popup menu to the left with a list of all files in the changelist. You can apply the patches one by one or in bulk. Seems to work great. I should have drilled into the docs more before posting this question.
Here's the text for picking the location:
"Patch files are applied to your
working copy. This should be done from
the same folder level as was used to
create the patch. If you are not sure
what this is, just look at the first
line of the patch file. For example,
if the first file being worked on was
doc/source/english/chapter1.xml and
the first line in the patch file is
Index: english/chapter1.xml then you
need to apply the patch to the
doc/source/ folder. However, provided
you are in the correct working copy,
if you pick the wrong folder level,
TortoiseSVN will notice and suggest
the correct level."
Be sure to pick the location carefully. If Tortoise SVN can't find it because you selected the wrong node in the VS file explorer, it will try to find a matching location and that might be wrong. In my tests, the Patch feature actually tried to map to a branch (!!) when I specified the wrong location.
Here's the relevant link:
http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-patch.html
Our trunk directory contains about 100mb of code and we create tags from the trunk directory. Normally, this is not an issue because a tag takes up no space until you need to use it for something. Since branches are created from tags in SVN, how can I create a branch from a tag wtihout first checking out the tag? It appears I need to do a Tortoise Update from Windows Explorer to get the tag down to my local machine before I can use Tortoise > Branch/Tag... to create a branch from it. This seems illogical since we don't make changes to tag folders, and it requires that I check out 100mb of code, only to create a branch, and then check out another 100mb of code in the branch folder, where the changes will actually be made.
Ideally, I'd be able to create a branch directly in the repository via RepoBrowser - but I can't see an option for it there.
Am I missing something?
Creating a branch is just a matter of copying the desired directory to another location. This can be done directly in the Repo Browser.
There is nothing special that differentiates a branch from a tag as far as Subversion is concerned. It is just a convention to store them under separate parent folders, named 'branches' and 'tags' accordingly.
The only difference between tags and branches is your attitude towards them -- they are equivalent behind the scenes -- shadow copies made in the repository.
You don't even need a working copy to create a branch/tag. For example, you can use this command-line:
svn copy http://server/test/trunk http://server/test/branch -m "make branch"
(assumes you have SVN.EXE in addition to TortoiseSVN, otherwise, use Ben's answer)