On Sat, Mar 17, 2018 at 6:22 PM, Thomas Gummerer wrote:
> Currently there is no indication in the "git worktree add" output that
> a new branch was created. This would be especially useful information
> in the case where the dwim of "git worktree add " kicks in, as the
> user didn't explicitly as
On Sat, Mar 17, 2018 at 6:22 PM, Thomas Gummerer wrote:
> [...]
> Fix these inconsistencies, and no longer show the identifier by making
> the 'git reset --hard' call quiet, and printing the message directly
> from the builtin command instead.
>
> Signed-off-by: Thomas Gummerer
> ---
> diff --git
On Mon, Mar 19, 2018 at 10:21:56AM +, Phillip Wood wrote:
> I've just been reviewing some patches with 'git log --graph --patch' and
> came across what looked like a bug:
>
> | @@ -272,6 +272,9 @@ do
> | --keep-empty)
> | keep_empty=yes
> | ;;
> | --all
On Sat, Mar 17, 2018 at 12:00:26AM +0100, Ævar Arnfjörð Bjarmason wrote:
>
> On Fri, Mar 16 2018, Jeff King jotted:
>
> > I really like the idea of being able to send our machine-readable output
> > in some "standard" syntax for which people may already have parsers. But
> > one big hangup with
On Mon, Mar 19, 2018 at 06:19:26AM -0400, Jeff Hostetler wrote:
> > To make the above work, I think you'd have to store a little more state.
> > E.g., the "array_append" functions check "out->len" to see if they need
> > to add a separating comma. That wouldn't work if we might be part of a
> > ne
On Sun, Mar 18, 2018 at 04:55:25PM +0100, Duy Nguyen wrote:
> On Sun, Mar 18, 2018 at 9:18 AM, Nguyễn Thái Ngọc Duy
> wrote:
> > +ifneq ($(or $(filter gcc6,$(COMPILER_FEATURES)),$(filter
> > clang4,$(COMPILER_FEATURES))),)
> > +CFLAGS += -Wextra
>
> Another thing we can add here is -Og instead
On Sat, Mar 17, 2018 at 11:05:59PM +0100, Ævar Arnfjörð Bjarmason wrote:
> Splitting this off into its own thread. Aside from the improvements in
> your repack memory reduction (20180317141033.21545-1-pclo...@gmail.com)
> and gc config (20180316192745.19557-1-pclo...@gmail.com) series's I'm
> wond
> So I think the "recommended subset" is basically "everything but these
> few constructs". We just need to document them. ;)
Mentioned so-far/running list?
- Matching directories recursively, or at all I guess (e.g. "/")
- (???) Instead: "/*"
- Negative matches
- (???) Instead: Is there any
On Tue, Mar 20, 2018 at 12:25:27AM -0400, Dakota Hawkins wrote:
> > Right. The technical reason is mostly "that is not how it was designed,
> > and it would possibly break some corner cases if we switched it now".
>
> I'm just spitballing here, but do you guys think there's any subset of
> the co
On Mon, Mar 19, 2018 at 05:56:11PM +, Ramsay Jones wrote:
> For the purposes of this discussion, the ce_write_entry() function has
> three code blocks of interest, that look like so:
>
> /* block #1 */
> if (ce->ce_flags & CE_STRIP_NAME) {
> saved_namelen = ce_
On Mon, Mar 19, 2018 at 05:53:09PM +, Ramsay Jones wrote:
> This series removes all 'self-initialised' variables (ie. var = var;).
> This construct has been used to silence gcc '-W[maybe-]uninitialized' warnings
> in the past [1]. Unfortunately, this construct causes warnings to be issued by
That's perfect, thank you so much!
On Tue, Mar 20, 2018 at 12:14 AM, Jeff King wrote:
> On Tue, Mar 20, 2018 at 12:04:11AM -0400, Jeff King wrote:
>
>> > I guess my takeaway is that it would be _good_ if the gitattributes
>> > documentation contained the caveat about not matching directories
>> >
> Right. The technical reason is mostly "that is not how it was designed,
> and it would possibly break some corner cases if we switched it now".
I'm just spitballing here, but do you guys think there's any subset of
the combined .gitignore and .gitattributes matching functionality that
could at l
On Mon, Mar 19, 2018 at 03:39:46PM +, CB Bailey wrote:
> > diff --git a/git-filter-branch.sh b/git-filter-branch.sh
> > index 1b7e4b2cd..21d84eff3 100755
> > --- a/git-filter-branch.sh
> > +++ b/git-filter-branch.sh
> > @@ -627,7 +627,7 @@ then
> > print H "$_:$f\n"
On Tue, Mar 20, 2018 at 12:04:11AM -0400, Jeff King wrote:
> > I guess my takeaway is that it would be _good_ if the gitattributes
> > documentation contained the caveat about not matching directories
> > recursively, but _great_ if gitattributes and gitignore (and whatever
> > else there is) were
On Mon, Mar 19, 2018 at 11:17:04PM -0400, Dakota Hawkins wrote:
> Sorry to tack on to my previous email, but I just thought of this:
>
> If something like "-diff=lfs" won't do what I (and git-lfs) thought it
> would, do you think it would be prudent/reasonable to suggest git-lfs
> add a "no-lfs"
On Mon, Mar 19, 2018 at 11:10:26PM -0400, Dakota Hawkins wrote:
> > As you noted below, that second line does not match your path, because
> > attributes on a directory aren't applied recursively. And it has nothing
> > to do with overriding. If you remove the png line entirely, you can see
> > th
On Mon, Mar 19, 2018 at 08:33:15PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > The best you can probably do is:
> >
> > /.readme-docs/* diff=foo
> >
> > Since you have no diff.foo.* config, that will behave in the default way
> > (including respecting the usual "is it binary" checks
On Mon, Mar 19, 2018 at 11:33 PM, Junio C Hamano wrote:
> Jeff King writes:
>
>> The best you can probably do is:
>>
>> /.readme-docs/* diff=foo
>>
>> Since you have no diff.foo.* config, that will behave in the default way
>> (including respecting the usual "is it binary" checks). So a bit hac
Jeff King writes:
> The best you can probably do is:
>
> /.readme-docs/* diff=foo
>
> Since you have no diff.foo.* config, that will behave in the default way
> (including respecting the usual "is it binary" checks). So a bit hacky,
> but I think it would work as "ignore prior diff".
You can s
Sorry to tack on to my previous email, but I just thought of this:
If something like "-diff=lfs" won't do what I (and git-lfs) thought it
would, do you think it would be prudent/reasonable to suggest git-lfs
add a "no-lfs" filter for exactly this case? That way I could have
explicit exclusions wit
Thanks for the quick reply!
On Mon, Mar 19, 2018 at 10:34 PM, Jeff King wrote:
> On Mon, Mar 19, 2018 at 09:49:28PM -0400, Dakota Hawkins wrote:
>
>> Summary: Trying to apply attributes to file extensions everywhere
>> except in one directory.
>>
>> .gitattributes:
>>
>> *.[Pp][Nn][Gg] filter
On Mon, Mar 19, 2018 at 09:49:28PM -0400, Dakota Hawkins wrote:
> Summary: Trying to apply attributes to file extensions everywhere
> except in one directory.
>
> .gitattributes:
>
> *.[Pp][Nn][Gg] filter=lfs diff=lfs merge=lfs -text
> /.readme-docs/ -filter=lfs -diff=lfs -merge=lfs
>
>
According to the gitattributes docs:
"When more than one pattern matches the path, a later line overrides
an earlier line. This overriding is done per attribute."
I had a need to do this recently, and while the attributes are git-lfs
specific, I think the issue may be generic.
Summary: Trying to
On 19/03/18 17:54, Ramsay Jones wrote:
>
> The 'self-initialised' variables construct (ie var = var;) has
> been used to silence gcc '-W[maybe-]uninitialized' warnings. This has,
> unfortunately, caused MSVC to issue 'uninitialized variable' warnings.
> Also, using clang static analysis causes
On 3/14/2018 4:53 PM, Lars Schneider wrote:
On 14 Mar 2018, at 18:02, Derrick Stolee wrote:
On 3/14/2018 12:56 PM, Lars Schneider wrote:
Hi,
I am investigating a Git merge (a86dd40fe) in which an older version of
a file won over the newer version. I try to understand why this is the
case. I c
On 3/19/2018 8:55 AM, Derrick Stolee wrote:
Thanks for this! Fixing this performance problem is very important to
me, as we will use the "--stdin-packs" mechanism in the GVFS scenario
(we will walk all commits in the prefetch packs full of commits and
trees instead of relying on refs). This s
On Tue, Mar 20, 2018 at 12:11 AM, Christian Couder
wrote:
> On Sun, Mar 18, 2018 at 11:15 PM, Paul Sebastian Ungureanu
>> First of all, I find it difficult to pick which scripts would benefit
>> the most by being rewritten. I am thinking of git bisect, git stash
>> and git rebase since these are m
'git stash push -u -- ' prints the following errors if
only matches untracked files:
fatal: pathspec 'untracked' did not match any files
error: unrecognized input
This is because we first clean up the untracked files using 'git clean
', and then use a command chain involving 'git add -u
From: Junio C Hamano
An earlier change bba067d2 ("stash: don't delete untracked files
that match pathspec", 2018-01-06) was made by taking a suggestion in
a list discussion [1] but did not copy the suggested snippet
correctly. And the bug was unnoticed during the review and slipped
through.
Thi
When introducing the stash push feature, and thus allowing users to pass
in a pathspec to limit the files that would get stashed in
df6bba0937 ("stash: teach 'push' (and 'create_stash') to honor
pathspec", 2017-02-28), this developer missed one place where the
pathspec should be passed in.
Namely
Thanks again Marc for all the testing and Junio for fixing up my brown
paper bag copy-pasto.
This iteration addresses the breakage Marc noticed with the latest
version of the patches, adds some more tests, and moves all the new
tests to t3905 instead of t3903, which I just noticed exists and is a
Hi,
On Sun, Mar 18, 2018 at 11:15 PM, Paul Sebastian Ungureanu
wrote:
> Hello,
>
> I am interested in the "Convert scripts to builtins" project. I have
> recently started to analyze it better and see exactly what it entails
> and a few questions came to my mind.
Great! As other potential GSoC st
Am 19.03.2018 um 00:04 schrieb Eric Wong:
> Andreas Heiduk wrote:
>> The email address in --authors-file and --authors-prog can be empty but
>> git-svn translated it into a syntethic email address in the form
>> $USERNAME@$REPO_UUID. Now git-svn behaves like git-commit: If the email
>> is explicit
On Mon, Mar 19, 2018 at 03:49:05PM +0100, Michele Locati wrote:
> In order to echo a tab character, it's better to use printf instead of
> "echo -e", because it's more portable (for instance, "echo -e" doesn't work
> as expected on a Mac).
>
> This solves the "fatal: Not a valid object name" error
On Mon, Mar 19, 2018 at 5:32 PM Martin Ågren wrote:
> This commit message mentions RUNTIME_PREFIX_PERL twice, but there is no
> use of RUNTIME_PREFIX_PERL in the actual diffs (patches 1-3/3). Should
> it be s/_PERL//? Your cover letter hints as much under "Changes in v6
> from v5". And "Add a new
Paul-Sebastian Ungureanu writes:
> Subject: Re: [GSoC][PATCH v5] Make options that expect object ids less chatty
> if id is invalid
For the past few iterations, this is no longer about "options that
expect object IDs that get an invalid one" anymore, right? The fix
has become a lot more generi
On 03/19, Marc Strapetz wrote:
> On 16.03.2018 21:43, Thomas Gummerer wrote:
> >Thanks Marc for catching the regression I almost introduced and Junio
> >for the review of the second patch. Here's a re-roll that should fix
> >the issues of v2.
>
> Thanks, existing issues are fixed, but cleanup of
Hi Sergey,
On 19/03/2018 06:44, Sergey Organov wrote:
>
> > > > > > Second side note: if we can fast-forward, currently we prefer
> > > > > > that, and I think we should keep that behavior with -R, too.
> > > > >
> > > > > I agree.
> > > >
> > > > I'm admittedly somewhat lost in the discussion, b
On 19 March 2018 at 03:50, Dan Jacques wrote:
> Add a new Makefile flag, RUNTIME_PREFIX_PERL, which, when enabled,
> configures Perl scripts to locate the Git installation's Perl support
> libraries by resolving against the script's path, rather than
> hard-coding that path at build-time.
>
> RUNT
Usually, the usage should be shown only if the user does not know what
options are available. If the user specifies an invalid value, the user
is already aware of the available options. In this case, there is no
point in displaying the usage anymore.
This patch applies to "git tag --contains", "gi
On Mon, Mar 19, 2018, 04:34 Johannes Schindelin
wrote:
>
> This is a real problem.
No it isn't.
We already handle those special cases specially, and install them in
the bin directory (as opposed to libexec). And it all works fine.
Look into the bin directory some day. You'll find things like
On 3/15/2018 4:36 AM, Ævar Arnfjörð Bjarmason wrote:
On Thu, Mar 15 2018, Junio C. Hamano jotted:
* nd/repack-keep-pack (2018-03-07) 6 commits
- SQUASH???
- pack-objects: display progress in get_object_details()
- pack-objects: show some progress when counting kept objects
- gc --auto:
Joseph Strauss writes:
> I found the following erroneous behavior with "git rebase -p".
>
> My current version is git version 2.16.2.windows.1
>
> I made an example at GitHub, https://github.com/jkstrauss/git-bug/
>
> There seem to be two problems when rebasing merge commits with git rebase -p :
Duy Nguyen writes:
>> @@ -320,10 +318,19 @@ static int add_worktree(const char *path, const char
>> *refname,
>> if (ret)
>> goto done;
>>
>> + fprintf(stderr, _("worktree HEAD is now at %s"),
>
> We use the term "working tree" for UI and documents. "worktree" is
>
I found the following erroneous behavior with "git rebase -p".
My current version is git version 2.16.2.windows.1
I made an example at GitHub, https://github.com/jkstrauss/git-bug/
There seem to be two problems when rebasing merge commits with git rebase -p :
1. All lines of merge commits' mes
Daniel Jacques writes:
>> > The merge conflict becomes a tad easier to deal with, also makes sense
>> > to have gitexecdir after infodir since that's the order we're listing
>> > these in just a few lines earlier, and this is otherwise (mostly)
>> > consistent.
>
> Actually as a quick follow-up q
On Sat, 3 Mar 2018 18:36:37 +0700
Nguyễn Thái Ngọc Duy wrote:
> The reason callers have to call this is to make sure either packed_git
> or packed_git_mru pointers are initialized since we don't do that by
> default. Sometimes it's hard to see this connection between where the
> function is cal
On Mon, Mar 19, 2018 at 04:14:31PM -0400, Nick Hunt wrote:
> oh, wait, switching branches didn't vaporize my changes, it auto-committed
> them.
> which is still weird and possibly a bug?
Are you sure that the changes were not already present on the
switched-to branch?
-Peff
oh, wait, switching branches didn't vaporize my changes, it auto-committed them.
which is still weird and possibly a bug?
Nick Hunt
nhun...@gmail.com
404-988-1845
On Mon, Mar 19, 2018 at 3:13 PM, Nick Hunt wrote:
> i committed my changes, then ran
> git reset --soft HEAD^
> at this point everyth
On Sat, 3 Mar 2018 18:36:32 +0700
Nguyễn Thái Ngọc Duy wrote:
> From: Stefan Beller
>
> Signed-off-by: Stefan Beller
> Signed-off-by: Junio C Hamano
> Signed-off-by: Nguyễn Thái Ngọc Duy
Thanks - I've checked that none of the functions invoked in
prepare_packed_git_one() access the_reposi
Duy Nguyen writes:
> There is a difference. For sizes smaller than 2^32, whatever you
> pass to oe_set_size() will be returned by oe_size(),
> consistently. It does not matter if this size is "good" If
> it's different, oe_size() will return something else other than
> oe_set_size() is given
Stefan Moch writes:
> Are such redundant checks in general a pattern worth searching
> for and cleaning up globally? Or is this rather in the category
> of cleaning up only when noticed?
A clean-up patch that is otherwise a no-op is still welcome as it
will improve the health of the codebase, bu
On Mon, Mar 19, 2018 at 3:21 PM Ævar Arnfjörð Bjarmason
wrote:
> I think it would be more idiomatic and more paranoid (we'll catch bugs)
> to do:
> my $exec_path;
> if (exists $ENV{GIT_EXEC_PATH}) {
> $exec_path = $ENV{GIT_EXEC_PATH};
> } else {
> [...]
>
Olga Telezhnaya writes:
> Continue removing any printing from ref-filter formatting logic,
> so that it could be more general.
>
> Change the signature of parse_ref_filter_atom() by adding
> strbuf parameter for error message.
> Return value means the same except negative values: they indicate
>
On Sat, 3 Mar 2018 18:36:03 +0700
Nguyễn Thái Ngọc Duy wrote:
> From: Stefan Beller
>
> In a process with multiple repositories open, packfile accessors
> should be associated to a single repository and not shared globally.
> Move packed_git and packed_git_mru into the_repository and adjust
>
On Mon, Mar 19, 2018 at 3:27 PM Ævar Arnfjörð Bjarmason
wrote:
> I wonder if it wouldn't be a lot more understandable if these were noted
> together, i.e. let's first document RUNTIME_PREFIX, then for all the
> other ones say below that:
Sounds good to me, done.
> Whitespace changed mixed in wi
On Mon, Mar 19 2018, Dan Jacques jotted:
> I'm dusting this back off now that avarab@'s Perl Makefile simplification
> patch set has landed. It's been a few months, so I'm a bit rusty, but I think
> that I've incorporated all of the feedback. Please take a look and let me know
> what you think!
On Mon, Mar 19 2018, Dan Jacques jotted:
> #
> # Define HAVE_BSD_SYSCTL if your platform has a BSD-compatible sysctl
> function.
> #
> +# Define HAVE_BSD_KERN_PROC_SYSCTL if your platform supports the KERN_PROC
> BSD
> +# sysctl function.
> +#
> +# Define PROCFS_EXECUTABLE_PATH if your platf
Olga Telezhnaya writes:
> Continue removing any printing from ref-filter formatting logic,
> so that it could be more general.
"more general" sounds overly broad. Is this to avoid calling die()
so that the caller can decide what error messages it wants to give,
abort operation or not, etc.? Fr
On Mon, Mar 19 2018, Dan Jacques jotted:
> +# BEGIN RUNTIME_PREFIX generated code.
> +#
> +# This finds our Git::* libraries relative to the script's runtime path.
> +sub __git_system_path {
> + my ($relpath) = @_;
> + my $gitexecdir_relative = '@@GITEXECDIR_REL@@';
> +
> + # GIT_EXE
> > The merge conflict becomes a tad easier to deal with, also makes sense
> > to have gitexecdir after infodir since that's the order we're listing
> > these in just a few lines earlier, and this is otherwise (mostly)
> > consistent.
Actually as a quick follow-up question: for these patch sets, i
On Mon, Mar 19, 2018 at 3:12 PM Ævar Arnfjörð Bjarmason
wrote:
> The merge conflict becomes a tad easier to deal with, also makes sense
> to have gitexecdir after infodir since that's the order we're listing
> these in just a few lines earlier, and this is otherwise (mostly)
> consistent.
Got it
i committed my changes, then ran
git reset --soft HEAD^
at this point everything is fine
then i switched branches, and all of my changes vaporized into thin
air. uhhh, is this supposed to happen?
anyway, thank god intellij saves my work for me as i go, so i didn't
have to re-write all my code.
my
Christian Couder writes:
> A lot of things are different because the jh/fsck-promisors and
> jh/partial-clone have been merged into master since the v1. So the
> integration is much more complete now (though not fully complete), and
> this integration happens quite early in the patch series.
>
>
On Mon, Mar 19 2018, Dan Jacques jotted:
> +gitexecdir_relative = $(patsubst $(prefix)/%,%,$(gitexecdir))
> mandir_relative = $(patsubst $(prefix)/%,%,$(mandir))
> infodir_relative = $(patsubst $(prefix)/%,%,$(infodir))
> +localedir_relative = $(patsubst $(prefix)/%,%,$(localedir))
> htmldir_r
On 3/19/2018 10:36 AM, Ævar Arnfjörð Bjarmason wrote:
On Mon, Mar 19 2018, Derrick Stolee jotted:
On 3/18/2018 9:25 AM, Ævar Arnfjörð Bjarmason wrote:
On Wed, Mar 14 2018, Derrick Stolee jotted:
+'git commit-graph write' [--object-dir ]
+
+
+DESCRIPTION
+---
+
+Manage the serialized
On Mon, Mar 19 2018, Duy Nguyen jotted:
> On Fri, Mar 16, 2018 at 10:05 PM, Ævar Arnfjörð Bjarmason
> wrote:
>>
>> On Fri, Mar 16 2018, Nguyễn Thái Ngọc Duy jotted:
>>
>>> +--keep-base-pack::
>>> + All packs except the base pack and those marked with a `.keep`
>>> + files are consolidate
Duy Nguyen writes:
> This is why I do "size_valid = size_ == size". In my private build, I
> reduced size_ to less than 32 bits and change the "fits_in_32bits"
> function to do something like
>
> int fits_in_32bits(unsigned long size)
> {
> struct object_entry e;
> e.size_ = size;
> return e.size
On Mon, Mar 19, 2018 at 7:07 PM, Jonathan Tan wrote:
>> -extern void repo_set_gitdir(struct repository *repo, const char *path);
>> +struct set_gitdir_args {
>> + const char *commondir;
>> + const char *object_dir;
>> + const char *graft_file;
>> + const char *index_file;
>> +};
>>
Usually, the usage should be shown only if the user does not know what
options are available. If the user specifies an invalid value, the user
is already aware of the available options. In this case, there is no
point in displaying the usage anymore.
This patch applies to "git tag --contains", "gi
Hello,
Thank you for your advice! Soon enough, I wil submit a new patch which
fixes the issues you mentioned.
Best regards,
Paul Ungureanu
On Mon, Mar 19 2018, Derrick Stolee jotted:
> On 3/19/2018 10:36 AM, Ævar Arnfjörð Bjarmason wrote:
>> On Mon, Mar 19 2018, Derrick Stolee jotted:
>>
>>> On 3/18/2018 9:25 AM, Ævar Arnfjörð Bjarmason wrote:
On Wed, Mar 14 2018, Derrick Stolee jotted:
> +'git commit-graph write' [--
On Mon, Mar 19, 2018 at 7:29 PM, Junio C Hamano wrote:
+ if (!e->size_valid) {
+ unsigned long real_size;
+
+ if (sha1_object_info(e->idx.oid.hash, &real_size) < 0 ||
+ size != real_size)
+ die("BUG: 'siz
On Sat, 3 Mar 2018 18:35:55 +0700
Nguyễn Thái Ngọc Duy wrote:
> It does not make sense that generic repository code contains handling
> of environment variables, which are specific for the main repository
> only. Refactor repo_set_gitdir() function to take $GIT_DIR and
> optionally _all_ other
Michele Locati writes:
> In order to echo a tab character, it's better to use printf instead of
> "echo -e", because it's more portable (for instance, "echo -e" doesn't work
> as expected on a Mac).
>
> This solves the "fatal: Not a valid object name" error in git-filter-branch
> when using the -
The function ce_write_entry() uses a 'self-initialised' variable
construct, for the symbol 'saved_namelen', to suppress a gcc
'-Wmaybe-uninitialized' warning, given that the warning is a false
positive.
For the purposes of this discussion, the ce_write_entry() function has
three code blocks of in
The 'self-initialised' variables construct (ie var = var;) has
been used to silence gcc '-W[maybe-]uninitialized' warnings. This has,
unfortunately, caused MSVC to issue 'uninitialized variable' warnings.
Also, using clang static analysis causes complaints about an 'Assigned
value is garbage or u
Johannes Schindelin writes:
> On Windows, strftime() does not silently ignore invalid formats, but
> warns about them and then returns 0 and sets errno to EINVAL.
>
> Unfortunately, Git does not expect such a behavior, as it disagrees
> with strftime()'s semantics on Linux. As a consequence, Git
This series removes all 'self-initialised' variables (ie. var = var;).
This construct has been used to silence gcc '-W[maybe-]uninitialized' warnings
in the past [1]. Unfortunately, this construct causes warnings to be issued by
MSVC [2], along with clang static analysis complaining about an 'Ass
Luciano Joublanc writes:
> Yesterday I created a git bundle as best as I can remember like this
>
> git bundle save chunk chunk.bundle --all master
>
> Note the 'master' I added accidentally at the end - this was a user
> error but still the bundle was created.
>
> When I tried to clone this, I g
Thank you Eric Sunshine,
I have done as you had instructed me. I look forward to more
understanding of the codebase and would love to fix
"git rev-parse" problems in my follow-on patches.
Thank you for the professional review comment.
Sorry for late follow-on patch, I got tied up with my universi
On 3/17/2018 3:38 AM, Jacob Keller wrote:
On Fri, Mar 16, 2018 at 2:18 PM, Jeff King wrote:
3. Some other similar format. YAML comes to mind. Last time I looked
(quite a while ago), it seemed insanely complex, but I think you
could implement only a reasonable subset. OTOH, I th
On Mon, Mar 19, 2018 at 1:24 PM Junio C Hamano wrote:
> Look for these misspelled words:
Oh boy ... thanks, and done.
> OK. An essentially no-op change but with the name better suited in
> the extended context---we used to only care about argv0 but that was
> an implementation detail of "where
Hi,
On Sat, 17 Mar 2018, Yash Yadav wrote:
> In the project ideas listed there is one idea talking of conversion of
> scripts to builtins. This interests me but no pointer forward is given
> and I'd like to dive more into that idea and go through the script(s).
>
> So, where should I look furthe
On Fri, Mar 16, 2018 at 10:05 PM, Ævar Arnfjörð Bjarmason
wrote:
>
> On Fri, Mar 16 2018, Nguyễn Thái Ngọc Duy jotted:
>
>> +--keep-base-pack::
>> + All packs except the base pack and those marked with a `.keep`
>> + files are consolidated into a single pack. The largest pack is
>> + c
Dan Jacques writes:
> Enable Git to resolve its own binary location using a variety of
> OS-specific and generic methods, including:
>
> - procfs via "/proc/self/exe" (Linux)
> - _NSGetExecutablePath (Darwin)
> - KERN_PROC_PATHNAME sysctl on BSDs.
> - argv0, if absolute (all, including Windows).
On Mon, Mar 19, 2018 at 1:14 PM Junio C Hamano wrote:
> > +# RUNTIME_PREFIX's resolution logic requires resource paths to be
expressed
> > +# relative to each other and share an installation path.
> > +#
> > +# This is a dependnecy in:
> dependency?
Oops, this is the second typo that has been p
Dan Jacques writes:
> +# RUNTIME_PREFIX's resolution logic requires resource paths to be expressed
> +# relative to each other and share an installation path.
> +#
> +# This is a dependnecy in:
dependency?
> +# - Git's binary RUNTIME_PREFIX logic in (see "exec_cmd.c").
> +# - The runtime prefix
Hi drizzd,
first of all: thank you so much for working on this. I am sure it will
be noticeable to many Windows users, and also make my life easier.
On Sat, 17 Mar 2018, Clemens Buchacher wrote:
> From the output of ls-files, we remove all but the leftmost path
> component and then we eliminate
On Sat, Mar 17, 2018 at 11:22 PM, Thomas Gummerer wrote:
> Currently 'git worktree add' produces output like the following, when
> '--no-checkout' is not given:
>
> Preparing foo (identifier foo)
> HEAD is now at 26da330922
>
> where the first line is written to stderr, and the second lin
Dan Jacques writes:
> This patch set expands support for the RUNTIME_PREFIX configuration flag,
> currently only used on Windows builds, to include Linux, Darwin, and
> FreeBSD. When Git is built with RUNTIME_PREFIX enabled, it resolves its
> ancillary paths relative to the runtime location of it
Todd Zullinger writes:
> Completion of tag names has worked for the short -d/-v options since
> 88e21dc746 ("Teach bash about completing arguments for git-tag",
> 2007-08-31). The long options were not added to "git tag" until many
> years later, in c97eff5a95 ("git-tag: introduce long forms for
On Mon, Mar 19, 2018 at 5:43 PM, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
>> +static inline void oe_set_size(struct object_entry *e,
>> +unsigned long size)
>> +{
>> + e->size_ = size;
>> + e->size_valid = e->size_ == size;
>
> A quite similar co
David Pursehouse writes:
> From: David Pursehouse
>
> Signed-off-by: David Pursehouse
> ---
I somehow had to stare at the patch for a few minutes, view it in
two Emacs buffers and run M-x compare-windows before I finally spot
the single-byte typofix.
Will queue with a retitle.
Documentat
On Windows, strftime() does not silently ignore invalid formats, but
warns about them and then returns 0 and sets errno to EINVAL.
Unfortunately, Git does not expect such a behavior, as it disagrees
with strftime()'s semantics on Linux. As a consequence, Git
misinterprets the return value 0 as "I
Nguyễn Thái Ngọc Duy writes:
> +static inline void oe_set_size(struct object_entry *e,
> +unsigned long size)
> +{
> + e->size_ = size;
> + e->size_valid = e->size_ == size;
A quite similar comment as my earlier one applies here. I wonder if
this is easier t
On Sun, Mar 18, 2018 at 7:56 PM, Ramsay Jones
wrote:
>
>
> On 18/03/18 15:55, Duy Nguyen wrote:
>> On Sun, Mar 18, 2018 at 9:18 AM, Nguyễn Thái Ngọc Duy
>> wrote:
>>> +ifneq ($(or $(filter gcc6,$(COMPILER_FEATURES)),$(filter
>>> clang4,$(COMPILER_FEATURES))),)
>>> +CFLAGS += -Wextra
>>
>> Anoth
On Mon, Mar 19, 2018 at 5:19 PM, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
>> +static inline int oe_fits_in_32bits(unsigned long limit)
>> +{
>> + uint32_t truncated_limit = (uint32_t)limit;
>> +
>> + return limit == truncated_limit;
>> +}
>
> I do not think it is worth a re
Nguyễn Thái Ngọc Duy writes:
> +static inline int oe_fits_in_32bits(unsigned long limit)
> +{
> + uint32_t truncated_limit = (uint32_t)limit;
> +
> + return limit == truncated_limit;
> +}
I do not think it is worth a reroll (there only are a few
callsites), but the above has nothing to
1 - 100 of 165 matches
Mail list logo
