[PATCH v5] commit: add a commit.verbose config variable

Add commit.verbose configuration variable as a convenience for those who always prefer --verbose. Signed-off-by: Pranit Bauva Mentored-by: Eric Sunshine --- The previous versions of this patch are: - [v4] $gmane/288652 - [v3] $gmane/288634 -

[RFC/GSoC] Introduction

Hi everyone! I am Sidhant Sharma, from Delhi, India. I'm a third year Software Engineering student at Delhi Technological University. I am looking to contribute to Git via GSoC 2016. I have also worked on one of the microprojects [1]. I've been using git for nearly two years now, and continue to

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

On Fri, Mar 11, 2016 at 10:21 AM, Paul Tan wrote: > Stepping back a bit, the only reason why we introduced opt_autostash = > -1 as a possible value is because we need to detect if > --[no-]autostash is being used with git-merge. I consider that a > kludge, because if git-merge

Re: [PATCH] diff: handle "-" as abbreviation of '@{-1}'

dash is usually used for representing stdin / stdout as a file. I think this could drive to error... but I would agree with transforming -h1 to @{-1} or -h2 to @{-2} (-h representing head). I do agree however that all those signs are thought with american keyboards in mind. All those punctuation

[PATCH] diff: handle "-" as abbreviation of '@{-1}'

Currently it just replace "-" in argv[] into "@{-1}". For example, git diff - equals to git diff @{-1} Signed-off-by: Senorsen --- Notes: Hello everyone, I'm Zhang Sen, a college student from Zhejiang University in China, and this is a patch for the

Re[2]: Possible bug: --ext-diff ignored with --cc in git log

On Fri, 11 Mar 2016 10:20:42 -0800 Junio C Hamano wrote: JCH> Vadim Zeitlin writes: JCH> JCH> > Thank you for your reply, Junio, I hadn't realized that --cc was dependent JCH> > on textual diff output format before, but now I understand why it can't

Re: [RFC/PATCH] clone: add `--shallow-submodules` flag

On Fri, Mar 11, 2016 at 4:41 PM, Junio C Hamano wrote: > Stefan Beller writes: > >> When creating a shallow clone of a repository with submodules, the depth >> argument does not influence the submodules, i.e. the submodules are done >> as non-shallow

Re: [RFC/PATCH] clone: add `--shallow-submodules` flag

Stefan Beller writes: > When creating a shallow clone of a repository with submodules, the depth > argument does not influence the submodules, i.e. the submodules are done > as non-shallow clones. It is unclear what the best default is for the > depth of submodules of a

[RFC/PATCH] clone: add `--shallow-submodules` flag

When creating a shallow clone of a repository with submodules, the depth argument does not influence the submodules, i.e. the submodules are done as non-shallow clones. It is unclear what the best default is for the depth of submodules of a shallow clone, so we need to have the possibility to do

Re: [PATCH v2 05/10] config: drop git_config_early

Jeff King writes: > There are no more callers, and it's a rather confusing > interface. This could just be folded into > git_config_with_options(), but for the sake of readability, > we'll leave it as a separate (static) helper function. Yay! ;-) -- To unsubscribe from this

[PATCH v2 06/10] setup: refactor repo format reading and verification

When we want to know if we're in a git repository of reasonable vintage, we can call check_repository_format_gently(), which does three things: 1. Reads the config from the .git/config file. 2. Verifies that the version info we read is sane. 3. Writes some global variables based on this.

[PATCH v2 04/10] check_repository_format_gently: stop using git_config_early

There's a chicken-and-egg problem with using the regular git_config during the repository setup process. We get around it here by using a special interface that lets us specify the per-repo config, and avoid calling git_pathdup(). But this interface doesn't actually make sense. It will look in

[PATCH v2 05/10] config: drop git_config_early

There are no more callers, and it's a rather confusing interface. This could just be folded into git_config_with_options(), but for the sake of readability, we'll leave it as a separate (static) helper function. Signed-off-by: Jeff King --- Documentation/technical/api-config.txt

[PATCH v2 08/10] setup: unify repository version callbacks

Once upon a time, check_repository_format_gently would parse the config with a single callback, and that callback would set up a bunch of global variables. But now that we have separate workdirs, we have to be more careful. Commit 31e26eb (setup.c: support multi-checkout repo setup, 2014-11-30)

[PATCH v2 09/10] setup: drop repository_format_version global

Nobody reads this anymore, and they're not likely to; the interesting thing is whether or not we passed check_repository_format(), and possibly the individual "extension" variables. Signed-off-by: Jeff King --- cache.h | 1 - environment.c | 1 - setup.c | 1 - 3

[PATCH v2 10/10] verify_repository_format: mark messages for translation

These messages are human-readable and should be translated. Signed-off-by: Jeff King --- setup.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/setup.c b/setup.c index 1314c17..09d3720 100644 --- a/setup.c +++ b/setup.c @@ -462,7 +462,7 @@ int

[PATCH v2 07/10] init: use setup.c's repo version verification

We check our templates to make sure they are from a version of git we understand (otherwise we would init a repository we cannot ourselves run in!). But our simple integer check has fallen behind the times. Let's use the helpers that setup.c provides to do it right. Signed-off-by: Jeff King

[PATCH v2 0/10] cleaning up check_repository_format_gently

This is a re-roll of: http://article.gmane.org/gmane.comp.version-control.git/288017 The changes from v1 are: - dropped original 10/10 that got rid of GIT_REPO_VERSION defines (David mentioned that he's going to be expanding their use, so the argument that they are not used does not

[PATCH v2 01/10] setup: document check_repository_format()

This function's interface is rather enigmatic, so let's document it further. While we're here, let's also drop the return value. It will always either be "0" or the function will die (consequently, neither of its two callers bothered to check the return). Signed-off-by: Jeff King

[PATCH v2 02/10] wrap shared_repository global in get/set accessors

It would be useful to control access to the global shared_repository, so that we can lazily load its config. The first step to doing so is to make sure all access goes through a set of functions. This step is purely mechanical, and should result in no change of behavior. Signed-off-by: Jeff King

Re: Ability to remember last known good build

Stefan Beller writes: >>> Any better way of accomplishing this? >> >> "test && git branch -f last-good"? > > Travis-CI enabled, tells me they're using Github and are distributed, > so one contributor would want to know the last known good state of > a remote, that others push

Re: Letter of Intent!!

Esteem Partner, I am Mr.Young Chio, I work with the China Merchants Bank, I wish to place your name as the beneficiary to Ten Million Three Hundred Thousand Dollars only due to the death of the depositor who died years ago along with her family. However, I assure you that this transaction will

Re: Sample pre-push hook can crash

Thanks for the information Junio. It is just interesting that although the pre-push hook receives the remote_sha value from the server, it does not get 'git merge-base $remote_sha $local_sha' which is what a check that iterated over all outgoing commits would really need. (I'm sure this is a

Re: Sample pre-push hook can crash

Stephen Morton writes: > That is interesting, so in the case of a non-ff push, there is no way > for a pre-push hook to know what is being pushed in order to run? If you were up-to-date from the other side once: ---A---B---C and built one new commit on top:

RE: Ability to remember last known good build

On March 11, 2016 1:08 PM Junio C Hamano wrote: > "Pedroso, Osiris" writes: > > > I participate in an open source project that any pull merge is accepted, no > matter what. > > > > This makes for lots of broken builds, even though we do have Travis-CI > enabled on

Re: Possible bug: --ext-diff ignored with --cc in git log

On Fri, Mar 11, 2016 at 11:08:32AM -0800, Junio C Hamano wrote: > Jeff King writes: > > >> It happens that the above is fairly easily doable with today's Git > >> without any modification. Here is how. > >> [...] > > > > I think an even easier way is: > > > > git log --cc

Re: Possible bug: --ext-diff ignored with --cc in git log

Jeff King writes: >> It happens that the above is fairly easily doable with today's Git >> without any modification. Here is how. >> [...] > > I think an even easier way is: > > git log --cc --raw > > I know that is somewhat beside the point you are making, which is how we >

Re: Possible bug: --ext-diff ignored with --cc in git log

On Fri, Mar 11, 2016 at 10:20:42AM -0800, Junio C Hamano wrote: > diff --cc foo.sln > index d7ff46e,6c9aaa1..b829410 > --- a/foo.sln > +++ b/foo.sln > @@@ 1,1 @@@ > - d7ff46ec4a016c6ab7d233b9d4a196ecde623528 - generated file >

Re: [PATCH v4] commit: add a commit.verbose config variable

From: "Pranit Bauva" On Fri, Mar 11, 2016 at 4:31 AM, Eric Sunshine wrote: Add commit.verbose configuration variable as a convenience for those who always prefer --verbose. or something. Sure! As a convenience to reviewers,

Re: [PATCH v2] t/t7502 : drop duplicate test

Pranit Bauva writes: > This extra test was introduced erroneously by > f9c0181 (t7502: test commit.status, --status and > --no-status, 2010-01-13) > > Signed-off-by: Pranit Bauva > --- Thanks. I briefly thought that this might be checking that

Re: Possible bug: --ext-diff ignored with --cc in git log

Vadim Zeitlin writes: > On Thu, 10 Mar 2016 14:33:55 -0800 Junio C Hamano wrote: > > JCH> Vadim Zeitlin writes: > JCH> > JCH> > I.e. the > JCH> > command "git log --ext-diff -p --cc" still outputs the real diff even > for > JCH> >

Re: Ability to remember last known good build

On Fri, Mar 11, 2016 at 10:08 AM, Junio C Hamano wrote: > "Pedroso, Osiris" writes: > >> I participate in an open source project that any pull merge is accepted, no >> matter what. >> >> This makes for lots of broken builds, even though we do

Re: [BUG?] fetch into shallow sends a large number of objects

On Fri, Mar 11, 2016 at 07:47:34AM +0700, Duy Nguyen wrote: > Well, assume again that F and G are ref heads, and their respective > distance to C and D are the same (like the below graph), then "fetch > --deptch=" can mark C and D as shallow cut points because > --depth traverses from refs until

Re: Ability to remember last known good build

"Pedroso, Osiris" writes: > I participate in an open source project that any pull merge is accepted, no > matter what. > > This makes for lots of broken builds, even though we do have Travis-CI > enabled on the project, because people will merge a request before

Ability to remember last known good build

I participate in an open source project that any pull merge is accepted, no matter what. This makes for lots of broken builds, even though we do have Travis-CI enabled on the project, because people will merge a request before even the build is complete. Therefore, I would like to remember

Re: [RFC/PATCH 00/48] Libifying git apply

On Thu, Mar 10, 2016 at 10:26 AM, Duy Nguyen wrote: > On Thu, Mar 10, 2016 at 12:48 AM, Christian Couder > wrote: >> This is a patch series about libifying "git apply" functionality, to >> be able to use this functionality in "git am" without

Re: [BUG?] fetch into shallow sends a large number of objects

Duy Nguyen writes: > Well, assume again that F and G are ref heads, and their respective > distance to C and D are the same (like the below graph), then "fetch > --deptch=" can mark C and D as shallow cut points because > --depth traverses from refs until the distance is met,

Re: Git for collaboration on RDF data

Hello Mark, I realize this is an old post, but I was looking into doing exactly what you are talking about. I did some research into JGIt to see if I could leverage any of that code to create an RDF Git-like experience. I came to the conclusion that I would either need to extend a lot of that

Re: [RFC/PATCH 00/48] Libifying git apply

On Wed, Mar 9, 2016 at 7:14 PM, Junio C Hamano wrote: > Christian Couder writes: > >> One point I'd especially welcome feedback about is the fact that there >> are many boolean options that are using OPT_BOOL(...), so they use an >> int. And there

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

On Fri, Mar 11, 2016 at 7:00 PM, Matthieu Moy wrote: > What Junio says is that you don't need to write > > static int config_autostash = 0; > > since it is equivalent to > > static int config_autostash; > > But there's nothing wrong with having a static variable

Re: Sample pre-push hook can crash

That is interesting, so in the case of a non-ff push, there is no way for a pre-push hook to know what is being pushed in order to run? Steve On Thu, Mar 10, 2016 at 4:43 PM, Junio C Hamano wrote: > Stephen Morton writes: > >> The sample pre-push

[PATCH 2/6] gitweb.perl : added ability to debug requests coming through gitweb interface by adding an option to request URL (also requires server-side envvar "GITWEB_MAY_DEBUG=yes")

--- gitweb/gitweb.perl | 26 +++--- 1 file changed, 23 insertions(+), 3 deletions(-) diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl index 030d429..c715472 100755 --- a/gitweb/gitweb.perl +++ b/gitweb/gitweb.perl @@ -74,6 +74,11 @@ sub evaluate_uri { our

[PATCH 5/6] gitweb.perl changed (and tested) to return HTTP-404 when missing objects are requested via snapshot

--- gitweb/gitweb.perl| 62 +-- t/t9502-gitweb-standalone-parse-output.sh | 24 ++-- 2 files changed, 63 insertions(+), 23 deletions(-) diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl index fc5b62d..2369ae3 100755 ---

[PATCH 1/6] gitweb.perl : added ability to "git archive" just certain paths (files or subdirs, not whole repo) via gitweb interface

--- gitweb/gitweb.perl | 17 + 1 file changed, 17 insertions(+) diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl index 05d7910..030d429 100755 --- a/gitweb/gitweb.perl +++ b/gitweb/gitweb.perl @@ -7328,6 +7328,15 @@ sub git_snapshot { die_error(403,

[PATCH 6/6] gitweb.perl : the optional DEBUG functionality is now unit-tested

--- t/t9502-gitweb-standalone-parse-output.sh | 35 +++ 1 file changed, 35 insertions(+) diff --git a/t/t9502-gitweb-standalone-parse-output.sh b/t/t9502-gitweb-standalone-parse-output.sh index a2ae5c4..4f1ddbf 100755 --- a/t/t9502-gitweb-standalone-parse-output.sh

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

Mehul Jain writes: > On Fri, Mar 11, 2016 at 10:21 AM, Paul Tan wrote: >>> static int config_autostash = -1; >> >> Hmm, why can't config_autostash just default to 0? > > Previously Junio recommended not to explicitly initialize a > static to 0 (or

[PATCH 4/6] gitweb.perl support for snapshots with lists of specified files is now tested

--- t/t9502-gitweb-standalone-parse-output.sh | 156 -- 1 file changed, 148 insertions(+), 8 deletions(-) diff --git a/t/t9502-gitweb-standalone-parse-output.sh b/t/t9502-gitweb-standalone-parse-output.sh index 0796a43..11a116f 100755 ---

[PATCH 3/6] gitweb.perl : added ability to DEBUG progression through "git archive"

--- gitweb/gitweb.perl | 29 + 1 file changed, 29 insertions(+) diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl index c715472..fc5b62d 100755 --- a/gitweb/gitweb.perl +++ b/gitweb/gitweb.perl @@ -891,6 +891,7 @@ sub evaluate_query_params { # now read PATH_INFO

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

On Fri, Mar 11, 2016 at 10:21 AM, Paul Tan wrote: >> static int config_autostash = -1; > > Hmm, why can't config_autostash just default to 0? Previously Junio recommended not to explicitly initialize a static to 0 (or NULL).

Re: [PATCH v4] commit: add a commit.verbose config variable

On 11 March 2016 at 05:44, Eric Sunshine wrote: > On Fri, Mar 11, 2016 at 05:45:27AM +0530, Pranit Bauva wrote: >> Actually I am sending the patches with submitGit herokuapp because my >> institute proxy does not allow IMAP/POP3 connections. Really glad to hear this is

Re: [PATCH v4] commit: add a commit.verbose config variable

On Fri, Mar 11, 2016 at 11:14 AM, Eric Sunshine wrote: > It's a bit tricky if you're not used to it, but check-for-diff > actually does what you want, and does so in a more direct way. While > it's true that it's not an "editor" per se, it does get access to the > entire