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 is expected that > the command would fail consistently to the case where a pathspec > "file/name" that happens to match only one path is given, and that > is the behaviour Phil saw, I would think. Right... why is this though? Why doesn't it just check out those files that *do* have a #3 entry? And also why the nonsense about switching branches when you don't specify any path or branch? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. If I try git checkout --theirs ., then it complains that not every single file in the directory has a "their" version. So? Take the ones that do. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 <ps...@ubuntu.com> 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 two trees, which include many other changes that have nothing to do with either commit. I think you are looking for the interdiff(1) tool. Yes, that is how I would do it before git... I was thinking there would be a git way of doing it, especially since it is there in gitk. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 there a way to do this on the command line? I thought it would be git diff -c or --cc, but it doesn't seem to filter out all of the other differences between the branches. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 at the old location in its entirety. How can I get it to correctly notice the rename and merge the changes in at the file's new location? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 limit the memory usage, but it still happens with this full command line: git repack -a -d --max-pack-size=500m -f -F --depth=20 --window=250 --window-memory=500m The key factor seems to be the --window... with 50 it works fine, but with 100 or more, even with the very low --window-memory limit, it crashes. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git-repack keeps running out of memory
On 6/1/2015 2:43 PM, Junio C Hamano wrote: Phil Susi ps...@ubuntu.com 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 this by limiting the pack size, and using --window-memory to limit the memory usage, but it still happens with this full command line: git repack -a -d --max-pack-size=500m -f -F --depth=20 --window=250 --window-memory=500m The key factor seems to be the --window... with 50 it works fine, but with 100 or more, even with the very low --window-memory limit, it crashes. Unfortunately, that is totally expected. Window tells us to keep enough information to compare with that many objects in-core. I do not think max-pack-size would affect much. It's more the --window-memory argument that is important here: it is supposed to prevent exactly this problem. I guess I tried adding the --max-pack-size as well on the off chance that it would help. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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, and if not, when did it change? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
