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

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

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? > >

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 >

[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

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

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,

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

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,

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

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.

[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

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

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

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:

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

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

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

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

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

[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

[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

[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

[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

[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

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

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 > >

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:

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

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

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

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

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

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

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

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(, 0, sizeof(sigc)); > + > + len =

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

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

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

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

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

[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

[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

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

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

[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.

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

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

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

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:

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

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 >

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

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)? >

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

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

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

[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

[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

[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

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

[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 +++

[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 ---

[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

[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 ---

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

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(, "refs")); > > Given that this function is creating the "refs" directory, it seems > like >

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, _var, description, enum_val)`:: + Introduce an option for subcommands. It is useful when you want to use + the

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

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

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

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

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

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

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

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

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

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

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, _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

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

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

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

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

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

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

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

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

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

Stanislav Kolotinskiy writes: > Subject: Re: [PATCH] git-send-pack: Fix --all option when used with directory Please see "git shortlog --no-merges" output from recent history and notice that s/Fix/fix/ would make things more consistent. > When using git send-pack with

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

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? > Documentation/technical/api-parse-options.txt | 6 ++ > 1 file changed, 6

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

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/")) + continue; thanks, Jeff -- To unsubscribe from this

Re: Resumable git clone?

"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

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

Torsten Bögershausen writes: >> [5/5] adds a new option --no-expand-tabs that controls the bit 4/5 >>introduces, so that "git log [--pretty] --no-expand-tabs" >>would show the log message indented by 4 spaces, without tab >>expansion. > > Does this

Re: [PATCH] mergetools: implemented new mergetool file for ExamDiff

David Aguilar writes: > We can probably do this without introducing a new file. One > possible home for this is with the rest of the "default" > definitions of the functions in git-mergetool--lib.sh's > setup_tool() function. > > But, that hints that we expect tools to

[Outreachy] Git remote whitelist/blacklist

Hi, I'm thinking of applying to Outreachy program this round with Git and the project I'm really interested in is "Git remote whitelist/blacklist" project (http://git.github.io/SoC-2016-Ideas/). I have drafted the description/timeline for this project and it would be great to get

  1   2   >