[BUG] git stash doesn't use --index as default

the --index) Made this super clear. #git agrees this is a bug, if only a UI default bug. Pretty serious though. Cheers, James PS: please cc me on replies, as I'm not subscribed to list. signature.asc Description: This is a digitally signed message part

[PATCH] Add --recursive flag to git bash completion script.

This is a patch to add a much needed option to the bash completion script. I'm not subscribed to this list, so please include me in your reply if you'd like me to see your response. Thanks, James From ca976de5bfeccc9bd69c22183f82b9d1e59d2547 Mon Sep 17 00:00:00 2001 From: James Shubin ja

[PATCH v2 2/2] clean: new option --exclude-from

From: James Rouzier <rouz...@gmail.com> Specify a file to read for exclude patterns. --- Documentation/git-clean.txt | 5 +++- builtin/clean.c | 15 ++-- t/t7300-clean.sh| 60 + 3 files changed, 77 insertions

[PATCH v2 1/2] modernize t7300

From: James Rouzier <rouz...@gmail.com> --- t/t7300-clean.sh | 382 +++ 1 file changed, 190 insertions(+), 192 deletions(-) diff --git a/t/t7300-clean.sh b/t/t7300-clean.sh index 86ceb38..d555bb6 100755 --- a/t/t7300-clean.sh +++ b/t

[PATCH] clean: new option --exclude-from

From: James Rouzier <rouz...@gmail.com> Specify a file to read for exclude patterns. --- Documentation/git-clean.txt | 5 - builtin/clean.c | 15 ++- t/t7300-clean.sh| 35 +++ 3 files changed, 53 insertions(+), 2 del

[PATCH] Add --recursive flag to git bash completion script.

Patch attached! Cheers, JamesFrom f7feb714a7ec703b97552e343d5f4ce541ffb7a1 Mon Sep 17 00:00:00 2001 From: James Shubin <ja...@shubin.ca> Date: Sun, 8 Mar 2015 19:57:17 -0400 Subject: [PATCH] Add --recursive flag to git bash completion script. This flag was missing from the list, and

Re: What is missing from Git v2.0

is that those specific power-users don't know to use aliases. -- James Denholm -- 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: What is missing from Git v2.0

-acceptable example, consider the rejection of Galileo's astronomical research by the Vatican of the time.) Just because Mercurial et. all does something doesn't mean git needs to, or even should. It needs objective consideration, not to just be ushered through on the basis of tradition. -- James

Re: [PATCH] subtree/Makefile: Standardize (esp. for packagers)

the proposal into a series as you suggest. Thanks for the advice! Regards, James Denholm. -- 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: [PATCH] subtree/Makefile: Standardize (esp. for packagers)

Jeff King p...@peff.net wrote: On Sun, Apr 27, 2014 at 12:35:13PM +1000, James Denholm wrote: Do we even make [subproject and mainline] anymore? It looks like they are part of the tests, but the whole test script runs inside its own trash directory. subproject and mainline are actually made

Re: Recording the current branch on each commit?

to. (Arguably, though, the better solution is to use a ticketing system, or anything that allows discussion to be easily referenced.) Regards, James Denholm. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info

Re: Recording the current branch on each commit?

Jeremy Morton ad...@game-point.net wrote: On 27/04/2014 22:40, James Denholm wrote: Also, you don't always have something you can link a commit to in an issue tracker. You may just be implementing a feature that has been agreed upon, independently of any such tracker. In that case, there's

Re: Recording the current branch on each commit?

Felipe Contreras felipe.contre...@gmail.com wrote: David Kastrup wrote: It becomes easier to actually change things when communicating in a less abrasive and destructive manner. That would make sense if I was the only one with the itch. But I wasn't the only one, so anybody could take the

Re: Recording the current branch on each commit?

Felipe Contreras felipe.contre...@gmail.com wrote: James Denholm wrote: It's not anybody else's job to take your patches and drizzle them in the honey of respectable discourse. It's nobody's job to do anything. This a collaborative effort and in a collaborative effort everbody chimes

Re: Recording the current branch on each commit?

On 29 April 2014 13:32:29 GMT+10:00, Felipe Contreras felipe.contre...@gmail.com wrote: James Denholm wrote: No, true, but my point was more related to that it's ones own task, perhaps being the better term than job, to debate the merits of one's own work when the merits are currently unknown

Re: Recording the current branch on each commit?

I've no right to say this, given that I've no contributions thus far to the project, little history in open source at all, and have only been following the list for less than a week, but I'll say it anyway, mayhaps. And I don't mean this to cause offence, or inspire outrage, or any similar sort

Re: Recording the current branch on each commit?

On 29 April 2014 21:47:42 GMT+10:00, Felipe Contreras felipe.contre...@gmail.com wrote: James Denholm wrote: I've no right to say this, given that I've no contributions I'm not saying that you shouldn't work on the git codebase, you could very easily fork it and make the innovative SCMS none

Re: Recording the current branch on each commit?

On 29 April 2014 23:31:29 GMT+10:00, Felipe Contreras felipe.contre...@gmail.com wrote: James Denholm wrote: So that we can all have egg on our faces when it takes off and is proven superior... Right? I don't know what you mean by we, but it certainly doesn't include you. % git log --author

Re: Recording the current branch on each commit?

On 30 April 2014 07:45:37 GMT+10:00, Felipe Contreras felipe.contre...@gmail.com wrote: James Denholm wrote: On 29 April 2014 23:31:29 GMT+10:00, Felipe Contreras felipe.contre...@gmail.com wrote: James Denholm wrote: So that we can all have egg on our faces when it takes off and is proven

Re: Recording the current branch on each commit?

Felipe Contreras wrote: James Denholm wrote: Either way your analogy is completely wrong as I already explained multiple times. I'm not trying to convince vegetarians to go hunting, I'm saying they should eat something, bread, meat, vegetables, anything. Instead they choose to starve

Re: Recording the current branch on each commit?

the argument needed to back your proposals? Regards, James Denholm. -- 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

[PATCH v2 0/5] contrib/subtree/Makefile: Standardisation pass

-scripts. Signed-off-by: James Denholm nod.h...@gmail.com Based-on-patch-by: Dan McGee dpmc...@gmail.com James Denholm (5): contrib/subtree/Makefile: scrap unused $(gitdir) contrib/subtree/Makefile: Use GIT-VERSION-FILE contrib/subtree/Makefile: s/libexecdir/gitexecdir contrib/subtree/Makefile

[PATCH v2 5/5] contrib/subtree/Makefile: clean rule cleanup

test. Hence, remove the rm call for those folders. Other makefiles don't remove *~ files, remove the rm call to prevent unexpected behaviour in the future. Similarly, clean doesn't remove the installable file, so rectify this. Signed-off-by: James Denholm nod.h...@gmail.com --- Admittedly

[PATCH v2 1/5] contrib/subtree/Makefile: scrap unused $(gitdir)

All references were removed in 7ff8463dba0d74fc07a766bed457ae7afcc902b5, but the assignment itself wasn't. Hence, drop gitdir assignment. Signed-off-by: James Denholm nod.h...@gmail.com --- contrib/subtree/Makefile | 1 - 1 file changed, 1 deletion(-) diff --git a/contrib/subtree/Makefile b

[PATCH v2 2/5] contrib/subtree/Makefile: Use GIT-VERSION-FILE

GVF is already being used in most/all other makefiles in the project, and has been for _quite_ a while. Hence, drop file-unique gitver and replace with GIT_VERSION. Signed-off-by: James Denholm nod.h...@gmail.com --- contrib/subtree/Makefile | 11 --- 1 file changed, 8 insertions(+), 3

[PATCH v2 4/5] contrib/subtree/Makefile: Doc-gen rules cleanup

MANPAGE_NORMAL_XSL with MANPAGE_XSL. Signed-off-by: James Denholm nod.h...@gmail.com --- contrib/subtree/Makefile | 13 - 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/contrib/subtree/Makefile b/contrib/subtree/Makefile index 579bb51..f3834b5 100644 --- a/contrib/subtree

[PATCH v2 3/5] contrib/subtree/Makefile: s/libexecdir/gitexecdir

$(libexecdir) isn't used anywhere else in the project, while $(gitexecdir) is the standard in the other appropriate makefiles. Hence, replace the former with the latter. Signed-off-by: James Denholm nod.h...@gmail.com --- contrib/subtree/Makefile | 6 +++--- 1 file changed, 3 insertions(+), 3

Re: [PATCH] subtree/Makefile: Standardize (esp. for packagers)

Matthew Ogilvie mmogilvi_...@miniinfo.net wrote: On Sun, Apr 27, 2014 at 12:35:13PM +1000, James Denholm wrote: Jeff King p...@peff.net wrote: Agreed. It also doesn't help that when subtree patches are proposed (especially new features instead of obvious bugs), there often seems to be little

Re: [PATCH] subtree/Makefile: Standardize (esp. for packagers)

to be a special snowflake. 'sall good, the v2 addresses most of my immediate concerns with it. Regards, James Denholm. -- 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: Pull is Mostly Evil

James Denholm` at one point to demonstrate that I had not yet made any contributions,instead of actually engaging in discussion. Oh, wait. If their argument is good, their argument is good. The problem, though, is that time and time again you've shown that you value your own arguments

Re: Pull is Mostly Evil

On 4 May 2014 19:51:09 GMT+10:00, Felipe Contreras felipe.contre...@gmail.com wrote: James Denholm wrote: Felipe Contreras wrote: David Lang wrote: the vast majority of people here do not take that attitude. It's actually the exact opposite. I don't care what is the track record

Re: [PATCH 1/9] Define a structure for object IDs.

, but an object of that internal type can't necessarily pretend to be a wrapper. That said, obviously I'm not David, so I could be wrong. That's what I got from his statement, though. Regards, James Denholm. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message

Re: [PATCH v2 5/5] contrib/subtree/Makefile: clean rule cleanup

On 5 May 2014 15:09:39 GMT+10:00, Jeff King p...@peff.net wrote: On Sat, May 03, 2014 at 10:49:35PM +1000, James Denholm wrote: diff --git a/contrib/subtree/Makefile b/contrib/subtree/Makefile index f3834b5..4f96a24 100644 --- a/contrib/subtree/Makefile +++ b/contrib/subtree/Makefile

Re: [PATCH v2 0/5] contrib/subtree/Makefile: Standardisation pass

On 5 May 2014 15:08:04 GMT+10:00, Jeff King p...@peff.net wrote: On Sat, May 03, 2014 at 10:49:30PM +1000, James Denholm wrote: The main issues are that calls are made to git itself in the build process, and that a subtree-exclusive variable is used for specifying the exec path. Patches 1/5

Re: [PATCH v2 5/5] contrib/subtree/Makefile: clean rule cleanup

On 6 May 2014 07:49:30 GMT+10:00, Jeff King p...@peff.net wrote: On Tue, May 06, 2014 at 07:41:29AM +1000, James Denholm wrote: I do not think BSD-ism matters for rm, as it works pretty much the same everywhere. install, on the other hand, is a bit weirder between systems. So you might want

Re: [PATCH v2 0/5] contrib/subtree/Makefile: Standardisation pass

On 6 May 2014 08:01, Jeff King p...@peff.net wrote: [fixed David's address in cc list] Ah, right. Wasn't sure what was going on there. On Tue, May 06, 2014 at 07:54:30AM +1000, James Denholm wrote: Given that subtree subtree doesn't really generate a lot of discussion, would it be advisable

[PATCH v2 5/5] contrib/subtree/Makefile: clean rule cleanup

test. Hence, remove the rm call for those folders. Other makefiles don't remove *~ files, remove the rm call to prevent unexpected behaviour in the future. Similarly, clean doesn't remove the installable file, so rectify this. Reviewed-by: Jeff King p...@peff.net Signed-off-by: James Denholm

[PATCH v2 2/5] contrib/subtree/Makefile: Use GIT-VERSION-FILE

GVF is already being used in most/all other makefiles in the project, and has been for _quite_ a while. Hence, drop file-unique gitver and replace with GIT_VERSION. Reviewed-by: Jeff King p...@peff.net Signed-off-by: James Denholm nod.h...@gmail.com --- contrib/subtree/Makefile | 11

[PATCH v2 3/5] contrib/subtree/Makefile: s/libexecdir/gitexecdir

$(libexecdir) isn't used anywhere else in the project, while $(gitexecdir) is the standard in the other appropriate makefiles. Hence, replace the former with the latter. Reviewed-by: Jeff King p...@peff.net Signed-off-by: James Denholm nod.h...@gmail.com --- contrib/subtree/Makefile | 6

[PATCH v2 4/5] contrib/subtree/Makefile: Doc-gen rules cleanup

MANPAGE_NORMAL_XSL with MANPAGE_XSL. Reviewed-by: Jeff King p...@peff.net Signed-off-by: James Denholm nod.h...@gmail.com --- contrib/subtree/Makefile | 13 - 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/contrib/subtree/Makefile b/contrib/subtree/Makefile index 579bb51

[PATCH v2 0/5] contrib/subtree/Makefile: Standardisation pass

-scripts. Reviewed-by: Jeff King p...@peff.net Signed-off-by: James Denholm nod.h...@gmail.com Based-on-patch-by: Dan McGee dpmc...@gmail.com James Denholm (5): contrib/subtree/Makefile: scrap unused $(gitdir) contrib/subtree/Makefile: Use GIT-VERSION-FILE contrib/subtree/Makefile: s/libexecdir

[PATCH v2 1/5] contrib/subtree/Makefile: scrap unused $(gitdir)

In 7ff8463dba0d74fc07a766bed457ae7afcc902b5, the references to gitdir were removed but the assignment itself wasn't. Hence, drop the gitdir assignment. Reviewed-by: Jeff King p...@peff.net Signed-off-by: James Denholm nod.h...@gmail.com --- contrib/subtree/Makefile | 1 - 1 file changed, 1

Re: [PATCH v2 0/5] contrib/subtree/Makefile: Standardisation pass

, noticing you posted something new, and not finding v3. Ah, right. I thought that resending a post-discussion patch was the done thing, given Documentation/SubmittingPatches, but that a comment line might not have been worth a version bump. Will queue. Thanks. Awesome, thanks. Regards, James

Re: [PATCH] Standardize python shebangs

is already non-sane, let's please not make it more so? Moving all instances of env python to be env python2, though, that I think is a reasonable solution (if this is even felt to be a problem). Regards, James Denholm. -- To unsubscribe from this list: send the line unsubscribe git in the body

Re: [PATCH] contrib/subtree bugfix: Crash if FETCH_HEAD is tag

On 4 May 2014 16:33:32 GMT+10:00, James Denholm nod.h...@gmail.com wrote: cmd_add_commit() is passed FETCH_HEAD by cmd_add_repository, which is then rev-parsed into an object ID. However, if the user is fetching a tag rather than a branch HEAD, such as by executing: $ git subtree add -P oldGit

Re: [PATCH] Standardize python shebangs

on python2 already, and hence we know that the user has python2, and these scripts run perfectly well on python2, why not mandate that the agnostic subset be run on python2? Regards, James Denholm. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord

Re: [PATCH] contrib/subtree bugfix: Crash if FETCH_HEAD is tag

After a closer look, it seems the initial patch wasn't correctly sent to the list. Please disregard, I'm re-sending the patch entirely. Regards, James Denholm. On 8 May 2014 07:53, James Denholm nod.h...@gmail.com wrote: On 4 May 2014 16:33:32 GMT+10:00, James Denholm nod.h...@gmail.com wrote

[PATCH] contrib/subtree bugfix: Can't `add` annotated tag

(), from git:git-sh-setup.sh Reported-by: Kevin Cagle kca...@micron.com Diagnosed-by: Junio C Hamano gits...@pobox.com Signed-off-by: James Denholm nod.h...@gmail.com --- NB: This bug doesn't surface when using --squash, as $rev is reassigned to the squash commit via new_squash_commit before git commit

Re: [PATCH 0/4] remote-hg: more improvements

Felipe, I would ask, suggest, beg, implore you to calm down. It's generally not a good plan to alienate the maintainer of a project, regardless of the correctness or incorrectness of one's arguments, but I fear that's only what you will achieve at the moment. -- Regards, James Denholm

Re: [PATCH] contrib/subtree bugfix: Can't `add` annotated tag

Junio C Hamano gits...@pobox.com wrote: The rev (not revs) seems to be used by more things than the final commit-tree state. Are we losing some useful information by peeling it too early like this patch does? (...) You're not wrong, actually, peeling at the last minute (or at least later)

Re: [PATCH v1 23/25] contrib: remove 'hooks/multimail'

with you if you don't let them descend to your level? Regards, James Denholm. -- 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: [PATCH] contrib/subtree bugfix: Can't `add` annotated tag

On Fri, May 09, 2014 at 05:36:15PM +1000, James Denholm wrote: Junio C Hamano gits...@pobox.com wrote: Would it be sufficient to do git commit-tree $tree $headp -p $rev^0 in that not squashing codepath instead? On line 561, sure. Do you want me to do a re-roll? Sorry to bump

[PATCH v2] contrib/subtree bugfix: Can't `add` annotated tag

(), from git:git-sh-setup.sh, pre-existing dependency of git-subtree. Reported-by: Kevin Cagle kca...@micron.com Helped-by: Junio C Hamano gits...@pobox.com Signed-off-by: James Denholm nod.h...@gmail.com --- I felt that defining revp would be a little more self-documenting than using $rev^0. contrib

Re: [PATCH v2] contrib/subtree bugfix: Can't `add` annotated tag

On Tue, May 13, 2014 at 12:34:13PM -0700, Junio C Hamano wrote: James Denholm nod.h...@gmail.com writes: I felt that defining revp would be a little more self-documenting than using $rev^0. That is a good decision, but as long as we are attempting to peel, don't we want to stop the damage

Re: [PATCH v2] contrib/subtree bugfix: Can't `add` annotated tag

On Tue, May 13, 2014 at 04:12:56PM -0700, Junio C Hamano wrote: James Denholm nod.h...@gmail.com writes: I'm not sure that can actually happen - peel_committish is essentially implemented as `rev-parse $arg^0` (though with a bit of bling, of course), and to my understanding FETCH_HEAD

Re: [PATCH v2] contrib/subtree bugfix: Can't `add` annotated tag

). Hence, working out a way to determine tag types, possibly before doing the fetch somehow, would be a boon to that methinks. Of course, this is something I haven't yet thought enough about and the idea is likely full of holes, but hey, I'm nothing if not impractically idealist. --- Regards, James

Re: [PATCH] remote-helpers: point at their upstream repositories

Felipe Contreras wrote: James Denholm wrote: On Fri, May 16, 2014 at 05:39:42PM -0500, Felipe Contreras wrote: (...) I would venture to say you have never made a package in your life. And you have, Felipe? Let us see the years of experience you surely have in the field

RE: Admin Alert

From: Tidwell, James Sent: Monday, August 18, 2014 4:45 AM To: Tidwell, James Subject: Admin Alert Help desk will undergo unscheduled system maintenance today in order to improve your account. The new Microsoft Outlook Web-access 2014 which will be installed

Re: [PATCH v2] unblock and unignore SIGPIPE

Today I learned that software can be constipated. On Thu, Sep 18, 2014 at 12:35 PM, Junio C Hamano gits...@pobox.com wrote: Thanks! -- 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

Can you git clone -partial? I am looking to make a mobile app and it would be nice to have.

to keep the projects .git in order to maintain consistency, or would you? I'm going to do some more research about what .git does exactly. Cheers, James -- 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

Re: Can you git clone -partial? I am looking to make a mobile app and it would be nice to have.

. Where does the compression happen? Cheers, James On Thu, Oct 2, 2014 at 1:38 AM, Junio C Hamano gits...@pobox.com wrote: James Hancock ja...@bookstobrains.com writes: i am thinking about developing an app and I want to integrate it with git but I only want to store a portion of the file

Re: [PATCH] Add --unannotate option to git-subtree

On Tue, Oct 9, 2012 at 4:26 PM, James Nylen jny...@gmail.com wrote: This new option does the reverse of --annotate, which is more useful when contributing back to a library which is also included in the repository for a larger project, and perhaps in other situations as well. Rather than

Re: Subtree in Git

On Fri, Oct 26, 2012 at 9:58 AM, David Michael Barr b...@rr-dav.id.au wrote: From a quick survey, it appears there are no more than 55 patches squashed into the submitted patch. As I have an interest in git-subtree for maintaining the out-of-tree version of vcs-svn/ and a desire to improve my

Re: Wrap commit messages on `git commit -m`

On Thu, Nov 1, 2012 at 2:12 PM, Thomas Adam tho...@xteddy.org wrote: Hi, On 1 November 2012 16:07, Ramkumar Ramachandra artag...@gmail.com wrote: Hi, Some of my colleagues are lazy to fire up an editor and write proper commit messages- they often write one-liners using `git commit -m`.

Re: [PATCH] Add --unannotate option to git-subtree

On Mon, Dec 31, 2012 at 8:15 PM, gree...@obbligato.org wrote: James Nylen jny...@gmail.com writes: Rather than adding a marker to each commit when splitting out the commits back to the subproject, --unannotate removes the specified string (or bash glob pattern) from the beginning

Re: [PATCH 2/8] Add --unannotate

On Tue, Jan 1, 2013 at 5:31 PM, gree...@obbligato.org wrote: Junio C Hamano gits...@pobox.com writes: David A. Greene gree...@obbligato.org writes: From: James Nylen jny...@gmail.com Teach git-subtree about --unannotate. This option strips a prefix from a commit message when doing

Re: [PATCH 13/13] contrib/subtree: Remove --annotate

On Tue, Feb 5, 2013 at 6:44 AM, gree...@obbligato.org wrote: Junio C Hamano gits...@pobox.com writes: Remove --annotate. This obviates the need for an --unannotate command. We really want a more generalized commit message rewrite mechanism. That may be a good goal as the end result, but

Re: [PATCH 13/13] contrib/subtree: Remove --annotate

On Mon, Feb 18, 2013 at 1:39 PM, gree...@obbligato.org wrote: James Nylen jny...@gmail.com writes: - add fancylib as a subtree of myprog - commit to myprog repo: fancylib: don't crash as much - split these commits back out to fancylib main repo, and remove the fancylib: prefix Should

Re: feature request

On Mon, Feb 18, 2013 at 1:52 PM, Jay Townsend townsend...@hotmail.com wrote: Hi everyone, Just would like to request a security feature to help secure peoples github accounts more by supporting 2 factor authentication like the yubikey more information can be found from this link

running git from non-standard location on Mac

I need to use -exec-path=/MyPathToGit/libexec/git-core? How do I change the content of @INC? Apologies if this is a dumb question, I'm not much of a unix man. Cheers, James -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More

RE: running git from non-standard location on Mac

-Original Message- From: Konstantin Khomoutov [mailto:flatw...@users.sourceforge.net] Sent: 21 February 2013 10:35 To: James French Cc: git@vger.kernel.org Subject: Re: running git from non-standard location on Mac On Thu, 21 Feb 2013 09:48:36 + James French james.fre

Re: SCSI trees, merges and git status

against BK Sorry for the screw up. James or at least that's what they claim in their changelogs. Oh, and here's the diffstat that matches scsi: drivers/block/scsi_ioctl.c |5 - drivers/s390/scsi/zfcp_aux.c |4 - drivers/s390/scsi/zfcp_def.h

Re: SCSI trees, merges and git status

:^\(..\):.git/objects/\1/:'|xargs rm removes all the objects from the tree prior to the bogus commit---it's based on your (Linus') git-prune-script. James - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http

GIT overlay repositories

, or merge the functionality into cogito (or wherever) great. I have a tree currently up that demonstrates the above in use. You can access it via: git-grab-overlay rsync://bughost.org/repos/ipw-delta/.git/ ipw-dev/ James #!/usr/bin/env bash # Copyright (c) 2005, Intel Corporation, James

Re: Getting list of changed objects...

as a set of boundaries. Thanks, James - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: cg update failing

Darrin == Darrin Thompson [EMAIL PROTECTED] writes: JimC cg-merge: merge blocked: seeked from master ` Darrin cg-seek master ? :; cg seek master On commit 514fd7fd01d378a7b5584c657d9807fc28f22079 -JimC - To unsubscribe from this list: send the line unsubscribe git in the body of a message

Re: cg update failing

Darrin == Darrin Thompson [EMAIL PROTECTED] writes: Darrin Now your merge should not be blocked. No? I figured out what you meant after I sent that first reply, but waited for update to finish to be sure it worked before replying again. It took about thirty minutes, and claimed that I had

Re: cg update failing

Well, it wasn't as Ok as I first thought. There were several .rej and backup files as left behind by patch(1). cg update HEAD says: Branch already fully merged but Makefile still says 2.6.12. I'm cloning now to a remote uml and will try and rsync from there to the laptop. Perhaps *that* will

Re: cg update failing

to seek to that tag to see the new versions of the files. But obviously that was long enough before hg’s repo broke that I’d forgotten how I’d done that I forget what version I started with. I’ve been tracking gentoo’s ebuild since it entered portage. -JimC -- James H. Cloos, Jr. [EMAIL

[PATCH] cogito -- add -c $commit support

, which was already used in cg-commit for something else. Signed-off-by: James Ketrenos [EMAIL PROTECTED] --- cg-commit | 46 +- 1 files changed, 45 insertions(+), 1 deletions(-) b07037397659763271e946fc15c0b3c61a8fcdfa diff --git a/cg-commit b/cg

RFE: support change-id generation natively

to cheer for a change-id champion; I suspect there are some out there who might rally to this cause. Thanks for your consideration. James Moger gitblit.com [1] https://git.eclipse.org/c/jgit/jgit.git/tree/org.eclipse.jgit/src/org/eclipse/jgit/api/CommitCommand.java?h=stable-3.1#n288 [2] http

Re: RFE: support change-id generation natively

there are some out there who might rally to this cause. Thanks for your consideration. James Moger gitblit.com [1] https://git.eclipse.org/c/jgit/jgit.git/tree/org.eclipse.jgit/src/org/eclipse/jgit/api/CommitCommand.java?h=stable-3.1#n288 [2] http://gerrit

Re: RFE: support change-id generation natively

On Mon, Oct 21, 2013, at 02:29 PM, Thomas Koch wrote: As I understand, a UUID could also be used for the same purbose as the change- id. How is the change-id generated by the way? Would it be a good english name to call it enduring commit identifier? Here is the algorithm:

Re: RFE: support change-id generation natively

That said, I don't think that --change-id option that the user must not forget to use is any better than a hook that the user must not forget to install. Having a --change-id option, to my mind, simplifies use of the patch workflow as it does not require downloading, copying and setting

Re: 2.0.0 regression? request pull does not seem to find head

/init_report 64ea29197d5e13772b1f7b6c24feaa79cc97d997 refs/remotes/origin/bug_fix/init_report The warning goes away if I give an explicit end commit. Should the default value for $remote in the call to $find_matching_ref be $head rather than HEAD (and similarly for the warning message)? --James

Possible bug in `git reset` in 1.9

Suppose I have the following branches: * branch-1 with commits A - B - C * branch-2 with commits A - B - C - D Prior to version 1.9, running `git reset --hard D` while branch-1 is checked out will result in changing the current branch HEAD to commit hash D (essentially what update-ref would do).

Re: Possible bug in `gitreset` in 1.9

Followup on this, it looks like the local repository actually didn't contain branch-2. So this doesn't appear to be an issue. -- 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

Packing speed

expectation wrong? -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 0x997A9F17ED7DAEA6 -- 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

Von James Hartop

Von James Hartop Brondesbury, North West London, England   Lieber Freund.   Ich bin James William Hartop von Brondesbury, North West London, hier in England. Ich arbeite für Niederlassung der UBS Investment Bank in London. Ich schreibe Ihnen aus meinem Büro, das von einem riesigen Vorteil für

Re: [PATCH 2/6] remote-http(s): Support SOCKS proxies

ntent. [0]: https://stackoverflow.com/help/licensing [1]: http://stackexchange.com/legal [2]: http://creativecommons.org/licenses/by-sa/3.0/ [3]: http://blog.stackoverflow.com/2009/06/attribution-required/ Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy <vega.ja...@gmail.com> -- To un

[PATCH] filter-branch: strip pgp signature in commit messages

being empty, causing the “skip header lines” loop to exit. The rest of the commit object is then re-used as the rewritten commit message, causing the new message to include the signature of the original commit. Signed-off-by: James McCoy <vega.ja...@gmail.com> --- git-filter-branch.sh

Re: [PATCH] filter-branch: strip pgp signature in commit messages

On Thu, Oct 08, 2015 at 12:00:54PM +0200, Michael J Gruber wrote: > Michael J Gruber venit, vidit, dixit 08.10.2015 10:43: > > Michael J Gruber venit, vidit, dixit 08.10.2015 10:15: > >> James McCoy venit, vidit, dixit 08.10.2015 07:01: > > ... > >> [No, t

[PATCH v2] filter-branch: remove multi-line headers in msg filter

This allows the loop to fully consume the header lines before emitting the original, intact commit message. Signed-off-by: James McCoy <vega.ja...@gmail.com> --- git-filter-branch.sh | 2 +- t/t7003-filter-branch.sh | 14 ++ 2 files changed, 15 insertions(+), 1 deletion(-) diff

Bug: git-p4 can skip changes when syncing large from multiple depot paths

lock iteration, much like there is already a temporary "end" variable, and resetting it to the value of changeStart at the top of the for loop. (Note: this appears to be how the code prior to 1051ef00636357061d72bcf673da86054fb14a12 functioned). Thanks! - James-- To unsubscribe

Re: [PATCH 0/2] git-p4: fix for handling of multiple depot paths

I'm not sure if my opinion as an outsider is of use, but since the perforce change number is monotonically increasing, my expectation as a user would be for them to be applied in order by the perforce change number. :) - James From: Luke Diamand &l

Bug: git-p4 can generate duplicate commits when syncing changes that span multiple depot paths

but I am no python expert so there may be a better way. Thanks! - James

Re: [musl] Re: Regression: git no longer works with musl libc's regex impl

I don't have to say why - everyone outside Microsoft knows why. In conclusion, I certainly hope that your view is not shared by the other git maintainers. PS: Rich, sorry for the distraction. I have said what I want to say, so I'll bow out from this thread. cheers, James

Re: [musl] Re: Regression: git no longer works with musl libc's regex impl

On Tue, 4 Oct 2016 18:08:33 +0200 (CEST) Johannes Schindelin wrote: > > No, it is not. You quote POSIX, but the matter of the fact is that we use > a subset of POSIX in order to be able to keep things running on Windows. > > And quite honestly, there are lots of

Purchase order...........

pls here is the PO

[PATCH v2] repack: Add option to preserve and prune old pack files

on them. The strategy is to preserve old pack files around until the next repack with the hopes that they will become unreferenced by then and not cause any exceptions to running processes when they are finally deleted (pruned). Signed-off-by: James Melvin <jmel...@codeaurora.org> --- Documentati

  1   2   >