Re: [PATCH] pull: pass --signoff/--no-signoff to "git merge"

"W. Trevor King" writes: > On Thu, Oct 12, 2017 at 10:17:51AM +0900, Junio C Hamano wrote: >> "W. Trevor King" writes: >> >> > Following 09c2cb87 (pull: pass --allow-unrelated-histories to "git >> > merge", 2016-03-18) with the tests also drawing on 14d01b4f

Re: [PATCH 1/2] color: downgrade "always" to "auto" only for on-disk configuration

Junio C Hamano wrote: > Jonathan Nieder writes: >> Should we document this special case treatment of color.* in -c >> somewhere? E.g. > > Perhaps, although I'd save that until we actually add the new option > to "git" potty, which hasn't happened yet, if I were thinking

Re: [PATCH] pull: pass --signoff/--no-signoff to "git merge"

On Thu, Oct 12, 2017 at 10:17:51AM +0900, Junio C Hamano wrote: > "W. Trevor King" writes: > > > Following 09c2cb87 (pull: pass --allow-unrelated-histories to "git > > merge", 2016-03-18) with the tests also drawing on 14d01b4f (merge: > > add a --signoff flag, 2017-07-04). >

Re: [PATCH 1/2] color: downgrade "always" to "auto" only for on-disk configuration

Jonathan Nieder writes: > Should we document this special case treatment of color.* in -c > somewhere? E.g. Perhaps, although I'd save that until we actually add the new option to "git" potty, which hasn't happened yet, if I were thinking about adding some text like that.

Re: [PATCH 1/2] color: downgrade "always" to "auto" only for on-disk configuration

Junio C Hamano wrote: [...] > --- a/color.c > +++ b/color.c > @@ -307,8 +307,21 @@ int git_config_colorbool(const char *var, const char > *value) > if (value) { > if (!strcasecmp(value, "never")) > return 0; > - if (!strcasecmp(value,

Re: [PATCH 2/2] color: discourage use of ui.color=always

Junio C Hamano wrote: > Warn when we read such a configuration from a file, and nudge the > users to spell them 'auto' instead. > > Signed-off-by: Junio C Hamano > --- > Documentation/config.txt | 2 +- > color.c | 7 +++ > 2 files changed, 8

Re: [PATCH] doc: emphasize stash "--keep-index" stashes staged content

Hi, Robert P. J. Day wrote: > It's not immediately obvious from the man page that the "--keep-index" > option still adds the staged content to the stash, so make that > abundantly clear. > > Signed-off-by: Robert P. J. Day > --- > > diff --git

Re: [PATCH v2 5/5] Add tests around status handling of ignored arguments

Jameson Miller writes: > Add tests for status handling of '--ignored=matching` and > `--untracked-files=normal`. > > Signed-off-by: Jameson Miller > --- Hmph, having some tests in 3/5, changes in 4/5 and even more tests in 5/5 makes me as a

Re: [PATCH v2 4/5] Expand support for ignored arguments on status

Jameson Miller writes: > Teach status command to handle matching ignored mode when showing > untracked files with the normal option. > > Signed-off-by: Jameson Miller > --- > dir.c | 20 ++-- > 1 file changed, 18 insertions(+),

Re: [PATCH 1/1] git-stash.txt: correct "git stash" behavior with no arguments

As you point, git stash without any argument is equivalent to both of git stash save git stash push . The original sentence is correct.

Re: [PATCH 1/1] git-stash.txt: correct "git stash" behavior with no arguments

As you point, git stash without any argument is equivalent to both of git stash save git stash push . The original sentence is correct. 2017-10-12 12:31 GMT+09:00 小川恭史 : > As you point, > > git stash > > without any argument is equivalent to both of >

Re: [PATCH][Outreachy] New git config variable to specify string that will be automatically passed as --push-option

Christian Couder writes: >> Can somebody explain what is going on? >> >> I am guessing that Thais and marius are different people (judging by >> the fact that one CC's a message to the other). Are you two >> collaborating on this change, or something? > > I guess

Re: git repack leaks disk space on ENOSPC

Hi Andreas, Andreas Krey wrote: > I observed (again) an annoying behavior of 'git repack': Do you have context for this 'again'? E.g. was this discussed previously on-list? > When the new pack file cannot be fully written because > the disk gets full beforehand, the tmp_pack file isn't >

Re: Unable to use --patch with git add

Hi Ayush, Ayush Goel wrote: > Thank you for your mail. It works :) > > For future reference, is there a page for known issues of git? We usually try not to have known issues that would require such a warning for long. And when we fail, reminders like yours are very welcome, though a search

Re: [PATCH v2 2/5] Update documentation for new directory and status logic

Jameson Miller writes: > Signed-off-by: Jameson Miller > --- > Documentation/git-status.txt | 21 +- > Documentation/technical/api-directory-listing.txt | 27 > +++ > 2 files changed, 43

Re: [PATCH v2 1/5] Teach status options around showing ignored files

Jameson Miller writes: > This change teaches the status command more options to control which > ignored files are reported independently of the which untracked files > are reported by allowing the `--ignored` option to take additional > arguments. Currently, the

Re: [PATCH][Outreachy] New git config variable to specify string that will be automatically passed as --push-option

On Thu, Oct 12, 2017 at 3:21 AM, Junio C Hamano wrote: > "Thais D. Braz" writes: > >> --- >> Documentation/git-push.txt | 3 +++ >> builtin/push.c | 9 - >> 2 files changed, 11 insertions(+), 1 deletion(-) > > Can somebody

Re: [PATCH v2 0/5] Teach Status options around showing ignored files

Jameson Miller writes: > Changes in v2: > > Addressed review comments from the original series: > > * Made fixes / simplifications suggested for documentation > > * Removed test_tick from test scripts > > * Merged 2 commits (as suggested) > > Jameson Miller (5): >

[PATCH 1/2] color: downgrade "always" to "auto" only for on-disk configuration

From: Jeff King An earlier patch downgraded "always" that comes via the ui.color configuration variable to "auto", in order to work around an unfortunate regression to "git add -i". That "fix" however regressed other third-party tools that depend on "git -c color.ui=always cmd"

[PATCH 0/2] Piling more kludge on top of color.ui

Earlier we added a patch to unconditionally downgrade 'always' that is set to the color.ui configuration variable. This was done to correc the unintended regression to "git add -i" that was caused by two earlier mistakes that we no longer can undo. - The "add -i" command wants to parse output

[PATCH 2/2] color: discourage use of ui.color=always

Warn when we read such a configuration from a file, and nudge the users to spell them 'auto' instead. Signed-off-by: Junio C Hamano --- Documentation/config.txt | 2 +- color.c | 7 +++ 2 files changed, 8 insertions(+), 1 deletion(-) diff --git

Hello dear,

Hello dear, I am Miss Makena Jelani. I have very important thing to discuss with you please, this information is very vital. Contact me with my privarte email so we can talk ( makenajel...@hotmail.com ) Makena.

Re: [PATCH][Outreachy] New git config variable to specify string that will be automatically passed as --push-option

"Thais D. Braz" writes: > --- > Documentation/git-push.txt | 3 +++ > builtin/push.c | 9 - > 2 files changed, 11 insertions(+), 1 deletion(-) Can somebody explain what is going on? I am guessing that Thais and marius are different people

Re: [PATCH] pull: pass --signoff/--no-signoff to "git merge"

"W. Trevor King" writes: > Following 09c2cb87 (pull: pass --allow-unrelated-histories to "git > merge", 2016-03-18) with the tests also drawing on 14d01b4f (merge: > add a --signoff flag, 2017-07-04). I cannot find a verb in the above. > The order of options in

Re: [RFC] deprecate git stash save?

Thomas Gummerer writes: > git stash push is the newer interface for creating a stash. While we > are still keeping git stash save around for the time being, it's better > to point new users of git stash to the more modern (and more feature > rich) interface, instead of

Re: [PATCH 1/1] git-stash.txt: correct "git stash" behavior with no arguments

Takahito Ogawa writes: > @@ -33,7 +33,7 @@ and reverts the working directory to match the `HEAD` > commit. > The modifications stashed away by this command can be listed with > `git stash list`, inspected with `git stash show`, and restored > (potentially on top of a

Re: [PATCH] doc: emphasize stash "--keep-index" stashes staged content

"Robert P. J. Day" writes: > -If the `--keep-index` option is used, all changes already added to the > -index are left intact. > +If the `--keep-index` option is used, all changes already staged in the > +index are left intact in the index, while still being added to the

Re: v2.15.0-rc1 test failure

On 11/10/17 23:34, Adam Dinwoodie wrote: [snip] > Hi Ramsay, > > I assume, given you're emailing me, that this is a Cygwin failure? Yes, sorry, I should have made that clear. > t0021.15 has PERL as a requirement, and I see semi-regular failures from > Git tests that are Perl-based in one way

Re: [RFC PATCH 2/4] change submodule push test to use proper repository setup

Heiko Voigt writes: > This "default" value thing got me thinking in a different direction. We > could use a scheme like that to get names (and values) for submodules > that are missing from the .gitmodules file. If we decide that we need to > handle them. Yes, I suspect that

Re: v2.15.0-rc1 test failure

Hi, Adam Dinwoodie wrote: > t0021.15 has PERL as a requirement, and I see semi-regular failures from > Git tests that are Perl-based in one way or another (git-svn tests are > the most common problems). I've not spotted t0021 failing in that way, > but it sounds like the same class of problem.

Re: v2.15.0-rc1 test failure

On Wed, Oct 11, 2017 at 11:15:57PM +0100, Ramsay Jones wrote: > Hi Adam, > > I had a test failure on the v2.15.0-rc1 build tonight. > The test in question being t0021-conversion.sh #15 > ('required process filter should filter data'). I didn't > have any test failures on v2.15.0-rc0, and I don't

Re: v2.15.0-rc1 test failure

On 11/10/17 23:15, Ramsay Jones wrote: > Hi Adam, > > I had a test failure on the v2.15.0-rc1 build tonight. > The test in question being t0021-conversion.sh #15 > ('required process filter should filter data'). I didn't > have any test failures on v2.15.0-rc0, and I don't see > any change that

v2.15.0-rc1 test failure

Hi Adam, I had a test failure on the v2.15.0-rc1 build tonight. The test in question being t0021-conversion.sh #15 ('required process filter should filter data'). I didn't have any test failures on v2.15.0-rc0, and I don't see any change that would have affected this test. Also, I ran this test

Re: Enhancement request: git-push: Allow (configurable) default push-option

On Wed, Oct 11, 2017 at 2:18 AM, Marius Paliga wrote: > Found one possible issue when looking for duplicates, we need to use > "unsorted_string_list_has_string" instead of "string_list_has_string" > > - if (!string_list_has_string(_options, >

[PATCH][Outreachy] New git config variable to specify string that will be automatically passed as --push-option

--- Documentation/git-push.txt | 3 +++ builtin/push.c | 9 - 2 files changed, 11 insertions(+), 1 deletion(-) diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt index 3e76e99f3..e1036feaf 100644 --- a/Documentation/git-push.txt +++

[PATCH][Outreachy] New git config variable to specify string that will be automatically passed as --push-option

--- Documentation/git-push.txt | 3 +++ builtin/push.c | 9 - 2 files changed, 11 insertions(+), 1 deletion(-) diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt index 3e76e99f3..e1036feaf 100644 --- a/Documentation/git-push.txt +++

[no subject]

I'll still try to make the test as suggested to complete this demand

[PATCH] pull: pass --signoff/--no-signoff to "git merge"

Following 09c2cb87 (pull: pass --allow-unrelated-histories to "git merge", 2016-03-18) with the tests also drawing on 14d01b4f (merge: add a --signoff flag, 2017-07-04). The order of options in merge-options.txt isn't clear to me, but I've put --signoff between --log and --stat as somewhat

[PATCH 1/1] git-stash.txt: correct "git stash" behavior with no arguments

"git stash" behavior without any arguments was changed in 1ada5020b ("stash: use stash_push for no verb form", 2017-02-28). This is equivalent to "git stash push" but documents says "git stash save". Correct it. Reviewed-by: Thomas Gummerer Signed-off-by: Takahito Ogawa

Re: Fwd: how can I conform if I succeed in sending patch to mailing list

On 10/12, 小川恭史 wrote: > Hello, I found a mistake in documents, fixed it, and send patch to mailing > list. > > Sending patches by 'git send-email' with Gmail smtp seemed to be > successful because CC included my email address and I received it. > However, I never received email from mailing

Re: slight addition to t.gummerer's proposed "git stash" patch

On Wed, 11 Oct 2017, Thomas Gummerer wrote: > On 10/11, Robert P. J. Day wrote: > > > > was perusing thomas gummerer's proposed "git stash" patch here: > > > > https://www.spinics.net/lists/git/msg313993.html > > > > and i'd make one more change -- i'd separate the OPTIONS entries for > > "git

Re: Fwd: how can I conform if I succeed in sending patch to mailing list

On Thu, 12 Oct 2017 04:14:18 +0900 小川恭史 wrote: > Hello, I found a mistake in documents, fixed it, and send patch to mailing > list. > > Sending patches by 'git send-email' with Gmail smtp seemed to be > successful because CC included my email address and I received it.

Re: slight addition to t.gummerer's proposed "git stash" patch

On 10/11, Robert P. J. Day wrote: > > was perusing thomas gummerer's proposed "git stash" patch here: > > https://www.spinics.net/lists/git/msg313993.html > > and i'd make one more change -- i'd separate the OPTIONS entries for > "git stash push" and "git stash save" so they don't end up

Fwd: how can I conform if I succeed in sending patch to mailing list

Hello, I found a mistake in documents, fixed it, and send patch to mailing list. Sending patches by 'git send-email' with Gmail smtp seemed to be successful because CC included my email address and I received it. However, I never received email from mailing list. Of course I'm subscribing mailing

Re: [PATCH 1/1] git-stash.txt: correct "git stash" behavior with no arguments

On 10/11, Thomas Gummerer wrote: > On 10/12, Takahito Ogawa wrote: > > "git stash" behavior without any arguments was changed in > > 1ada5020b ("stash: use stash_push for no verb form", 2017-02-28). > > This is equivalent to "git stash push" but documents says > > "git stash save". > > > >

Re: [PATCH 1/1] git-stash.txt: correct "git stash" behavior with no arguments

On 10/12, Takahito Ogawa wrote: > "git stash" behavior without any arguments was changed in > 1ada5020b ("stash: use stash_push for no verb form", 2017-02-28). > This is equivalent to "git stash push" but documents says > "git stash save". > > Correct it. Thanks for fixing this! I recently sent

Re: [PATCH] column: show auto columns when pager is active

On 11 October 2017 at 20:36, Kevin Daudt wrote: > On Wed, Oct 11, 2017 at 08:12:35PM +0200, Martin Ågren wrote: >> On 11 October 2017 at 19:23, Kevin Daudt wrote: >> I wonder if it's useful to set COLUMNS a bit lower so that this has to >> split across more than

Re: Unable to use --patch with git add

On Wed, Oct 11, 2017 at 11:16:39PM +0530, Ayush Goel wrote: > $ git --version > git version 2.14.2 > > What more details can I provide to help debug this? > Hello Ayush, Run: git config --global color.ui auto git config --unset --local color.ui #in case it's set locally This is a known

[PATCH 1/1] git-stash.txt: correct "git stash" behavior with no arguments

"git stash" behavior without any arguments was changed in 1ada5020b ("stash: use stash_push for no verb form", 2017-02-28). This is equivalent to "git stash push" but documents says "git stash save". Correct it. Signed-off-by: Takahito Ogawa ---

Re: [PATCH] column: show auto columns when pager is active

On Wed, Oct 11, 2017 at 08:12:35PM +0200, Martin Ågren wrote: > On 11 October 2017 at 19:23, Kevin Daudt wrote: > > finalize_colopts in column.c only checks whether the output is a TTY to > > determine if columns should be enabled with columns set to auto. Also check > > if the

Re: Unable to use --patch with git add

On Wed, Oct 11, 2017 at 11:43:46PM +0530, Ayush Goel wrote: > Thank you for your mail. It works :) > > For future reference, is there a page for known issues of git? No, there's just the mailing list archive. But you can search it. E.g.: https://public-inbox.org/git/?q=%22add+-p%22 finds

Re: Unable to use --patch with git add

Hey Jeff, Thank you for your mail. It works :) For future reference, is there a page for known issues of git? On Wed, Oct 11, 2017 at 11:30 PM, Jeff King wrote: > On Wed, Oct 11, 2017 at 11:25:52PM +0530, Ayush Goel wrote: > >> On Wed, Oct 11, 2017 at 11:19 PM, Santiago Torres

Re: [PATCH] column: show auto columns when pager is active

On 11 October 2017 at 19:23, Kevin Daudt wrote: > finalize_colopts in column.c only checks whether the output is a TTY to > determine if columns should be enabled with columns set to auto. Also check > if the pager is active. Maybe you could say something about the difficulties

Re: No log --no-decorate completion?

On Wed, Oct 11, 2017 at 7:47 AM, Max Rothman wrote: > I recently noticed that in the git-completion script, there's > completion for --decorate={full,yes,no} for git log and family, but > not for --no-decorate. Is that intentional? If not, I *think* I see > how it could

[PATCH 1/1] git-stash.txt: correct "git stash" behavior with no arguments

"git stash" behavior without any arguments was changed in 1ada5020b ("stash: use stash_push for no verb form", 2017-02-28). This is equivalent to "git stash push" but document says "git stash save". Correct it. Signed-off-by: Takahito Ogawa ---

[PATCH 1/1] git-stash.txt: correct "git stash" behavior with no arguments

"git stash" behavior without any arguments was changed in 1ada5020b ("stash: use stash_push for no verb form", 2017-02-28). This is equivalent to "git stash push" but document says "git stash save". Correct it. Signed-off-by: Takahito Ogawa ---

Re: Unable to use --patch with git add

On Wed, Oct 11, 2017 at 11:25:52PM +0530, Ayush Goel wrote: > On Wed, Oct 11, 2017 at 11:19 PM, Santiago Torres wrote: > > It'd be helpful to know: > > > > - What did you do? > > I have recently updated to git version 2.14.2. The problem started > happening after that. > Made

Re: Unable to use --patch with git add

Hello Santiago, Thank you for picking this up. On Wed, Oct 11, 2017 at 11:19 PM, Santiago Torres wrote: > It'd be helpful to know: > > - What did you do? I have recently updated to git version 2.14.2. The problem started happening after that. Made changes to a file. Tried

Re: Award

From: Abraham, Jimmy Sent: Wednesday, October 11, 2017 11:11 AM Subject: Award Reply for details on award. CONFIDENTIALITY NOTICE: This email message and any accompanying data or files is confidential and may contain privileged information intended only

Re: Unable to use --patch with git add

It'd be helpful to know: - What did you do? - What did you expect to happen? - What happened instead? I suspect you are using --patch with a new file, so you probably need to first add it with -N or so. This is just a shot in the dark though... Thanks, -Santiago. On Wed, Oct 11, 2017 at

Unable to use --patch with git add

$ git --version git version 2.14.2 What more details can I provide to help debug this? -- Regards, Ayush Goel

[PATCH] column: show auto columns when pager is active

When columns are set to automatic for git tag and the output is paginated by git, the output is a single column instead of multiple columns. Standard behaviour in git is to honor auto values when the pager is active, which happens for example with commands like git log showing colors when being

git repack leaks disk space on ENOSPC

Hi all, I observed (again) an annoying behavior of 'git repack': When the new pack file cannot be fully written because the disk gets full beforehand, the tmp_pack file isn't deleted, meaning the disk stays full: $ df -h .; git repack -ad; df -h .; ls -lart .git/objects/pack/tmp*; rm

Re: [RFC PATCH 2/4] change submodule push test to use proper repository setup

On Tue, Oct 10, 2017 at 11:39:21AM -0700, Stefan Beller wrote: > On Tue, Oct 10, 2017 at 6:03 AM, Heiko Voigt wrote: > > but in the long run my goal > > for submodules is and always was: Make them behave as close to files as > > possible. And why should a 'git add submodule'

Re: [RFC PATCH 2/4] change submodule push test to use proper repository setup

On Wed, Oct 11, 2017 at 08:31:37AM +0900, Junio C Hamano wrote: > Stefan Beller writes: > > > So you propose to make git-add behave like "git submodule add" > > (i.e. also add the .gitmodules entry for name/path/URL), which I > > like from a submodule perspective. > > > >

Re: [RFC PATCH 2/4] change submodule push test to use proper repository setup

On Tue, Oct 10, 2017 at 11:39:21AM -0700, Stefan Beller wrote: > So you propose to make git-add behave like "git submodule add" > (i.e. also add the .gitmodules entry for name/path/URL), which I > like from a submodule perspective. Well more like: clone and add will behave like "git submodule

No log --no-decorate completion?

I recently noticed that in the git-completion script, there's completion for --decorate={full,yes,no} for git log and family, but not for --no-decorate. Is that intentional? If not, I *think* I see how it could be added. Thanks, Max

Re: [PATCH v4 4/4] sha1_name: minimize OID comparisons during disambiguation

On 10/10/2017 9:30 AM, Jeff King wrote: On Tue, Oct 10, 2017 at 09:11:15AM -0400, Derrick Stolee wrote: On 10/10/2017 8:56 AM, Junio C Hamano wrote: Jeff King writes: OK, I think that makes more sense. But note the p->num_objects thing I mentioned. If I do: git

Re: Enhancement request: git-push: Allow (configurable) default push-option

Marius Paliga writes: > @@ -505,6 +509,12 @@ static int git_push_config(const char *k, const > char *v, void *cb) > recurse_submodules = val; > } > > +default_push_options = git_config_get_value_multi("push.optiondefault"); > +if

[PATCH v2 5/5] Add tests around status handling of ignored arguments

Add tests for status handling of '--ignored=matching` and `--untracked-files=normal`. Signed-off-by: Jameson Miller --- t/t7519-ignored-mode.sh | 60 - 1 file changed, 59 insertions(+), 1 deletion(-) diff --git

[PATCH v2 3/5] Add tests for git status `--ignored=matching`

Add tests for new ignored mode (matching) when showing all untracked files. Signed-off-by: Jameson Miller --- t/t7519-ignored-mode.sh | 125 1 file changed, 125 insertions(+) create mode 100755 t/t7519-ignored-mode.sh diff

[PATCH v2 2/5] Update documentation for new directory and status logic

Signed-off-by: Jameson Miller --- Documentation/git-status.txt | 21 +- Documentation/technical/api-directory-listing.txt | 27 +++ 2 files changed, 43 insertions(+), 5 deletions(-) diff --git

[PATCH v2 4/5] Expand support for ignored arguments on status

Teach status command to handle matching ignored mode when showing untracked files with the normal option. Signed-off-by: Jameson Miller --- dir.c | 20 ++-- 1 file changed, 18 insertions(+), 2 deletions(-) diff --git a/dir.c b/dir.c index

[PATCH v2 0/5] Teach Status options around showing ignored files

Changes in v2: Addressed review comments from the original series: * Made fixes / simplifications suggested for documentation * Removed test_tick from test scripts * Merged 2 commits (as suggested) Jameson Miller (5): Teach status options around showing ignored files Update documentation

[PATCH v2 1/5] Teach status options around showing ignored files

This change teaches the status command more options to control which ignored files are reported independently of the which untracked files are reported by allowing the `--ignored` option to take additional arguments. Currently, the shown ignored files are linked to how untracked files are

Re: Enhancement request: git-push: Allow (configurable) default push-option

Marius Paliga writes: > +default_push_options = git_config_get_value_multi("push.optiondefault"); > +if (default_push_options) > +for_each_string_list_item(item, default_push_options) > +if (!string_list_has_string(_options, item->string)) > +

Re: [PATCH v2 00/24] object_id part 10

Michael Haggerty writes: > I took a stab at rebasing this patch series on top of current master > using `git-imerge`. I pushed the results to my GitHub fork [1] as branch > `object-id-part-10-rebased`. I didn't check the results very carefully, > nor whether the commit

Re: [PATCH v2 00/24] object_id part 10

On 10/09/2017 03:11 AM, brian m. carlson wrote: > This is the tenth in a series of patches to convert from unsigned char > [20] to struct object_id. This series mostly involves changes to the > refs code. After these changes, there are almost no references to > unsigned char in the main refs

$850.000.00 Donation !.

David & Maureen picked you for $850.000.00 Donation, Kindly reply for details and claim.

Re: Enhancement request: git-push: Allow (configurable) default push-option

Found one possible issue when looking for duplicates, we need to use "unsorted_string_list_has_string" instead of "string_list_has_string" - if (!string_list_has_string(_options, item->string)) + if (!unsorted_string_list_has_string(_options,

slight addition to t.gummerer's proposed "git stash" patch

was perusing thomas gummerer's proposed "git stash" patch here: https://www.spinics.net/lists/git/msg313993.html and i'd make one more change -- i'd separate the OPTIONS entries for "git stash push" and "git stash save" so they don't end up being rendered all crushed together when displaying

[PATCH] doc: emphasize stash "--keep-index" stashes staged content

It's not immediately obvious from the man page that the "--keep-index" option still adds the staged content to the stash, so make that abundantly clear. Signed-off-by: Robert P. J. Day --- diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt index

Re: [PATCH v2 24/24] refs/files-backend: convert static functions to object_id

On 10/09/2017 03:11 AM, brian m. carlson wrote: > Convert several static functions to take pointers to struct object_id. > Change the relevant parameters to write_packed_entry to be const, as we > don't modify them. Rename lock_ref_sha1_basic to lock_ref_oid_basic to > reflect its new argument. >

Re: "git rm" seems to do recursive removal even without "-r"

On Tue, 10 Oct 2017, Heiko Voigt wrote: > On Sun, Oct 08, 2017 at 07:56:20AM -0400, Robert P. J. Day wrote: > > but as i asked in my earlier post, if i wanted to remove *all* files > > with names of "Makefile*", why can't i use: > > > > $ git rm 'Makefile*' > > > > just as i used: > > > > $

Re: [PATCH v2 23/24] refs: convert read_raw_ref backends to struct object_id

On 10/09/2017 03:11 AM, brian m. carlson wrote: > Convert the unsigned char * parameter to struct object_id * for > files_read_raw_ref and packed_read_raw-ref. Update the documentation. Nit: s/packed_read_raw-ref/packed_read_raw_ref/ > Switch from using get_sha1_hex and a hard-coded 40 to

Re: [PATCH v2 21/24] refs: convert resolve_ref_unsafe to struct object_id

On 10/09/2017 03:11 AM, brian m. carlson wrote: > Convert resolve_ref_unsafe to take a pointer to struct object_id by > converting one remaining caller to use struct object_id, converting the > declaration and definition, and applying the following semantic patch: > > @@ > expression E1, E2, E3,

Re: [PATCH v2 14/24] refs: convert peel_ref to struct object_id

On 10/09/2017 03:11 AM, brian m. carlson wrote: > Convert peel_ref (and its corresponding backend) to struct object_id. > > This transformation was done with an update to the declaration, > definition, and test helper and the following semantic patch: > > @@ > expression E1, E2; > @@ > -

[ANNOUNCE] Git Rev News edition 32

Hi everyone, The 32st edition of Git Rev News is now published: https://git.github.io/rev_news/2017/10/11/edition-32/ Thanks a lot to all the contributors and helpers! Enjoy, Christian, Thomas, Jakub and Markus.

Re: Enhancement request: git-push: Allow (configurable) default push-option

Including proposed patch... Signed-off-by: Marius Paliga --- Documentation/git-push.txt | 3 +++ builtin/push.c | 11 ++- t/t5545-push-options.sh| 48 ++ 3 files changed, 61 insertions(+), 1

Re: [PATCH v2 05/24] refs: update ref transactions to use struct object_id

On 10/09/2017 03:11 AM, brian m. carlson wrote: > Update the ref transaction code to use struct object_id. Remove one > NULL pointer check which was previously inserted around a dereference; > since we now pass a pointer to struct object_id directly through, the > code we're calling handles this

What's cooking in git.git (Oct 2017, #02; Wed, 11)

Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. The ones marked with '.' do not appear in any of the integration branches, but I am still holding onto them. 2.15-rc1 has been tagged. Some

[ANNOUNCE] Git v2.15.0-rc1

A release candidate Git v2.15.0-rc1 is now available for testing at the usual places. It is comprised of 721 non-merge commits since v2.14.0, contributed by 72 people, 22 of which are new faces. The tarballs are found at: https://www.kernel.org/pub/software/scm/git/testing/ The following

Re: [PATCH v2 04/24] refs: convert update_ref and refs_update_ref to use struct object_id

On 10/09/2017 03:11 AM, brian m. carlson wrote: > Convert update_ref, refs_update_ref, and write_pseudoref to use struct > object_id. Update the existing callers as well. Remove update_ref_oid, > as it is no longer needed. > > Signed-off-by: brian m. carlson > ---

Re: [PATCH v3] run-command: add hint when a hook is ignored

Junio C Hamano writes: > Quite honestly, I do not particulary think this is confusing, and I > expect that this change will irritate many people by forcing them to > either set the advise config or move the ones that they deliberately > left unexecutable by renaming them by

Re: [PATCH 1/2] describe: do not use cmd_*() as a subroutine

SZEDER Gábor writes: > Maybe you already considered all this WRT that cmd_name_rev() call, I > don't know. In any case, I think at least the subject line should > spell out cmd_diff_index(). Perhaps. The intent was to eradicate cmd_*() used as a subroutine, so I'd rather