Compare two diffs on the command line?

If you have a commit that exists on two branches, in gitk you can mark one, then select the other and choose to compare the two. This results in a diff of the two diffs, rather than a diff between the two trees, which include many other changes that have nothing to do with either commit. Is t

Re: Compare two diffs on the command line?

On 9/4/2015 2:10 PM, Junio C Hamano wrote: On Fri, Sep 4, 2015 at 11:00 AM, Phil Susi wrote: If you have a commit that exists on two branches, in gitk you can mark one, then select the other and choose to compare the two. This results in a diff of the two diffs, rather than a diff between the

git-repack keeps running out of memory

I keep having git-repack run out of virtual memory ( 32 bit system ) when trying to repack my linux kernel repo. It keeps making it right up to 99% then barfing saying mmap failed: Cannot allocate memory. I thought I could help this by limiting the pack size, and using --window-memory to limi

Re: git-repack keeps running out of memory

On 6/1/2015 2:43 PM, Junio C Hamano wrote: Phil Susi writes: I keep having git-repack run out of virtual memory ( 32 bit system ) when trying to repack my linux kernel repo. It keeps making it right up to 99% then barfing saying mmap failed: Cannot allocate memory. I thought I could help

Merge after rename

I'm trying to cherry pick an old change from an old branch onto the current master, and since the old change, the directory structure was altered and the modified files were moved. Instead of detecting the new location of the file and applying the changes to it, git is re-adding the old file a

git checkout --theirs fails

I'm doing a rebase and got some conflicts. I just want to take their version of all files, but git checkout --theirs complains: --ours/--theirs' cannot be used with switching branches What gives? I'm not *trying* to switch branches. I just want to resolve the conflict by taking their version.

Re: git checkout --theirs fails

On 3/15/2016 5:47 PM, Junio C Hamano wrote: > would fail when the path file/name is unmerged and does not have > stage #3 entry, wouldn't it? So with ".", unless all paths that > match that pathspec (i.e. all available files) are either merged > (i.e. without conflict) or have stage #3 entry, it i

What happened to having to recover from upstream rebase?

So it used to be that when upstream rebased, you'd get an error when you tried to pull again and have to fix things up with some git reset or rebase hackery. Trying to demo this today I found that the pull *worked*, using an automatic recursive merge. Am I crazy in thinking this used to error