Re: [PATCH v9 2/3] t7507-commit-verbose: make test suite use write_script

On Fri, Mar 25, 2016 at 11:54 AM, Eric Sunshine wrote: > On Fri, Mar 25, 2016 at 2:06 AM, Pranit Bauva wrote: >> On Fri, Mar 25, 2016 at 5:27 AM, Eric Sunshine >> wrote: >>> Agreed that this needs proper justification in the commit message. >>> And, the justification is to make each test more s

Re: [PATCH/GSoC] add a add.patch config variable

Dominik Fischer writes: > As the configuration variable can be overwritten by a command line > option, I am tempted to amend this by replacing all occurrences of > "git add" in other scripts with "git add --no-patch" to ensure the > expected behavior. Don't even think about it--you won't know al

Re: [PATCH 3/4] submodule--helper list: lose the extra prefix option

Stefan Beller writes: > The usual early machinery of Git is to change the directory to > the top level of the working tree and pass the actual path inside > the working tree as `prefix` to the command being run. > > This is the case both for commands written in C (where the > prefix is passed int

Re: [PATCH v9 2/3] t7507-commit-verbose: make test suite use write_script

On Fri, Mar 25, 2016 at 2:06 AM, Pranit Bauva wrote: > On Fri, Mar 25, 2016 at 5:27 AM, Eric Sunshine > wrote: >> Agreed that this needs proper justification in the commit message. >> And, the justification is to make each test more self-contained, >> particularly because a subsequent patch will

Re: [PATCH 1/2] Modified flag field type in rev_list_info struct in bisect.h. There is no need for flag field to be signed, as it is not supposed to be used as decimal.

Stefan Beller writes: > Maybe my exposure to the code was accidentally in a way such that > I ever only saw the version without int. The older part of the code tends to spell flag words with "unsigned" without "int", which is primarily historical fault of mine. -- To unsubscribe from this list:

Re: [PATCH v9 3/3] commit: add a commit.verbose config variable

On Fri, Mar 25, 2016 at 5:35 AM, Eric Sunshine wrote: > On Thu, Mar 24, 2016 at 4:25 AM, Pranit Bauva wrote: >> Add commit.verbose configuration variable as a convenience for those >> who always prefer --verbose. > > The implementation looks better in this version. A couple comments > below about

Re: [PATCH v9 2/3] t7507-commit-verbose: make test suite use write_script

On Fri, Mar 25, 2016 at 5:27 AM, Eric Sunshine wrote: > On Thu, Mar 24, 2016 at 7:00 AM, SZEDER Gábor wrote: >>> Also remove test_set_editor from global scope and use it in whichever >>> test it is required. >> >> Why? >> >> test_set_editor sets and exports shell variables. Since you don't >> in

Re: [PATCH] tag.c: move PGP verification code from plumbing

On Fri, Mar 25, 2016 at 01:23:57AM -0400, Eric Sunshine wrote: > On Thu, Mar 24, 2016 at 8:33 PM, wrote: > > The verify tag function is just a thin wrapper around the verify-tag > > command. We can avoid one fork call by doing the verification inside > > the tag builtin instead. > > Hopefully,

Re: [PATCH] tag.c: move PGP verification code from plumbing

On Thu, Mar 24, 2016 at 8:33 PM, wrote: > The verify tag function is just a thin wrapper around the verify-tag > command. We can avoid one fork call by doing the verification inside > the tag builtin instead. Hopefully, the below review comments are meaningful, however, aside from having just re

Re: [GSoC] Proposal

Some developers are already working on that[1]. [1]: http://thread.gmane.org/gmane.comp.version-control.git/288306 On Fri, Mar 25, 2016 at 10:12 AM, 惠轶群 wrote: > There is an interesting idea as an idea for GSoC of 2008, is it still > proposable? > > https://git.wiki.kernel.org/index.php/SoC2008I

Re: [GSoC] Proposal

There is an interesting idea as an idea for GSoC of 2008, is it still proposable? https://git.wiki.kernel.org/index.php/SoC2008Ideas#Restartable_Clone 2016-03-25 11:45 GMT+08:00 惠轶群 : > Hi, > > I'm proposing to take part in GSoC as a developer of git. > > Here is my > [Draft](https://docs.google

[GSoC] Proposal

Hi, I'm proposing to take part in GSoC as a developer of git. Here is my [Draft](https://docs.google.com/document/d/1zqOVb_cnYcaix48ep1KNPeLpRHvNKA26kNXc78yjhMg/edit?usp=sharing). I'm planning to refactor some part of git. Following is what I'm interested in: - port parts of “git rebase” to a

Re: [PATCH v2] worktree: add: introduce --checkout option

On Fri, Mar 25, 2016 at 8:29 AM, Eric Sunshine wrote: > On Thu, Mar 24, 2016 at 9:22 PM, Eric Sunshine > wrote: >> On Thu, Mar 24, 2016 at 5:52 AM, Zhang Lei wrote: >>> 2016-03-24 17:16 GMT+08:00 Duy Nguyen : I think we can follow git-clone and use '-n' for this. [...] >>> >>> My PATCH v1

Re: [PATCH v2] worktree: add: introduce --checkout option

On Thu, Mar 24, 2016 at 9:22 PM, Eric Sunshine wrote: > On Thu, Mar 24, 2016 at 5:52 AM, Zhang Lei wrote: >> 2016-03-24 17:16 GMT+08:00 Duy Nguyen : >>> I think we can follow git-clone and use '-n' for this. [...] >> >> My PATCH v1 did follow git-clone -n, however, Junio C Hamano and Eric >> Sun

Re: [PATCH v2] worktree: add: introduce --checkout option

[please respond inline rather than top-posting] On Thu, Mar 24, 2016 at 5:52 AM, Zhang Lei wrote: > 2016-03-24 17:16 GMT+08:00 Duy Nguyen : >> I think we can follow git-clone and use '-n' for this. [...] > > My PATCH v1 did follow git-clone -n, however, Junio C Hamano and Eric Sunshine > suggeste

Re: [PATCH v2] worktree: add: introduce --checkout option

On Thu, Mar 24, 2016 at 2:07 AM, Ray Zhang wrote: > By adding this option which defaults to true, we can use the > corresponding --no-checkout to make some customizations before > the checkout, like sparse checkout, etc. This version of the patch looks better. Thanks. A few comments below... > S

RE: "git svn fetch" error: [main] perl 9296 child_info_fork::abort: unable to map

Johannes, I don't have detail steps for the reproduce, but I could share some information. Yesterday one of my colleagues told me he also met this error after he updated GIT to latest 2.7.4, same with me. Then we uninstall the 64bit GIT and install a 32bit GIT on our 64bit Windows 8 machines, a

Re: [PATCH/GSoC] add a add.patch config variable

Am 24.03.2016 um 22:20 schrieb Junio C Hamano: XZS writes: Users may like to review their changes when staging by default. It is also a convenient safety feature for beginners nudging them to have a second look at their changes when composing a commit. To this end, the config variable allows t

Re: [RFD] minor frustration in 'git add' pathname completion

On Thu, Mar 24, 2016 at 3:55 PM, Junio C Hamano wrote: > Stefan Beller writes: > >>> If I were to explicitly ignore that file, then even though I know >>> whats-cooking.txt is not ignored, >>> >>>$ git add whats-coo >>> >>> would not offer anything. I'd be left scratching my head, wondering

[PATCH] tag.c: move PGP verification code from plumbing

From: Santiago Torres The verify tag function is just a thin wrapper around the verify-tag command. We can avoid one fork call by doing the verification inside the tag builtin instead. To do this, the run_pgp_verify() and verify_tag() functions are moved to tag.c. The definition of verify_tag wa

Re: [PATCH 4/4] submodule: add more tests for recursive submodule behavior

On Thu, Mar 24, 2016 at 5:25 PM, Eric Sunshine wrote: > On Thu, Mar 24, 2016 at 7:34 PM, Stefan Beller wrote: >> This adds a test for "submodule update", wich calls "submodule update" > > s/wich/which/ > >> from an untracked repository in the superproject. When doing creating > > Grammo: "doing c

Re: [PATCH 4/4] submodule: add more tests for recursive submodule behavior

On Thu, Mar 24, 2016 at 7:34 PM, Stefan Beller wrote: > This adds a test for "submodule update", wich calls "submodule update" s/wich/which/ > from an untracked repository in the superproject. When doing creating Grammo: "doing creating" > the parent patch a similar test failed for "submodule

Re: [PATCH v9 3/3] commit: add a commit.verbose config variable

On Thu, Mar 24, 2016 at 4:25 AM, Pranit Bauva wrote: > Add commit.verbose configuration variable as a convenience for those > who always prefer --verbose. The implementation looks better in this version. A couple comments below about the test script... > Signed-off-by: Pranit Bauva > --- > diff

Re: [PATCH v9 2/3] t7507-commit-verbose: make test suite use write_script

On Thu, Mar 24, 2016 at 7:00 AM, SZEDER Gábor wrote: >> Also remove test_set_editor from global scope and use it in whichever >> test it is required. > > Why? > > test_set_editor sets and exports shell variables. Since you don't > invoke test_set_editor in a subshell, after the first invocation t

Re: [PATCH 3/4] submodule--helper list: lose the extra prefix option

On Thu, Mar 24, 2016 at 4:34 PM, Stefan Beller wrote: > The usual early machinery of Git is to change the directory to > the top level of the working tree and pass the actual path inside > the working tree as `prefix` to the command being run. > This is the case both for commands written in C (whe

Re: [PATCH 1/4] submodule: fix recursive path printing from non root directory

On Thu, Mar 24, 2016 at 4:38 PM, Jacob Keller wrote: > On Thu, Mar 24, 2016 at 4:34 PM, Stefan Beller wrote: >> Recursing into submodules currently works by just calling >> (cd $submodule && eval ) for update, sync and status >> command. >> >> Say you have the following setup >> >> repo/ # a supe

Re: [PATCH 2/4] submodule: fix recursive execution from non root directory

On Thu, Mar 24, 2016 at 4:34 PM, Stefan Beller wrote: > One of the first things that happens in most submodule sub commands is > > git submodule--helper list --prefix "$wt_prefix" > > Currently the passed --prefix is used for doing path calculation > as if we were in that path relative to the

Re: [PATCH 1/4] submodule: fix recursive path printing from non root directory

On Thu, Mar 24, 2016 at 4:34 PM, Stefan Beller wrote: > Recursing into submodules currently works by just calling > (cd $submodule && eval ) for update, sync and status > command. > > Say you have the following setup > > repo/ # a superproject repository > repo/untracked/ # an untracked dir in rep

[PATCHv2 0/4] submodule helper: cleanup prefix passing

The first two patches fix two subtle bugs that would show up if we'd apply the third patch without them. The third patch replaces git submodule--helper --prefix $wt_prefix list by the more Git idiomatic git -C $wt_prefix submodule--helper list The series is finished by adding more tes

[PATCH 1/4] submodule: fix recursive path printing from non root directory

Recursing into submodules currently works by just calling (cd $submodule && eval ) for update, sync and status command. Say you have the following setup repo/ # a superproject repository repo/untracked/ # an untracked dir in repo/ repo/sub/ # a submodule repo/sub/subsub # a submodule of a submodu

[PATCH 3/4] submodule--helper list: lose the extra prefix option

The usual early machinery of Git is to change the directory to the top level of the working tree and pass the actual path inside the working tree as `prefix` to the command being run. This is the case both for commands written in C (where the prefix is passed into the command in a function paramete

[PATCH 2/4] submodule: fix recursive execution from non root directory

One of the first things that happens in most submodule sub commands is git submodule--helper list --prefix "$wt_prefix" Currently the passed --prefix is used for doing path calculation as if we were in that path relative to the repository root, which is why we need to pass "$wt_prefix". The m

[PATCH 4/4] submodule: add more tests for recursive submodule behavior

This adds a test for "submodule update", wich calls "submodule update" from an untracked repository in the superproject. When doing creating the parent patch a similar test failed for "submodule sync", but all tests passed for "submodule update". It took me a long time to figure out this was a diff

Re: [PATCH v9 1/3] parse-options.c: make OPTION__COUNTUP consider negative values

On Thu, Mar 24, 2016 at 6:33 AM, SZEDER Gábor wrote: >> The reason to make it consider negative values or more specifically >> "unspecified" values is to give the ability to differentiate between >> once, multiple time or with --no-option. >> >> Eg. : >> initialize verbose = -1 >> `git commit` =>

Re: [PATCH/RFC] builtin/tag.c: move PGP verification inside builtin.

On Thu, Mar 24, 2016 at 06:32:58PM -0400, Santiago Torres wrote: > > But I notice that we already handle SIGPIPE explicitly in sign_buffer() > > for similar reasons. What I was wondering earlier was whether we should > > teach other functions that call gpg (like verify_signed_buffer()) to > > ign

Re: [PATCH 1/2] Modified flag field type in rev_list_info struct in bisect.h. There is no need for flag field to be signed, as it is not supposed to be used as decimal.

On Thu, Mar 24, 2016 at 3:56 PM, Eric Sunshine wrote: > On Thu, Mar 24, 2016 at 4:01 PM, work wrote: >> On 03/24/2016 10:51 PM, Stefan Beller wrote: >>> On Thu, Mar 24, 2016 at 12:41 PM, Motroni Igor >>> wrote: From: Pontifik >>> >>> Here is a good place to put reasoning for why this is a

Re: [PATCH 1/2] Modified flag field type in rev_list_info struct in bisect.h. There is no need for flag field to be signed, as it is not supposed to be used as decimal.

On Thu, Mar 24, 2016 at 4:01 PM, work wrote: > On 03/24/2016 10:51 PM, Stefan Beller wrote: >> On Thu, Mar 24, 2016 at 12:41 PM, Motroni Igor >> wrote: >>> From: Pontifik >> >> Here is a good place to put reasoning for why this is a good idea. >> I see you have a long subject, so maybe we can sh

Re: [RFD] minor frustration in 'git add' pathname completion

Stefan Beller writes: >> If I were to explicitly ignore that file, then even though I know >> whats-cooking.txt is not ignored, >> >>$ git add whats-coo >> >> would not offer anything. I'd be left scratching my head, wondering >> if I mistyped the early part of the filename (e.g. "wahts-coo"

Re: [RFD] minor frustration in 'git add' pathname completion

On Thu, Mar 24, 2016 at 3:06 PM, Junio C Hamano wrote: > Stefan Beller writes: > >> On Thu, Mar 24, 2016 at 2:44 PM, Junio C Hamano wrote: >>> Discuss. >> >>> For example, I keep >>> a backup version of whats-cooking.txt in the working tree that I use >>> to manage the 'todo' branch as whats-coo

Re: [PATCH/RFC] builtin/tag.c: move PGP verification inside builtin.

> > This is my first stab at this, in the dumbest/simplest way imaginable. I > > don't like that there is no code reuse (the run_gpg_verify function is > > repeated here and in the plumbing command). I would appreciate pointers > > on what would be the best way to avoid this. > > It looks to me li

Re: [RFD] minor frustration in 'git add' pathname completion

Junio C Hamano writes: > I am wondering if there is a downside to removing (3) from the > completion logic. > > Discuss. Eh, please don't. Somehow this no longer reproduces for me. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kerne

Re: [RFD] minor frustration in 'git add' pathname completion

Junio C Hamano writes: > Stefan Beller writes: > >> On Thu, Mar 24, 2016 at 2:44 PM, Junio C Hamano wrote: >>> Discuss. >> >>> For example, I keep >>> a backup version of whats-cooking.txt in the working tree that I use >>> to manage the 'todo' branch as whats-cooking.txt+, and this is not >>>

Re: [PATCH/RFC] builtin/tag.c: move PGP verification inside builtin.

> I know you are just copying this from the one in builtin/verify-tag.c, > but I find the use of "size" and "len" for two different purposes > confusing. Those words are synonyms, so how do the variables differ? > > Perhaps "payload_size", or "signature_offset" would be a better term for > "len".

Re: [PATCH/RFC] builtin/tag.c: move PGP verification inside builtin.

On Thu, Mar 24, 2016 at 05:51:05PM -0400, Santiago Torres wrote: > Sorry for the delay with this, I got caught up with coursework. No problem. The project moves forward as contributor time permits. > This is my first stab at this, in the dumbest/simplest way imaginable. I > don't like that there

Re: [PATCH/RFC] builtin/tag.c: move PGP verification inside builtin.

On Thu, Mar 24, 2016 at 05:39:20PM -0400, santi...@nyu.edu wrote: > +static int run_gpg_verify(const char *buf, unsigned long size, unsigned > flags) > +{ > + struct signature_check sigc; > + int len; > + int ret; > + > + memset(&sigc, 0, sizeof(sigc)); > + > + len = parse_sig

Re: [RFD] minor frustration in 'git add' pathname completion

Stefan Beller writes: > On Thu, Mar 24, 2016 at 2:44 PM, Junio C Hamano wrote: >> Discuss. > >> For example, I keep >> a backup version of whats-cooking.txt in the working tree that I use >> to manage the 'todo' branch as whats-cooking.txt+, and this is not >> explicitly "ignored". > > Completel

Re: [RFD] minor frustration in 'git add' pathname completion

On Thu, Mar 24, 2016 at 2:44 PM, Junio C Hamano wrote: > Discuss. > For example, I keep > a backup version of whats-cooking.txt in the working tree that I use > to manage the 'todo' branch as whats-cooking.txt+, and this is not > explicitly "ignored". Completely side tracking thought: Have you c

Re: What's cooking in git.git (Mar 2016, #04; Wed, 23)

"Philip Oakley" writes: > This was just clarifying that if a variant of the bundle format (# > V3?) was used, that it must, if the name was retained(*), still work > as a sneakernet transfer option. In that case the user would need to > be told, or be able to find out via (e.g.) the 'verify' sub-

Re: [PATCH/RFC] builtin/tag.c: move PGP verification inside builtin.

Hi Jeff. Sorry for the delay with this, I got caught up with coursework. This is my first stab at this, in the dumbest/simplest way imaginable. I don't like that there is no code reuse (the run_gpg_verify function is repeated here and in the plumbing command). I would appreciate pointers on what

Re: What's cooking in git.git (Mar 2016, #04; Wed, 23)

From: "Junio C Hamano" "Philip Oakley" writes: The beginning of "split bundle", which could be one of the ingredients to allow "git clone" traffic off of the core server network to CDN. ... Hi Junio, I think there may be a concept clash between the ideals of a sneakernet bundle' and the '

Re: [PATCH 2/2] completion: add 'revisions' and 'everyday' to 'git help'

"Philip Oakley" writes: >> The first step may be to teach a new subcommand to "git help" >> to show a list of these words, and then _git_help can use it to >> lazily compute the list just like __git_commands does. > > 'git help -a' (or --all) already determines the list of commands > available, b

[RFD] minor frustration in 'git add' pathname completion

It seems that "git add foo" completes to files (1) whose names match 'foo*', (2) that are not ignored (i.e. "foobar~" will not be offered for Emacs users), and (3) are different from the index. The last one is somewhat frustrating at times. For example, I keep a backup version of whats

[PATCH/RFC] builtin/tag.c: move PGP verification inside builtin.

From: Santiago Torres The verify tag function is just a thin wrapper around the verify-tag command. We can avoid one fork call by doing the verification instide the tag builtin instead. Signed-off-by: Santiago Torres --- builtin/tag.c | 44 ++-- 1 file c

Re: [PATCH/GSoC] add a add.patch config variable

XZS writes: > Users may like to review their changes when staging by default. It is > also a convenient safety feature for beginners nudging them to have a > second look at their changes when composing a commit. > > To this end, the config variable allows to have git-add to always act > like -p w

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

Stefan Beller writes: > Maybe we can revive the term "group" and call it submodule.defaultGroup. > The defaultGroup is defined by selection of names, paths and labels. There are many ways to specify one or more of submodules: - By giving "pathspecs", you would choose submodules whose paths

[GSoC] Proposal

Greetings, I hope it is not yet too late to jump on the Summer of Code bandwagon. I would appreciate comments on my application [1] and my microproject contribution, which will follow this mail as a reply. My proposal mostly stems from what was noted under "convert scripts to builtins" and "git

[PATCH/GSoC] add a add.patch config variable

Users may like to review their changes when staging by default. It is also a convenient safety feature for beginners nudging them to have a second look at their changes when composing a commit. To this end, the config variable allows to have git-add to always act like -p was passed. Signed-off-by

Re: Resumable git clone?

From: "Junio C Hamano" "Philip Oakley" writes: From: "Junio C Hamano" If you clone a repository, and the connection drops, the next attempt will have to start from scratch. This can add significant time and expense if you're on a low-bandwidth or metered connection trying to clone someth

Re: [PATCH] rebase-i: print abbreviated hash when stop for editing

2016-03-24 20:56 GMT+01:00 Junio C Hamano : > Ralf Thielow writes: > >> Signed-off-by: Ralf Thielow >> --- > > Hmph, the reason why this is a good thing to do is because an > overlong $sha1 would push $rest too far to the right (possibly > making it overflow to the next line)? > Yes. Another so

Re: [PATCH 2/2] completion: add 'revisions' and 'everyday' to 'git help'

From: "Junio C Hamano" Ralf Thielow writes: Signed-off-by: Ralf Thielow --- contrib/completion/git-completion.bash | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) It is somewhat silly that we have to maintain this list to be in sync with the set of documents we offer. Wouldn't

GSoC proposal

As I was strongly encouraged to submit my GSoC proposal, I'll post it here and CC to my possible mentor. Please, provide with your feedback about my draft. You can also comment it right in the Google doc. Thanks in advance Proposal: https://docs.google.com/document/d/1Hpu9FfD3wb7qgWgTiKtIAie41

Re: [PATCH 2/2] completion: add 'revisions' and 'everyday' to 'git help'

Ralf Thielow writes: > Signed-off-by: Ralf Thielow > --- > contrib/completion/git-completion.bash | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) It is somewhat silly that we have to maintain this list to be in sync with the set of documents we offer. Wouldn't it make more sense t

Re: [PATCH 1/2] completion: add option '--guides' to 'git help'

Ralf Thielow writes: > Signed-off-by: Ralf Thielow > --- > contrib/completion/git-completion.bash | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Sounds sensible. Thanks. > > diff --git a/contrib/completion/git-completion.bash > b/contrib/completion/git-completion.bash > index e3918

Re: [PATCH 1/2] Modified flag field type in rev_list_info struct in bisect.h. There is no need for flag field to be signed, as it is not supposed to be used as decimal.

On 03/24/2016 10:51 PM, Stefan Beller wrote: On Thu, Mar 24, 2016 at 12:41 PM, Motroni Igor wrote: From: Pontifik Here is a good place to put reasoning for why this is a good idea. I see you have a long subject, so maybe we can shorten the first line (down to less than ~ 80 characters) and pu

Re: [PATCH] rebase-i: print abbreviated hash when stop for editing

Ralf Thielow writes: > Signed-off-by: Ralf Thielow > --- Hmph, the reason why this is a good thing to do is because an overlong $sha1 would push $rest too far to the right (possibly making it overflow to the next line)? > git-rebase--interactive.sh | 3 ++- > 1 file changed, 2 insertions(+),

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

On Wed, Mar 23, 2016 at 5:13 PM, Junio C Hamano wrote: > Stefan Beller writes: > >> On Tue, Mar 22, 2016 at 3:40 PM, Junio C Hamano wrote: >>> Stefan Beller writes: >>> This change introduces the 'submodule.actionOnLabel' variable in a repository configuration. Generally speaking 'sub

Re: [PATCH 1/2] Modified flag field type in rev_list_info struct in bisect.h. There is no need for flag field to be signed, as it is not supposed to be used as decimal.

On Thu, Mar 24, 2016 at 12:41 PM, Motroni Igor wrote: > From: Pontifik Here is a good place to put reasoning for why this is a good idea. I see you have a long subject, so maybe we can shorten the first line (down to less than ~ 80 characters) and put the longer explanation here. How about:

Re: [PATCH v7 17/33] refs: make lock generic

On 03/01/2016 01:52 AM, David Turner wrote: > Instead of using a files-backend-specific struct ref_lock, the generic > ref_transaction struct should provide a void pointer that backends can use > for their own lock data. Aside from the comments I've already mentioned, I've checked the patches up t

[PATCH 2/2] Just a minor commit to trigger Travis Ci build

From: Pontifik Signed-off-by: Pontifik --- notes.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/notes.c b/notes.c index 88cf474..6d7da1e 100644 --- a/notes.c +++ b/notes.c @@ -539,8 +539,8 @@ static unsigned char determine_fanout(struct int_node *tree, unsigned char

[PATCH 0/2] GSoC student

Hi! My name is Motroni Igor and I'm a Russian student who wants to apply for the GSoC developing some cool stuff for Git. As a microproject, I've made two little changes in my Git fork. Modified flag field type in rev_list_info struct in bisect.h. There is no need for flag field to be sig

[PATCH 1/2] Modified flag field type in rev_list_info struct in bisect.h. There is no need for flag field to be signed, as it is not supposed to be used as decimal.

From: Pontifik Signed-off-by: Pontifik --- bisect.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bisect.h b/bisect.h index acd12ef..a979a7f 100644 --- a/bisect.h +++ b/bisect.h @@ -16,7 +16,7 @@ extern struct commit_list *filter_skipped(struct commit_list *list, struc

Re: [PATCH v7 09/33] refs: reduce the visibility of do_for_each_ref()

On Thu, 2016-03-24 at 08:07 +0100, Michael Haggerty wrote: > > +/* > > + * The common backend for the for_each_*ref* functions > > + */ > > +static int do_for_each_ref(const char *submodule, const char > > *base, > > + each_ref_fn fn, int trim, int flags, > > + void *cb_

[PATCH] rebase-i: print abbreviated hash when stop for editing

Signed-off-by: Ralf Thielow --- git-rebase--interactive.sh | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh index 4cde685..9ea3075 100644 --- a/git-rebase--interactive.sh +++ b/git-rebase--interactive.sh @@ -548,7 +548,8

[PATCH 2/2] completion: add 'revisions' and 'everyday' to 'git help'

Signed-off-by: Ralf Thielow --- contrib/completion/git-completion.bash | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash index 70f4171..ffe6004 100644 --- a/contrib/completion/git-completion.bas

[PATCH 0/2] completion: git-help: add missing option and params

The bash completion is missing the option '--guides' for 'git-help' and some params you see there. Add them both. Ralf Thielow (2): completion: add option '--guides' to 'git help' completion: add 'revisions' and 'everyday' to 'git help' contrib/completion/git-completion.bash | 6 +++--- 1 f

[PATCH 1/2] completion: add option '--guides' to 'git help'

Signed-off-by: Ralf Thielow --- contrib/completion/git-completion.bash | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash index e3918c8..70f4171 100644 --- a/contrib/completion/git-completion.bash ++

Re: [PATCH v3 0/5] Expanding tabs in "git log" output

Torsten Bögershausen writes: > Would it make sense to have > git log --tab-size=8 > (or similar) > > and add a config variable like > git config ui.logtabsize > which is 0 by default to get the old handling and 8 for the new one ? That may be a good approach (I agree with you that --tab-size is

Re: [PATCH v7 14/33] refs: add methods to init refs db

On Thu, 2016-03-24 at 08:28 +0100, Michael Haggerty wrote: > > if (shared_repository) { > > adjust_shared_perm(get_git_dir()); > > - adjust_shared_perm(git_path_buf(&buf, "refs")); > > Given that this function is creating the "refs" directory, it seems > like > adjust_sha

Re: [PATCH] api-parse-options.txt: document OPT_CMDMODE()

On Thu, Mar 24, 2016 at 10:46 PM, Junio C Hamano wrote: > Pranit Bauva writes: > +`OPT_CMDMODE(short, long, &int_var, description, enum_val)`:: + Introduce an option for subcommands. It is useful when you want to use + the command with a particular sub command only an

Re: [PATCH] git-send-pack: Fix --all option when used with directory

On Thu, Mar 24, 2016 at 07:47:12PM +0200, Stanislav Kolotinskiy wrote: > >Thanks for noticing; the above explanation however does not make it > >very clear why the symptom exhibits itself only when "directory" is > >given (it also is unclear if "target" being a directory is special, > >or if any r

Re: Regarding GSoC 2016

On Thu, Mar 24, 2016 at 11:13 PM, Saurabh Jain wrote: > The proposal can be accessed here. > 5mWF_cqoZS6IUvGr6CVu5SmkbZk/edit?usp=sharing> It's broken I guess. Also Cc Carlos Martín Nieto . He is one of the possible mentor on this one. >

Re: [PATCH v2 09/17] Add watchman support to reduce index refresh cost

On Thu, 2016-03-24 at 09:47 -0400, Jeff Hostetler wrote: > I'm seeing wm->name have value ".git" rather than ".git/" on Linux. > > > On 03/18/2016 09:04 PM, David Turner wrote: > > + if (!strncmp(wm->name, ".git/", 5) || > > + strstr(wm->name, "/.git/")) > > +

Re: [PATCH] git-send-pack: Fix --all option when used with directory

On 24/03/16 19:37, Jeff King wrote: I guess a follow-up to my question is: what does "git send-pack" do that "git push" does not? Again, this is just for my curiosity (the answer may be "nothing, we just happened to build our scripts around send-pack", and that is perfectly fine). Well, this is s

Re: [PATCH] git-send-pack: Fix --all option when used with directory

On 24/03/16 18:11, Junio C Hamano wrote: Please see "git shortlog --no-merges" output from recent history and notice that s/Fix/fix/ would make things more consistent. Thanks for letting me know, I'll update that. Thanks for noticing; the above explanation however does not make it very clear wh

Regarding GSoC 2016

Hi, I know it's bit too late but I was busy with some other stuff. I have applied for GSoC under libgit for this project "Port packfile creation optimisations to libgit2". I request all the mentors and concerned people to please review my proposal and suggest some possible changes. The proposa

Re: Issue with git submodule update --init --depth=1 submodA

On Wed, Mar 23, 2016 at 11:21 PM, Jared Davison wrote: > > > I've had a go at patching the git-submodule.sh code further to achieve > the result I'm seeking and it seems to work for me. Can you see a > problem with this? Welcome to Git development :) I think the code looks fine, as it solves you

Re: [PATCH] git-send-pack: Fix --all option when used with directory

On Thu, Mar 24, 2016 at 03:57:59PM +0200, Stanislav Kolotinskiy wrote: > On 23/03/16 23:22, Jeff King wrote: > >Not that it matters for this bug, but for my own curiosity, what do you > >use "send-pack --all" for? I've generally assumed that nobody directly > >calls send-pack themselves these days

Re: [PATCH/GSoC] parse-options: Add a new nousage opt

On Thu, Mar 24, 2016 at 10:51:05PM +0530, Chirayu Desai wrote: > I definitely want to work with Git in the future too, it has always > piqued my interest being something that I use daily. > I want to get this change done as well, if that is okay. Sure, that's great. Part of the point of microproj

Re: git-apply does not work in a sub-directory of a Git repository

Junio C Hamano writes: > So a better alternative may be to conditionally disable the "Paths > outside are not touched regardless of --include" logic, i.e. we > exclude paths outside by default just as before, but if there is at > least one explicit "--include" given, we skip this "return 0". > >

Re: "git tag --contains " is too chatty, if is invalid

On Thu, Mar 24, 2016 at 4:11 AM, Jeff King wrote: > On Sun, Mar 20, 2016 at 12:19:46PM +0530, Chirayu Desai wrote: > >> I went for 3, and have sent a patch for that here - [PATCH/GSoC] >> parse-options: Add a new nousage opt >> However, it currently has one bug >> Running 'git tag --contains qq' t

Re: [PATCH/GSoC] parse-options: Add a new nousage opt

Note Before: I have decided not to apply for GSoC with Git this year, as I was already late, and all the remaining time got taken by the proposal I wrote for Debian, and college studies / exams. I definitely want to work with Git in the future too, it has always piqued my interest being something

Re: [PATCH] api-parse-options.txt: document OPT_CMDMODE()

Pranit Bauva writes: >>> +`OPT_CMDMODE(short, long, &int_var, description, enum_val)`:: >>> + Introduce an option for subcommands. It is useful when you want to use >>> + the command with a particular sub command only and ignore other sub >>> + commands it has. It will set `int_var` t

Re: [PATCH v2 3/4] format-patch: introduce --base=auto option

Ye Xiaolong writes: > On Wed, Mar 23, 2016 at 11:25:41AM -0700, Junio C Hamano wrote: >>I also do not see the point of showing "parent id" which as far as I >>can see is just a random commit object name and show different >>output that is not even described what it is. It would be better to > >

Re: [PATCH] api-parse-options.txt: document OPT_CMDMODE()

On Thu, Mar 24, 2016 at 9:37 PM, Junio C Hamano wrote: > Pranit Bauva writes: > >> OPT_CMDMODE() was introduced in the release of 1.8.5 which makes the use >> of subcommands in the form of arguments a lot cleaner and easier. >> --- > > Sign-off? Will include this. >> Documentation/technical/ap

Re: [PATCH] Disown ssh+git and git+ssh

On Wed, 2016-03-09 at 13:56 -0800, Junio C Hamano wrote: > Eric Sunshine writes: > > > > > It might be helpful to cite some reference to support the claim > > that > > they are "silly" since it's not necessarily obvious to readers who > > did > > not following the discussion. > > ... > > > > >

Re: git-apply does not work in a sub-directory of a Git repository

Nguyễn Thái Ngọc Duy writes: >> On Wed, Mar 23, 2016 at 11:55 PM, Junio C Hamano wrote: >>> The include/exclude mechanism does use wildmatch() but does not use >>> the pathspec mechanism (it predates the pathspec machinery that was >>> made reusable in places like this). We should be able to >

Re: git-apply does not work in a sub-directory of a Git repository

Duy Nguyen writes: >> The include/exclude mechanism does use wildmatch() but does not use >> the pathspec mechanism (it predates the pathspec machinery that was >> made reusable in places like this). We should be able to >> >> $ cd d/e/e/p/d/i/r >> $ git apply --include=:/ ../../../../..

Re: [PATCH/GSoC 3/3] Nousage message in error

On Thu, Mar 24, 2016 at 9:53 PM, Junio C Hamano wrote: > Pranit Bauva writes: > >> A general convention followed by git users it to write the commit >> message as "What he did to the code?" rather than "What problem was >> there in the code?" > > It is OK for other projects to adopt a different c

Re: [PATCH/GSoC 3/3] Nousage message in error

Pranit Bauva writes: > A general convention followed by git users it to write the commit > message as "What he did to the code?" rather than "What problem was > there in the code?" It is OK for other projects to adopt a different convention, but The project convention here is different. We tend

Re: What's cooking in git.git (Mar 2016, #04; Wed, 23)

"Philip Oakley" writes: >> >> The beginning of "split bundle", which could be one of the >> ingredients to allow "git clone" traffic off of the core server >> network to CDN. >> > ... > Hi Junio, > > I think there may be a concept clash between the ideals of a > sneakernet bundle' and the 'resuma

  1   2   >