I am using git with a latex project but it seems that I am not using latexdiff in an efficient way.
In order to run latexdiff to compare the current version with the previous revision, I learned to use:
latexdiff-vc -r HEAD~1 main.tex
Further info here: www.mankier.com/1/latexdiff-vc
The HEAD~1 above picks the previous git revision, which is something that I find useful.
However, the generated diff file has the following name main-diffHEAD~1.tex, which I find a terrible name: both for clarity and since my tex editor has issues with the ~.
Due to the issue, my questions are:
Am I properly using -r HEAD~1, or is there another more natural way to do the same comparison?
Is there a simple way to control the file name output instead of renaming it? Say, main-diff1.tex would be better.
To ensure the hash in is the filename you can run this:
$ latexdiff-vc --git -r `git rev-parse --short HEAD~1` main.tex
where HEAD~1 can be replaced with any of the alternatives mentioned by #torek in the question comments.
I personally use this quite often so have the sub-command as an alias in my ~/.gitconfig, like so:
[alias]
shash = "!git rev-parse --short HEAD"
and then actually run the same command from above as:
$ latexdiff-vc --git -r `git shash HEAD~1` main.tex
Related
When working with Gerrit (Code Review), I often need to get a copy of a given patch set for testing or validation purpose. The obvious and easiest way is to download the archive or the patch file through the Gerrit Web interface and manually apply it to my local source.
While the above steps are pretty straightforward and fulfill my needs, in the best world I would like to have the patch set appearing as a commit in my local Git.
I was looking around and didn't find the solution. I found some sparse info that once compiled together gives the following solution.
Say that you want to pull the patch set 2 of the Gerrit change 1222:
Find the remote refs we are interested in:
$ git ls-remote | grep 1220
From http://something.com:8081/MyProject
e2e0212a59240ac5cd7c11220c35542523f44b59 refs/changes/13/713/1
b8c4dceea5eaf1bad711b0ea6938c80ec932726a refs/changes/20/1220/1
6f20c182ec7f54a2aa9e8f6188a0eef1b0790df4 refs/changes/20/1220/2
ed94a98386d224ce3d86004ce99f61220905a077 refs/changes/22/1222/1
Pull the refs:
git pull origin refs/changes/20/1220/2
This will create a Git commit point that you could eventually rebase:
git rebase
This feature is standard in the Gerrit UI.
On the top right of the UI for a patch, click Download, and you will see something like:
When you are navigating the patches you go to the download section and copy the command line command for checking out the patch set, for example like this:
git fetch https://gerrit.googlesource.com/gerrit refs/changes/03/64403/2 && git checkout FETCH_HEAD
Then I normally create a branch with the review number and patchset as name
git checkout -b b64403-2
For here you can work normally and commit your changes or cherry-pick/rebase your changes on this change.
Once the review of r64403 is done your code can be merged or when there is another patchset submitted you will need to do the same thing again.
If you do not see the options to download the option to Checkout or Cherry Pick you need to edit the gerrit.config, something like this:
[download]
scheme = ssh
command = checkout
command = cherry_pick
More details can be found in the Gerrit Documentation
Update:
As barryku correctly points out, in the later version you need to download the downloads-commands plugin. This can be done during the initial setup or by using the following command:
java -jar gerrit-2.11.4.war init -d review_site --batch --install-plugin download-commands
Or you can use the -d option to git-review. For example, assuming you were working the with nova-docker repository and were interested in this change in gerrit:
https://review.openstack.org/#/c/148486/
You could download the latest patchset like this:
git review -d 148486
Or you can use the change id:
git review -d I35729a86e211391f67cc959d19416c9125c6f9eb
You can also request a specific revision of the patch by appending a comma and the patch number. E.g, to get the second revision of that patch:
git review -d 148486,2
I am not 100% sure what your question is. Sounds like you want to easy the workflow or typing. larsks mentioned already git review which is mostly used.
For your case, maybe it helps to download all ref's automatically so you can reference them directly. You can always all specified ref's like with
git fetch origin "+refs/changes/*:refs/remotes/origin/changes/*"
Then you can work locally with the commit id.
A simple git alias or scripting it for all refs can be easily done. An example of such a while loop can be found in the script on https://github.com/saper/gerrit-fetch-all With such a small shell snippet you can easily accomplish to skip one part of the ref id to easier reference them:
Server side: Client side:
refs/changes/13/713/1 refs/head/713/1
refs/changes/20/1220/1 refs/head/1220/1
refs/changes/20/1220/2 refs/head/1220/2
refs/changes/22/1222/1 refs/head/1222/1
As mentioned in the comments, you can just get the right git command from the gerrit GUI. If you really dislike GUIs, or you want to automate it (and for some reason can't use git-review), you can use the gerrit API:
curl -s 'https://<your gerrit server>/r/changes/<change id>?o=CURRENT_REVISION&o=DOWNLOAD_COMMANDS' | tail -n+2 | jq -r '.revisions[.current_revision].fetch["anonymous http"].commands.Pull' | bash -
or
git pull origin `curl -s 'https://<your gerrit server>/r/changes/<change id>?o=CURRENT_REVISION' | tail -n+2 | jq -r '.revisions[.current_revision].ref'`
I'd like to modify the dtc formula to build a specialized version of dtc used with the Beaglebone Black (and other device-tree ARM boards). The problem is multi-fold. The dtc formula provides bottled versions, and installed 1.4.0. I want to install a version that comes from newer sources, but not the absolute latest, and applies a patch available elsewhere. I can build this manually on OS X, but I don't know the best way to make it available in homebrew.
I'd like to make it a variant. Either an entirely separate formula, or something within the current formula that can be selected with a command-line parameter. But I'm not well-versed enough in brew to know how best to do this.
I tried creating new formula called "dtc-dyn" but it doesn't like dashes in the name.
I'd also like to make it a bottle, for others' convenience, but that seems more complicated.
I tried just modifying the current dtc and removing all the bottle stuff, then modifying the URL, version, and adding system steps. But some of the operations fail (that seem to work when run from the original build script):
def install
git_sha = "f6dbc6ca9618391e4f30c415a0a09b7af35f7647"
system "git checkout master -f"
system "git pull"
system "git checkout #{git_sha} -b #{git_sha}-build"
system "git pull --no-edit https://github.com/pantoniou/dtc dt-overlays5"
system "make clean"
system "make all"
end
Sadly, this doesn't work:
$ brew install dtc
==> Cloning git://git.kernel.org/pub/scm/utils/dtc/dtc.git
Updating /Library/Caches/Homebrew/dtc--git
==> Checking out branch master
==> git checkout master -f
==> git pull
==> git checkout f6dbc6ca9618391e4f30c415a0a09b7af35f7647 -b f6dbc6ca9618391e4f30c415a0a09b7af35f7647-build
2015-09-21 00:22:37 -0700
git checkout f6dbc6ca9618391e4f30c415a0a09b7af35f7647 -b f6dbc6ca9618391e4f30c415a0a09b7af35f7647-build
fatal: reference is not a tree: f6dbc6ca9618391e4f30c415a0a09b7af35f7647
READ THIS: https://git.io/brew-troubleshooting
The original script can be found here.
Anyway, what's the best way to approach this? I think some kind of with-option, based on some of the example scripts, but I'm not sure how to avoid the bottle business. Thanks!
Second Approach
Okay, after more doc reading and experimenting, I'm trying this:
class Dtc < Formula
desc "Device tree compiler"
homepage "http://www.devicetree.org/"
url "https://mirrors.kernel.org/debian/pool/main/d/device-tree-compiler/device-tree-compiler_1.4.0+dfsg.orig.tar.gz"
mirror "https://mirrors.ocf.berkeley.edu/debian/pool/main/d/device-tree-compiler/device-tree-compiler_1.4.0+dfsg.orig.tar.gz"
sha256 "f5f9a1aea478ee6dbcece8907fd4551058fe72fc2c2a7be972e3d0b7eec4fa43"
version "1.4.0"
option "with-symbols", "Add symbols/fixup support (-# option)."
bottle…
if build.with? "symbols"
url "http://git.kernel.org/pub/scm/utils/dtc/dtc.git", :revision => "f6dbc6ca9618391e4f30c415a0a09b7af35f7647"
system "git", "pull", "--no-edit", "https://github.com/pantoniou/dtc", "dt-overlays5"
end
def install
system "make"
system "make", "DESTDIR=#{prefix}", "PREFIX=", "install"
mv lib/"libfdt.dylib.1", lib/"libfdt.1.dylib"
end
end
Unfortunately, the git pull fails because it does that before cloning the git repo, and it's not in the right directory. I first considered patch do…, but it wasn't clear how to apply the patch via git pull. I tried this:
if build.with? "symbols"
url "http://git.kernel.org/pub/scm/utils/dtc/dtc.git", :revision => "f6dbc6ca9618391e4f30c415a0a09b7af35f7647"
patch do
system "git", "pull", "--no-edit", "https://github.com/pantoniou/dtc", "dt-overlays5"
end
end
But it still tries to do the git pull before cloning the repo and cding to it.
I encounter a problem about running some Git commands which contain white spaces in file names with Ruby, like:
aaa = "xxxxxxx/xxxx/BOM\ Explosion.txt"
`git update-index --assume-unchanged -- #{aaa}`
or
aaa = "xxxxxxx/xxxx/BOM Explosion.txt".shellescape
`git update-index --assume-unchanged -- #{aaa}`
I have tried either way above to escape space and run it in Git Bash, but neither of them work, with the error message:
fatal: Unable to mark file 'xxxxxxx/xxxx/BOM
Updated git index
Anyone have some ideas?
You can largely ignore escaping concerns if you specify parameters individually:
system("git", "update-index", "--assume-unchanged", "--", aaa)
This passes the arguments through directly without the shell interpreting them. This is the most reliable way to pass them through correctly.
I was trying to solve an issue with some gem conflicts, and I added all of my gems to vendor/cache, I have since removed them, but now I have a 40M pack file where it used to be less than 1M.
I have tried to filter the branch
git filter-branch --index-filter 'git rm -r --cached --ignore-unmatch vendor/cache' --prune-empty -- --all
This goes through a list of rm commands, for example:
rm 'vendor/cache/sass-3.2.8.gem'
and then at the end
Rewrite 9c90286ba515f46919e82e73e2c01a5db1762668 (202/202)
Ref 'refs/heads/master' was rewritten
Ref 'refs/remotes/origin/master' was rewritten
WARNING: Ref 'refs/remotes/origin/master' is unchanged
Finally I run
git gc --aggressive --expire=now
But I still have the same huge number of objects, and the pack file is still 40M. I even try forcing a push when this was complete with no change. Any idea how I can clean up my repository following this mistake?
I think you'll find the answer at the bottom of the question or in the accepted answer here:
Remove file from git repository (history)
The key is in that warning line you have:
WARNING: Ref 'refs/remotes/origin/master' is unchanged
The solution discusses how to get rid of that so that the other steps accomplish what you want and reduce the size back down.
I am using Ruby on Rails, the Capistrano gem and git. I would like to do not put anymore under version control some directories that until now I was tracking.
For my application I have a file system structure like the following:
...
.gitignore
/public/aaa/000/001
/public/aaa/000/002
/public/aaa/000/003
/public/aaa/000/...
To accomplish that I aim, I changed the .gitignore file and added to it the following lines:
# Ignoring "/public/aaa/*" directories
public/aaa/
However, if I check what directories are under version control, I see that those I would like to ignore are still tracked. So, when I deploy with Capistrano to the remote server the content of those directories is still changing.
How can I definitely ignore those directories?
In few words, what I would like to do is to do not change public/aaa directories and files on the remote machine (and, thus, to do not track those with git on my local machine) so that when I deploy with Capistrano those folders (on the remote machine) are untouched.
You'll need to remove them before they'll disappear from source control. They're still part of your git repo, so git is going to continue paying attention to them.
git rm -r --cached public/aaa
The -r tells git to remove the directory (just like rm -r in the console) and --cached tells git to leave the file(s), just remove it from the repo.
You could use git update-index --assume-unchanged <filename>. This will keep the files around, but will no longer track their changes.
You can do this recursively with
find ./folder/ -type f | xargs git update-index --assume-unchanged