-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
-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
-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?
Have you tried with --show-notes?
It works
-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
-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 would
-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
-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 ps...@ubuntu.com
wrote:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1
I made a shallow clone of my repo, then used git bundle create to
pack it all
-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 gits...@pobox.com
wrote:
The only way a bundle can record something noting that it is
an incomplete history, while allowing it to be read by existing
-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 use a
-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
-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's
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 03/31/2015 06:17 PM, Junio C Hamano wrote:
Phillip Susi ps...@ubuntu.com 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 the introdution
-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
-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,
-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, just
-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:
psusi
-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 the general case, because we have tests
-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
-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 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 missing file
-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
-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 work with
-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:
-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 seems
-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.17
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2/24/2014 3:19 PM, Junio C Hamano wrote:
Phillip Susi ps...@ubuntu.com 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 that a bug tracker mangles
-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
-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
way
-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
removal.
-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
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
-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,
the output gets an odd
-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
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 instance
-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
