-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 06/01/2015 04:58 PM, Jeff King wrote:
> How many processors do you have? The window-memory is per-thread.
> Try with --threads=1.
Ahh, right... 8... that explains it ;)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQEcBAEBCgAGBQJVbPMBAAoJEN
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
After doing a rebase -i to fix up some older commits, I noticed that
notes I had associated with commits failed to follow the commit across
the rebase, so the notes are now orphaned and will be pruned.
Shouldn't notes be copied to the new commit during
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 4/7/2015 10:13 AM, Michael J Gruber wrote:
> Seriously: gitk knows F5 and Shift-F5 for refresh, and I think the
> latter is the thorougher refreshment.
Neither one makes newly added notes show up. The only way seems to be
to close and restart git
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 4/7/2015 9:40 AM, Michael J Gruber wrote:
> Phillip Susi venit, vidit, dixit 02.04.2015 21:34:
>> I can't seem to get gitk to show notes, even when I give it
>> --notes. Does it just not handle notes?
>>
>>
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 4/5/2015 10:15 PM, Shane da Silva wrote:
> I’m trying to wrap my head around why this is the current behavior,
> as I suspect this is intentional but it seems unexpected. If anyone
> can shed any light on this, I would really appreciate it!
Why wou
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I can't seem to get gitk to show notes, even when I give it --notes.
Does it just not handle notes?
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)
iQEcBAEBAgAGBQJVHZm5AAoJENRVrw2cjl5RT0wIAJVfE2cDQODUCoOsIwhVDiMf
CNeTKy1VxCgwVy8KDoYxY2
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 04/01/2015 08:33 PM, Duy Nguyen wrote:
> OK two additional options on top of what we already have:
>
> - save .have and add extra prerequisite SHA-1. - create a bundle
> that does not hit shallow boundary in the first place, roughly
> speaking it
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 4/1/2015 9:36 AM, Duy Nguyen wrote:
> Thank you. I can reproduce it now. We need to plug this hole.
I'd much rather it not refuse to clone so that I can end up with a
proper shallow clone. At least the way it is now, when I clone the
detached head
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 4/1/2015 9:09 AM, Duy Nguyen wrote:
>> Strange; it works fine for me using git 1.9.4.msysgit.1, and then
>> I just get the complaints from gitk. I created the bundle with
>> no prereq argument, i.e. "git bundle create shallow.bundle". Did
>> you u
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 4/1/2015 6:01 AM, Duy Nguyen wrote:
> On Wed, Apr 1, 2015 at 1:31 PM, Junio C Hamano
> wrote:
>> The only way a bundle can record "something" "noting" that it is
>> an incomplete history, while allowing it to be read by existing
>> implementations
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 4/1/2015 5:55 AM, Duy Nguyen wrote:
> On Wed, Apr 1, 2015 at 4:10 AM, Phillip Susi
> wrote:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>>
>> I made a shallow clone of my repo, then used git bundle create to
>>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 03/31/2015 06:17 PM, Junio C Hamano wrote:
> Phillip Susi writes:
>
>> I made a shallow clone of my repo, then used git bundle create to
>> pack it all into a bundle file, then cloned from that bundle.
>
> I think th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I made a shallow clone of my repo, then used git bundle create to pack
it all into a bundle file, then cloned from that bundle. The initial
shallow clone has a .git/shallow file that identifies it as a shallow
clone ( and I guess keeps things from com
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Why does gitk -g master not work? I would expect gitk to load up the
master branch reflog and show each of the previous heads that master
has transitioned through, but it doesn't. Instead I have to run gitk
master@{1} master@{2}, etc, and then, whi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I'm trying to import a git log into a spreadsheet. I used a simple
- --pretty=format: switch to select the fields I wanted and separate
them with commas to generate a CSV file that can be imported. The
message body, however, is presenting a problem.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 6/13/2014 3:34 AM, Jeff King wrote:
> Thanks for saving the stuck state.
>
> If it's possible to share the whole repo, it might be worth seeing
> (then we can all just run "git rebase --continue" ourselves). If
> it's too big or is confidential, ju
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 06/12/2014 09:02 PM, brian m. carlson wrote:
> On Thu, Jun 12, 2014 at 05:01:16PM -0400, Phillip Susi wrote:
>> So nobody has any ideas on what to check for or how to debug
>> this?
>
> I'm assuming this works in th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
So nobody has any ideas on what to check for or how to debug this?
On 6/10/2014 2:57 PM, Phillip Susi wrote:
> I'm in the middle of a long rebase and have had no trouble with
> git rebase --skip several times, but now it has become stuck:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I'm in the middle of a long rebase and have had no trouble with git rebase
--skip several times, but now it has become stuck:
psusi@devserv:~/parted.git$ git rebase --skip
Auto-merging libparted/arch/linux.c
CONFLICT (content): Merge conflict in lib
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I have seen some discussion about various changes to the format of the
index and pack files over time, but can't find anything about it in
the man pages. Are the different formats documented anywhere, and how
to tell which format you are using?
-
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 3/5/2014 12:13 PM, Jeff King wrote:
> We apply the changes to "modified" and "new" to the working tree,
> but we do not stage anything in the index. I suspect this is
> because our invocation of "apply --index" (which is what is doing
> the real wor
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 3/5/2014 11:34 AM, Jeff King wrote:
> I don't think those steps are necessary for Chris's example. When
> he switches back to the master branch, git removes the subdirectory
> (the file is tracked in "temp" but not "master", so we remove it
> when s
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 3/5/2014 3:10 AM, Chris Packham wrote:
> My example is creating a commit on the "temp" branch then applying
> it to the "master" branch using git am.
>
>> Do a reset HEAD~1 --hard, and git clean -x -f -d before git am.
>> I didn't notice the missin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 03/04/2014 10:08 PM, Chris Packham wrote:
> Could you provide a few more details such as your git version (git
> --version) and an example of the failure. I've tried to reproduce
> the problem based on the description provided but everything seem
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
I applied a patch with git am that adds a new source file to a new
directory, and later noticed that file was missing from the commit.
It seems that git am fails to add the new file/directory to the index.
-BEGIN PGP SIGNATURE-
Version: GnuP
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2/24/2014 3:19 PM, Junio C Hamano wrote:
> Phillip Susi writes:
>
>> git am already ignores the "[PATCH X/Y]" prefix that
>> format-patch adds. Is it possible to get it to ignore any
>> additional prefix t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
git am already ignores the "[PATCH X/Y]" prefix that format-patch
adds. Is it possible to get it to ignore any additional prefix that a
bug tracker mangles into the subject line? i.e. "bug #:"?
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.1
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 11/25/2013 10:13 PM, Duy Nguyen wrote:
> There's a difference between "skip commits that touch anything
> directory foo even if it also touches something outside of foo" and
> "skip commits that _only_ touches something in foo". Not sure which
> w
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I can't seem to find a way to invert the meaning of a pathspec given
to git log in order to find commits touching anything BUT a given
path. Does such a thing exist?
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG w
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/17/2013 5:14 PM, Junio C Hamano wrote:
> Correct.
>
> Without inspecting them, you would not know what you would be
> losing by blindly resolving to removal, hence we do not
> auto-resolve "one side removed, the other side changed" to a
> remova
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I have a commit I am trying to cherry pick that removes a number of
files. It seems to generate conflicts for those files that have been
modified on this branch since the common ancestor. Since they are
being removed, I don't care about what changes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Of course! Thanks, now it completely makes sense.
On 07/09/2013 03:41 PM, Jeff King wrote:
> On Tue, Jul 09, 2013 at 02:28:32PM -0400, Phillip Susi wrote:
>
>> When I try to look at a color diff of a file using dos newlines,
>>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
When I try to look at a color diff of a file using dos newlines, the
output gets an odd sequence of ansi escapes and a stray carriage
return showing up only on the + lines, but not the -. The normal
looking - lines look like this:
\r\n ( from previou
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/08/2013 05:42 PM, Junio C Hamano wrote:
> It is very easy to miss misidentification of scissors line; as a
> dangerous, potentially information losing option, I do not think
> it should be on by default.
I suppose if it only requires one instan
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I was wondering why am's scissors option is not enabled by default.
It seems a very handy feature, but I'm reluctant to use it when
sending patches because the recipient has to notice the scissors and
remember to pass --scissors to git am.
Could this
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I have not had any issue until I ran a git fsck recently, which
repored gzip and crc errors in some pack files. git fsck does not
seem to repair the errors, only report them. I would like to try to
rebuild my repository, without downloading any more
36 matches
Mail list logo
