Hi Junio,
On Fri, Feb 24, 2017 at 11:28:58AM -0800, Junio C Hamano wrote:
> * Use of an empty string that is used for 'everything matches' is
>still warned and Git asks users to use a more explicit '.' for that
>instead. The hope is that existing users will not mind this
>change, and
handle_revision_opt() tries to recognize and handle the given argument. If an
option was unknown to it, it used to add the option to unkv[(*unkc)++]. This
increment of unkc causes the variable in the caller to change.
Teach handle_revision_opt to not update unknown arguments inside unkc anymore.
handle_revision_opt() tries to recognize and handle the given argument. If an
option was unknown to it, it used to add the option to unkv[(*unkc)++]. This
increment of unkc causes the variable in the caller to change.
Teach handle_revision_opt to not update unknown arguments inside unkc anymore.
Swap the condition and bodies of an "if (A) do_A else do_B" in
setup_revisions() to "if (!A) do_B else do A", to make the change in
the the next step easier to read.
No behaviour change is intended in this step.
Signed-off-by: Siddharth Kannan
---
revision.c | 6 +++---
1 file changed, 3 insert
revert.c:run_sequencer calls setup_revisions right after replacing "-" with
"@{-1}" for this shorthand. A previous patch taught setup_revisions to handle
this shorthand by doing the required replacement inside revision.c:get_sha1_1.
Hence, the code here is redundant and has been removed.
This pat
The callchain for handling each argument contains the function
revision.c:get_sha1 where the shorthand for "-" ~ "@{-1}" has already been
implemented in a previous patch; the complete callchain leading to that
function is:
1. merge.c:collect_parents
2. commit.c:get_merge_parent : this function cal
This patch introduces "-" as a method to refer to a revision, and adds tests to
test that git-log works with this shorthand.
This change will touch the following commands (through
revision.c:setup_revisions):
* builtin/blame.c
* builtin/diff.c
* builtin/diff-files.c
* builtin/diff-index.c
* built
An updated version of the patch [1]. Discussion here[1] has been taken into
account. The test for "-@{yesterday}" is there inside the log-shorthand test,
it is commented out for now.
I have removed the redundant pieces of code in merge.c and revert.c as mentioned
by Matthieu in [2]. As analysed by
setup_revisions used to consider any argument starting with "-" to be either a
valid or an unknown option.
Teach setup_revisions to check if an argument is a revision before adding it as
an unknown option (something that setup_revisions didn't understand) to argv,
and moving on to the next argumen
Linus Torvalds writes:
> For example, what I would suggest the rules be is something like this:
>
> - introduce new tag2/commit2/tree2/blob2 object type tags that imply
> that they were hashed using the new hash
>
> - an old type obviously can never contain a pointer to a new type (ie
> you can
Repos should address keeping / 'fixing' broken sha-1 as needed.
They also really need to create new native modes so users can
initialize and use repos with (sha-3 / sha-256 / whatever) going forward.
Backward compatibility with sha-1 or 'fixed sha-1' will be fine. Clients
can 'taste' and 'test' rep
Duy Nguyen writes:
> You'll probably want to update the comment block above if msg can be
> NULL. We have _very_ good documentation in this file, let's keep it
> uptodate.
Looking at how other functions in refs.h document their "msg" or
"logmsg" parameter, none seem to mention it explicitly. up
Hello
On Fri, Feb 24, 2017 at 5:39 PM, David Lang wrote:
> On Fri, 24 Feb 2017, Jeff King wrote:
>
>>> what if they are forks of each other? (LEDE and OpenWRT, or just
>>> linux-kernel and linux-kernel-stable)
>>
>>
>> Once one flips, the other one needs to flip to, or can't interact with
>> them. I kno
On Fri, Feb 24, 2017 at 5:21 PM, Jeff King wrote:
> On Fri, Feb 24, 2017 at 05:00:55PM -0800, David Lang wrote:
>
>> On Fri, 24 Feb 2017, Jeff King wrote:
>>
>> >
>> > So I'd much rather see strong rules like:
>> >
>> > 1. Once a repo has flag-day switched over to the new hash format[1],
>> >
On Fri, 24 Feb 2017, Jeff King wrote:
OpenWRT/LEDE have their core repo, and they pull from many other (unrelated)
projects into that repo (and then have 'feeds', which is
sort-of-like-submodules to pull in other software that's maintained
completely independently)
I think with submodules this
On Fri, Feb 24, 2017 at 05:39:43PM -0800, David Lang wrote:
> On Fri, 24 Feb 2017, Jeff King wrote:
>
> > > what if they are forks of each other? (LEDE and OpenWRT, or just
> > > linux-kernel and linux-kernel-stable)
> >
> > Once one flips, the other one needs to flip to, or can't interact with
On Fri, 24 Feb 2017, Jeff King wrote:
what if they are forks of each other? (LEDE and OpenWRT, or just
linux-kernel and linux-kernel-stable)
Once one flips, the other one needs to flip to, or can't interact with
them. I know that's harsh, and is likely to create headaches. But in the
long run,
When a submodule is initialized, the config variable 'submodule..url'
is set depending on the value of the same variable in the .gitmodules
file. When the URL indicates to be relative, then the url is computed
relative to its default remote. The default remote cannot be determined
accurately in all
On Fri, Feb 24, 2017 at 05:00:55PM -0800, David Lang wrote:
> On Fri, 24 Feb 2017, Jeff King wrote:
>
> >
> > So I'd much rather see strong rules like:
> >
> > 1. Once a repo has flag-day switched over to the new hash format[1],
> > new references are _always_ done with the new hash. Even
Whenever tree_objects is set to 1 in revision.h's struct rev_info,
blob_objects is likewise set, and vice versa. Combine those two fields
into one.
Some of the existing code does not handle tree_objects being different
from blob_objects properly. For example, "handle_commit" in revision.c
recurses
As stated in a previous e-mail [1], I was trying to think a way to allow
Git to fetch arbitrary blobs from another Git server, and it turned out
that fetch-pack already can. However, there were some bugs with blob
reachability. This patch set fixes those bugs, and verifies (with tests)
that fetch-p
When the --objects argument is given to rev-list, an argument of the
form "^$tree" can be given to exclude all blobs and trees reachable from
that tree, but an argument of the form "^$commit" only excludes that
commit, not any blob or tree reachable from it. Make "^$commit" behave
consistent to "^$
If allowreachablesha1inwant is set, upload-pack will provide a blob to a
user, provided its hash, regardless of whether the blob is reachable or
not. Teach upload-pack to compute reachability correctly by passing the
"--objects" argument when it invokes "rev-list" if necessary.
This commit only af
On Fri, Feb 24, 2017 at 04:39:45PM -0800, Linus Torvalds wrote:
> For example, what I would suggest the rules be is something like this:
>
> - introduce new tag2/commit2/tree2/blob2 object type tags that imply
> that they were hashed using the new hash
>
> - an old type obviously can never con
On Fri, Feb 24, 2017 at 5:00 PM, David Lang wrote:
> On Fri, 24 Feb 2017, Jeff King wrote:
>
>>
>> So I'd much rather see strong rules like:
>>
>> 1. Once a repo has flag-day switched over to the new hash format[1],
>> new references are _always_ done with the new hash. Even ones that
>>
On Fri, 24 Feb 2017, Jeff King wrote:
So I'd much rather see strong rules like:
1. Once a repo has flag-day switched over to the new hash format[1],
new references are _always_ done with the new hash. Even ones that
point to pre-flag-day objects!
how do you define when a repo has "s
On Fri, Feb 24, 2017 at 4:39 PM, Linus Torvalds
wrote:
>
> - you'd see in the "object->type" whether it's a new or old-style hash.
Actually, I take that back. I think it might be easier to keep
"object->type" as-is, and it would only show the current OBJ_xyz
fields. Then writing the SHA ends up
On Thu, Feb 9, 2017 at 9:02 PM, Jeff King wrote:
>
> I think this is only half the story. A heavy-sha1 workload is faster,
> which is good. But one of the original reasons to prefer blk-sha1 (at
> least on Linux) is that resolving libcrypto.so symbols takes a
> non-trivial amount of time. I just t
On Fri, Feb 24, 2017 at 3:39 PM, Jeff King wrote:
>
> One thing I worry about in a mixed-hash setting is how often the two
> will be mixed.
Honestly, I think that a primary goal for a new hash implementation
absolutely needs to be to minimize mixing.
Not for security issues, but because of combi
On Fri, Feb 24, 2017 at 3:50 PM, Brandon Williams wrote:
> Add the `PATHSPEC_FROMROOT` flag to allow callers to instruct
> 'parse_pathspec()' that all provided pathspecs are relative to the root
> of the repository. This allows a caller to prevent a path that may be
> outside of the repository fr
On 24 February 2017 at 21:32, Junio C Hamano wrote:
> ankostis writes:
>
>> Let's assume that git is retroffited to always support the "default"
>> SHA-3, but support additionally more hash-funcs.
>> If in the future SHA-3 also gets defeated, it would be highly unlikely
>> that the same math woul
Ian Jackson writes ("Re: SHA1 collisions found"):
> The idea of using the length is a neat trick, but it cannot support
> the dcurrent object name abbreviation approach unworkable.
Sorry, it's late here and my grammar seems to have disintegrated !
Ian.
When using the --recurse-submodules flag with a relative pathspec which
includes "..", an error is produced inside the child process spawned for a
submodule. When creating the pathspec struct in the child, the ".." is
interpreted to mean "go up a directory" which causes an error stating that the
p
Fix a bug which causes a child process for a submodule to error out when
a relative pathspec with a ".." is provided in the superproject.
While at it, correctly construct the super-prefix to be used in a
submodule when not at the root of the repository.
Signed-off-by: Brandon Williams
---
built
Fix a bug which causes a child process for a submodule to error out when a
relative pathspec with a ".." is provided in the superproject.
While at it, correctly construct the super-prefix to be used in a submodule
when not at the root of the repository.
Signed-off-by: Brandon Williams
---
built
Add the `PATHSPEC_FROMROOT` flag to allow callers to instruct
'parse_pathspec()' that all provided pathspecs are relative to the root
of the repository. This allows a caller to prevent a path that may be
outside of the repository from erroring out during the pathspec struct
construction.
Signed-o
When using the --recurse-submodules flag with a relative pathspec which
includes "..", an error is produced inside the child process spawned for
a submodule. When creating the pathspec struct in the child, the ".."
is interpreted to mean "go up a directory" which causes an error stating
that the p
It was discovered that when using the --recurse-submodules flag with `git grep`
and `git ls-files` and specifying a relative path when not at the root causes
the child processes spawned to error out with an error like:
fatal: ..: '..' is outside repository
While true that ".." is outside the scop
Junio C Hamano writes ("Re: SHA1 collisions found"):
> Ian Jackson writes:
> > * Therefore the transition needs to be done by giving every object
> >two names (old and new hash function). Objects may refer to each
> >other by either name, but must pick one. The usual shape of
>
> I do
On Fri, Feb 24, 2017 at 09:32:13AM -0800, Junio C Hamano wrote:
> > * Therefore the transition needs to be done by giving every object
> >two names (old and new hash function). Objects may refer to each
> >other by either name, but must pick one. The usual shape of
>
> I do not think i
W dniu 25.02.2017 o 00:06, Jeff King pisze:
> On Fri, Feb 24, 2017 at 11:47:46PM +0100, Jakub Narębski wrote:
>
>> I have just read on ArsTechnica[1] that while Git repository could be
>> corrupted (though this would require attackers to spend great amount
>> of resources creating their own collis
On Fri, Feb 24, 2017 at 1:08 PM, Jeff King wrote:
> + (!parse_config_key(var, section, NULL, NULL, &key) &&
> +!strcmp(key, "hiderefs"))) {
Heh, see how fast my code gets replaced with even better code? ;)
All three patches look good,
Thanks,
Stefan
On 2017-02-25 00:05:34, Jakub Narębski wrote:
> W dniu 24.02.2017 o 23:53, Santiago Torres pisze:
> > On Fri, Feb 24, 2017 at 11:47:46PM +0100, Jakub Narębski wrote:
> > > I have just read on ArsTechnica[1] that while Git repository could
> > > be corrupted (though this would require attackers to
On Fri, Feb 24, 2017 at 11:47:46PM +0100, Jakub Narębski wrote:
> I have just read on ArsTechnica[1] that while Git repository could be
> corrupted (though this would require attackers to spend great amount
> of resources creating their own collision, while as said elsewhere
> in this thread alleg
W dniu 24.02.2017 o 23:53, Santiago Torres pisze:
> On Fri, Feb 24, 2017 at 11:47:46PM +0100, Jakub Narębski wrote:
>>
>> I have just read on ArsTechnica[1] that while Git repository could be
>> corrupted (though this would require attackers to spend great amount
>> of resources creating their own
On Fri, Feb 24, 2017 at 11:47:46PM +0100, Jakub Narębski wrote:
> I have just read on ArsTechnica[1] that while Git repository could be
> corrupted (though this would require attackers to spend great amount
> of resources creating their own collision, while as said elsewhere
> in this thread allege
I have just read on ArsTechnica[1] that while Git repository could be
corrupted (though this would require attackers to spend great amount
of resources creating their own collision, while as said elsewhere
in this thread allegedly easy to detect), putting two proof-of-concept
different PDFs with sa
From: "Nguyễn Thái Ngọc Duy"
Sometimes a set of repositories want to share configuration settings
among themselves that are distinct from other such sets of repositories.
A user may work on two projects, each of which have multiple
repositories, and use one user.email for one project while using
W dniu 24.02.2017 o 21:37, Andreas Heiduk pisze:
> Linking the description for pathname quoting to the configuration
> variable "core.quotePath" removes inconstistent and incomplete
> sections while also giving two hints how to deal with it: Either with
> "-c core.quotePath=false" or with "-z".
Th
Johannes Sixt writes:
> It can be argued that in normal interactive use, it is hard to notice
> that another DLL is loaded. Don't forget, though, that on Windows it
> is not only the pure time to resolve the entry points, but also that
> typically virus scanners inspect every executable file that
W dniu 24.02.2017 o 21:37, Andreas Heiduk pisze:
> Signed-off-by: Andreas Heiduk
Thanks. This is good work.
> ---
> Documentation/config.txt | 24 ++--
> 1 file changed, 14 insertions(+), 10 deletions(-)
>
> diff --git a/Documentation/config.txt b/Documentation/config.txt
On Fri, Feb 24, 2017 at 01:20:48PM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > The parse_config_key() function was introduced to make it
> > easier to match "section.subsection.key" variables. It also
> > handles the simpler "section.key", and the caller is
> > responsible for disting
Jeff King writes:
> The parse_config_key() function was introduced to make it
> easier to match "section.subsection.key" variables. It also
> handles the simpler "section.key", and the caller is
> responsible for distinguishing the two from its
> out-parameters.
>
> Most callers who _only_ want "
On Fri, Feb 24, 2017 at 01:18:48PM -0800, Junio C Hamano wrote:
> > While I'm thinking about it, here are patches to do that. The third one
> > I'd probably squash into yours (after ordering it to the end).
> >
> > [1/3]: parse_config_key: use skip_prefix instead of starts_with
> > [2/3]: pars
Junio C Hamano writes:
> Jeff King writes:
>
>> The parse_config_key() function was introduced to make it
>> easier to match "section.subsection.key" variables. It also
>> handles the simpler "section.key", and the caller is
>> responsible for distinguishing the two from its
>> out-parameters.
>
Jeff King writes:
> On Fri, Feb 24, 2017 at 01:18:48PM -0800, Junio C Hamano wrote:
>
>> > While I'm thinking about it, here are patches to do that. The third one
>> > I'd probably squash into yours (after ordering it to the end).
>> >
>> > [1/3]: parse_config_key: use skip_prefix instead of st
Jeff King writes:
> On Fri, Feb 24, 2017 at 03:39:40PM -0500, Jeff King wrote:
>
>> This will start parsing "receive.foobar.hiderefs", which we don't want.
>> I think you need:
>>
>> !parse_config_key(var, section, &subsection, &subsection_len, &key) &&
>> !subsection &&
>> !strcmp(key, "h
This lets us avoid declaring some otherwise useless
variables.
Signed-off-by: Jeff King
---
refs.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/refs.c b/refs.c
index 21bc8c910..b9188908b 100644
--- a/refs.c
+++ b/refs.c
@@ -1034,11 +1034,10 @@ static struct string_l
The parse_config_key() function was introduced to make it
easier to match "section.subsection.key" variables. It also
handles the simpler "section.key", and the caller is
responsible for distinguishing the two from its
out-parameters.
Most callers who _only_ want "section.key" would just use a
str
This saves us having to repeatedly add in "section_len" (and
also avoids walking over the first part of the string
multiple times for a strlen() and strrchr()).
Signed-off-by: Jeff King
---
config.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/config.c b/config.c
in
On Fri, Feb 24, 2017 at 03:39:40PM -0500, Jeff King wrote:
> This will start parsing "receive.foobar.hiderefs", which we don't want.
> I think you need:
>
> !parse_config_key(var, section, &subsection, &subsection_len, &key) &&
> !subsection &&
> !strcmp(key, "hiderefs")
>
> Perhaps passin
Brandon Williams writes:
> Currently the submodule..url config option is used to determine
> if a given submodule exists and is interesting to the user. This
> however doesn't work very well because the URL is a config option for
> the scope of a repository, whereas the existence of a submodule
Stefan Beller writes:
> parse_config_key was introduced in 1b86bbb0ade (config: add helper
> function for parsing key names, 2013-01-22), the NEEDSWORK that is removed
> in this patch was introduced at daebaa7813 (upload/receive-pack: allow
> hiding ref hierarchies, 2013-01-18), which is only a c
On Fri, Feb 24, 2017 at 12:43:35PM -0800, Stefan Beller wrote:
> parse_config_key was introduced in 1b86bbb0ade (config: add helper
> function for parsing key names, 2013-01-22), the NEEDSWORK that is removed
> in this patch was introduced at daebaa7813 (upload/receive-pack: allow
> hiding ref hie
Hello Dear Friend,
My name is Samfo Abudu I have decided to seek a confidential
co-operation with you in the execution of the deal described
here-under for our both mutual benefit and I hope you will keep it a
top secret because of the nature of the transaction, During the
course of our bank y
parse_config_key was introduced in 1b86bbb0ade (config: add helper
function for parsing key names, 2013-01-22), the NEEDSWORK that is removed
in this patch was introduced at daebaa7813 (upload/receive-pack: allow
hiding ref hierarchies, 2013-01-18), which is only a couple days apart,
so presumably
parse_config_key was introduced in 1b86bbb0ade (config: add helper
function for parsing key names, 2013-01-22), the NEEDSWORK that is removed
in this patch was introduced at daebaa7813 (upload/receive-pack: allow
hiding ref hierarchies, 2013-01-18), which is only a couple days apart,
so presumably
On Fri, Feb 24, 2017 at 12:33:35PM -0800, Stefan Beller wrote:
> parse_config_key was introduced in 1b86bbb0ade (config: add helper
> function for parsing key names, 2013-01-22), the NEEDSWORK that is removed
> in this patch was introduced at daebaa7813 (upload/receive-pack: allow
> hiding ref hie
Signed-off-by: Andreas Heiduk
---
Documentation/config.txt | 24 ++--
1 file changed, 14 insertions(+), 10 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 1fee83c..fa06c2a 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
Linking the description for pathname quoting to the configuration
variable "core.quotePath" removes inconstistent and incomplete
sections while also giving two hints how to deal with it: Either with
"-c core.quotePath=false" or with "-z".
Signed-off-by: Andreas Heiduk
---
Documentation/diff-form
These two patches replace and extend the precious patches with the
same subject. Suggestions from Philip Oakley and Junio C Hamano are
included.
I tried to find and adjust all places where pathname quoting and "-z"
were described. I omitted these places:
* Here "-z" is for input only. Quoting is
On Fri, Feb 24, 2017 at 11:51:22AM -0800, Junio C Hamano wrote:
> > A slightly worse is that the upcoming Git will ship with a rewritten
> > "difftool" that makes the above sequence segfault.
>
> The culprit seems to be these lines in run_dir_diff():
>
> if (S_ISLNK(lmode)) {
>
From: "Stefan Beller"
On Fri, Feb 24, 2017 at 10:14 AM, Junio C Hamano
wrote:
you are inviting people to start using
md5,54ddf8d47340e048166c45f439ce65fd
as object names.
which might even be okay for specific subsets of operations.
(e.g. all local work including staging things, makin
ankostis writes:
> Let's assume that git is retroffited to always support the "default"
> SHA-3, but support additionally more hash-funcs.
> If in the future SHA-3 also gets defeated, it would be highly unlikely
> that the same math would also break e.g. Blake.
> So certain high-profile repos mig
On Fri, Feb 24, 2017 at 12:19 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> When a submodule is initialized, the config variable 'submodule..url'
>> is set depending on the value of the same variable in the .gitmodules
>> file. When the URL indicates to be relative, then the url is compu
Stefan Beller writes:
> When a submodule is initialized, the config variable 'submodule..url'
> is set depending on the value of the same variable in the .gitmodules
> file. When the URL indicates to be relative, then the url is computed
> relative to its default remote. The default remote cannot
On 24 February 2017 at 20:20, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> On Fri, Feb 24, 2017 at 10:14 AM, Junio C Hamano wrote:
>>
>>> you are inviting people to start using
>>>
>>> md5,54ddf8d47340e048166c45f439ce65fd
>>>
>>> as object names.
>>
>> which might even be okay for spec
Junio C Hamano writes:
> The not-so-well-hidden agenda was exactly that we _SHOULD_ not
> mimick PGP. They do not have a requirement to encourage everybody
> to use the same thing because each message is encrypted/signed
> independently, i.e. they do not have to chain things like we do.
To put
Junio C Hamano writes:
>> cd /tmp
>> mkdir a
>> cd a
>> git init
>> touch b
>> ln -s b c
>> git add .
>> git commit -m 'first'
>> touch d
>> rm c
>> ln -s d c
>> git difftool --dir-diff
>
> A slightly worse is that the upcoming Git will ship with a rewritten
> "difftool" that makes the above sequ
On 24/02/17 13:14, Nguyễn Thái Ngọc Duy wrote:
[snip]
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> Documentation/config.txt | 61 +
> config.c | 97
> +++
> t/t1305-config-include.sh | 56 ++
The latest feature release Git v2.12.0 is now available at the
usual places. It is comprised of 517 non-merge commits since
v2.11.0, contributed by 80 people, 24 of which are new faces.
The tarballs are found at:
https://www.kernel.org/pub/software/scm/git/
The following public repositories
What's cooking in git.git (Feb 2017, #08; Fri, 24)
--
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
Welcome to the Git development community.
This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.
* Mailing list and the community
The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports
Jeff King:
> diff --git a/Makefile b/Makefile
> index 8e4081e06..7c4906250 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1386,6 +1390,11 @@ ifdef APPLE_COMMON_CRYPTO
> SHA1_MAX_BLOCK_SIZE = 1024L*1024L*1024L
> endif
>
> +ifdef USE_SHA1DC
> + SHA1_HEADER = "sha1dc/sha1.h"
> + LIB_O
On Thu, Feb 23, 2017 at 5:25 PM, Ramsay Jones
wrote:
>> +int option_parse_recurse_submodules(const struct option *opt,
>> + const char *arg, int unset)
>
> Again, this function should be marked static.
>
> [I also noted _two_ other local functions with the same name
Stefan Beller writes:
> On Fri, Feb 24, 2017 at 10:14 AM, Junio C Hamano wrote:
>
>> you are inviting people to start using
>>
>> md5,54ddf8d47340e048166c45f439ce65fd
>>
>> as object names.
>
> which might even be okay for specific subsets of operations.
> (e.g. all local work including stag
On Thu, Feb 23, 2017 at 5:21 PM, Ramsay Jones
wrote:
>
>
> On 23/02/17 22:57, Stefan Beller wrote:
>> In later patches we introduce the options and flag for commands
>> that modify the working directory, e.g. git-checkout.
>>
>> This piece of code will be used universally for
>> all these working
On Fri, Feb 24, 2017 at 12:03:45PM +0100, Geert Uytterhoeven wrote:
> > The problem isn't on the applying end, but rather on the generating end.
> > The From header in the attached mbox is:
> >
> > From: =?us-ascii?B?PT9VVEYtOD9xP1NpbW9uPTIwU2FuZHN0cj1DMz1CNm0/PQ==?=
> >
>
> Slightly related,
On Fri, Feb 24, 2017 at 10:14 AM, Junio C Hamano wrote:
> you are inviting people to start using
>
> md5,54ddf8d47340e048166c45f439ce65fd
>
> as object names.
which might even be okay for specific subsets of operations.
(e.g. all local work including staging things, making local "fixup" comm
On Fri, Feb 24, 2017 at 06:36:00PM +, HW42 wrote:
> > +ifdef USE_SHA1DC
> > + SHA1_HEADER = "sha1dc/sha1.h"
> > + LIB_OBJS += sha1dc/sha1.o
> > + LIB_OBJS += sha1dc/ubc_check.o
> > +else
> > ifdef BLK_SHA1
> > SHA1_HEADER = "block-sha1/sha1.h"
> > LIB_OBJS += block-sha1/sha1.o
>
Nguyễn Thái Ngọc Duy writes:
> +Conditional includes
> +
> +
> +You can include one config file from another conditionally by setting
> +a `includeIf..path` variable to the name of the file to be
> +included. The variable's value is treated the same way as `include.path`.
> +
When a submodule is initialized, the config variable 'submodule..url'
is set depending on the value of the same variable in the .gitmodules
file. When the URL indicates to be relative, then the url is computed
relative to its default remote. The default remote cannot be determined
accurately in all
David Lang writes:
> On Fri, 24 Feb 2017, Junio C Hamano wrote:
>
>> *1* In the above toy example, length being 40 vs 64 is used as a
>>sign between SHA-1 and the new hash, and careful readers may
>>wonder if we should use sha-3,20769079d22... or something like
>>that that more explic
Jiang Xin writes:
> Hi Junio,
>
> Please pull l10n updates for Git 2.12.0:
>
> The following changes since commit 076c05393a047247ea723896289b48d6549ed7d0:
>
> Hopefully the final batch of mini-topics before the final
> (2017-02-16 14:46:35 -0800)
>
> are available in the git repository at:
>
>
Duy Nguyen writes:
>>> + if (skip_prefix_mem(cond, cond_len, "gitdir:", &cond, &cond_len))
>>> + return include_by_gitdir(cond, cond_len, 0);
>>> + else if (skip_prefix_mem(cond, cond_len, "gitdir/i:", &cond,
>>> &cond_len))
>>> + return include_by_gitdir(cond, co
Christophe Macabiau writes:
> with the commands below, you will get :
>
>> fatal: bad object
>> show : command returned error: 128
>>
>
> I am using version 2.5.5 fedora 23
>
> cd /tmp
> mkdir a
> cd a
> git init
> t
On Fri, 24 Feb 2017, Junio C Hamano wrote:
*1* In the above toy example, length being 40 vs 64 is used as a
sign between SHA-1 and the new hash, and careful readers may
wonder if we should use sha-3,20769079d22... or something like
that that more explicity identifies what hash is used,
Jeff King writes:
> On Fri, Feb 24, 2017 at 09:46:45AM +0100, Patrick Steinhardt wrote:
>
>> In commit 07e7dbf0d (gc: default aggressive depth to 50, 2016-08-11),
>> the default aggressive depth of git-gc has been changed to 50. While
>> git-config(1) has been updated to represent the new default
Hi Ian,
On Fri, Feb 24, 2017 at 03:13:37PM +, Ian Jackson wrote:
> Joey Hess writes ("SHA1 collisions found"):
> > https://shattered.io/static/shattered.pdf
> > https://freedom-to-tinker.com/2017/02/23/rip-sha-1/
> >
> > IIRC someone has been working on parameterizing git's SHA1 assumptions
>
1 - 100 of 119 matches
Mail list logo