Some distros provide SHA1 collision detect code as a shared library.
It's the very same code as we have in git tree, and git can link with
it as well; at least, it may make maintenance easier, according to our
security guys.
This patch allows user to build git linking with the external sha1dc
On Sat, Jul 1, 2017 at 5:24 PM, Dan Kohn wrote:
> https://github.com/coreinfrastructure/best-practices-badge is a user
> of the https://github.com/probot/dco bot which checks that commits
> have a signoff. The issue is that there is no `--signoff` option in
> git for
On Mon, Jul 24, 2017 at 10:00 PM, lukaszgryglicki wrote:
> I can't reach Him, every time I send an email it is returned "no such
> address".
> Can You please ask Him to take a look?
Junio referred to
https://public-inbox.org/git/87fueferd4@gmail.com/
His actual email
I can't reach Him, every time I send an email it is returned "no such address".
Can You please ask Him to take a look?
> On 24 Jul 2017, at 22:42, Junio C Hamano wrote:
>
> Junio C Hamano writes:
>
>> lukaszgryglicki writes:
>>
>>>
On Mon, Jul 24, 2017 at 12:38 PM, Orgad Shaneh wrote:
> Sorry, I thought it's the same thing. I mean ref-in-want[1]. This
> issue in gerrit[2] was closed, claiming that ref-in-want will solve
> it. I just want to know if this is likely to be merged soon enough (I
> consider
Greetings!
I have a proposal for you, this however is not mandatory nor will I in
any manner compel you to honor against your will. I am Dr.Paul Benk a
former executive director with Arab Tunisian Bank here in Tunis; I
retired 1 year 7 months ago after putting in 28 years of meticulous
service.
On 07/25, Prathamesh Chavan wrote:
> This aims to make git-submodule foreach a builtin. This is the very
> first step taken in this direction. Hence, 'foreach' is ported to
> submodule--helper, and submodule--helper is called from git-submodule.sh.
> The code is split up to have one function to
On 07/25, Prathamesh Chavan wrote:
> It was observer that the variable '$displaypath' was accessible but
s/observer/observed
> undocumented. Hence, document it.
>
> Discussed-with: Ramsay Jones
> Signed-off-by: Stefan Beller
> Signed-off-by:
On 07/25, Prathamesh Chavan wrote:
> As using a variable '$path' may be harmful to users due to
> capitalization issues, see 64394e3ae9 (git-submodule.sh: Don't
> use $path variable in eval_gettext string, 2012-04-17). Adjust
> the documentation to advocate for using $sm_path, which contains
>
On 07/25, Prathamesh Chavan wrote:
> When running 'git submodule foreach' from a subdirectory of your
> repository, nested submodules get a bogus value for $sm_path:
> For a submodule 'sub' that contains a nested submodule 'nested',
> running 'git -C dir submodule foreach echo $path' would report
On 07/25, Prathamesh Chavan wrote:
> The submodule subcommand 'summary' is ported in the process of
> making git-submodule a builtin. The function cmd_summary() from
> git-submodule.sh is ported to functions module_summary(),
> compute_summary_module_list(), prepare_submodule_summary() and
>
On 07/25, Prathamesh Chavan wrote:
> The same mechanism is used even for porting this submodule
> subcommand, as used in the ported subcommands till now.
> The function cmd_deinit in split up after porting into three
> functions: module_deinit(), for_each_submodule_list() and
> deinit_submodule().
On Mon, Jul 24, 2017 at 3:22 PM, Stefan Beller wrote:
> On Sat, Jul 22, 2017 at 11:29 AM, Shawn Pearce wrote:
>> 3rd iteration of the reftable storage format.
>>
>> You can read a rendered version of this here:
>>
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.
With help from Jiang, Dscho and
A release candidate Git v2.14.0-rc1 is now available for testing
at the usual places. It is comprised of 708 non-merge commits
since v2.13.0, contributed by 61 people, 14 of which are new faces.
The tarballs are found at:
https://www.kernel.org/pub/software/scm/git/testing/
The following
The value has not eluded documentation so far.
Signed-off-by: Andreas Heiduk
---
Documentation/diff-config.txt | 2 +-
Documentation/diff-options.txt | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/diff-config.txt
Junio C Hamano writes:
> Also, while I do agree with you that the problem exists, it is
> unclear why this patch is a solution and not a hack that sweeps a
> problem under the rug.
>
> It is unclear why this "silently detach HEAD without telling the
> user" is a better
On Sat, Jul 22, 2017 at 11:29 AM, Shawn Pearce wrote:
> 3rd iteration of the reftable storage format.
>
> You can read a rendered version of this here:
> https://googlers.googlesource.com/sop/jgit/+/reftable/Documentation/technical/reftable.md
>
> Significant changes from v2:
Hi,
Jonathan Tan wrote:
> Refactor, into a common function, the version and capability negotiation
> done when invoking a long-running process as a clean or smudge filter.
> This will be useful for other Git code that needs to interact similarly
> with a long-running process.
>
> Signed-off-by:
On 07/25, Prathamesh Chavan wrote:
> Port the submodule subcommand 'sync' from shell to C using the same
> mechanism as that used for porting submodule subcommand 'status'.
> Hence, here the function cmd_sync() is ported from shell to C.
> This is done by introducing three functions:
Am 24.07.2017 um 00:13 schrieb Junio C Hamano:
> Andreas Heiduk writes:
>
>> A `git fetch . origin/master:master` protects the currently checked out
>> branch (HEAD) unless the `-u/--update-head-ok` is supplied. This avoids a
>> mismatch between the index and HEAD.
SZEDER Gábor writes:
> While these reminders are useful for new users, with time they learn
> what the score is, and experienced users might find these advices are
> just wasting a couple of lines' worth of screen real estate.
>
> Make displaying these advices configurable
Jeff King writes:
> On Mon, Jul 24, 2017 at 10:09:15AM -0700, Jonathan Nieder wrote:
>
>> Jeff King wrote:
>>
>> > This seems like the correct path to me. If the existing behavior is to
>> > lock the referring symref, that seems like a violation of the lock
>> > procedure in the
SZEDER Gábor writes:
> When attempting to blame a non-existing path, git should show an error
> message like this:
>
> $ git blame e83c51633 -- nonexisting-file
> fatal: no such path nonexisting-file in e83c51633
>
> Since the recent commit 835c49f7d (blame: rework
Refactor, into a common function, the version and capability negotiation
done when invoking a long-running process as a clean or smudge filter.
This will be useful for other Git code that needs to interact similarly
with a long-running process.
Signed-off-by: Jonathan Tan
Jonathan Nieder writes:
> Yikes. Yes, this bug looks problematic. Thanks for working on it.
>
>> I improved the commit message laying out the current state of affairs,
>> arguing that any future plan should not weigh in as much as the current
>> possible data loss.
>
> Can
On 07/25, Prathamesh Chavan wrote:
> This aims to make git-submodule 'status' a built-in. Hence, the function
> cmd_status() is ported from shell to C. This is done by introducing
> three functions: module_status(), submodule_status() and print_status().
>
> The function module_status() acts as
Kaartic Sivaraam writes:
> The patch in the previous mail results in a change in output as
> specified below.
>
> $ git branch
> * master
> foo
> bar
>
> Before patch,
>
> $ git branch -m hypothet master
> fatal: A branch named 'master'
When attempting to blame a non-existing path, git should show an error
message like this:
$ git blame e83c51633 -- nonexisting-file
fatal: no such path nonexisting-file in e83c51633
Since the recent commit 835c49f7d (blame: rework methods that
determine 'final' commit, 2017-05-24) the
Stefan Beller writes:
>> Are you saying
>> the current behavior of updating whatever branch HEAD is on (which,
>> don't get me wrong, is a wrong behavior that needs fixing) bypassed
>> the reflog?
>
> No, I am not saying that.
> I am saying that updating an unrelated branch
On 07/25, Prathamesh Chavan wrote:
> +static int print_name_rev(int argc, const char **argv, const char *prefix)
> +{
> + char *namerev;
> + if (argc != 3)
> + die("print-name-rev only accepts two arguments: ");
> +
> + namerev = get_name_rev(argv[1], argv[2]);
> + if
Phillip Wood writes:
> git rebase --continue requiring one to git add first confuses/annoys me
> too. I started a patch to autostage unstaged changes if they don't
> contain conflict markers a couple of weeks ago, I'll clean it up and
> post it later this week.
As
Junio C Hamano writes:
> lukaszgryglicki writes:
>
>> Hi, what is the state of this patch?
>
> I was expecting you to respond to Ævar's <87tw2sbnyl@gmail.com>
> to explain how your new version addresses his concerns, or him to
> respond to your new
It was observer that the variable '$displaypath' was accessible but
undocumented. Hence, document it.
Discussed-with: Ramsay Jones
Signed-off-by: Stefan Beller
Signed-off-by: Prathamesh Chavan
---
This aims to make git-submodule foreach a builtin. This is the very
first step taken in this direction. Hence, 'foreach' is ported to
submodule--helper, and submodule--helper is called from git-submodule.sh.
The code is split up to have one function to obtain all the list of
submodules. This
It does not contain the topmost superproject as the author assumed,
but the direct superproject, such that $toplevel/$sm_path is the
actual absolute path of the submodule.
Discussed-with: Ramsay Jones
Signed-off-by: Stefan Beller
Signed-off-by:
As using a variable '$path' may be harmful to users due to
capitalization issues, see 64394e3ae9 (git-submodule.sh: Don't
use $path variable in eval_gettext string, 2012-04-17). Adjust
the documentation to advocate for using $sm_path, which contains
the same value. We still make the 'path'
The submodule subcommand 'summary' is ported in the process of
making git-submodule a builtin. The function cmd_summary() from
git-submodule.sh is ported to functions module_summary(),
compute_summary_module_list(), prepare_submodule_summary() and
print_submodule_summary().
The first function
When running 'git submodule foreach' from a subdirectory of your
repository, nested submodules get a bogus value for $sm_path:
For a submodule 'sub' that contains a nested submodule 'nested',
running 'git -C dir submodule foreach echo $path' would report
path='../nested' for the nested submodule.
Change the scope of function count_lines for allowing the function
to be reused in other parts of the code as well.
Mentored-by: Christian Couder
Mentored-by: Stefan Beller
Signed-off-by: Prathamesh Chavan
---
diff.c | 2 +-
The same mechanism is used even for porting this submodule
subcommand, as used in the ported subcommands till now.
The function cmd_deinit in split up after porting into three
functions: module_deinit(), for_each_submodule_list() and
deinit_submodule().
Mentored-by: Christian Couder
Port the submodule subcommand 'sync' from shell to C using the same
mechanism as that used for porting submodule subcommand 'status'.
Hence, here the function cmd_sync() is ported from shell to C.
This is done by introducing three functions: module_sync(),
sync_submodule() and
Introduce function for_each_submodule_list() and
replace a loop in module_init() with a call to it.
The new function will also be used in other parts of the
system in later patches.
Mentored-by: Christian Couder
Mentored-by: Stefan Beller
This aims to make git-submodule 'status' a built-in. Hence, the function
cmd_status() is ported from shell to C. This is done by introducing
three functions: module_status(), submodule_status() and print_status().
The function module_status() acts as the front-end of the subcommand.
It parses
Introduce function get_submodule_displaypath() to replace the code
occurring in submodule_init() for generating displaypath of the
submodule with a call to it.
This new function will also be used in other parts of the system
in later patches.
Mentored-by: Christian Couder
Function set_name_rev() is ported from git-submodule to the
submodule--helper builtin. The function get_name_rev() generates the
value of the revision name as required, and the function
print_name_rev() handles the formating and printing of the obtained
revision name.
Mentored-by: Christian
SUMMARY OF MY PROJECT:
Git submodule subcommands are currently implemented by using shell script
'git-submodule.sh'. There are several reasons why we'll prefer not to
use the shell script. My project intends to convert the subcommands into
C code, thus making them builtins. This will increase
Thx jeff, i will try it tomorrow.
> Am 24.07.2017 um 22:32 schrieb Jeff King :
>
> On Mon, Jul 24, 2017 at 10:26:22PM +0200, tonka3...@gmail.com wrote:
>
>>> I'm not sure exactly what you're trying to accomplish. If you're unhappy
>>> with the file as utf-16, then you should
On Mon, Jul 24, 2017 at 10:26:22PM +0200, tonka3...@gmail.com wrote:
> > I'm not sure exactly what you're trying to accomplish. If you're unhappy
> > with the file as utf-16, then you should probably convert to utf-8 as a
> > single commit (since the diff will otherwise be unreadable) and then
>
Jeff King writes:
> On Mon, Jul 24, 2017 at 02:58:38PM +1000, Andrew Ardill wrote:
>
>> On 24 July 2017 at 13:45, Farshid Zavareh wrote:
>> > I'll probably test this myself, but would modifying and committing a 4GB
>> > text file actually add 4GB to the
On Mon, Jul 24, 2017 at 7:13 PM, Jonathan Tan wrote:
> On Sun, 23 Jul 2017 09:41:50 +0300
> Orgad Shaneh wrote:
>
>> Hi,
>>
>> Jonathan Tan proposed a design and a patch series for requesting a
>> specific ref on fetch 4 months ago[1].
>>
>> Is there
On Mon, Jul 24, 2017 at 12:29:04PM -0700, Junio C Hamano wrote:
> > There's already some prior art around trailers in the trailer.* config.
> > I wonder if it would make sense to claim a new key there, like:
> >
> > git config trailer.Reported-by.autocc true
> >
> > If "Reported-by" is a
Jeff King writes:
>> I also should have mentioned the need for a way to say "remove all
>> hardcoded default and start from scratch".
>
> There's already some prior art around trailers in the trailer.* config.
> I wonder if it would make sense to claim a new key there, like:
>
>
On Mon, Jul 24, 2017 at 09:02:12PM +0200, tonka3...@gmail.com wrote:
> There is no .gitattributes file in the repo. I think that the git
> heuristic will also detect utf-16 files as binary (in windows), so i
> think that is the reason why my file is binary (i have to check that
> tomorrow).
John Szakmeister writes:
> Correct, it appears that if any line in the ignore matches, then it
> exits with 0. So it's not that it's ignored, but that there is a
> matching line in an ignore file somewhere. I can see the logic in
> this if it's meant to be a debugging
The patch in the previous mail results in a change in output as
specified below.
$ git branch
* master
foo
bar
Before patch,
$ git branch -m hypothet master
fatal: A branch named 'master' already exists.
$ git branch -m hypothet real
error: refname
Jiang Xin writes:
> 2017-07-23 10:33 GMT+08:00 Jean-Noël AVILA :
>> Plus, I hope that some day, instead of translators finding afterwards
>> that a change broke i18n capabilities, developpers would have some kind
>> of sanity check.
Jiang Xin writes:
>> So let's go with Junio's patch.
>
> I agree. We just go with the sed-then-cleanup version until we meet
> ambiguities (I mean some words other than PRItime need to be
> replaced).
OK, thanks for all involved to get us to a conclusion. Jiang, I
On Mon, Jul 24, 2017 at 11:03 AM, Jonathan Nieder wrote:
> Hi,
>
> Stefan Beller wrote:
>
>> When a submodule is on a branch and in its superproject you run a
>> recursive checkout, the branch of the submodule is updated to what the
>> superproject checks out. This is very
Hey Jeff,
Thx for your answer.
There is no .gitattributes file in the repo. I think that the git heuristic
will also detect utf-16 files as binary (in windows), so i think that is the
reason why my file is binary (i have to check that tomorrow). If i add a
.gitattribute file i have the
> So I actually would be OK with having an advice.* option to squelch
> rebase and/or commit instructions. But only if users decide they would
> never like to see that text. So yes, your tool could piggy-back on that
> config option, but it would be a slight abuse of the intent.
I don't mind the
On Fri, Jul 21, 2017 at 09:03:16AM -0700, Junio C Hamano wrote:
> Eric Blake writes:
>
> > You mean, something like
> >
> > git config --add contacts.autocc Reported-by
> > git config --add contacts.autocc Suggested-by
> >
> > where contacts.autocc would be a new multi-valued
On Mon, Jul 24, 2017 at 07:11:06AM +0200, tonka tonka wrote:
> I have a problem with an already committed file into my repo. This git
> repo was converted from svn to git some years ago. Last week I have
> change some lines in a file and I saw in the diff that it is marked as
> binary (it's a
On Mon, Jul 24, 2017 at 02:58:38PM +1000, Andrew Ardill wrote:
> On 24 July 2017 at 13:45, Farshid Zavareh wrote:
> > I'll probably test this myself, but would modifying and committing a 4GB
> > text file actually add 4GB to the repository's size? I anticipate that it
> >
On Mon, Jul 24, 2017 at 10:12:59AM -0700, Stefan Beller wrote:
> > Interestingly I have no problems compiling it here. I wonder if Stefan's
> > config.mak is supplying -std=c89 or some other restrictive flag. Or if
> > his compiler is a different version (though I tried with gcc-6, gcc-4.9,
> >
Hi,
Stefan Beller wrote:
> When a submodule is on a branch and in its superproject you run a
> recursive checkout, the branch of the submodule is updated to what the
> superproject checks out. This is very unexpected in the current model of
> Git as e.g. 'submodule update' always detaches the
On 07/23, Jacob Keller wrote:
> On Sat, Jul 22, 2017 at 11:02 PM, Orgad Shaneh wrote:
> > Hi,
> >
> > When git grep --color=always is used, and the output is redirected to
> > a file or a pipe, results inside submodules are not colored. Results
> > in the supermodule are colored
When a submodule is on a branch and in its superproject you run a
recursive checkout, the branch of the submodule is updated to what the
superproject checks out. This is very unexpected in the current model of
Git as e.g. 'submodule update' always detaches the submodule HEAD.
Despite having plans
On Mon, Jul 24, 2017 at 01:26:09AM +0300, Kirill Likhodedov wrote:
> > Not at all interested, as that would mean your tool will tell its
> > users to set such a configuration variable and their interactive use
> > of Git outside your tool will behave differently from other people
> > who use
On Mon, Jul 24, 2017 at 10:08 AM, Jeff King wrote:
> On Wed, Jul 19, 2017 at 11:23:42AM -0700, Brandon Williams wrote:
>
>> > object.c: In function ‘object_array_remove_duplicates’:
>> > object.c:404:2: error: ‘for’ loop initial declarations are only allowed in
>> > C99 mode
>> >
On Mon, Jul 24, 2017 at 10:09:15AM -0700, Jonathan Nieder wrote:
> Jeff King wrote:
>
> > This seems like the correct path to me. If the existing behavior is to
> > lock the referring symref, that seems like a violation of the lock
> > procedure in the first place. Because if "A" points to "B",
Hi,
Jeff King wrote:
> This seems like the correct path to me. If the existing behavior is to
> lock the referring symref, that seems like a violation of the lock
> procedure in the first place. Because if "A" points to "B", we take
> "A.lock" and then modify "B". But "B" may have any number of
When attempting to blame a non-existing path, git should show an error
message like this:
$ git blame e83c51633 -- nonexisting-file
fatal: no such path nonexisting-file in e83c51633
Since the recent commit 835c49f7d (blame: rework methods that
determine 'final' commit, 2017-05-24) the
On Wed, Jul 19, 2017 at 11:23:42AM -0700, Brandon Williams wrote:
> > object.c: In function ‘object_array_remove_duplicates’:
> > object.c:404:2: error: ‘for’ loop initial declarations are only allowed in
> > C99 mode
> > for (unsigned src = 0; src < nr; src++) {
> > ^
> > object.c:404:2:
On Thu, Jul 20, 2017 at 11:01:45PM -0700, Junio C Hamano wrote:
> The general strategy we take for these atomic update of a file
> entity at $path is to:
>
> (1) try to create $path.lock exclusively; if we cannot, somebody
> else holds the lock so fail (or backoff and retry, which
>
On Fri, Jul 21, 2017 at 08:15:17AM -0700, Junio C Hamano wrote:
> In general, I (and other experienced reviewers here) prefer to give
> chances to people who are new to the Git development community and
> are inclined to do so to scratch their own itch, by giving analysis
> of the problem and a
On Sun, 23 Jul 2017 09:41:50 +0300
Orgad Shaneh wrote:
> Hi,
>
> Jonathan Tan proposed a design and a patch series for requesting a
> specific ref on fetch 4 months ago[1].
>
> Is there any progress with this?
>
> - Orgad
>
> [1]
>
On Sat, Jul 22, 2017 at 06:39:12AM +0200, Christian Couder wrote:
> @@ -1175,10 +1175,9 @@ int ref_is_hidden(const char *refname, const char
> *refname_full)
> }
>
> /* refname can be NULL when namespaces are used. */
> - if (!subject ||
The inexistence of the branch trying to be renamed wasn't checked
and was left for 'rename_ref' to point out. It's better to do it
explicitly as it leads to unconventional behaviour in the following
case,
$ git branch -m foo master
fatal: A branch named 'master' already exists.
Hi,
In the last round of l10n, some l10n messages from "date.c" are
disappeared because of the l10n unfriendly PRItime macro. This issue
has been fixed by commit fc0fd5b23b (Makefile: help gettext tools to
cope with our custom PRItime format), so let's start new round of l10n
based on the new
24.07.2017 07:02, Jacob Keller пишет:
generally, I'd suggest using "git describe" to output a version based
on tag, and as part of your build system set that in some sort of
--version output of some kind.
I am not sure I understand that suggestion.
I can use 'git describe' (and that seems to be
On 16/07/17 12:39, Philip Oakley wrote:
>
> From: "Junio C Hamano"
> Sent: Wednesday, July 12, 2017 10:29 PM
>> William Duclot writes:
>>
- The original said "When you have resolved this problem", without
giving a guidance how to
On Sun, Jul 23, 2017 at 12:33 PM, Philip Oakley wrote:
[snip]
>>
>>
>> git init .
>> echo 'foo/*' > .gitignore
>> echo '!foo/bar' > .gitignore
>
>
> Is this missing the >> append to get the full two line .gitignore?
> adding in a `cat .gitignore` would help check.
Yes,
From: Paolo Bonzini
Allow using non-default values for trailers without having to set
them up in .gitconfig first. For example, if you have the following
configuration
trailer.signed-off-by.where = end
you may use "--where before" when a patch author forgets his
From: Paolo Bonzini
Separate the mechanical changes out of the next patch. The functions
are changed to take a pointer to enum, because struct conf_info is not
going to be public.
Set the default values explicitly in default_conf_info, since they are
not anymore close to
From: Paolo Bonzini
This will provide a place to store the current state of the
--where, --if-exists and --if-missing options.
Signed-off-by: Paolo Bonzini
---
builtin/interpret-trailers.c | 41 +
trailer.c
From: Paolo Bonzini
These options are useful to experiment with "git interpret-trailers"
without having to tinker with .gitconfig (Junio said git should ahve
done this first and only added configuration afterwards). It can
be useful in the case where you want a different
lukaszgryglicki writes:
> Hi, what is the state of this patch?
I was expecting you to respond to Ævar's <87tw2sbnyl@gmail.com>
to explain how your new version addresses his concerns, or him to
respond to your new patch to say that it addresses his concerns
adequately.
Hi, what is the state of this patch?
What else should I do to get it merged into git?
Thanks.
> On 4 Jul 2017, at 11:33, Łukasz Gryglicki wrote:
>
> Some projects require every commit to be signed off.
> Our workflow is to create feature branches and require every commit
89 matches
Mail list logo