This character class, like many others in this script, matches
horizontal whitespace consisting of spaces and tabs, however, a few
extra, entirely harmless, spaces somehow slipped into the expression.
Removing them is purely a cosmetic fix.
While at it, re-indent three lines with a single TAB
dammit! those threat actors found a way and were on for quite a
whileshould we do something different? These people need a life.
On Mon, Jul 30, 2018 at 9:29 PM, Christine Frankel <
chrisconnorsfr...@gmail.com> wrote:
>
>
On Mon, Jul 30, 2018 at 04:52:40PM +0200, Duy Nguyen wrote:
> On Mon, Jul 30, 2018 at 2:34 PM Han-Wen Nienhuys wrote:
> > + struct kwtable {
> > + const char *keyword;
> > + const char *color;
> > + } keywords[] = {
> > + {"hint",
On Mon, Jul 30, 2018 at 5:19 PM Jonathan Tan wrote:
>
> > So let's go back to the clean API, just requiring a ref_store as an
> > argument.
>
> Here, you say that we want ref_store as an argument...
I do.
>
> > -int for_each_replace_ref(struct repository *r, each_ref_fn fn, void
> > *cb_data)
emit_line_0 has no nested conditions, but puts out all its arguments
(if set) in order. There is still a slight confusion with set
and set_sign, but let's defer that to a later patch.
'first' used be output always no matter if it was 0, but that got lost
at "diff: add an internal option to
For now just change the signature, we'll reason about the actual
change in a follow up patch.
Pass 'set_sign' (which is output before the sign) and 'set' which
controls the color after the first character. Hence, promote any
'set's to 'set_sign' as we want to have color before the sign
for now.
All lines that use emit_line_0 multiple times per line, are combined
into a single call to emit_line_0, making use of the 'set' argument.
Signed-off-by: Stefan Beller
---
diff.c | 26 --
1 file changed, 12 insertions(+), 14 deletions(-)
diff --git a/diff.c b/diff.c
Signed-off-by: Stefan Beller
---
diff.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/diff.c b/diff.c
index fdad7ffdd77..f565a2c0c2b 100644
--- a/diff.c
+++ b/diff.c
@@ -576,11 +576,12 @@ static void check_blank_at_eof(mmfile_t *mf1, mmfile_t
*mf2,
}
The order shall be all colors first, then the content, flags at the end.
The colors are in order.
Signed-off-by: Stefan Beller
---
diff.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/diff.c b/diff.c
index f7251c89cbb..8fd2171d808 100644
--- a/diff.c
+++
Signed-off-by: Stefan Beller
---
t/test-lib-functions.sh | 2 ++
1 file changed, 2 insertions(+)
diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh
index 2b2181dca09..be8244c47b5 100644
--- a/t/test-lib-functions.sh
+++ b/t/test-lib-functions.sh
@@ -42,6 +42,8 @@ test_decode_color
The 'expect'ed outcome has been taken by running the 'range-diff | decode'.
Signed-off-by: Stefan Beller
---
t/t3206-range-diff.sh | 39 +++
1 file changed, 39 insertions(+)
diff --git a/t/t3206-range-diff.sh b/t/t3206-range-diff.sh
index
addressed all of Erics feedback:
* reworded commit messages
* dropped q_to_tab and use cat instead
* use -\EOF isntead of -EOF
Thanks,
Stefan
Stefan Beller (8):
test_decode_color: understand FAINT and ITALIC
t3206: add color test for range-diff --dual-color
diff.c: simplify caller of
> So let's go back to the clean API, just requiring a ref_store as an
> argument.
Here, you say that we want ref_store as an argument...
> -int for_each_replace_ref(struct repository *r, each_ref_fn fn, void *cb_data)
> +int for_each_replace_ref(each_ref_fn fn, void *cb_data)
> {
> - return
On Fri, Jul 27, 2018 at 7:48 PM Ævar Arnfjörð Bjarmason
wrote:
>
> Change various tests that use an idiom of the form:
>
> >expect &&
> test_cmp expect actual
>
> To instead use:
>
> test_must_be_empty actual
Thanks for working on this.
> The test_must_be_empty() wrapper was
I want us to join hands as partners because i have a deal for you.
I want us to join hands as partners because i have a deal for you.
On Mon, Jul 30, 2018 at 1:18 PM Junio C Hamano wrote:
> > I already pushed an update to https://github.com/gitgitgadget/git/pull/1.
>
> Should I take "pushed to ... GGG" to mean "do not merge what you
> have to 'next' yet, as there will be an updated series (not
> incremental) being prepared"?
On Mon, Jul 30, 2018 at 10:50:51AM -0700, Brandon Williams wrote:
> 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
This documents current behavior of the config machinery, when changing
the value of some settings. This patch just serves to provide a baseline
for the follow up that will fix some issues with the current behavior.
Signed-off-by: Stefan Beller
---
t/t1300-config.sh | 86
This is a no-op because the section names are lower-cased already in
get_base_var, this is purely for demonstration that we do not need to
care about case issues in this part of the code.
Signed-off-by: Stefan Beller
---
config.c | 16 +++-
1 file changed, 15 insertions(+), 1
A use reported a submodule issue regarding strange case indentation
issues, but it could be boiled down to the following test case:
$ git init test && cd test
$ git config foo."Bar".key test
$ git config foo."bar".key test
$ tail -n 3 .git/config
[foo "Bar"]
key = test
On Mon, Jul 30, 2018 at 5:50 AM Johannes Schindelin
wrote:
> 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?
right.
> How does the
> patch take care of that? Is it relying on
Commit 989b8c4452 ("fetch-pack: put shallow info in output parameter",
2018-06-28) allows transports to report the refs that they have fetched
in a new out-parameter "fetched_refs". If they do so,
transport_fetch_refs() makes this information available to its caller.
Because
Samuel Lijin writes:
> Following up on Junio's review from last time.
>
> Samuel Lijin (4):
> t7501: add coverage for flags which imply dry runs
> wt-status: rename commitable to committable
> wt-status: teach wt_status_collect about merges in progress
> commit: fix exit code when doing
't5504-fetch-receive-strict.sh', in particular the test 'push with
transfer.fsckobjects' failed on me while building this branch the
other day, caused by 'test_cmp' failing, because 'git push' didn't
print anything to its standard input.
I was unable to reproduce the failure with the usual
Hi,
Le 30/07/2018 à 20:25, SZEDER Gábor a écrit :
>> 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
Hi Ramsay,
Le 30/07/2018 à 00:44, Ramsay Jones a écrit :
>
> Commit 94d4e2fb88 ("rebase -i: move rebase--helper modes to
> rebase--interactive", 2018-07-24) removed the definition of the
> 'cmd_rebase__helper' symbol, but forgot to remove the corresponding
> declaration in the 'builtin.h' header
On Mon, Jul 30, 2018 at 5:26 PM Thomas Gummerer wrote:
> On 07/30, Johannes Schindelin wrote:
> > On Sun, 29 Jul 2018, Thomas Gummerer wrote:
> > > There's one more thing that I noticed here:
> > >
> > > git range-diff --no-patches
> > > fatal: single arg format requires a symmetric range
Han-Wen Nienhuys writes:
> 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
On Mon, Jul 30, 2018 at 4:59 PM Jonathan Nieder wrote:
> Eric Sunshine wrote:
> > The subshell linter would normally fold out the here-doc content, but
> > 'sed' isn't a proper programming language, so the linter can't
> > recognize arbitrary here-doc tags. Instead it has hard-coded knowledge
> >
On 07/30, Johannes Schindelin wrote:
> 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
On 07/30, Johannes Schindelin wrote:
> Hi Thomas,
>
> On Sun, 29 Jul 2018, Thomas Gummerer wrote:
>
> > On 07/21, Johannes Schindelin via GitGitGadget wrote:
> > >
> > > [...]
> > >
> > > +static void find_exact_matches(struct string_list *a, struct string_list
> > > *b)
> > > +{
> > > +
(+cc: some folks interested in git-remote-mediawiki)
Hi,
Eric Sunshine wrote:
> Signed-off-by: Eric Sunshine
> ---
> Jonathan's discovery[1] of a broken &&-chain in a contrib/subtree test
> prompted me to check other tests bundled in contrib/. This was the
> only other problem found. Unlike the
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
Luke Diamand writes:
> Possibly it should say "it takes no parameters" rather than "it takes
> no parameter"; it is confusing that in English, zero takes the plural
> rather than the singular. There's a PhD in linguistics there for
> someone!
I count three instances. Will squash in the
Eric Sunshine wrote:
> On Mon, Jul 30, 2018 at 2:14 PM Jonathan Nieder wrote:
>> (
>> chks_sub=$(cat <> $chks
>> TXT
>> ) &&
>>
>> Ugly quoting, useless use of "cat", etc, aside, I don't think it's
>> missing any &&. Hints?
>
> Yes, it's a false positive.
>
> The
On 7/29/2018 6:33 AM, Nguyễn Thái Ngọc Duy wrote:
This is a micro optimization that probably only shines on repos with
deep directory structure. Instead of allocating and freeing a new
cache_entry in every iteration, we reuse the last one and only update
the parts that are new each iteration.
On 7/29/2018 6:33 AM, Nguyễn Thái Ngọc Duy wrote:
From: Duy Nguyen
In order to merge one or many trees with the index, unpack-trees code
walks multiple trees in parallel with the index and performs n-way
merge. If we find out at start of a directory that all trees are the
same (by comparing
On 07/30, Junio C Hamano wrote:
> 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
On 07/30, Junio C Hamano wrote:
> 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
Signed-off-by: Eric Sunshine
---
Jonathan's discovery[1] of a broken &&-chain in a contrib/subtree test
prompted me to check other tests bundled in contrib/. This was the
only other problem found. Unlike the subtree &&-chain case, this
breakage is at the top-level, thus was caught by the normal
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
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
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
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
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 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
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
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
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
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
> > 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
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
"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
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
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
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
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
---
(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
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,
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 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
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
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
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.
> 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 =
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
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
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
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
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
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
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
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
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:
> 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
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
> 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
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.
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
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
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
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
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.
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
>
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
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
>
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
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:
>
>
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
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
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
>
>
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
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
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
[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
1 - 100 of 144 matches
Mail list logo
