Hi,
I have a shared linux account which is used by multiple developers. But I would
like to have git commit history configured so that I can see who made a change
to common repository (so that author of the commit would be correct person, not
shared user). There are reasons why developers canno
Hi Brian,
On Tue, 24 Jul 2018, brian m. carlson wrote:
> On Tue, Jul 24, 2018 at 02:13:07PM -0700, Junio C Hamano wrote:
> > Yup. I actually was leaning toward saying "all of them are OK in
> > practice, so the person who is actually spear-heading the work gets to
> > choose", but if we picked S
When "git rebase -i --root" creates a new root commit (say, by swapping
in a different commit for the root), it corrupts the commit's "author"
header with trailing garbage:
author A U Thor @1112912773 -0700...@example.com
This is a result of read_author_ident() neglecting to NUL-terminate th
When "git rebase -i --root" creates a new root commit, it corrupts the
"author" header's timezone by repeating the last digit:
author A U Thor @1112912773 -07000
This is due to two bugs.
First, write_author_script() neglects to add the closing quote to the
value of GIT_AUTHOR_DATE when gene
This series fixes bugs causing corruption of the root commit when
"rebase -i --root" is used to swap in a new root commit. In particular,
the "author" header has trailing garbage. Some tools handle the
corruption somewhat gracefully by showing a bogus date, but others barf
on it (gitk, for instance
On 27/07/18 13:37, Johannes Schindelin wrote:
> Hi Phillip, Junio and Akinori,
>
> I just noticed that t3404 is broken without my patches (but with Junio's
> fixup), on Windows, macOS and Linux. (See log at the end.)
>
> On Fri, 27 Jul 2018, Phillip Wood wrote:
>
>> On 26/07/18 13:33, Johannes S
On Sun, Jul 29 2018, Michael wrote:
> On 29/07/2018 22:06, brian m. carlson wrote:
>> On Sun, Jul 29, 2018 at 09:48:43PM +0200, Michael wrote:
>>> On 29/07/2018 21:27, brian m. carlson wrote:
Well, that explains it. I would recommend submitting a patch to
https://github.com/cr-marcste
On Mon, Jul 30, 2018 at 5:30 AM Eric Sunshine wrote:
> This series fixes bugs causing corruption of the root commit when
> "rebase -i --root" is used to swap in a new root commit. In particular,
> the "author" header has trailing garbage. Some tools handle the
> corruption somewhat gracefully by s
ATTENTION BENEFICIARY:
THIS IS TO INFORM YOU THAT A DELIVERY PERSONNEL IS PRESENTLY IN YOUR
HOME COUNTRY WITH YOUR CONSIGNMENT AS SEALED .THE UNITED NATION
MONETARY SETTLEMENT AGENCY ASSIGNED $15.5M IN YOUR FAVOR AS THE
BENEFICIARY,YOUR NAME APPEAR TO BE ONE OF THE BENEFICIARY.YOU ARE
REQUIRED TO
On 30/07/18 10:29, Eric Sunshine wrote:
> This series fixes bugs causing corruption of the root commit when
> "rebase -i --root" is used to swap in a new root commit. In particular,
> the "author" header has trailing garbage. Some tools handle the
> corruption somewhat gracefully by showing a bogus
The highlighting is done on the client-side. Supported keywords are
"error", "warning", "hint" and "success".
The colorization is controlled with the config setting "color.remote".
Signed-off-by: Han-Wen Nienhuys
Change-Id: I090412a1288bc2caef0916447e28c2d0199da47d
---
sideband.c
---
config.h | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/config.h b/config.h
index b95bb7649..d39256eb1 100644
--- a/config.h
+++ b/config.h
@@ -178,11 +178,16 @@ struct config_set {
};
extern void git_configset_init(struct config_set *cs);
-extern int git_con
Hi Eric
On 30/07/18 10:29, Eric Sunshine wrote:
> When "git rebase -i --root" creates a new root commit, it corrupts the
> "author" header's timezone by repeating the last digit:
>
> author A U Thor @1112912773 -07000
>
> This is due to two bugs.
>
> First, write_author_script() neglects to
On Thu, Jul 26, 2018 at 8:50 PM Junio C Hamano wrote:
> Hold your objection a bit. I'll come back to it soon ;-)
>
> It theoretically may make more sense to color on the sender side,
> but that is true only if done at a higher layer that prepares a
> string and calls into the sideband code to
The highlighting is done on the client-side. Supported keywords are
"error", "warning", "hint" and "success".
The colorization is controlled with the config setting "color.remote".
Signed-off-by: Han-Wen Nienhuys
---
sideband.c | 79 +
t/t540
---
config.h | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/config.h b/config.h
index b95bb7649..d39256eb1 100644
--- a/config.h
+++ b/config.h
@@ -178,11 +178,16 @@ struct config_set {
};
extern void git_configset_init(struct config_set *cs);
-extern int git_con
The highlighting is done on the client-side. Supported keywords are
"error", "warning", "hint" and "success".
The colorization is controlled with the config setting "color.remote".
Signed-off-by: Han-Wen Nienhuys
---
sideband.c | 78 +
t/t540
Made tests compile and pass (oops). Remove Change-Id footer.
Han-Wen Nienhuys (1):
Highlight keywords in remote sideband output.
sideband.c | 78 +
t/t5409-colorize-remote-messages.sh | 34 +
2 files changed, 103 insertions(+), 9
Hi,
On Fri, 27 Jul 2018, Junio C Hamano wrote:
> Stefan Beller writes:
>
> [...]
Thanks for the patch!
The only thing that was not clear to me from the patch and from the commit
message was: the first part *is* case insensitive, right? How does the
patch take care of that? Is it relying on `gi
I'm trying to search my git log history for a particular term -
"unobtrusive" - so I run this command:
git log -S unobtrusive --oneline
When I do this, this is displayed and I'm in an interactive less
terminal or something:
pdftotext version 4.00
Copyright 1996-2017 Glyph & Cog, LLC
Usage: p
Can you get back to me for a viable business we can do together ?
> I have a shared linux account which is used by multiple developers.
> But I would like to have git commit history configured so that I can
> see who made a change to common repository (so that author of the
> commit would be correct person, not shared user). There are reasons
> why developers can
Hi Junio,
On Fri, 27 Jul 2018, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
> > Count me in the "this is useful" camp, but also I did look at the latest
> > submission this time around, but had nothing to say, so I didn't say
> > anything :)
>
> Please make it a habit to do say so
Hi Jonathan,
On Mon, 23 Jul 2018, Jonathan Nieder wrote:
> Johannes Schindelin via GitGitGadget wrote:
>
> > From: Johannes Schindelin
> >
> > VS Code is a lightweight but powerful source code editor which runs on
> > your desktop and is available for Windows, macOS and Linux. Among other
> > l
Derrick Stolee writes:
> This commit is not intended to be merged, but is only to create a test
> environment to see what works with the commit-graph feature and what
> does not. The tests that fail are primarily related to corrupting the
> object store to remove a commit from visibility and test
Hi Junio,
On Mon, 23 Jul 2018, Junio C Hamano wrote:
> "Johannes Schindelin via GitGitGadget"
> writes:
>
> > diff --git a/contrib/vscode/init.sh b/contrib/vscode/init.sh
> > new file mode 100755
> > index 0..3cc93243f
> > --- /dev/null
> > +++ b/contrib/vscode/init.sh
> > @@ -0,0 +1,16
Hi Jonathan,
On Mon, 23 Jul 2018, Jonathan Nieder wrote:
> Johannes Schindelin via GitGitGadget wrote:
>
> > From: Johannes Schindelin
> >
> > Sadly, we do not get all of the definitions via ALL_CFLAGS. Some defines
> > are passed to GCC *only* when compiling specific files, such as git.o.
> >
Ævar Arnfjörð Bjarmason writes:
>>> When fsck. is set to an unknown value it'll cause "fsck" to
>>> die, but the same is not rue of the "fetch" and "receive"
>>> variants. Document this and test for it.
> ...
> We could change it. This is just something I ran into and figured it
> should be teste
Hi Hannes,
On Wed, 25 Jul 2018, Johannes Sixt wrote:
> Am 23.07.2018 um 15:52 schrieb Johannes Schindelin via GitGitGadget:
> > From: Johannes Schindelin
> >
> > This adds a couple settings for the .c/.h files so that it is easier to
> > conform to Git's conventions while editing the source cod
On Mon, Jul 30, 2018 at 2:34 PM Han-Wen Nienhuys wrote:
> + struct kwtable {
> + const char *keyword;
> + const char *color;
> + } keywords[] = {
> + {"hint", GIT_COLOR_YELLOW},
> + {"warning", GIT_COLOR_BOLD_YELLOW},
> +
Ævar Arnfjörð Bjarmason writes:
> And, as an aside, the reason we can't easily make it better ourselves is
> because the build process for git.git doesn't have a facility to run
> code to detect this type of stuff (the configure script is always
> optional). So we can't just run this test ourselv
On Fri, Jul 27, 2018 at 02:37:17PM +, Ævar Arnfjörð Bjarmason wrote:
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index 7ff453c53b..8dace49daa 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -1467,6 +1467,16 @@ fetch.fsckObjects::
> ch
On Mon, Jul 30 2018, Duy Nguyen wrote:
> On Fri, Jul 27, 2018 at 02:37:17PM +, Ævar Arnfjörð Bjarmason wrote:
>> diff --git a/Documentation/config.txt b/Documentation/config.txt
>> index 7ff453c53b..8dace49daa 100644
>> --- a/Documentation/config.txt
>> +++ b/Documentation/config.txt
>> @@ -
Paths that only differ in case work fine in a case-sensitive
filesystems, but if those repos are cloned in a case-insensitive one,
you'll get problems. The first thing to notice is "git status" will
never be clean with no indication what's exactly is "dirty".
This patch helps the situation a bit b
Phillip Wood writes:
>> Moreover, patch 2/2 of this series provides a more thorough fix overall
>> than Akinori, so it may make sense to replace his patch with this
>> series, though perhaps keep the test his patch adds to augment the
>> strict test of the "author" header added by this series.
>
On Mon, Jul 30, 2018 at 01:49:46PM +0100, Jeremy Morton wrote:
> I'm trying to search my git log history for a particular term -
> "unobtrusive" - so I run this command:
>
> git log -S unobtrusive --oneline
>
> When I do this, this is displayed and I'm in an interactive less terminal or
> someth
Johannes Schindelin writes:
> FWIW I picked up your Asciidoc-underline fix, and I also fixed a typo in a
> commit message (you may want to pick that up, too, unless you want me to
> send a full new iteration, I don't care either way):
Meaning that if you send a full new iteration it would match
From: Johannes Schindelin
VS Code is a lightweight but powerful source code editor which runs on
your desktop and is available for Windows, macOS and Linux. Among other
languages, it has support for C/C++ via an extension, which offers to
not only build and debug the code, but also Intellisense,
From: Johannes Schindelin
While it is technically possible, it is confusing. Not only the user,
but also VS Code's intellisense.
Signed-off-by: Johannes Schindelin
---
cache.h | 24 +---
1 file changed, 13 insertions(+), 11 deletions(-)
diff --git a/cache.h b/cache.h
index
From: Johannes Schindelin
The C/C++ settings are special, as they are the only generated VS Code
configurations that *will* change over the course of Git's development,
e.g. when a new constant is defined.
Therefore, let's only update the C/C++ settings, also to prevent user
modifications from b
From: Johannes Schindelin
Sadly, we do not get all of the definitions via ALL_CFLAGS. Some defines
are passed to GCC *only* when compiling specific files, such as git.o.
Let's just hard-code them into the script for the time being.
Signed-off-by: Johannes Schindelin
---
contrib/vscode/init.sh
[Visual Studio Code](https://code.visualstudio.com/) (nickname "VS Code") is a
light-weight, cross-platform, Open Source development environment, with an
increasingly powerful extension to support C/C++ development. In particular the
intellisense support as well as all the other niceties develop
From: Johannes Schindelin
When configuring VS Code as core.editor (via `code --wait`), we really
want to adhere to the Git conventions of wrapping commit messages.
Signed-off-by: Johannes Schindelin
---
contrib/vscode/init.sh | 4
1 file changed, 4 insertions(+)
diff --git a/contrib/vsco
From: Johannes Schindelin
By default, the cSpell extension ignores all files under .git/. That
includes, unfortunately, COMMIT_EDITMSG, i.e. commit messages. However,
spell checking is *quite* useful when writing commit messages... And
since the user hardly ever opens any file inside .git (apart
From: Johannes Schindelin
The quite useful cSpell extension allows VS Code to have "squiggly"
lines under spelling mistakes. By default, this would add too much
clutter, though, because so much of Git's source code uses words that
would trigger cSpell.
Let's add a few words to make the spell che
From: Johannes Schindelin
This adds a couple settings for the .c/.h files so that it is easier to
conform to Git's conventions while editing the source code.
Signed-off-by: Johannes Schindelin
---
contrib/vscode/init.sh | 8
1 file changed, 8 insertions(+)
diff --git a/contrib/vscode
From: Johannes Schindelin
This helps VS Code's intellisense to figure out that we want to include
windows.h, and that we want to define the minimum target Windows version
as Windows Vista/2008R2.
Signed-off-by: Johannes Schindelin
---
config.mak.uname | 2 +-
1 file changed, 1 insertion(+), 1
Hi Eric,
On Mon, 30 Jul 2018, Eric Sunshine wrote:
> When "git rebase -i --root" creates a new root commit (say, by swapping
> in a different commit for the root), it corrupts the commit's "author"
> header with trailing garbage:
>
> author A U Thor @1112912773 -0700...@example.com
>
> Thi
Hi Eric,
On Mon, 30 Jul 2018, Eric Sunshine wrote:
> On Mon, Jul 30, 2018 at 5:30 AM Eric Sunshine wrote:
> > This series fixes bugs causing corruption of the root commit when
> > "rebase -i --root" is used to swap in a new root commit. In particular,
> > the "author" header has trailing garbage
Hi Phillip,
On Mon, 30 Jul 2018, Phillip Wood wrote:
> On 30/07/18 10:29, Eric Sunshine wrote:
> > This series fixes bugs causing corruption of the root commit when
> > "rebase -i --root" is used to swap in a new root commit. In particular,
> > the "author" header has trailing garbage. Some tools
Am 30.07.2018 um 14:49 schrieb Jeremy Morton:
> I'm trying to search my git log history for a particular term - "unobtrusive"
> - so I run this command:
>
> git log -S unobtrusive --oneline
>
> When I do this, this is displayed and I'm in an interactive less terminal or
> something:
>
> pdftot
I discovered it was an issue with the version of Git for Windows I was
using. Upgraded to the latest version and it works now.
--
Best regards,
Jeremy Morton (Jez)
On 30/07/2018 16:37, Jeff King wrote:
On Mon, Jul 30, 2018 at 01:49:46PM +0100, Jeremy Morton wrote:
I'm trying to search my gi
Hi Thomas,
On Sat, 28 Jul 2018, Thomas Gummerer wrote:
> On 07/21, Johannes Schindelin via GitGitGadget wrote:
> > From: Johannes Schindelin
> >
> > The problem solved by the code introduced in this commit goes like this:
> > given two sets of items, and a cost matrix which says how much it
> >
One of the things I notice when watching a normal git user face a
merge conflicts is the output is very verbose (especially when there
are multiple conflicts) and it's hard to spot the important parts to
start resolving conflicts unless you know what to look for.
This is the start to hopefully hel
Hi Thomas,
On Sun, 29 Jul 2018, Thomas Gummerer wrote:
> On 07/21, Johannes Schindelin via GitGitGadget wrote:
> > From: Johannes Schindelin
> >
> > At this stage, `git range-diff` can determine corresponding commits
> > of two related commit ranges. This makes use of the recently introduced
>
Hi Thomas & Eric,
On Sun, 29 Jul 2018, Thomas Gummerer wrote:
> On 07/29, Eric Sunshine wrote:
> > On Sun, Jul 29, 2018 at 3:04 PM Thomas Gummerer
> > wrote:
> > > On 07/21, Johannes Schindelin via GitGitGadget wrote:
> > > > Just like tbdiff, we now show the diff between matching patches. This
This commit imitates the strategy that was used to convert the
difftool to a builtin. We start by renaming the shell script
`git-rebase.sh` to `git-legacy-rebase.sh` and introduce a
`builtin/rebase.c` that simply executes the shell script version,
unless the config setting `rebase.useBuiltin` is se
As a GSoC project, I have been working on the builtin rebase.
The motivation behind the rewrite of rebase i.e. from shell script to C
are for following reasons:
1. Writing shell scripts and getting it to production is much faster
than doing the equivalent in C but lacks in performance and ex
The functions present in `git-legacy-rebase.sh` are used by the rebase
backends as they are implemented as shell script functions in the
`git-rebase--` files.
To make the `builtin/rebase.c` work, we have to provide support via
a Unix shell script snippet that uses these functions and so, we
want t
This patch gives life to the skeleton added in the previous patches:
With this change, we can perform a elementary rebase (without any
options).
It can be tested thusly by:
git -c rebase.usebuiltin=true rebase HEAD~2
The rebase backends (i.e. the shell script functions defined in
`git-rebase--`)
Hi Eric,
On Sun, 22 Jul 2018, Eric Sunshine wrote:
> On Sat, Jul 21, 2018 at 6:05 PM Thomas Rast via GitGitGadget
> wrote:
> > These are essentially lifted from https://github.com/trast/tbdiff, with
> > light touch-ups to account for the command now being names `git
>
> s/names/named/
Thanks.
> I wonder though if all those changes to the testsuite shouldn't be
> merged.
I think Stolee doesn't want this to be merged after rereading
subject and the commit message.
Thanks,
Stefan
On Mon, Jul 30, 2018 at 9:00 AM Nguyễn Thái Ngọc Duy wrote:
>
> One of the things I notice when watching a normal git user face a
> merge conflicts is the output is very verbose (especially when there
> are multiple conflicts) and it's hard to spot the important parts to
> start resolving conflict
Thomas Gummerer writes:
> Currently rerere can't handle nested conflicts and will error out when
> it encounters such conflicts. Do that by recursively calling the
> 'handle_conflict' function to normalize the conflict.
>
> The conflict ID calculation here deserves some explanation:
>
> As we ar
On 07/29, brian m. carlson wrote:
> The object ID parsing machinery is aware of "@" as a synonym for "HEAD"
> and this is documented accordingly in gitrevisions(7). The push
> documentation describes the source portion of a refspec as "any
> arbitrary 'SHA-1 expression'"; however, "@" is not allow
Thomas Gummerer writes:
> +Different conflict styles and branch names are normalized by stripping
> +the labels from the conflict markers, and removing extraneous
> +information from the `diff3` conflict style. Branches that are merged
s/extraneous information/commmon ancestor version/ perhaps,
Thomas Gummerer writes:
> Currently when a user doesn't resolve a conflict in a file, but
> commits the file with the conflict markers, and later the file ends up
> in a state in which rerere can't handle it, subsequent rerere
> operations that are interested in that path, such as 'rerere clear'
Thomas Gummerer writes:
> Thomas Gummerer (11):
> rerere: unify error messages when read_cache fails
> rerere: lowercase error messages
> rerere: wrap paths in output in sq
> rerere: mark strings for translation
> rerere: add documentation for conflict normalization
> rerere: fix cras
Thomas Gummerer writes:
> Factor out the handle_conflict function, which handles a single
> conflict in a path. This is in preparation for a subsequent commit,
> where this function will be re-used. No functional changes intended.
>
> Signed-off-by: Thomas Gummerer
> ---
> rerere.c | 87 +
Thomas Gummerer writes:
> We currently return the exact number of conflict hunks a certain path
> has from the 'handle_paths' function. However all of its callers only
> care whether there are conflicts or not or if there is an error.
> Return only that information, and document that only that i
Thomas Gummerer writes:
> Currently we write the conflict to disk directly in the handle_path
> function. To make it re-usable for nested conflicts, instead of
> writing the conflict out directly, store it in a strbuf and let the
> caller write it out.
>
> This does mean some slight increase in
On 07/29, Jeff King wrote:
> I've noticed for the past couple of weeks that some of my fetches don't
> seem to actually update refs, but a follow-up fetch will. I finally
> managed to catch it in the act and track it down. It bisects to your
> 989b8c4452 (fetch-pack: put shallow info in output para
Chen Bin writes:
> The `p4-pre-submit` hook is executed before git-p4 submits code.
> If the hook exits with non-zero value, submit process not start.
>
> Signed-off-by: Chen Bin
> ---
Luke, does this version look good to you?
I still think the addition to self.description is a bit too much bu
On 7/29/2018 6:33 AM, Nguyễn Thái Ngọc Duy wrote:
This series speeds up unpack_trees() a bit by using cache-tree.
unpack-trees could bit split in three big parts
- the actual tree unpacking and running n-way merging
- update worktree, which could be expensive depending on how much I/O
is i
Hi,
Eric Sunshine wrote:
> The --chain-lint option detects broken &&-chains by forcing the test to
> exit early (as the very first step) with a sentinel value. If that
> sentinel is the test's overall exit code, then the &&-chain is intact;
> if not, then the chain is broken. Unfortunately, this
> diff --git a/sequencer.c b/sequencer.c
> index 1c035ceec7..d257903db0 100644
> --- a/sequencer.c
> +++ b/sequencer.c
> +int write_basic_state(struct replay_opts *opts, const char *head_name,
> + const char *onto, const char *orig_head)
> +{
> + const char *quiet = getenv("G
On Sat, Jul 28, 2018 at 2:16 PM Masaya Suzuki wrote:
> Signed-off-by: Masaya Suzuki
The email addresses mismatch?
> Unlike ref advertisement, client capabilities and the first want are
> separated by SP, not NUL, in the implementation. Fix the documentation
> to align with the implementation.
Junio C Hamano writes:
> Ævar Arnfjörð Bjarmason writes:
>
>> And, as an aside, the reason we can't easily make it better ourselves is
>> because the build process for git.git doesn't have a facility to run
>> code to detect this type of stuff (the configure script is always
>> optional). So we
The change was definitely made for performance. Removing the if
statements, conditioned upon endianess was an approx 10% improvement, which
was very important to getting this library accepted into git.
Thanks,
Dan
On Mon, Jul 30, 2018 at 11:32 AM, Junio C Hamano wrote:
> Junio C Hamano write
On Mon, Jul 30, 2018 at 8:20 AM Phillip Wood wrote:
> On 30/07/18 10:29, Eric Sunshine wrote:
> > When "git rebase -i --root" creates a new root commit, it corrupts the
> > "author" header's timezone by repeating the last digit:
> > [...]
> > Signed-off-by: Eric Sunshine
> > ---
> > diff --git a/
On Mon, Jul 30, 2018 at 8:26 AM Han-Wen Nienhuys wrote:
> ---
> config.h | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
Missing sign-off.
On 30 July 2018 at 20:07, Junio C Hamano wrote:
> Chen Bin writes:
>
>> The `p4-pre-submit` hook is executed before git-p4 submits code.
>> If the hook exits with non-zero value, submit process not start.
>>
>> Signed-off-by: Chen Bin
>> ---
>
> Luke, does this version look good to you?
>
Yes,
(resetting cc list)
Jonathan Nieder wrote:
> This is causing contrib/subtree tests to fail for me: running "make -C
> contrib/subtree test" produces
[...]
> error: bug in the test script: broken &&-chain or run-away HERE-DOC:
[...]
> Ugly quoting, useless use of "cat", etc, aside, I don't th
Detected using t/chainlint.
Signed-off-by: Jonathan Nieder
---
contrib/subtree/t/t7900-subtree.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/subtree/t/t7900-subtree.sh
b/contrib/subtree/t/t7900-subtree.sh
index d05c613c97..e6a28f2c3e 100755
--- a/contrib/subtree
This mixture of quoting, pipes, and here-docs to produce expected
results in shell variables is difficult to follow. Simplify by using
simpler constructs that write output to files instead.
Noticed because without this patch, t/chainlint is not able to
understand the script in order to validate t
On Mon, Jul 30, 2018 at 8:14 AM Phillip Wood wrote:
> On 30/07/18 10:29, Eric Sunshine wrote:
> > It was only after I diagnosed and fixed these bugs that I thought to
> > check 'pu' and discovered that Akinori MUSHA already made a stab[1] at
> > fixing one of the three bugs which this series fixes
On Mon, Jul 30, 2018 at 11:47 AM Johannes Schindelin
wrote:
> On Mon, 30 Jul 2018, Eric Sunshine wrote:
> > Unfortunately, after sending this series, I see that there is
> > additional corruption that needs to be addressed. In particular, the
> > "author" header time is incorrectly prefixed with "
"Derrick Stolee via GitGitGadget" writes:
> From: Derrick Stolee
>
> Make close_commit_graph() work for arbitrary repositories.
The first line (above) does not match the rest of the commit message.
> Call close_commit_graph() when about to start a rev-list walk that
> includes shallow commits.
From: Derrick Stolee
This is the smallest possible change that makes prepare_replace_objects
work properly with arbitrary repositories. By supplying the repository
as the cb_data, we do not need to modify any code in the ref iterator
logic. We will likely want to do a full replacement of the ref
> > I anticipate that we need to have a lot of back pointers to the repository
> > in question, hence I think we should have the repository pointer promoted
> > to not just a back pointer.
>
> I will probably need more time to study that commit and maybe the mail
> archive for the history of this s
On Fri, Jul 27, 2018 at 11:28 PM Eric Sunshine wrote:
>
> On Fri, Jul 27, 2018 at 11:05 PM Stefan Beller wrote:
> > The 'expect'ed outcome is taken by running the 'range-diff |decode';
> > it is not meant as guidance, rather as a documentation of the current
> > situation.
>
> I'm not really sure
This effectively reverts commit 0d296c57ae (refs: allow for_each_replace_ref
to handle arbitrary repositories, 2018-04-11) and 60ce76d3581 (refs: add
repository argument to for_each_replace_ref, 2018-04-11).
The repository argument is not any special from the ref-store's point
of life. If you nee
Eric Sunshine writes:
> On Mon, Jul 30, 2018 at 8:26 AM Han-Wen Nienhuys wrote:
>> ---
>> config.h | 10 --
>> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> Missing sign-off.
Besides, the patch is corrupt in that it miscounts both preimage and
postimage lines and claims it applie
Hello all. Johannes, thanks for adding me to this discussion.
So, as one of the coauthors of the SHA-1 collision detection code, I just
wanted to chime in and say I'm glad to see the move to a longer hash function.
Though, as a cryptographer, I have a few thoughts on the matter that I thought
On 7/29/2018 6:33 AM, Nguyễn Thái Ngọc Duy wrote:
We're going to optimize unpack_trees() a bit in the following
patches. Let's add some tracing to measure how long it takes before
and after. This is the baseline ("git checkout -" on gcc.git, 80k
files on worktree)
0.018239226 s: read cac
Johannes Schindelin writes:
> On Sun, 22 Jul 2018, Eric Sunshine wrote:
>
>> On Sat, Jul 21, 2018 at 6:05 PM Thomas Rast via GitGitGadget
>> wrote:
>> > These are essentially lifted from https://github.com/trast/tbdiff, with
>> > light touch-ups to account for the command now being names `git
>>
On 07/30, Junio C Hamano wrote:
> Thomas Gummerer writes:
>
> > Currently rerere can't handle nested conflicts and will error out when
> > it encounters such conflicts. Do that by recursively calling the
> > 'handle_conflict' function to normalize the conflict.
> >
> > The conflict ID calculatio
On 07/30, Junio C Hamano wrote:
> Thomas Gummerer writes:
>
> > +Different conflict styles and branch names are normalized by stripping
> > +the labels from the conflict markers, and removing extraneous
> > +information from the `diff3` conflict style. Branches that are merged
>
> s/extraneous i
On Mon, Jul 30, 2018 at 2:14 PM Jonathan Nieder wrote:
> Eric Sunshine wrote:
> > Address this shortcoming by feeding the body of the test to a
> > lightweight "linter" which can peer inside subshells and identify broken
> > &&-chains by pure textual inspection.
>
> This is causing contrib/subtree
On 07/30, Junio C Hamano wrote:
> Thomas Gummerer writes:
>
> > Currently when a user doesn't resolve a conflict in a file, but
> > commits the file with the conflict markers, and later the file ends up
> > in a state in which rerere can't handle it, subsequent rerere
> > operations that are inte
1 - 100 of 144 matches
Mail list logo
