Hello Eric,
On Tue, Jul 19, 2016 at 02:52:42PM -0400, Eric Sunshine wrote:
> On Tue, Jul 19, 2016 at 2:04 PM, Junio C Hamano wrote:
> > Antoine Tenart writes:
> >> Adds a --name option allowing to specify the name of a worktree when
> >> creating it. This allows to have multiple worktrees in dir
Hi team,
Great work on the documentation provided for GIT on https://git-scm.com
But found an error on the same, to just for testing, I switched to Hindi
Language (Clicked on Hindi link on left panel) as for reading the
pages/book in hindi language, I got 500 Internal server Error.
I hope y
On Tue, Jul 19, 2016 at 10:59 PM, Lars Schneider
wrote:
> Hi,
>
> some time ago Michael wrote in a blog post [1]:
> "It's not recommended to use git worktree with a repository that contains
> submodules."
>
> Plus "Documentation/git-worktree.txt" states:
> "Multiple checkout in general is still e
Duy Nguyen wrote:
> On Tue, Jul 19, 2016 at 12:54 AM, Eric Wong wrote:
> > Oops, forgot to Cc some folks who worked on this :x
> >
> > Filesystem is ufs and it fails regardless of whether
> > soft-updates is enabled or not.
>
> Nothing stands out to my eyes, so I'm going to install freebsd this
Perl has not been part of the base system since FreeBSD 5.0:
https://www.freebsd.org/releases/5.0R/relnotes-i386.html
Signed-off-by: Eric Wong
---
Does anybody still run git on FreeBSD 4.x or earlier?
4.11 was released a few months before git in 2005:
https://www.freebsd.org
On 07/20/2016 12:01 AM, Lars Schneider wrote:
On 19 Jul 2016, at 23:33, Junio C Hamano wrote:
Lars Schneider writes:
Git writes --> 4 byte filename length
Git writes --> filename string
Why limit to 32GB? Perhaps NUL termination is more appropriate
here?
OK, I will use NUL terminatio
Checking the version of the installed SVN libraries should not
require a git repository at all. This matches the behavior of
"git --version".
Add a test for "git svn help" for the same behavior while we're
at it, too.
Signed-off-by: Eric Wong
---
I'm hoping "cd /" in the test will always succ
W dniu 2016-06-30 o 00:00, Jeff King pisze:
> On Wed, Jun 29, 2016 at 11:49:35PM +0200, Jakub Narębski wrote:
>> Do Git use EWAH / EWOK bitmaps for reachability analysis, or is it still
>> limited to object counting?
>
> At GitHub we are using them for --contains analysis, along with mass
> ahead/
Signed-off-by: Stefan Beller
---
Is it too obvious?
I was approached off list and this was only obvious after some discussion,
so I think it is a valid warning.
On the other hand this might show that we want to get worktree working with
submodules.
Documentation/git-submodule.txt | 4 +++
> the logical place to pull that information from would be
> ../../GIT-VERSION-FILE,
I agree. It would make more sense to build this to a specific version
or git revision rather
than a time. Perhaps that would be a different patch?
> So unless the "dynamic lookup in the Makefile" turns out to be
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.
You can find the changes described
This patch series adds porcelain V2 format to status.
This provides detailed information about file changes
and about the current branch.
The new output is accessed via:
git status --porcelain=2 [--branch]
An earlier draft of this work was submitted under the
"Add very verbose porcelain outpu
This commit contains unit tests to exercise
the V2 porcelain status format.
Signed-off-by: Jeff Hostetler
---
t/t7064-wtstatus-pv2.sh | 461
t/t7501-commit.sh | 9 +
2 files changed, 470 insertions(+)
create mode 100755 t/t7064-wtstatus-p
Simple unit tests to validate the argument parsing.
Signed-off-by: Jeff Hostetler
---
t/t7060-wtstatus.sh | 21 +
t/t7501-commit.sh | 14 ++
2 files changed, 35 insertions(+)
diff --git a/t/t7060-wtstatus.sh b/t/t7060-wtstatus.sh
index 44bf1d8..a39b0e2 100755
-
Update the --porcelain argument to take an optional
version number. This will allow us to define new
porcelain formats in the future.
This default to 1 and represents the existing porcelain
format.
Signed-off-by: Jeff Hostetler
---
Documentation/git-commit.txt | 2 +-
Documentation/git-status
This commit updates the status manpage to include
information about porcelain format V2.
Signed-off-by: Jeff Hostetler
---
Documentation/git-status.txt | 62 +---
1 file changed, 59 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-status.txt b
This commit sets up version 2 porcelain status and
defines the format of detail lines. This includes
the usual XY and pathname fields. It adds the various
file modes and SHAs and the rename score. For regular
entries these values reflect the head, index and
worktree. For unmerged entries these v
This commit expand porcelain status V2 to print
detailed information about the current branch.
This includes the SHA of the current commit, the
current branch name, the upstream branch name,
and the ahead/behind counts.
This additional information is included when
the --branch argument is given.
On 19 Jul 2016, at 23:33, Junio C Hamano wrote:
> Lars Schneider writes:
>
>> Git writes --> 4 byte filename length
>> Git writes --> filename string
>
> Why limit to 32GB? Perhaps NUL termination is more appropriate
> here?
OK, I will use NUL termination for the filename.
You're also right
Lars Schneider writes:
> Git writes --> 4 byte filename length
> Git writes --> filename string
Why limit to 32GB? Perhaps NUL termination is more appropriate
here?
> Git writes --> 4 byte content length
> Git writes --> content string
> Git reads <-- 4 byte filtered content length
> Git reads
Junio C Hamano writes:
> It is not wrong per-se, but as you are in a subshell, you do not
> have to unset these, I would think. Not worth a reroll, but unless
> I am overlooking something (in which case please holler) I'm
> inclined to remove these two lines myself while queuing the series.
I p
Hi,
some time ago Michael wrote in a blog post [1]:
"It's not recommended to use git worktree with a repository that contains
submodules."
Plus "Documentation/git-worktree.txt" states:
"Multiple checkout in general is still experimental, and the support
for submodules is incomplete. It is NOT re
On 19 Jul 2016, at 20:53, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> The key benefit of this arrangement is the above can be done without
>> having to do poll() to flip between reading and writing that is
>> needed to avoid deadlocking, which kept the code simpler. A later
>> convers
Jonathan Nieder writes:
> In the stateless-rpc case, linear growth means getting a bounded
> number of 'have's worth of benefit (new 'have's) in each round, in
> exchange for a linearly increasing cost (existing 'have's). That is a
> high cost for limited benefit. Exponential growth is a better
Junio C Hamano wrote:
> Even if it is conservative, I wonder if it is truly a good idea to
> make it exponentially grow forever from that point of view. Would
> it give essentially the same result to you if we discard the patch
> in question and just raise LARGE_FLUSH to 10k instead?
I don't thi
On Tue, Jul 19, 2016 at 09:04:11PM +0200, Duy Nguyen wrote:
> On Tue, Jul 19, 2016 at 8:54 PM, Antoine Tenart wrote:
> > On Tue, Jul 19, 2016 at 08:23:58PM +0200, Duy Nguyen wrote:
> >> On Tue, Jul 19, 2016 at 8:04 PM, Junio C Hamano wrote:
> >>
> >> 080739b (worktree.c: find_worktree() search by
Johannes Schindelin writes:
> I do not need cc/apply-am at all, it turns out, but my patch series has a
> minor conflict with 'jc/renormalize-merge-kill-safer-crlf'.
>
> Since you indicated that you want to cook that branch a bit in 'next'
> first, I will rebase to master+bc/cocci+js/am-call-thei
On Tue, Jul 19, 2016 at 12:08:11PM -0700, Junio C Hamano wrote:
> Antoine Tenart writes:
>
> > Being able to manually define the name can also be useful in some (rare)
> > cases, where you reorganize your project directory tree. But that's not
> > a strong argument for adding this option :-)
>
>
On Tue, Jul 19, 2016 at 12:15 PM, Junio C Hamano wrote:
> René Scharfe writes:
>
>> Use a string constant instead of an empty strbuf to shorten the code
>> and make it easier to read.
>>
>> Signed-off-by: Rene Scharfe
>> ---
>> ... unless someone can come up with a suitable non-empty string to f
Jonathan Tan writes:
>> So I guess what I do not understand is why we need to slow down the
>> exponential growth at all?
>
> The current code has an exponential (a' = a * 2) then a linear (a' = a
> + 1024) growth. I'm not slowing down the exponential growth - that
> part is retained. I'm replaci
On Tue, Jul 19, 2016 at 3:04 PM, Duy Nguyen wrote:
> On Tue, Jul 19, 2016 at 8:54 PM, Antoine Tenart wrote:
>> Like moving a worktree (or is there a command for this?)
>
> Don't touch it. I've been waiting patiently for that patch series to
> be reviewed :)
For newcomers, "that patch series" ref
On Tue, Jul 19, 2016 at 12:03 PM, Jonathan Tan wrote:
> On Tue, Jul 19, 2016 at 9:46 AM, Stefan Beller wrote:
>> Care to elaborate on why you choose 11/10 as growth factor?
>>
>> (As someone who has a tick in micro optimizing:
>> 9/8 is roughly the same exponent, but the division
>> by 8 is easie
René Scharfe writes:
> Use a string constant instead of an empty strbuf to shorten the code
> and make it easier to read.
>
> Signed-off-by: Rene Scharfe
> ---
> ... unless someone can come up with a suitable non-empty string to feed
> to git_config_from_mem() as its name parameter.
>
> submodu
From: "Jakub Narębski"
W dniu 2016-07-13 o 00:11, Philip Oakley pisze:
From: "Junio C Hamano"
[...]
I actually think this is a good place to have them described.
^ is about specifying a single commit. These two are
not that (you can say HEAD^2^@ but you cannot say HEAD^@^2, for
example).
Antoine Tenart writes:
> Being able to manually define the name can also be useful in some (rare)
> cases, where you reorganize your project directory tree. But that's not
> a strong argument for adding this option :-)
Continuing the rationale that rejected the topic from the earlier
discussion
Use a string constant instead of an empty strbuf to shorten the code
and make it easier to read.
Signed-off-by: Rene Scharfe
---
... unless someone can come up with a suitable non-empty string to feed
to git_config_from_mem() as its name parameter.
submodule-config.c | 3 +--
1 file changed, 1
On Tue, Jul 19, 2016 at 8:54 PM, Antoine Tenart wrote:
> On Tue, Jul 19, 2016 at 08:23:58PM +0200, Duy Nguyen wrote:
>> On Tue, Jul 19, 2016 at 8:04 PM, Junio C Hamano wrote:
>>
>> 080739b (worktree.c: find_worktree() search by path suffix -
>> 2016-06-13) from 'next' should help identify worktre
On Tue, Jul 19, 2016 at 9:46 AM, Stefan Beller wrote:
> Care to elaborate on why you choose 11/10 as growth factor?
>
> (As someone who has a tick in micro optimizing:
> 9/8 is roughly the same exponent, but the division
> by 8 is easier as it is just a shift by 3. Similar 17/16)
I don't have a s
2016-07-19 20:04 GMT+02:00 Duy Nguyen :
> On Tue, Jul 19, 2016 at 7:59 PM, David Lang wrote:
>> On Tue, 19 Jul 2016, Duy Nguyen wrote:
>>
>>> On Tue, Jul 19, 2016 at 7:34 PM, David Lang wrote:
On Tue, 19 Jul 2016, Duy Nguyen wrote:
> On Tue, Jul 19, 2016 at 9:18 AM, Johannes Sc
On Tue, Jul 19, 2016 at 08:23:58PM +0200, Duy Nguyen wrote:
> On Tue, Jul 19, 2016 at 8:04 PM, Junio C Hamano wrote:
>
> 080739b (worktree.c: find_worktree() search by path suffix -
> 2016-06-13) from 'next' should help identify worktrees in this case by
> specifying 'project0/foo', 'project1/foo
Junio C Hamano writes:
> The key benefit of this arrangement is the above can be done without
> having to do poll() to flip between reading and writing that is
> needed to avoid deadlocking, which kept the code simpler. A later
> conversion of the write side into async does not fundamentally
> c
On Tue, Jul 19, 2016 at 2:04 PM, Junio C Hamano wrote:
> Antoine Tenart writes:
>> Adds a --name option allowing to specify the name of a worktree when
>> creating it. This allows to have multiple worktrees in directories
>> having the same name (e.g. project0/foo, project1/foo etc...). This
>> c
Duy Nguyen writes:
>> Even though that single operation might be possible, do not go
>> there. A "pathname" identifies a "path", not its contents, and
>> "appending crap after path" breaks the data model badly.
>
> I thought about that but I thought all those operations required
> special treatm
Hi,
On Tue, Jul 19, 2016 at 11:04:59AM -0700, Junio C Hamano wrote:
>
> > Adds a --name option allowing to specify the name of a worktree when
> > creating it. This allows to have multiple worktrees in directories
> > having the same name (e.g. project0/foo, project1/foo etc...). This
> > commit
Use strbuf_addbuf() where possible; it's shorter and more efficient.
Signed-off-by: Rene Scharfe
---
dir.c | 2 +-
path.c | 2 +-
wt-status.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/dir.c b/dir.c
index 6172b34..0ea235f 100644
--- a/dir.c
+++ b/dir.c
@@ -
David Aguilar writes:
> Call Git::command() and friends directly wherever possible.
> This makes it clear that these operations can be invoked directly
> without needing to manage the current directory and related GIT_*
> environment variables.
Good.
> @@ -88,11 +80,11 @@ sub changed_files
>
On Tue, Jul 19, 2016 at 8:04 PM, Junio C Hamano wrote:
> Antoine Tenart writes:
>
>> Adds a --name option allowing to specify the name of a worktree when
>> creating it. This allows to have multiple worktrees in directories
>> having the same name (e.g. project0/foo, project1/foo etc...). This
>>
David Aguilar writes:
> Environment variables are global and hard to reason about.
> Use the `--git-dir` and `--work-tree` arguments when invoking `git`
> instead of relying on the environment.
>
> Add a test to ensure that difftool's dir-diff feature works when these
> variables are present in t
David Aguilar writes:
> From: John Keeping
>
> When in a subdirectory of a repository, path arguments should be
> ...
> directory.
>
> Reported-by: Bernhard Kirchen
> Signed-off-by: John Keeping
> Acked-by: David Aguilar
> ---
> This patch is unchanged from John's version but also includes
>
On Tue, Jul 19, 2016 at 7:59 PM, David Lang wrote:
> On Tue, 19 Jul 2016, Duy Nguyen wrote:
>
>> On Tue, Jul 19, 2016 at 7:34 PM, David Lang wrote:
>>>
>>> On Tue, 19 Jul 2016, Duy Nguyen wrote:
>>>
On Tue, Jul 19, 2016 at 9:18 AM, Johannes Schindelin
wrote:
>>
>>
>> But we
Antoine Tenart writes:
> Adds a --name option allowing to specify the name of a worktree when
> creating it. This allows to have multiple worktrees in directories
> having the same name (e.g. project0/foo, project1/foo etc...). This
> commit keeps the previous behaviour by making it the default v
On Tue, 19 Jul 2016, Duy Nguyen wrote:
On Tue, Jul 19, 2016 at 7:34 PM, David Lang wrote:
On Tue, 19 Jul 2016, Duy Nguyen wrote:
On Tue, Jul 19, 2016 at 9:18 AM, Johannes Schindelin
wrote:
But we can recreate SHA-1 from the same content and verify GPG, right?
I know it's super expensive,
Lars Schneider writes:
> a long time ago in aa4ed4 Junio introduced the external filter
> driver definition. Since that time we fork the Git process and
> then we fork again to run the external filter. This is probably a
> super stupid question with an obvious answer... but can anyone
> help me t
On Tue, Jul 19, 2016 at 7:34 PM, David Lang wrote:
> On Tue, 19 Jul 2016, Duy Nguyen wrote:
>
>> On Tue, Jul 19, 2016 at 9:18 AM, Johannes Schindelin
>> wrote:
But we can recreate SHA-1 from the same content and verify GPG, right?
I know it's super expensive, but it feels safer to
On Tue, 19 Jul 2016, Duy Nguyen wrote:
On Tue, Jul 19, 2016 at 9:18 AM, Johannes Schindelin
wrote:
But we can recreate SHA-1 from the same content and verify GPG, right?
I know it's super expensive, but it feels safer to not carry SHA-1
around when it's not secure anymore (I recall something a
On Tue, Jul 19, 2016 at 7:06 PM, Junio C Hamano wrote:
> Duy Nguyen writes:
>
>> Post-shower thoughts. In a tree object, a submodule entry consists of
>> perm (S_IFGITLINK), hash (which is the external hash) and path. We
>> could fill the "hash" part with all zero (invalid, signature of new
>> su
Johannes Schindelin writes:
> On Mon, 18 Jul 2016, Junio C Hamano wrote:
>
>> Johannes Schindelin writes:
>>
>> > Hrm. That sounds a little magical, and fragile, to me. What if the next
>> > person's unzip returns 0 and *still* cannot handle -a?
>>
>> That is a very sensible line of thought.
>
Duy Nguyen writes:
> Post-shower thoughts. In a tree object, a submodule entry consists of
> perm (S_IFGITLINK), hash (which is the external hash) and path. We
> could fill the "hash" part with all zero (invalid, signature of new
> submodule hash format), then append "/:" to
> the "path" part. Th
Shawn Pearce writes:
> On Mon, Jul 18, 2016 at 9:32 PM, Parker Moore wrote:
>>> The label does not even identify the version of the source in any way, so I
>>> am not sure how people are depending on that feature anyway ;-)
>>
>> Would it be a better solution simply to remove this build flag?
>
On Mon, Jul 18, 2016 at 3:21 PM, Jonathan Tan wrote:
> When updating large repositories, the LARGE_FLUSH limit (that is, the
> limit at which the window growth strategy switches from exponential to
> linear) is reached quite quickly. Use a conservative exponential growth
> strategy when that limit
Hi,
a long time ago in aa4ed4 Junio introduced the external filter driver
definition. Since that time we fork the Git process and then we fork again to
run the external filter. This is probably a super stupid question with an
obvious answer... but can anyone help me to understand the code and e
On Tue, Jul 19, 2016 at 12:54 AM, Eric Wong wrote:
> Oops, forgot to Cc some folks who worked on this :x
>
> Filesystem is ufs and it fails regardless of whether
> soft-updates is enabled or not.
Nothing stands out to my eyes, so I'm going to install freebsd this
weekend. I hope ufs does not have
On Mon, Jul 18, 2016 at 6:51 PM, Duy Nguyen wrote:
> On Sun, Jul 17, 2016 at 4:21 PM, brian m. carlson
> wrote:
>> I'm going to end up having to do something similar because of the issue
>> of submodules. Submodules may still be SHA-1, while the main repo may
>> be a newer hash.
>
> Or even the
On Tue, Jul 19, 2016 at 3:07 AM, Jeff King wrote:
> On Mon, Jul 18, 2016 at 10:28:25PM -0700, Stefan Beller wrote:
>
>> On Sat, Jul 16, 2016 at 12:56 AM, Jeff King wrote:
>> >> > + if (use_keepalive == KEEPALIVE_AFTER_NUL &&
>> >> > !keepalive_active) {
>> >> > +
W dniu 2016-07-13 o 00:11, Philip Oakley pisze:
> From: "Junio C Hamano"
[...]
>> I actually think this is a good place to have them described.
>> ^ is about specifying a single commit. These two are
>> not that (you can say HEAD^2^@ but you cannot say HEAD^@^2, for
>> example).
>
> These two ar
On Tue, Jul 19, 2016 at 9:18 AM, Johannes Schindelin
wrote:
>> But we can recreate SHA-1 from the same content and verify GPG, right?
>> I know it's super expensive, but it feels safer to not carry SHA-1
>> around when it's not secure anymore (I recall something about
>> exploiting the weakest lin
Johannes Schindelin writes:
>
>A better method might be to use the `git difftool` command, e.g.
>
>git difftool -x diff
Something like:
git difftool --no-prompt --extcmd=diff
or like:
git difftool --no-prompt --extcmd="diff -b" "$@"
works great for me. Thank you very much indeed!
Norman
Adds a --name option allowing to specify the name of a worktree when
creating it. This allows to have multiple worktrees in directories
having the same name (e.g. project0/foo, project1/foo etc...). This
commit keeps the previous behaviour by making it the default value, i.e.
by using $(basename )
Hi Richard,
On Tue, 19 Jul 2016, Richard Soderberg wrote:
> Aha! Yes, this works precisely as intended: the prompt works
> correctly, and quickly, with this change in place.
Okay, next step for you: read
http://github.com/git-for-windows/git/blob/master/Documentation/SubmittingPatches
and submit
Hi Junio,
On Tue, 19 Jul 2016, Johannes Schindelin wrote:
> On Mon, 18 Jul 2016, Junio C Hamano wrote:
>
> > Junio C Hamano writes:
> >
> > You can assume that I'll merge bc/cocci and
> > js/am-call-theirs-theirs-in-fallback-3way to 'master' during that time,
> > so an appropriate base to use
Aha! Yes, this works precisely as intended: the prompt works
correctly, and quickly, with this change in place.
- R.
On Tue, Jul 19, 2016 at 4:24 AM, Johannes Schindelin
wrote:
> Hi Richard,
>
> On Mon, 18 Jul 2016, Richard Soderberg wrote:
>
>> Hi, I wanted to report something interesting that
Hi Junio,
On Mon, 18 Jul 2016, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > Johannes Schindelin writes:
> >
> >> The two topics that are in 'pu' and conflict with this series are
> >> 'jh/clean-smudge-annex' and 'bc/cocci'.
> >>
> >> It also conflicted with 'va/i18n-even-more', but tha
On Tue, Jul 19, 2016 at 05:29:07AM -0600, Jeff King wrote:
> On Sun, Jul 17, 2016 at 08:06:49PM +0300, Kirill Smelkov wrote:
>
> > > Anyway, please find below updated patch according to your suggestion.
> > > Hope it is ok now.
> >
> > Ping. Is the patch ok or something needs to be improved still
On Sun, Jul 17, 2016 at 08:06:49PM +0300, Kirill Smelkov wrote:
> > Anyway, please find below updated patch according to your suggestion.
> > Hope it is ok now.
>
> Ping. Is the patch ok or something needs to be improved still?
Sorry, I'm traveling and haven't carefully reviewed it yet. It's sti
Hi Junio,
On Mon, 18 Jul 2016, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > Hrm. That sounds a little magical, and fragile, to me. What if the next
> > person's unzip returns 0 and *still* cannot handle -a?
>
> That is a very sensible line of thought.
>
> > I'd rather do somethin
Hi Richard,
On Mon, 18 Jul 2016, Richard Soderberg wrote:
> Hi, I wanted to report something interesting that I found while tracing
> a severe slowdown in git-prompt.sh.
>
> https://github.com/git/git/commit/6d158cba282f22fa1548af1188f78042fed30aed#diff-f37c4f4a898819f0ca4b5ff69e81d4d9R141
>
>
This has always been supported since we read config variables
based on the command-line option parser. Document it explicitly
since users usually want to maintain the same program across
invocations.
Signed-off-by: Eric Wong
---
Pushed to master of bogomips.org/git-svn.git, but I might
have mo
On Mon, Jul 18, 2016 at 10:28:25PM -0700, Stefan Beller wrote:
> On Sat, Jul 16, 2016 at 12:56 AM, Jeff King wrote:
> >> > + if (use_keepalive == KEEPALIVE_AFTER_NUL &&
> >> > !keepalive_active) {
> >> > + const char *p = memchr(data, '\0', sz);
> >> > +
On Tue, 19 Jul 2016, Johannes Schindelin wrote:
Hi Duy,
On Mon, 18 Jul 2016, Duy Nguyen wrote:
On Sun, Jul 17, 2016 at 4:21 PM, brian m. carlson
wrote:
I'm going to end up having to do something similar because of the issue
of submodules. Submodules may still be SHA-1, while the main repo
Hi Duy,
On Mon, 18 Jul 2016, Duy Nguyen wrote:
> On Sun, Jul 17, 2016 at 4:21 PM, brian m. carlson
> wrote:
> > I'm going to end up having to do something similar because of the issue
> > of submodules. Submodules may still be SHA-1, while the main repo may
> > be a newer hash.
>
> Or even the
Hi Zsolt,
On Mon, 18 Jul 2016, Herczeg Zsolt wrote:
> >> My point is not to throw out old hashes and break signatures. My point
> >> is to convert the data storage, and use mapping to resolve problems
> >> with those old hashes and signatures.
> >
> > If you convert the data storage, then the SHA
Hi Duy,
On Mon, 18 Jul 2016, Duy Nguyen wrote:
> On Mon, Jul 18, 2016 at 5:57 PM, Johannes Schindelin
> wrote:
> >
> > On Mon, 18 Jul 2016, Herczeg Zsolt wrote:
> >
> >> >> I think converting is a much better option. Use a single-hash
> >> >> storage, and convert everything to that on import/clo
82 matches
Mail list logo
