On Sat, Mar 2, 2019 at 4:09 PM Thomas Gummerer wrote:
>
> On 03/01, Duy Nguyen wrote:
> > On Fri, Mar 1, 2019 at 5:20 AM Christian Couder
> > wrote:
> > >
> > > Hi Matheus,
> > >
> > > On Thu, Feb 28, 2019 at 10:46 PM Matheus Tavares Bernardino
> > > wrote:
> > > >
> > > > I've been in the maili
On Sat, Mar 2, 2019 at 4:19 PM Johannes Schindelin via GitGitGadget
wrote:
> The --stress option currently accepts an argument, but it is confusing
> to at least this user that the argument does not define the maximal
> number of stress iterations, but instead the number of jobs to run in
> parall
Jeff King writes:
> Wouldn't that mean all of the file data is available in the object
> database? Unfortunately without an index, there's nothing to mark which
> file was which. But `git fsck --lost-found` should copy out all of the
> file content into .git/lost-found.
If we had a hierachically
Phillip Wood writes:
> Thanks for explaining, it all makes sense to me now
It would be necessary to make sure that it all makes sense to all
future readers. Are they patches good enough as-is for that, or do
they need some updates before I take a look at them to pick up?
SZEDER Gábor wrote:
[... lots of good history ...]
Thanks for an excellent summary!
> Note, however, that for completeness sake, if we choose to update
> list_cmds_by_config() to read the repo's config as well, then we
> should also update the completion script to run $(__git
> --list-cmds=...),
Elijah Newren writes:
> Whatever we choose for the default could be tweaked by some new option
> (e.g. make it less noisy or don't mark such paths as conflicted if the
> user has explicitly stated their preference for or against directory
> rename detection). I'm struggling to see directory rena
"brian m. carlson" writes:
> On Wed, Feb 27, 2019 at 07:17:51PM +0100, Martin Ågren wrote:
>> Just like v1 [1], this v2 removes a spurious space which shows up in a
>> large number of places in our manpages when Asciidoctor expands the
>> linkgit:foo[bar] macro. The only difference is a new parag
Thomas Gummerer writes:
> As I was advocating for this series to go into 'next' without a large
> refactor of this series, I'll put my money were my mouth is and try to
> make the cleanups and fixes required, though without trying to avoid
> further external process calls, or changing the series
Thomas Gummerer writes:
> One thing that came up in the latest reviews, was to keep the stash
> script intact throughout the series, and to not re-introduce it after
> deleting it. I did however not do that, as that would make the
> range-diff quite a bit harder to read.
Of course, if you start
Martin Ågren writes:
> On Thu, 28 Feb 2019 at 03:44, Kyle Meyer wrote:
>
>> Change it to "linkgit" so that the reference is properly rendered.
>
>> have `` as direct ancestor will keep their original branch point,
>> -i.e. commits that would be excluded by gitlink:git-log[1]'s
>> +i.e. commits
Jeff King writes:
> This is a pretty horrible UI trap. Most of the time with pathspecs we
> require them to be on the right-hand side of a "--" unless the paths
> actually exist in the filesystem. But then, in most of those cases we're
> making sure they're not ambiguous between revisions and pat
Jeff King writes:
> I agree that sanitize_refname_format() would be nice, but I'm pretty
> sure it's going to end up having to duplicate many of the rules from
> check_refname_format(). Which is ugly if the two ever get out of sync.
>
> But if we could write it in a way that keeps the actual poli
Jeff King writes:
> On Fri, Feb 22, 2019 at 06:50:06PM +0300, Olga Telezhnaya wrote:
>
>> In my opinion, it still has some issues. I mentioned all of them in
>> TODOs in comments. All of them considered to be separate tasks for
>> other patches. Some of them sound easy and could be great tasks fo
"Johannes Schindelin via GitGitGadget"
writes:
> From: Johannes Schindelin
>
> This fixes an issue pointed out by clang.
>
> Signed-off-by: Johannes Schindelin
> ---
> upload-pack.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/upload-pack.c b/upload-pack.c
> index 2
Jeff King writes:
> But for git-fetch, our primary purpose is receiving data and writing it
> to disk. We should be checking all of our write()s already, and SIGPIPE
> is just confusing.
Yup, sounds like a very sensible argument.
> So I'd actually be fine with just declaring that certain comman
On Tue, Feb 26, 2019 at 12:05:34PM +0100, Andrej Shadura wrote:
> The colours gitk is currently using are from the basic 16 colour
> palette, and are a bit too intensive to be comfortable or pleasant
> to work with.
>
> Adjust the main colours (commit nodes, remotes, tags and one branch
> colour)
"Johannes Schindelin via GitGitGadget"
writes:
> Back when we stopped using MakeMaker, we forgot one reference...
>
> Johannes Schindelin (1):
> mingw: drop MakeMaker reference
>
> config.mak.uname | 1 -
> 1 file changed, 1 deletion(-)
>
>
> base-commit: 8104ec994ea3849a968b4667d072fedd1e6886
Fernando Chorney writes:
> Hmm looks like I forgot to send my reply to this back to the mailing list.
>
> "Hmm, so I currently have it set to run vim as my commit editor, and
> enter the message in there most of the time. I can definitely see
> output from the hook into the shell before my vim ed
Taylor Blau writes:
> Invocations of 'git config ' print a trailing newline after
> writing the value assigned to the given configuration variable.
>
> This has an unexpected interaction with 63e2a0f8e9 (builtin/config:
> introduce `color` type specifier, 2018-04-09), which causes a newline to
>
On Fri, Mar 01, 2019 at 06:19:48AM +, Wendeborn, Jonathan wrote:
> Hi,
>
> I have a problem with fast-import on an NTFS drive: If I try to import tags
> which are identical apart from their casing a failure due to identical lock
> file names occurs.
>
> I am running git for windows 2.15.1.2
Hi Junio,
On Thu, Feb 28, 2019 at 6:52 PM Junio C Hamano wrote:
>
> As you know that I've always been skeptical to this rename-directory
> business, this probably won't come as a surprise, but I seriously
> think directory renames should be made opt-in, and as a separate
> option, making the opti
Hi all,
I am trying to figure out how the crc32 value is calculated for deltified
objects.
It appears that the crc32 value is updated in the use() function. After
calculating the header, the unpack_raw_entry() function will call
unpack_entry_data(). This function inflates the delta object and cal
Hi Alban,
On Fri, 1 Mar 2019, Alban Gruin wrote:
> name_rev() is a recursive function. For each commit, it allocates the
> name of its parents, and call itself. A parent may not use a name for
> multiple reasons, but in any case, the name will not be released. On a
> repository with a lot of b
Hi Peff,
On Fri, 1 Mar 2019, Jeff King wrote:
> diff --git a/builtin/fetch.c b/builtin/fetch.c
> index b620fd54b4..4ba63d5ac6 100644
> --- a/builtin/fetch.c
> +++ b/builtin/fetch.c
> @@ -1556,7 +1556,9 @@ static int fetch_one(struct remote *remote, int argc,
> const char **argv, int pru
>
>
From: Johannes Schindelin
It does not make much sense that running a test with
--stress-limit= seemingly ignores that option because it does not
stress test at all.
Signed-off-by: Johannes Schindelin
---
t/test-lib.sh | 1 +
1 file changed, 1 insertion(+)
diff --git a/t/test-lib.sh b/t/test-l
From: Johannes Schindelin
The --stress option currently accepts an argument, but it is confusing
to at least this user that the argument does not define the maximal
number of stress iterations, but instead the number of jobs to run in
parallel per stress iteration.
Let's introduce a separate opt
If my mistake using --stress= instead of --stress-limit= is any indication,
then the current options are very confusing.
This is my attempt at making them less confusing.
Johannes Schindelin (2):
tests: let --stress-limit= imply --stress
tests: introduce --stress-jobs=
t/test-lib.sh | 9 +++
Hi Taylor,
On Fri, 1 Mar 2019, Taylor Blau wrote:
> Invocations of 'git config ' print a trailing newline after
> writing the value assigned to the given configuration variable.
>
> This has an unexpected interaction with 63e2a0f8e9 (builtin/config:
> introduce `color` type specifier, 2018-04-09
Hi Peff,
On Fri, 1 Mar 2019, Jeff King wrote:
> On Fri, Mar 01, 2019 at 11:57:46AM -0800, Johannes Schindelin via
> GitGitGadget wrote:
>
> > In d85b0dff72 (Makefile: use `find` to determine static header
> > dependencies, 2014-08-25), we switched from a static list of header
> > files to a dyn
Hi Peff,
On Fri, 1 Mar 2019, Jeff King wrote:
> On Fri, Mar 01, 2019 at 04:36:19PM -0500, Jeff King wrote:
>
> > > This has one notable consequence: we no longer include
> > > `command-list.h` in `LIB_H`, as it is a generated file, not a
> > > tracked one.
> >
> > We should be able to add back
Hi Peff,
On Fri, 1 Mar 2019, Jeff King wrote:
> On Fri, Mar 01, 2019 at 04:54:15PM -0500, Jeff King wrote:
>
> > The one thing we do lose, though, is make's parallelization. It would
> > probably be possible to actually shove this into a sub-make which
> > defined the hdr-check rules, but I don'
my lovely friend,
how are you doing.my name is Sherry Mars. i want to tell you something is very
important and good okay. so if you are interested contact me on this email
address okay (sherrymars...@gmail.com) is very important talk.
Hey! Thomas
Thank you for replying over my woes.
>
> It is up to you how far you would like to go with this. If you want
> to add the helper, to make further cleanups in t3600, I think that
> would be a good thing to do (after double checking that it would be
> useful in other test files as well
On 03/01, Duy Nguyen wrote:
> On Fri, Mar 1, 2019 at 5:20 AM Christian Couder
> wrote:
> >
> > Hi Matheus,
> >
> > On Thu, Feb 28, 2019 at 10:46 PM Matheus Tavares Bernardino
> > wrote:
> > >
> > > I've been in the mailing list for a couple weeks now, mainly working
> > > on my gsoc micro-project
On 03/01, Rohit Ashiwal wrote:
> Hey!
>
> I'm a little confused as you never provide a clear indication to
> where shall I proceed? :-
>
> On Fri, 01 Mar 2019 11:51:46 +0900 Junio C Hamano wrote:
> > I think you are talking about t3600, which uses an ancient style.
> > If this were a real projec
On Fri, Mar 1, 2019 at 7:41 PM Taylor Blau wrote:
> [...]
> In this case, printing a terminating newline is not desirable. Callers
> may want to print out such a configuration variable in a sub-shell in
> order to color something else, in which case they certainly don't want a
> newline.
It's ext
Signed-off-by: Robert P. J. Day
---
diff --git a/Documentation/git-gc.txt b/Documentation/git-gc.txt
index a7442499f6..a7c1b0f60e 100644
--- a/Documentation/git-gc.txt
+++ b/Documentation/git-gc.txt
@@ -76,7 +76,7 @@ be performed as well.
--prune=::
Prune loose objects older than date
more pedantry, but digging through "git gc", the man page reads:
--prune=
Prune loose objects older than date (default is 2 weeks
ago, overridable by the config variable gc.pruneExpire).
--prune=all prunes loose objects regardless of their age
38 matches
Mail list logo
