Junio C Hamano writes:
> We need to be able to answer "why does '-c color.ui=always' work
> only from the command line?", but I doubt we want to actively
> encourage the use of it, though, so I dunno.
For today's pushout, I've queued this as [PATCH 3/2]
Thanks..
-- >8 --
From: Jonathan Nieder
On Thu, Oct 12, 2017 at 02:42:30PM +0900, Junio C Hamano wrote:
> "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) w
Jonathan Nieder writes:
> 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
"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 (merge:
>> > add a --signoff flag, 2
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 about
> adding some text
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).
>
> I cannot find a v
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. Also I'd call that --
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, "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 insertions(+), 1 deletion(-)
Th
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 a/Documentation/git-stash.txt b/Documentation/git-st
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 reader a bit confused, as the description for
these tw
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(+), 2 deletions(-)
>
> diff --git a/dir.c b/dir.c
> ind
As you point,
git stash
without any argument is equivalent to both of
git stash save
git stash push
. The original sentence is correct.
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
> git stash save and
>
>
> 2
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 that Thais decided to work on th
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
> delet
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 thro
Jameson Miller writes:
> 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 a/Doc
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 shown ignored files are linked to
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 explain what is going on?
>
> I am guessing that Thai
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):
> Teach status options around sh
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" as the way to def
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 fr
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 a/Documentation/config.txt b/
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.
"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 (judging by
the fact that one CC'
"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 merge-options.txt isn't clear to
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 teaching them the older ve
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 different commit) with `g
"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 stash.
I do not think "l
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 o
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 would improve things
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.
>
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 s
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
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 b
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(&push_options,
> item->string))
> +
---
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
+++ b/Documentation/git-push.t
---
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
+++ b/Documentation/git-push.t
I'll still try to make the test as suggested to complete this demand
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 alphabe
"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
---
Documentation/git-s
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 list.
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 s
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.
> However, I never receiv
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 being
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
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".
> >
> > Correct
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
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 one line (but not six), i.e., to d
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 'b
"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
---
Documentation/git-stash.txt | 2 +-
1 file change
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 pager is active.
>
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 the
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 wrote:
>> > It'd
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 of writing a test
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 be added.
>
> Thanks,
> Max
"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
---
Documentation/git-stash.txt | 2 +-
1 file changed
"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
---
Documentation/git-stash.txt | 2 +-
1 file changed
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 changes to a file.
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 `git add -p`.
> - Wh
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 f
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 11:16:3
$ git --version
git version 2.14.2
What more details can I provide to help debug this?
--
Regards,
Ayush Goel
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 pa
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
.git/obje
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' not magically do
> > e
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.
> >
> > However other users of g
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 add"
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
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 pack-objects .git/object
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 (default_push_options)
> +for_each_st
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 a/t/t7519-ignored-mode.sh b/t/t7519-
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 --git a/t/t7519-ignore
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 a/Documentation/git-status.txt b/Documentation
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 b9af87eca9..8636d080b2 100644
--- a/dir.
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 f
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 reported
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(&push_options, item->string))
> +strin
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 messages need adjusting, bu
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 code
David & Maureen picked you for $850.000.00 Donation, Kindly reply for details
and claim.
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(&push_options,
item->string))
+ if
(!unsorted_string_list_has_string(&push_options,
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 t
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 00f95fee1..037144037 100644
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.
>
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:
> >
> > $
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 using
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, E
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;
> @@
> - peel_ref
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.
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 deletion(-)
diff --git a/Documenta
92 matches
Mail list logo