On Tue, Jul 12, 2016 at 10:38 PM, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
>> Since I now could reproduce the problem that Christoph showed, I
>> decided to send the good patches out. To sum up, we use "unsigned
>> long" in some places related to file size. On 32-bit systems, it's
On Tue, Jul 12, 2016 at 11:12:25AM -0700, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> >> Cool! Thanks for working on this.
> >
> > Well, I had to. Git for Windows v2.9.1 needs to get released, and I won't
> > do that with a failing test suite.
>
> Let's do 2.9.2 together, as this is
On Tue, Jul 12, 2016 at 11:12 AM, Junio C Hamano wrote:
>
> Let's do 2.9.2 together, as this is not limited to GfW.
>
> Taking Peff's suggestions into account, perhaps like the attached?
If I can get positive comments soon enough, I can do 2.9.2 early
tomorrow my time.
Or a reasonable counter-pro
= SUMMARY ==
My public git.git is available here[1]. I regularly keep pushing my work so
anyone interested can track me there. Feel free to participate in the
discussions going on PRs with my mentors. Your comments are valuable.
I am using git 2.9.0.windows.1 in windows 10. With core.editor set to
vim.
Vim was downloaded from vim.org latest version binary: VIM - Vi IMproved
7.4.1023 (2013 Aug 10, compiled Jan 2 2016 14:24:35) MS-Windows 32-bit
console version
When I do a git commit in a cmd window, it goes into a vim
is_empty_file() can help to refactor a lot of code. This will be very
helpful in porting "git bisect" to C.
Suggested-by: Torsten Bögershausen
Mentored-by: Lars Schneider
Mentored-by: Christian Couder
Signed-off-by: Pranit Bauva
---
builtin/am.c | 20 ++--
cache.h | 3 ++
Reimplement the `write_terms` shell function in C and add a `write-terms`
subcommand to `git bisect--helper` to call it from git-bisect.sh . Also
remove the subcommand `--check-term-format` as it can now be called from
inside the function write_terms() C implementation.
Also `|| exit` is added whe
Hey Junio,
A small mistake got unnoticed by me which Lars recently pointed out.
The naming convention is "git_path_" and underscore
instead of spaces.
Thanks!
The interdiff is:
diff --git a/builtin/bisect--helper.c b/builtin/bisect--helper.c
index c2f3cee..88a1df8 100644
--- a/builtin/bisect--he
Reimplement the `bisect_write` shell function in C and add a
`bisect-write` subcommand to `git bisect--helper` to call it from
git-bisect.sh
Using `--bisect-write` subcommand is a temporary measure to port shell
function in C so as to use the existing test suite. As more functions
are ported, this
Add test to explicitly check that 'git bisect reset' is working as
expected. This is already covered implicitly by the test suite.
Mentored-by: Lars Schneider
Mentored-by: Christian Couder
Signed-off-by: Pranit Bauva
---
I faced this problem while converting `bisect_clean_state` and the tests
Reimplement `bisect_clean_state` shell function in C and add a
`bisect-clean-state` subcommand to `git bisect--helper` to call it from
git-bisect.sh .
Using `--bisect-clean-state` subcommand is a measure to port shell
function to C so as to use the existing test suite. As more functions
are ported
Reimplement the `check_term_format` shell function in C and add
a `--check-term-format` subcommand to `git bisect--helper` to call it
from git-bisect.sh
Using `--check-term-format` subcommand is a temporary measure to port
shell function to C so as to use the existing test suite. As more
functions
`--next-all` is meant to be used as a subcommand to support multiple
"operation mode" though the current implementation does not contain any
other subcommand along side with `--next-all` but further commits will
include some more subcommands.
Helped-by: Johannes Schindelin
Mentored-by: Lars Schne
Reimplement `is_expected_rev` & `check_expected_revs` shell function in
C and add a `--check-expected-revs` subcommand to `git bisect--helper` to
call it from git-bisect.sh .
Using `--check-expected-revs` subcommand is a temporary measure to port
shell functions to C so as to use the existing test
Reimplement `bisect_reset` shell function in C and add a `--bisect-reset`
subcommand to `git bisect--helper` to call it from git-bisect.sh .
Using `bisect_reset` subcommand is a temporary measure to port shell
functions to C so as to use the existing test suite. As more functions
are ported, this
From: "Junio C Hamano"
Philip Oakley writes:
This is the re-roll of the po/range-doc (2016-07-01) 3 commits and its
follow on patch.
The series has gained additional patches following the discussions
($gmane/298790).
..
The patches can be squashed together if required.
Looked mostly sen
From: "Junio C Hamano"
Marc Branchaud writes:
+The '{caret}' (caret) notation
+~~~
To exclude commits reachable from a commit, a prefix '{caret}'
notation is used. E.g. '{caret}r1 r2' means commits reachable
from 'r2' but exclude the ones reachable from 'r1'
Torsten Bögershausen wrote re jh/clean-smudge-annex:
> The thing is that we need to check the file system to find .gitatttibutes,
> even if we just did it 1 nanosecond ago.
>
> So the .gitattributes is done 3 times:
> -1 would_convert_to_git_filter_fd(
> -2 assert(would_convert_to_git_filter_fd(pa
On Tue, Jul 12, 2016 at 10:41:35PM +0100, Philip Oakley wrote:
> > > +The '{caret}' (caret) notation
> > > +~~~
> > > To exclude commits reachable from a commit, a prefix '{caret}'
> > > notation is used. E.g. '{caret}r1 r2' means commits reachable
> > > from 'r2
From: "Marc Branchaud"
On 2016-07-11 04:25 PM, Philip Oakley wrote:
Do not self-define `reachable`, which can lead to misunderstanding.
Instead define `reachability` explictly.
Signed-off-by: Philip Oakley
---
Documentation/revisions.txt | 14 ++
1 file changed, 10 insertions(+
From: "Junio C Hamano"
Philip Oakley writes:
The terms Left and Right side originate from the symmetric
difference. Name them there.
---
Sign-off?
Oops - will fix.
Documentation/revisions.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/revisions.t
From: "Marc Branchaud"
On 2016-07-11 04:25 PM, Philip Oakley wrote:
While there, also break out the other shorthand notations and
add a title for the revision range summary (which also appears
in git-rev-parse, so keep it mixed case).
Signed-off-by: Philip Oakley
---
Documentation/revisions
Johannes Schindelin writes:
> This is the second iteration of the long-awaited re-roll of the attempt to
> avoid spawning merge-recursive from the builtin am and use merge_recursive()
> directly instead.
This is actually the third iteration.
I am trying to tease dependencies apart and apply thi
Nguyễn Thái Ngọc Duy writes:
> diff --git a/cache-tree.c b/cache-tree.c
> index c2676e8..2d50640 100644
> --- a/cache-tree.c
> +++ b/cache-tree.c
> @@ -380,6 +380,13 @@ static int update_one(struct cache_tree *it,
> continue;
> }
>
> + /*
> +
Nguyễn Thái Ngọc Duy writes:
> This is a special SHA1. Let's keep it at one place, easier to replace
> later when the hash change comes, easier to recognize. Start with an
> underscore to reduce the chances somebody may override it without
> realizing it's predefined.
>
> Signed-off-by: Nguyễn T
Nguyễn Thái Ngọc Duy writes:
> Since I now could reproduce the problem that Christoph showed, I
> decided to send the good patches out. To sum up, we use "unsigned
> long" in some places related to file size. On 32-bit systems, it's
> limited to 32 bits even though the system can handle files la
Torsten Bögershausen writes:
>> How do things look at this point? This version is what I ended up
>> queuing in 'pu', but I took your "Thanks" in $gmane/299120 to only
>> mean "Thanks for feeding some ideas to help me move forward", not
>> necessarily "Tnanks that looks like the right approach."
Joey Hess writes:
> Since tb/convert-peek-in-index is not currently in pu, this reroll isn't
> based on it, and will conflict if that topic gets added back into pu.
> Not sure what the status of tb/convert-peek-in-index is at this point?
It appears that we are converging on _not_ using that topi
On Tue, Jul 12, 2016 at 5:12 PM, Duy Nguyen wrote:
>
> No. People could create an index file anywhere in theory. So you don't
> know how many index files there are.
Maybe when an index file is created, its path and its sharedindex file
could be appended into a log file.
We could check this log fi
Philip Oakley writes:
> This is the re-roll of the po/range-doc (2016-07-01) 3 commits and its
> follow on patch.
>
> The series has gained additional patches following the discussions
> ($gmane/298790).
>
> The original first 3 patches are unchanged, though 2/8 has been inserted
> to name the Le
Nguyễn Thái Ngọc Duy writes:
> va_end(params);
> - die(_("pack has bad object at offset %lu: %s"), offset, buf);
> + die(_("pack has bad object at offset %"PRIiMAX": %s"),
> + (intmax_t)offset, buf);
Subject: [PATCH] SQUASH???
diff --git a/builtin/index-pack.c b/builtin/i
Nguyễn Thái Ngọc Duy writes:
> - strbuf_addf(sb, "%lu", data->disk_size);
> + strbuf_addf(sb, "%"PRIuMAX, data->disk_size);
Subject: [PATCH] SQUASH???
---
builtin/cat-file.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/cat
On Fri, Jul 08, 2016 at 01:38:55PM +0300, Kirill Smelkov wrote:
> Peff first of all thanks for feedback,
>
> On Thu, Jul 07, 2016 at 04:52:23PM -0400, Jeff King wrote:
> > On Thu, Jul 07, 2016 at 10:09:17PM +0300, Kirill Smelkov wrote:
> >
> > > Starting from 6b8fda2d (pack-objects: use bitmaps w
Junio C Hamano writes:
>> +if (type != OBJ_BLOB || size < big_file_threshold) {
>> +data = unpack_entry(p, entries[i].offset, &type, &size);
>> +data_valid = 1;
>
> This codepath slurps the data in-core to hash and data is later
> freed, i.e. no
Junio C Hamano writes:
> Nguyễn Thái Ngọc Duy writes:
>
>> Since I now could reproduce the problem that Christoph showed, I
>> decided to send the good patches out. To sum up, we use "unsigned
>> long" in some places related to file size. On 32-bit systems, it's
>> limited to 32 bits even thoug
Nguyễn Thái Ngọc Duy writes:
> For this particular operation, not unpacking the blob and letting
> check_sha1_signature, which supports streaming interface, do the job
> is sufficient.
That reasoning is sound, I would think, but...
> We will call the callback function "fn" with NULL as "data".
On Tue, Jul 12, 2016 at 3:46 PM, Jeff King wrote:
> On Tue, Jul 12, 2016 at 03:31:00PM +0200, Andreas Schwab wrote:
>
>> Johannes Schindelin writes:
>>
>> > Hi Andreas,
>> >
>> > On Tue, 12 Jul 2016, Andreas Schwab wrote:
>> >
>> >> Johannes Schindelin writes:
>> >>
>> >> >> PRIuMAX isn't compat
Just thinking out loud. I've been thinking about this more about this.
After the move from signal-based to unix socket for communication, we
probably are better off with a simpler design than the shm-alike one
we have now.
What if we send everything over a socket or a pipe? Sending 500MB over
a un
Jeff King writes:
> In case it wasn't clear, I was mostly guessing there. So I dug a bit
> further, and indeed, I am wrong. Linux never bumped to a 64-bit time_t
> on i386 because of the ABI headaches.
This is being worked on.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerpr
Johannes Schindelin writes:
>> Cool! Thanks for working on this.
>
> Well, I had to. Git for Windows v2.9.1 needs to get released, and I won't
> do that with a failing test suite.
Let's do 2.9.2 together, as this is not limited to GfW.
Taking Peff's suggestions into account, perhaps like the at
Nguyễn Thái Ngọc Duy writes:
> Use the right type for offsets in this case, off_t, which makes a
> difference on 32-bit systems with large file support, and change
> formatting code accordingly.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> builtin/index-pack.c | 7 ---
> 1 file changed,
Nguyễn Thái Ngọc Duy writes:
> This field, filled by sha1_object_info() contains the on-disk size of
> an object, which could go over 4GB limit of unsigned long on 32-bit
> systems. Use off_t for it instead and update all callers.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> builtin/cat-fil
Nguyễn Thái Ngọc Duy writes:
> diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
> index 8f5e358..df6ecd5 100644
> --- a/builtin/pack-objects.c
> +++ b/builtin/pack-objects.c
> @@ -349,7 +349,7 @@ static unsigned long write_reuse_object(struct sha1file
> *f, struct object_entry
>
Nguyễn Thái Ngọc Duy writes:
> Since I now could reproduce the problem that Christoph showed, I
> decided to send the good patches out. To sum up, we use "unsigned
> long" in some places related to file size. On 32-bit systems, it's
> limited to 32 bits even though the system can handle files la
Marc Branchaud writes:
>> +The '{caret}' (caret) notation
>> +~~~
>> To exclude commits reachable from a commit, a prefix '{caret}'
>> notation is used. E.g. '{caret}r1 r2' means commits reachable
>> from 'r2' but exclude the ones reachable from 'r1'.
>
> All of
On Tue, Jul 12, 2016 at 4:22 AM, Ricardo Sánchez-Sáez
wrote:
> Stefan Beller google.com> writes:
>
> Hi,
>
> sorry to awake an old thread. Has this been fixed? In which git version?
> It's hitting me on git version 2.7.4 (Apple Git-66) (default git client on
> OS X 10.11.5 (15F34)).
>
> I think
Philip Oakley writes:
> The terms Left and Right side originate from the symmetric
> difference. Name them there.
> ---
Sign-off?
> Documentation/revisions.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt
> i
Helped-by: Jeff King
Signed-off-by: Nguyễn Thái Ngọc Duy
---
v3 fixes some memory leak and typos. Most importantly it no longer
depends on core.ignorecase for case-insensitive matching. The choice
must be explicitly made by the user when they choose "gitdir" or
"gitdir/i" keyword.
Documenta
Jeff King writes:
> In case it wasn't clear, I was mostly guessing there. So I dug a bit
> further, and indeed, I am wrong. Linux never bumped to a 64-bit time_t
> on i386 because of the ABI headaches.
X-< (yes, I knew).
> That being said, I still think the "clamp to time_t" strategy is
> reaso
Thanks for the feedback. I like the overall direction of your
suggestions. Going for a porcelain V2 feels better than piling
onto verbose. I think that would also give us a little more license
to address some of the line format issues that you point out.
Let me retool what I have along these l
On Tue, Jul 12, 2016 at 5:51 PM, Jeff King wrote:
> On Tue, Jul 12, 2016 at 05:46:12PM +0200, Duy Nguyen wrote:
>
>> I'm not opposed to letting one worktree see everything, but this move
>> makes it harder to write new scripts (or new builtin commands, even)
>> that works with both single and mult
On Tue, Jul 12, 2016 at 08:41:42AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > I am not certain that there is a modern system with 32-bit time_t. We
> > know there are systems with 32-bit unsigned long, and I think that is
> > what produced the results people saw. I'd expect even 32-b
On Mon, Jul 11, 2016 at 7:22 PM, Christian Couder
wrote:
> Future work
> ~~~
>
> One thing that is probably missing is a mechanism to avoid having too
> many changes accumulating in the (split) index while in split index
> mode. The git-update-index documentation says:
>
> If split
Hello,
My name is Chan Chak a bank manager with an investment bank, I have a
business deal of mutual benefit that involve transfer of large sum of
money. Get back to me through my private email:- chanch...@gmail.com for
more details if you are interested.
CHAN CHAK
--
To unsubscribe from this
Jeff King writes:
> However, I was thinking that it might be handy to have this and some
> other information available for helping with debugging. E.g., that we
> could ask bug reporters for "git version --build-options" when we
> suspect something related to their config.
Sure. I was wrong to
On Tue, Jul 12, 2016 at 05:46:12PM +0200, Duy Nguyen wrote:
> I'm not opposed to letting one worktree see everything, but this move
> makes it harder to write new scripts (or new builtin commands, even)
> that works with both single and multiple worktrees because you refer
> to one ref (in current
li...@haller-berlin.de (Stefan Haller) writes:
> I have read and re-read this thread a hundred times now, but I still
> don't understand why it makes much of a difference whether or not Bob
> rebases his branch onto master before pushing his merge. In both cases,
> Alice and Bob have this race as
On Tue, Jul 12, 2016 at 5:26 PM, Jeff King wrote:
> Likewise for other per-worktree items. If we used refs/MERGE_HEAD and
> refs/worktree/foo/MERGE_HEAD, then you could access them independently
> by using the fully qualified names.
I'm not opposed to letting one worktree see everything, but this
Jeff King writes:
> I am not certain that there is a modern system with 32-bit time_t. We
> know there are systems with 32-bit unsigned long, and I think that is
> what produced the results people saw. I'd expect even 32-bit systems to
> use "int64_t" or similar for their time_t these days.
OK.
On Tue, Jul 12, 2016 at 08:25:51AM -0700, Junio C Hamano wrote:
> On Tue, Jul 12, 2016 at 8:16 AM, Jeff King wrote:
> >>
> >> But moving the internal time representation used in various fields
> >> like commit->date to time_t is likely to be a wrong thing to do,
> >> because the first problem wit
On Tue, Jul 12, 2016 at 12:47:06PM +0200, Johannes Schindelin wrote:
> > Not so fast; it cuts both ways.
> >
> > People who want multiple worktrees with branches checked out to work
> > in would want to do per-worktree things like bisection, which needs
> > tons more state than we'd be comfortabl
On Tue, Jul 12, 2016 at 8:16 AM, Jeff King wrote:
>>
>> But moving the internal time representation used in various fields
>> like commit->date to time_t is likely to be a wrong thing to do,
>> because the first problem with "unsigned long", i.e. "may not be
>> wide enough", is not limited to "not
On Thu, Jul 07, 2016 at 03:26:28PM -0400, Jeff Hostetler wrote:
> Tools interacting with Git repositories may need to know the complete
> state of the working directory. For efficiency, it would be good to have
> a single command to obtain this information.
>
> We already have a `--porcelain` mod
On Tue, Jul 12, 2016 at 07:34:14AM -0700, Junio C Hamano wrote:
> > Git's source code assumes that unsigned long is at least as precise as
> > time_t. Well, Git's source code is wrong.
> > ...
>
> That is correct. As people mentioned downthread already, "unsigned
> long" has two problems, it may
On Tue, Jul 12, 2016 at 9:04 AM, Christian Couder
wrote:
> On Mon, Jul 11, 2016 at 8:27 PM, Duy Nguyen wrote:
>> On Mon, Jul 11, 2016 at 7:22 PM, Christian Couder
>> wrote:
>>> Everytime split index is turned on, it creates a "sharedindex."
>>> file in the git directory. This makes sure that
On Tue, Jul 12, 2016 at 6:16 AM, Johannes Schindelin
wrote:
>
> On Mon, 11 Jul 2016, Junio C Hamano wrote:
>
>> [New Topics]
>>
>> [...]
>
> What about http://thread.gmane.org/gmane.comp.version-control.git/299050?
Not forgotten.
It just is not one of the "New Topics" yet, together with several
Johannes Schindelin writes:
> Git's source code assumes that unsigned long is at least as precise as
> time_t. Well, Git's source code is wrong.
> ...
That is correct. As people mentioned downthread already, "unsigned
long" has two problems, it may not be wide enough, and it cannot
represent ti
On Mon, Jul 11, 2016 at 08:40:56PM -0400, Anders Kaseorg wrote:
> On 07/11/2016 07:54 PM, Jeff King wrote:
> > Yes, that's somewhat the point of the test.
> >
> > How does it fail for you (what does it look like with "-v")? We may be
> > able to check for an outcome that matches both cases.
>
>
On 2016-07-11 04:25 PM, Philip Oakley wrote:
While there, also break out the other shorthand notations and
add a title for the revision range summary (which also appears
in git-rev-parse, so keep it mixed case).
Signed-off-by: Philip Oakley
---
Documentation/revisions.txt | 23 +++
On Tue, Jul 12, 2016 at 01:25:20PM +0200, Johannes Schindelin wrote:
> [PATCH] Work around test failures due to timestamps being unsigned long
>
> Git's source code refers to timestamps as unsigned longs. On 32-bit
> platforms, as well as on Windows, unsigned long is not large enough to
> capture
On 2016-07-11 04:25 PM, Philip Oakley wrote:
Do not self-define `reachable`, which can lead to misunderstanding.
Instead define `reachability` explictly.
Signed-off-by: Philip Oakley
---
Documentation/revisions.txt | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff -
On Tue, Jul 12, 2016 at 03:31:00PM +0200, Andreas Schwab wrote:
> Johannes Schindelin writes:
>
> > Hi Andreas,
> >
> > On Tue, 12 Jul 2016, Andreas Schwab wrote:
> >
> >> Johannes Schindelin writes:
> >>
> >> >> PRIuMAX isn't compatible with time_t.
> >> >
> >> > That statement is wrong.
> >>
Junio C Hamano wrote:
> Another thing to consider is that the proposed workflow would not
> scale if your team becomes larger. Requiring each and every commit
> on the trunk to be a merge commit, whose second parent (i.e. the tip
> of the feature branch) fast-forwards to the first parent of the
Johannes Schindelin writes:
> Hi Andreas,
>
> On Tue, 12 Jul 2016, Andreas Schwab wrote:
>
>> Johannes Schindelin writes:
>>
>> >> PRIuMAX isn't compatible with time_t.
>> >
>> > That statement is wrong.
>>
>> No, it isn't. PRIuMAX is for uintmax_t, and time_t is not uintmax_t
>> (even if the
Hi Andreas,
On Tue, 12 Jul 2016, Andreas Schwab wrote:
> Johannes Schindelin writes:
>
> >> PRIuMAX isn't compatible with time_t.
> >
> > That statement is wrong.
>
> No, it isn't. PRIuMAX is for uintmax_t, and time_t is not uintmax_t
> (even if they happen to have the same representation).
Hi Junio,
On Mon, 11 Jul 2016, Junio C Hamano wrote:
> [New Topics]
>
> [...]
What about http://thread.gmane.org/gmane.comp.version-control.git/299050?
Ciao,
Dscho
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More major
Johannes Schindelin writes:
>> PRIuMAX isn't compatible with time_t.
>
> That statement is wrong.
No, it isn't. PRIuMAX is for uintmax_t, and time_t is not uintmax_t
(even if they happen to have the same representation).
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint =
Hi Andreas,
On Tue, 12 Jul 2016, Andreas Schwab wrote:
> Johannes Schindelin writes:
>
> > @@ -88,11 +88,11 @@ static int local_tzoffset(unsigned long time)
> > return offset * eastwest;
> > }
> >
> > -void show_date_relative(unsigned long time, int tz,
> > +void show_date_relative(time_
Hi Peff,
On Tue, 12 Jul 2016, Jeff King wrote:
> On Tue, Jul 12, 2016 at 09:30:28AM +0200, Johannes Schindelin wrote:
>
> > FWIW I have this monster patch as a starting point (I plan to work more on
> > this today):
>
> Cool! Thanks for working on this.
Well, I had to. Git for Windows v2.9.1 n
Stefan Beller google.com> writes:
>
> On Thu, May 5, 2016 at 12:20 PM, Loet Avramson forter.com> wrote:
> > It happened on 2.8.1, also reproducible on 2.8.2.
> > Haven't had the time to dive deeper into the code but my guess is that
> > relative_path() returns different results in those 2 cases
Hi Junio,
On Mon, 11 Jul 2016, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> >> No, the point is, refs subsystem needs to know which refs is per-repo,
> >> which is per-worktree. So far the rules are "everything under refs,
> >> except a few known exceptions, is per-repo" and "everyt
> On 10 Jul 2016, at 17:10, Joey Hess wrote:
>
> larsxschnei...@gmail.com wrote:
>> (2) Joey's topic, which is the base for my patch, looks stalled for more than
>> 2 weeks:
>> http://thread.gmane.org/gmane.comp.version-control.git/297994/focus=298006
>> I would be happy to address Junio's comme
Signed-off-by: Dimitriy Ryazantcev
---
po/ru.po | 640 ---
1 file changed, 328 insertions(+), 312 deletions(-)
diff --git a/po/ru.po b/po/ru.po
index 17ed026..6a00dc2 100644
--- a/po/ru.po
+++ b/po/ru.po
@@ -3,15 +3,15 @@
# Translators
Thanks for the quick reply.
On 12/07/16 06:26, Johannes Sixt wrote:
Am 11.07.2016 um 18:54 schrieb Garoe:
I have a repository on github, a clone on my desktop and bare repo on a
private server, in my desktop the remotes looks like this
allg...@github.com:user/repo.git (fetch)
allg...@g
Johannes Schindelin writes:
> @@ -88,11 +88,11 @@ static int local_tzoffset(unsigned long time)
> return offset * eastwest;
> }
>
> -void show_date_relative(unsigned long time, int tz,
> +void show_date_relative(time_t time, int tz,
> const struct timeval *no
On Tue, Jul 12, 2016 at 09:30:28AM +0200, Johannes Schindelin wrote:
> On Mon, 11 Jul 2016, Junio C Hamano wrote:
>
> > Those who care about 32-bit builds need to start building and
> > testing 'next' and 'master' regularly, or similar breakages are
> > bound to continue happening X-<.
>
> Pleas
Hi Junio & Peff,
On Mon, 11 Jul 2016, Junio C Hamano wrote:
> Those who care about 32-bit builds need to start building and
> testing 'next' and 'master' regularly, or similar breakages are
> bound to continue happening X-<.
Please note that "unsigned long" is 32-bit even on 64-bit Windows.
FWI
On Mon, Jul 11, 2016 at 8:27 PM, Duy Nguyen wrote:
> On Mon, Jul 11, 2016 at 7:22 PM, Christian Couder
> wrote:
>> Everytime split index is turned on, it creates a "sharedindex."
>> file in the git directory. This makes sure that old sharedindex
>> files are removed after a new one has been c
88 matches
Mail list logo
