Mike Hommey writes:
> On Fri, Jul 05, 2019 at 01:14:13AM -0400, Jeff King wrote:
>> On Thu, Jul 04, 2019 at 10:13:20PM +0900, Mike Hommey wrote:
[...]
>> I think I explained all of the memory-usage questions in my earlier
>> response, but just for reference: if you have access to it, valgrind's
>
Hi,
Using git version 2.22.0.windows.1
I have a repository with number of .txt files encoded in
little-endian UTF-16 with BOM.
What are the best practice and recommended configuration to
manage such files with Git to avoid unexpected re-encoding to
UTF-8 or others?
Currently, there is .gitattri
On Fri, Jul 05, 2019 at 02:45:16PM +0900, Mike Hommey wrote:
> On Fri, Jul 05, 2019 at 01:09:55AM -0400, Jeff King wrote:
> > On Thu, Jul 04, 2019 at 07:05:30PM +0900, Mike Hommey wrote:
> > > Finally, with 1 thread, the picture changes greatly. The overall process
> > > takes 2.5h:
> > > - 50 seco
Johannes Schindelin writes:
> Team,
>
> I kept talking about this idea of a purely online Git Contributor Summit,
> and it is finally time for action.
>
> The idea: just like the Git Contributor Summits we have on the day before
> GitMerge, but instead of traveling to the same place, we'll use an
Hi Dscho,
On 03/07/2019 14:01, Johannes Schindelin wrote:
Team,
I kept talking about this idea of a purely online Git Contributor Summit,
and it is finally time for action.
The idea: just like the Git Contributor Summits we have on the day before
GitMerge, but instead of traveling to the same
On Thu, Jul 4, 2019 at 6:30 PM Johannes Schindelin
wrote:
>
> Hi Matheus,
>
> On Thu, 4 Jul 2019, Matheus Tavares Bernardino wrote:
> >
> > I wanted to take a look at the failures to see if I could help, [...]
> > Could you point me to the right place, please?
[...]
>
> I usually click on the "Tes
On Fri, Jul 05, 2019 at 01:35:13PM +0200, Mateusz Loskot wrote:
> Hi,
>
> Using git version 2.22.0.windows.1
>
> I have a repository with number of .txt files encoded in
> little-endian UTF-16 with BOM.
>
> What are the best practice and recommended configuration to
> manage such files with Git to
---
builtin/merge.c | 63 +
1 file changed, 32 insertions(+), 31 deletions(-)
diff --git a/builtin/merge.c b/builtin/merge.c
index 6e99aead46..d5745a7888 100644
--- a/builtin/merge.c
+++ b/builtin/merge.c
@@ -64,6 +64,7 @@ static int option_edit = -
On Fri, Jul 5, 2019 at 10:56 AM Edmundo Carmona Antoranz
wrote:
>
> ---
> builtin/merge.c | 63 +
> 1 file changed, 32 insertions(+), 31 deletions(-)
>
This would be a first step in order to achieve the dream of having
rebase/squash in a single ste
Make parse_git_header a "public" function in apply.h, so we can re-use
it in range-diff in a subsequent commit.
Signed-off-by: Thomas Gummerer
---
I considered creating a separate struct for only the metadata here,
and embedding that in 'struct patch'. As struct patch is mostly
metadata fields
The line count in the outer diff's hunk headers of a range diff is not
all that interesting. It merely shows how far along the inner diff
are on both sides. That number is of no use for human readers, and
range-diffs are not meant to be machine readable.
In a subsequent commit we're going to add
Currently range-diff keeps the diff header of the inner diff
intact (apart from stripping lines starting with index). This diff
header is somewhat useful, especially when files get different
names in different ranges.
However there is no real need to keep the whole diff header for that.
The main
Currently the 'gitdiff_*()' functions take 'struct apply_state' as
parameter, even though they only needs the root, linenr and p_value
from that struct.
These functions are in the callchain of 'parse_git_header()', which we
want to make more generally useful in a subsequent commit. To make
that h
In a range-diff it's not always clear which file a certain funcname of
the inner diff belongs to, because the diff header (or section header
as added in a previous commit) is not always visible in the
range-diff.
Add the filename to the inner diffs header, so it's always visible to
users.
This al
It's been quite a while since I sent the RFC [1] (thanks all for the
comments on that), and the series changed shapes quite a bit since the
last round.
Since it's been such a long time, just to remind everyone, the goal of
this series is to make the range-diff output clearer, by showing
informatio
When postprocessing the inner diff in range-diff, we currently replace
the whole hunk header line with just "@@". This matches how 'git
tbdiff' used to handle hunk headers as well.
Most likely this is being done because line numbers in the hunk header
are not relevant without other changes. They
Currently the 'git_header_name()' function takes 'struct apply_state'
as parameter, even though it only needs the p_value from that struct.
This function is in the callchain of 'parse_git_header()', which we
want to make more generally useful in a subsequent commit. To make
that happen we only wa
Currently the 'find_name_*()' functions take 'struct apply_state' as
parameter, even though they only need the 'root' member from that
struct.
These functions are in the callchain of 'parse_git_header()', which we
want to make more generally useful in a subsequent commit. To make
that happen we o
Currently the 'check_header_line()' function takes 'struct
apply_state' as parameter, even though it only needs the linenr from
that struct.
This function is in the callchain of 'parse_git_header()', which we
want to make more generally useful in a subsequent commit. To make
that happen we only w
Add the section headers/hunk headers we introduced in the previous
commits to the outer diff's hunk headers. This makes it easier to
understand which change we are actually looking at. For example an
outer hunk header might now look like:
@@ Documentation/config/interactive.txt
while previ
public-inbox.org links include the whole message ID by default. This
means the message can still be found even if the site goes away, which
is not the case with the marc.info link. Replace the marc.info link
with a more future proof one.
Signed-off-by: Thomas Gummerer
---
apply.c | 2 +-
1 fil
Fix the indentation of the function parameters for a couple of
functions, to match the style in the rest of the file.
Signed-off-by: Thomas Gummerer
---
range-diff.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/range-diff.c b/range-diff.c
index 48b0e1b4ce..9242b8975f 1
Currently range-diff uses the 'strbuf_getline()' function for doing
its line by line processing. In a future patch we want to do parts of
that parsing using the 'parse_git_header()' function, which does
requires reading parts of the input from that function, which doesn't
use strbufs.
Switch rang
Currently the 'skip_tree_prefix()' function takes 'struct apply_state'
as parameter, even though it only needs the p_value from that struct.
This function is in the callchain of 'parse_git_header()', which we
want to make more generally useful in a subsequent commit. To make
that happen we only w
I need your help
Hi Matheus,
On Fri, 5 Jul 2019, Matheus Tavares Bernardino wrote:
> On Thu, Jul 4, 2019 at 6:30 PM Johannes Schindelin
> wrote:
> >
> > Hi Matheus,
> >
> > On Thu, 4 Jul 2019, Matheus Tavares Bernardino wrote:
> > >
> > > I wanted to take a look at the failures to see if I could help, [...]
> >
Hi Thomas,
On Fri, 5 Jul 2019, Thomas Gummerer wrote:
> Make parse_git_header a "public" function in apply.h, so we can re-use
> it in range-diff in a subsequent commit.
This function probably wants a different name when it becomes public, as
it was relatively obvious inside `apply.c` that it wa
Hi Thomas,
On Fri, 5 Jul 2019, Thomas Gummerer wrote:
> Currently the 'gitdiff_*()' functions take 'struct apply_state' as
> parameter, even though they only needs the root, linenr and p_value
> from that struct.
>
> These functions are in the callchain of 'parse_git_header()', which we
> want to
On Fri, 5 Jul 2019 at 18:25, Torsten Bögershausen wrote:
> On Fri, Jul 05, 2019 at 01:35:13PM +0200, Mateusz Loskot wrote:
> >
> > Using git version 2.22.0.windows.1
> >
> > I have a repository with number of .txt files encoded in
> > little-endian UTF-16 with BOM.
> >
> > What are the best practi
Hi Thomas,
On Fri, 5 Jul 2019, Thomas Gummerer wrote:
> Currently range-diff uses the 'strbuf_getline()' function for doing
> its line by line processing. In a future patch we want to do parts of
> that parsing using the 'parse_git_header()' function, which does
If you like my suggestion in pa
Hi Thomas,
On Fri, 5 Jul 2019, Thomas Gummerer wrote:
> When postprocessing the inner diff in range-diff, we currently replace
> the whole hunk header line with just "@@". This matches how 'git
> tbdiff' used to handle hunk headers as well.
Right, that's why I did it this way: `tbdiff` did it.
Hi Thomas,
On Fri, 5 Jul 2019, Thomas Gummerer wrote:
> Currently range-diff keeps the diff header of the inner diff
> intact (apart from stripping lines starting with index). This diff
> header is somewhat useful, especially when files get different
> names in different ranges.
>
> However ther
Hi Thomas,
On Fri, 5 Jul 2019, Thomas Gummerer wrote:
> It's been quite a while since I sent the RFC [1] (thanks all for the
> comments on that), and the series changed shapes quite a bit since the
> last round.
>
> Since it's been such a long time, just to remind everyone, the goal of
> this ser
variable ret used in cmd_merge introduced in d5a35c114ab was already
a local variable used inside a for loop inside the function.
for-local variable is being renamed to ret_try_merge to avoid shadow.
---
builtin/merge.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff
Hi Jakub,
On Fri, 5 Jul 2019, Jakub Narebski wrote:
> Johannes Schindelin writes:
>
> > I kept talking about this idea of a purely online Git Contributor
> > Summit, and it is finally time for action.
> >
> > The idea: just like the Git Contributor Summits we have on the day
> > before GitMerge,
Hi,
I’d like to be able to discover the new parents-to-be SHA-1s during
the hooks that run before a commit*. Essentially I’d like be able to
distinguish the ‘git commit’ case from ‘git commit —amend’. Is there
already a way to do this that I have overlooked? (I’ve read ‘man
githooks’ and searched
36 matches
Mail list logo
