[RFC_PATCHv4 5/7] submodule update: respect submodule.actionOnLabel

This change introduces the 'submodule.actionOnLabel' variable in a repository configuration. Generally speaking 'submodule.actionOnLabel' restricts the action of a command when no submodules are selected via the command line explicitely to those submodules, which are selected by

[RFC_PATCHv4 7/7] WIP status/diff: respect submodule.actionOnLabel

When 'submodule.actionOnLabel' is set, submodules which are selected by a label will be inspected in status and diff. If a submodule is not selected, it is ignored. Signed-off-by: Stefan Beller --- submodule.c| 15 +++ t/t7400-submodule-basic.sh |

[RFC_PATCHv4 4/7] submodule init: redirect stdout to stderr

Reroute the output of stdout to stderr as it is just informative messages, not to be consumed by machines. We want to init submodules from the helper for `submodule update` in a later patch and the stdout output of said helper is consumed by the parts of `submodule update` which are still written

[RFC_PATCHv4 1/7] git submodule: teach `add` to label submodules

When adding new submodules, you can specify the label(s) the submodule belongs to by giving one or more --label arguments. This will record each label in the .gitmodules file as a value of the key "submodule.$NAME.label". Signed-off-by: Stefan Beller ---

[RFC_PATCHv4 3/7] submodule-config: add method to check for being labeled

In later patches we need to tell if a submodule is labeled by the given labels. Signed-off-by: Stefan Beller --- submodule-config.c | 48 submodule-config.h | 3 +++ 2 files changed, 51 insertions(+) diff --git

[RFC_PATCHv4 6/7] clone: allow specification of submodules to be cloned

This is in line with clone being the contraction of mkdir && cd git init git config git fetch git submodule update Signed-off-by: Stefan Beller --- Documentation/git-clone.txt | 6 ++ builtin/clone.c | 40 -

[RFC_PATCHv4 2/7] submodule-config: keep labels around

We need the submodule labels in a later patch. Signed-off-by: Stefan Beller --- submodule-config.c | 18 +- submodule-config.h | 2 ++ 2 files changed, 19 insertions(+), 1 deletion(-) diff --git a/submodule-config.c b/submodule-config.c index

[RFC_PATCHv4 0/7] Git submodule labels

This series introduces labels which you can attach to submodules like so: $ cat .gitmodules [submodule "gcc"] path = gcc url = git://... label = default label = devel [submodule "linux"] path = linux url = git://... label =

Re: [PATCH] branch: update all per-worktree HEADs when renaming a branch

On Tue, Mar 22, 2016 at 12:41 AM, Eric Sunshine wrote: >> diff --git a/worktree.c b/worktree.c >> @@ -217,3 +217,41 @@ char *find_shared_symref(const char *symref, const char >> *target) >> +int update_worktrees_head_symref(const char *oldref, const char *newref) >> +{

Re: [PATCH] bisect--helper: convert a function in shell to C

On Mon, Mar 21, 2016 at 12:00 PM, Pranit Bauva wrote: > Convert the code literally without changing its design even though it > seems that its obscure as to the use of comparing revision to different bisect > arguments which seems like a problem in shell because of the way

[PATCH] bisect--helper: convert a function in shell to C

Convert the code literally without changing its design even though it seems that its obscure as to the use of comparing revision to different bisect arguments which seems like a problem in shell because of the way function arguments are handled. Signed-off-by: Pranit Bauva

Re: When does git check for branch-X being uptodate with origin/branch-X?

On Mon, Mar 21, 2016 at 3:42 PM, Junio C Hamano wrote: > Stefan Beller writes: > >> On> 494398473714dcbedb38b1ac79b531c7384b3bc4 Stefan Beller >> 1455150849 -0800 rebase -i (start): checkout >> origin/master: fast-forward >> >> I do

Re: When does git check for branch-X being uptodate with origin/branch-X?

Stefan Beller writes: > On> 494398473714dcbedb38b1ac79b531c7384b3bc4 Stefan Beller > 1455150849 -0800 rebase -i (start): checkout > origin/master: fast-forward > > I do understand the "fetch --append origin fast-forward", (I assume > they are coming from

Re: [PATCH] commit: do not lose SQUASH_MSG contents

Sven Strickroth writes: > When concluding a conflicted "git merge --squash", the command > failed to read SQUASH_MSG that was prepared by "git merge", and > showed only the "# Conflicts:" list of conflicted paths. > > Place the contents from SQUASH_MSG at the beginning, just

[PATCH] commit: do not lose SQUASH_MSG contents

When concluding a conflicted "git merge --squash", the command failed to read SQUASH_MSG that was prepared by "git merge", and showed only the "# Conflicts:" list of conflicted paths. Place the contents from SQUASH_MSG at the beginning, just like we show the commit log skeleton first when

Re: [PATCH 00/16] git bisect improvements

Hi Pranit, On 03/20/2016 07:50 PM, Pranit Bauva wrote: > I have been recently following this series of patches and it seems a > bit stale. These patches haven't been followed up with improvement > patches. I'm on vacation at the moment. Patchset v1 contains some bugs. So I just updated the

Re: When does git check for branch-X being uptodate with origin/branch-X?

On Mon, Mar 21, 2016 at 2:57 PM, Junio C Hamano wrote: > Stefan Beller writes: > >>> "branch-X is uptodate with origin/branch-X (as of DD-MM-YY HH:MM:SS)" >> >> Actually I like that feature of recording the last known time we fetched, >> I would have found

Re: [PATCH v2] Add the tag.gpgsign option to sign all created tags

Junio C Hamano writes: >>> If you are forcing users to always leave a message and then further >>> forcing users to always sign with the single new configuration, i.e. >>> >>> $ git tag v1.0 >>> ... opens the editor to ask for a message ... >>> ... then makes the

Re: When does git check for branch-X being uptodate with origin/branch-X?

Stefan Beller writes: >> "branch-X is uptodate with origin/branch-X (as of DD-MM-YY HH:MM:SS)" > > Actually I like that feature of recording the last known time we fetched, > I would have found that information useful in the past a few times. (unrelated > to this exact

Re: When does git check for branch-X being uptodate with origin/branch-X?

On Mon, Mar 21, 2016 at 2:12 PM, Thomas Adam wrote: > On 21 March 2016 at 20:50, Jeff King wrote: >> But that's just my opinion. Did you have some specific change you're >> interested in? I don't think removing that message is productive; it >> _is_ useful

[ANNOUNCE] Git v2.8.0-rc4

A release candidate Git v2.8.0-rc4 is now available for testing at the usual places. It is comprised of 521 non-merge commits since v2.7.0, contributed by 73 people, 21 of which are new faces. Relative to v2.8.0-rc3, this reverts the change to the gitignore mechanism (which also is used in a

Re: [PATCH v4] Add the tag.gpgsign option to sign annotated tags

Laurent Arnoud writes: > @@ -326,7 +332,7 @@ int cmd_tag(int argc, const char **argv, const char > *prefix) > struct create_tag_options opt; > char *cleanup_arg = NULL; > int create_reflog = 0; > - int annotate = 0, force = 0; > + int annotate = -1,

Re: When does git check for branch-X being uptodate with origin/branch-X?

On 21 March 2016 at 21:18, Jeff King wrote: > Again, just my opinion, but that looks awfully clunky. And it doesn't > address the other messages (you might be behind origin/branch-X by N > commits, or ahead by N, but only as of that particular date). Do we want > to annotate every

Re: When does git check for branch-X being uptodate with origin/branch-X?

On Mon, Mar 21, 2016 at 09:12:18PM +, Thomas Adam wrote: > On 21 March 2016 at 20:50, Jeff King wrote: > > But that's just my opinion. Did you have some specific change you're > > interested in? I don't think removing that message is productive; it > > _is_ useful information.

Re: When does git check for branch-X being uptodate with origin/branch-X?

On 21 March 2016 at 20:50, Jeff King wrote: > But that's just my opinion. Did you have some specific change you're > interested in? I don't think removing that message is productive; it > _is_ useful information. Perhaps it could be more clear that we are > talking about the

Re: When does git check for branch-X being uptodate with origin/branch-X?

Jeff King writes: > The message from checking is looking only at your local > refs/remotes/fvwmorg/master branch, which is essentially a cache of what > is in the actual remote repository. Saying "cache of what is ..." would further confuse people, I am afraid. We just keep a

[PATCH v4] Add the tag.gpgsign option to sign annotated tags

The `tag.gpgsign` config option allows to sign annotated tags automatically. `--annotate` command line option disable configuration `tag.gpgsign`. Signed-off-by: Laurent Arnoud --- Documentation/config.txt | 5 + builtin/tag.c| 20 +++-

Re: When does git check for branch-X being uptodate with origin/branch-X?

On Mon, Mar 21, 2016 at 08:43:17PM +, Thomas Adam wrote: > On 21 March 2016 at 20:28, Jeff King wrote: > > We never contact other repositories unless explicitly asked to by > > fetch, pull, push, etc. If you want to have the most up-to-date value > > without merging, you can

Re: When does git check for branch-X being uptodate with origin/branch-X?

On Mon, Mar 21, 2016 at 1:28 PM, Jeff King wrote: > On Mon, Mar 21, 2016 at 08:21:46PM +, Thomas Adam wrote: > >> Something I've seen a few times of late (although I doubt that's any >> indication that the code has changed in Git) is the reporting of >> branch-X being uptodate

Re: When does git check for branch-X being uptodate with origin/branch-X?

Thomas Adam writes: > On 21 March 2016 at 20:28, Jeff King wrote: >> We never contact other repositories unless explicitly asked to by >> fetch, pull, push, etc. If you want to have the most up-to-date value >> without merging, you can just "git fetch" to

Re: When does git check for branch-X being uptodate with origin/branch-X?

On 21 March 2016 at 20:28, Jeff King wrote: > We never contact other repositories unless explicitly asked to by > fetch, pull, push, etc. If you want to have the most up-to-date value > without merging, you can just "git fetch" to update the tracking > branches. Thanks. I

Re: When does git check for branch-X being uptodate with origin/branch-X?

On Mon, Mar 21, 2016 at 08:21:46PM +, Thomas Adam wrote: > Something I've seen a few times of late (although I doubt that's any > indication that the code has changed in Git) is the reporting of > branch-X being uptodate with origin/branch-X when it isn't. > > When does git check to see if

When does git check for branch-X being uptodate with origin/branch-X?

Hi all, Something I've seen a few times of late (although I doubt that's any indication that the code has changed in Git) is the reporting of branch-X being uptodate with origin/branch-X when it isn't. When does git check to see if branch-X has a remote tracking branch and that it has changes on

[PATCH v10 2/2] pull --rebase: add --[no-]autostash flag

If rebase.autoStash configuration variable is set, there is no way to override it for "git pull --rebase" from the command line. Teach "git pull --rebase" the --[no-]autostash command line flag which overrides the current value of rebase.autoStash, if set. As "git rebase" understands the

Re: [PATCH v2] Add the tag.gpgsign option to sign all created tags

On Mon, Mar 21, 2016 at 12:43:45PM -0700, Junio C Hamano wrote: > If so, then the configuration is "when the user gives us a message > to create a tag without explicitly saying -a/-s, we create an > annotated tag by default, but create a signed tag instead in such a > case", I would think. That

Re: [ANNOUNCE] Git v2.8.0-rc2

Michael J Gruber writes: > I think this is a general question about how to track build > products. The proper place may be in a tree that is referenced > from a note or so. > Maybe I shouldn't consider git.pot a build product - I don't know, > as I honestly don't

Re: [PATCH v2] Add the tag.gpgsign option to sign all created tags

On Mon, Mar 21, 2016 at 12:43:45PM -0700, Junio C Hamano wrote: > > You know that when you have sign configuration enabled globally annotate is > > implicite, so its difficult to join both world. > > Sorry, I am not sure what you mean by that. It is unclear what two > worlds you are referring

Re: [PATCH v2] Add the tag.gpgsign option to sign all created tags

On Sun, Mar 20, 2016 at 10:50:48PM -0700, Junio C Hamano wrote: > > Support `--no-sign` option to countermand configuration `tag.gpgsign`. > > That sound quite counter-intuitive. > [...] I was the one who suggested --no-sign, as we usually like to have a way to countermand the config. But

Re: [PATCH v2] Add the tag.gpgsign option to sign all created tags

Laurent Arnoud writes: >> > Support `--no-sign` option to countermand configuration `tag.gpgsign`. >> So I do not see why you need a new --no-sign option at all. If >> you have the configuration and you do want to create an unsigned >> annotated tag one-shot, all you need is

Re: [PATCH v3] Add the tag.gpgsign option to sign annotated tags

On Mon, Mar 21, 2016 at 08:32:07PM +0100, Laurent Arnoud wrote: > The `tag.gpgsign` config option allows to sign all > annotated tags automatically. > > Support `--no-sign` option to countermand configuration `tag.gpgsign`. > > Signed-off-by: Laurent Arnoud > Reviewed-by:

Re: merge: fix NULL pointer dereference when merging nothing into void

On Mon, Mar 21, 2016 at 3:01 PM, Junio C Hamano wrote: > When we are on an unborn branch and merging only one foreign parent, > we allow "git merge" to fast-forward to that foreign parent commit. > > This codepath incorrectly attempted to dereference the list of > parents that

[PATCH] Documentation: fix broken linkgit to git-config

Signed-off-by: Matthieu Moy --- Documentation/githooks.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt index d954bf6..90a59d1 100644 --- a/Documentation/githooks.txt +++

Re: [PATCH v10 2/2] pull --rebase: add --[no-]autostash flag

Mehul Jain writes: > --- a/Documentation/git-pull.txt > +++ b/Documentation/git-pull.txt > @@ -128,6 +128,15 @@ unless you have read linkgit:git-rebase[1] carefully. > --no-rebase:: > Override earlier --rebase. > > +--autostash:: > +--no-autostash:: > +

[PATCH v3] Add the tag.gpgsign option to sign annotated tags

The `tag.gpgsign` config option allows to sign all annotated tags automatically. Support `--no-sign` option to countermand configuration `tag.gpgsign`. Signed-off-by: Laurent Arnoud Reviewed-by: Jeff King --- Documentation/config.txt | 5 +

Re: git master describe segfault

Daniel Stenberg writes: > 0. I'm on a Linux box: a reasonably updated Debian unstable. > > 1. I'm up to date with the latest git master branch of gecko-dev: > https://github.com/mozilla/gecko-dev (counting a little over 467K > commits) > > 2. I built the current git off the

Re: [PATCH v2] Add the tag.gpgsign option to sign all created tags

On Sun, Mar 20, 2016 at 10:50:48PM -0700, Junio C Hamano wrote: > > The `tag.gpgsign` config option allows to sign all > > commits automatically. > > I presume that you meant "all annotated tags" here. But I am not > sure it this is sensible. Yes its a mistake. > > Support `--no-sign` option

Re: [PATCH][Outreachy] branch -D: allow - as abbreviation of @{-1}

On Mon, Mar 21, 2016 at 12:14 PM, Eric Sunshine wrote: > [please don't top-post; respond inline instead] > > On Mon, Mar 21, 2016 at 2:53 PM, elena petrashen > wrote: >> Thank you for the feedback! >> The safety concert is indeed a good point.

Re: [PATCH][Outreachy] branch -D: allow - as abbreviation of @{-1}

On Mon, Mar 21, 2016 at 1:24 PM, Matthieu Moy wrote: > Elena Petrashen writes: >> * git branch (-d | -D) is not supposed to accept any other >> arguments except for branch name so it makes sense to replace >> the argv[i] with @{-1}. We

Re: [PATCH][Outreachy] branch -D: allow - as abbreviation of @{-1}

[please don't top-post; respond inline instead] On Mon, Mar 21, 2016 at 2:53 PM, elena petrashen wrote: > Thank you for the feedback! > The safety concert is indeed a good point. Would it maybe make > sense to request user to confirm this operation? I.e: > $git delete

merge: fix NULL pointer dereference when merging nothing into void

When we are on an unborn branch and merging only one foreign parent, we allow "git merge" to fast-forward to that foreign parent commit. This codepath incorrectly attempted to dereference the list of parents that the merge is going to record even when the list is empty. It must refuse to operate

[PATCH v10 2/2] pull --rebase: add --[no-]autostash flag

If rebase.autoStash configuration variable is set, there is no way to override it for "git pull --rebase" from the command line. Teach "git pull --rebase" the --[no-]autostash command line flag which overrides the current value of rebase.autoStash, if set. As "git rebase" understands the

[PATCH v10 0/2] introduce --[no-]autostash command line flag

Following series of patches introduce --[no-]autostash command line flag for "git pull --rebase". [PATCH v10 1/2] git-pull.c: introduce git_pull_config() It's a clean-up patch for changes introduced in [PATCH v10 2/2]. [PATCH v10 2/2] pull --rebase: add --[no-]autostash flag Changes introduced

[PATCH v10 1/2] git-pull.c: introduce git_pull_config()

git-pull makes a seperate call to git_config_get_bool() to read the value of "rebase.autostash". This can be reduced as a call to git_config() is already there in the code. Introduce a callback function git_pull_config() to read "rebase.autostash" along with other variables. Helped-by: Junio C

Re: GSoC Project | Improvise git bisect

On Mon, Mar 21, 2016 at 11:23 PM, Christian Couder wrote: > Hi Pranit, > > On Mon, Mar 21, 2016 at 8:29 AM, Pranit Bauva wrote: >> On Mon, Mar 21, 2016 at 12:48 PM, Johannes Schindelin >> wrote: >>> Hi Pranit, >>>

Re: [PATCH][Outreachy] branch -D: allow - as abbreviation of @{-1}

Eric Sunshine writes: > On Mon, Mar 21, 2016 at 1:47 PM, Junio C Hamano wrote: >> Matthieu Moy writes: >>> But I'm not sure how often people want to delete (force-delete according >>> to your message) the branch they

Re: [PATCH][Outreachy] branch -D: allow - as abbreviation of @{-1}

On Mon, Mar 21, 2016 at 1:47 PM, Junio C Hamano wrote: > Matthieu Moy writes: >> But I'm not sure how often people want to delete (force-delete according >> to your message) the branch they just come from. > > One that I heard was this sequence: >

Re: [PATCH v2 0/2] git-p4: fix AsciiDoc formatting

larsxschnei...@gmail.com writes: > From: Lars Schneider > > diff to v1: > * reference external pages similar to git-bisect-lk2009 (thanks Luke) > * fix quotation marks (you can see the error here: > https://git-scm.com/docs/git-p4/2.7.4 ... search for cp1252 ) > >

Re: GSoC Project | Improvise git bisect

Hi Pranit, On Mon, Mar 21, 2016 at 8:29 AM, Pranit Bauva wrote: > On Mon, Mar 21, 2016 at 12:48 PM, Johannes Schindelin > wrote: >> Hi Pranit, >> >> On Sun, 20 Mar 2016, Pranit Bauva wrote: >> >>> I could first move individual functions to

Re: [PATCH][Outreachy] branch -D: allow - as abbreviation of @{-1}

Matthieu Moy writes: > But I'm not sure how often people want to delete (force-delete according > to your message) the branch they just come from. One that I heard was this sequence: $ git checkout -b work master $ work work work ... $ git checkout

Re: [PATCH 1/2] git-compat-util: st_add4: work around gcc 4.2.x compiler crash

On 2016-03-21 05.35, Eric Sunshine wrote: > } > -#define st_add3(a,b,c) st_add((a),st_add((b),(c))) > -#define st_add4(a,b,c,d) st_add((a),st_add3((b),(c),(d))) > +#define st_add3(a,b,c) st_add(st_add((a),(b)),(c)) > +#define st_add4(a,b,c,d) st_add(st_add3((a),(b),(c)),(d)) > That fix

Re: [PATCH] branch: update all per-worktree HEADs when renaming a branch

On Mon, Mar 21, 2016 at 5:50 AM, Kazuki Yamaguchi wrote: > When renaming a branch, the current code only updates the current > working tree's HEAD, but it should update .git/HEAD of all checked out > working trees. > > This is the current behavior, /path/to/wt's HEAD is not updated:

Re: [PATCH][Outreachy] branch -D: allow - as abbreviation of @{-1}

Hi, and welcome! Elena Petrashen writes: > Signed-off-by: Elena Petrashen > > --- > This micro-patch is meant to allow “-“ as a short-hand for > “@{-1} for branch -D (Cf. $gmane/230828): Is it a good thing to do? I find "git checkout -"

Re: [PATCH] read-cache: increase write buffer size

On Sat, 2016-03-19 at 18:18 +0700, Duy Nguyen wrote: > On Sat, Mar 19, 2016 at 8:19 AM, David Turner < > dtur...@twopensource.com> wrote: > > Each write() has syscall overhead, and writing a large index > > entails > > many such calls. A larger write buffer reduces the overhead, > > leading to

Re: [PATCH][Outreachy] branch: allow - as abbreviation of '@{-1}'

elena petrashen writes: > Hi Eric, Junio, > > thank you very much for your feedback! I honestly apologize I > got so many things wrong. Nothing to apologize. You are not expected to know all the local conventions from the beginning, and we appreciate your willingness

Re: [PATCH][Outreachy] branch: allow - as abbreviation of '@{-1}'

On Mon, Mar 21, 2016 at 11:12 AM, elena petrashen wrote: > Hi Eric, Junio, > > thank you very much for your feedback! I honestly apologize I > got so many things wrong. No apologies necessary. We understand that it takes time for newcomers to the project to absorb the

Re: Properties of trees referencing commit objects (mode 160000)?

On Mon, Mar 21, 2016 at 01:57:13AM -0400, Jeff King wrote: > On Sun, Mar 20, 2016 at 04:22:02PM -0700, Josh Triplett wrote: > > > I want to track the evolution of a patch series or other commit history, > > through non-fast-forwarding actions like rebase, rebase -i, or commit > > --amend.

[PATCH][Outreachy] branch -D: allow - as abbreviation of @{-1}

Signed-off-by: Elena Petrashen --- This micro-patch is meant to allow “-“ as a short-hand for “@{-1} for branch -D (Cf. $gmane/230828): * git branch (-d | -D) is not supposed to accept any other arguments except for branch name so it makes sense to replace the argv[i]

Re: [PATCH][Outreachy] branch: allow - as abbreviation of '@{-1}'

Hi Eric, Junio, thank you very much for your feedback! I honestly apologize I got so many things wrong. I'll try to minimize the scope a little bit for the next attempt to make sure my approach is good first and then expand: i.e will only teach git branch to delete "-" & give out an error

Re: [PATCH/RFC/GSoC 05/17] rebase-options: implement rebase_options_load() and rebase_options_save()

Hi Dscho, (Sorry for the very late reply, I got caught up with some unexpected work and am still clearing my inbox ><) On Thu, Mar 17, 2016 at 1:11 AM, Johannes Schindelin wrote: > On Wed, 16 Mar 2016, Paul Tan wrote: >> On Wed, Mar 16, 2016 at 4:04 PM, Johannes

Re: [ANNOUNCE] Git v2.7.4 (and updates to older maintenance tracks)

> On Mar 21, 2016, at 01:41, Eric Sunshine wrote: > > [cc:+Torsten] > > On Sun, Mar 20, 2016 at 3:43 PM, Jeff King wrote: >> On Sun, Mar 20, 2016 at 01:07:52PM -0400, Eric Sunshine wrote: >>> On Sun, Mar 20, 2016 at 11:32 AM, Renato Botelho

Changing two defaults in the upcoming Git for Windows 2.8.0

Dear Git users, even if 2.8.0 got delayed a little bit, it is pretty imminent now. And it also poses an excellent excuse for me to make some more visible changes in the Git for Windows installer. In particular, I would like to enable fscache by default:

Re: [GSOC/RFC] GSoC Proposal Draft | Git Beginner

Hi, I updated the draft with links, ggit usage examples and some changes to the timeline. I placed the links with reference here, but in the Google Doc, they're inline. Thanks and regards, Sidhant Sharma --- Implement a beginner mode for Git. Abstract Git is a very powerful version control

Re: [GSOC/RFC] GSoC Proposal Draft | Git Beginner

On Monday 21 March 2016 01:59 PM, Matthieu Moy wrote: > Sidhant Sharma writes: > >> On Monday 21 March 2016 12:22 AM, Matthieu Moy wrote: >> >>> Note that it implies writting an almost full-blown option parser to >>> recognize commands like >>> >>> ggit --work-tree git

[PATCH] branch: update all per-worktree HEADs when renaming a branch

When renaming a branch, the current code only updates the current working tree's HEAD, but it should update .git/HEAD of all checked out working trees. This is the current behavior, /path/to/wt's HEAD is not updated: % git worktree list /path/to 2c3c5f2 [master] /path/to/wt 2c3c5f2

git master describe segfault

Hello good peeps! I just ran head-first into a segfault that is fully reproducable for me but I'm not at all fluent in these internals so I'm not the suitable person to offer a fix. Let me instead offer you some fine details: 0. I'm on a Linux box: a reasonably updated Debian unstable. 1.

Re: [PATCH v6 4/4] config: add '--show-origin' option to print the origin of a config value

On 02 Mar 2016, at 18:33, Johannes Sixt wrote: > Am 19.02.2016 um 10:16 schrieb larsxschnei...@gmail.com: >> +test_expect_success '--show-origin with --list' ' >> +cat >expect <<-EOF && >> +file:$HOME/.gitconfig user.global=true >> +

Re: [GSOC/RFC] GSoC Proposal Draft | Git Beginner

Sidhant Sharma writes: > On Monday 21 March 2016 12:22 AM, Matthieu Moy wrote: > >> Note that it implies writting an almost full-blown option parser to >> recognize commands like >> >> ggit --work-tree git --namespace reset --git-dir --hard git log >> >> (just looking for

Re: [PATCH/RFC/GSoC 01/17] perf: introduce performance tests for git-rebase

Hi Thomas, On Sun, 20 Mar 2016, Thomas Gummerer wrote: > On 03/18, Johannes Schindelin wrote: > > > > On Fri, 18 Mar 2016, Thomas Gummerer wrote: > > > > > [1] > > > http://thread.gmane.org/gmane.comp.version-control.git/1379419842-32627-1-git-send-email-t.gumme...@gmail.com > > > > Yes, I

Re: [GSOC/RFC] GSoC Proposal Draft | Git Beginner

On Monday 21 March 2016 12:22 AM, Matthieu Moy wrote: > Sidhant Sharma writes: > >> A wrapper is to be implemented around (currently called 'ggit'), which will >> provide the following user interface: >> `ggit ` > There's actually already a tool doing this: > >

Re: GSoC Project | Improvise git bisect

On Mon, Mar 21, 2016 at 12:48 PM, Johannes Schindelin wrote: > Hi Pranit, > > On Sun, 20 Mar 2016, Pranit Bauva wrote: > >> I could first move individual functions to bisect--helper.c. > > My suggestion would be to give it a try already with some functionality > you

Re: GSoC Project | Improvise git bisect

Hi Pranit, On Sun, 20 Mar 2016, Pranit Bauva wrote: > I could first move individual functions to bisect--helper.c. My suggestion would be to give it a try already with some functionality you deem small enough to move to the bisect--helper within a day or so. It is always good to test the waters

Re: [PATCH] Fixing segmentation fault when merging FETCH_HEAD

On Sun, Mar 20, 2016 at 8:11 PM, Jose Ivan B. Vilarouca Filho wrote: > Hello, Eric. > > Thanks for suggestions. I've added a test in commit replacing git fetch > origin by a fake FETCH_HEAD content. Thanks for the re-roll. To be "git am"-friendly, you should either place