Am 04.06.19 um 00:00 schrieb Drew DeVault:
> On Mon Jun 3, 2019 at 11:09 PM Johannes Sixt wrote:
>> I have to wonder how --check works when 'am' applies multiple patches.
>>
>> When the second patch in a patch series depends on that the first patch
>> is fully applied, what does --check do? Without
Am 03.06.19 um 22:45 schrieb Matthew DeVore:
> There is no reason to allow %00 to terminate a string, so do not allow it.
> Otherwise, we end up returning arbitrary content in the string (that which is
> after the %00) which is effectively hidden from callers and can escape sanity
> checks and vali
Am 03.06.19 um 22:45 schrieb Matthew DeVore:
> url_decode_internal could have been tricked into reading past the length
> of the **query buffer if there are fewer than 2 characters after a % (in
> a null-terminated string, % would have to be the last character).
> Prevent this from happening by che
SafariViewService - Jun 4, 1 Reiwa at 11:23 AM.pdf
Description: Adobe PDF document
gabriel...@gmail.com
On Mon, Jun 3, 2019 at 3:39 PM Matthew DeVore wrote:
>
> On Mon, Jun 03, 2019 at 03:07:40PM -0700, Jacob Keller wrote:
> > > +/*
> > > + * Similar to ALLOC_GROW but handles updating of the nr value and
> > > + * zeroing the bytes of the newly-grown array elements.
> > > + *
> > > + * DO NOT USE an
On Tue, Jun 04, 2019 at 11:32:24AM +1000, Ben Humphreys wrote:
> Hi folks,
>
> I’m one of the Bitbucket Server developers and I just wanted to let
> you know of one of our test cases that is now failing on the 2.22.0
> release candidates (tested rc2 and rc3). I’m still looking into it,
> but figur
Commit e198b3a740 changed the behavior of fetch with regards to tags.
Before, null oids where not ignored, now they are, regardless of whether
the refs have been explicitly cleared or not.
e198b3a740 (fetch: replace string-list used as a look-up table with a hashmap)
When using a transport help
The comment makes it seem as if the condition is the other way around.
The exception is when the oid is null, so check for that.
Signed-off-by: Felipe Contreras
---
builtin/fetch.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/builtin/fetch.c b/builtin/fetc
Create a helper function to clear an item. The way items are cleared has
changed, and will change again soon.
No functional changes.
Signed-off-by: Felipe Contreras
---
builtin/fetch.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/builtin/fetch.c b/builtin/fetc
This used to work, but commit e198b3a740 broke it.
e198b3a740 (fetch: replace string-list used as a look-up table with a hashmap)
Probably all remote helpers that use the import method are affected, but
we didn't catch the issue.
Signed-off-by: Felipe Contreras
---
t/t5801-remote-helpers.sh
The code is much simpler this way, specially thanks to:
git fast-export --refspec
Signed-off-by: Felipe Contreras
---
t/t5801-remote-helpers.sh | 8
t/t5801/git-remote-testgit | 11 ---
2 files changed, 8 insertions(+), 11 deletions(-)
diff --git a/t/t5801-remote-helpers.s
I noticed a regression with running tests for git-remote-hg; can't seem to be
able to fetch tags.
Probably all remote helpers that use the import method are affected, if not
all.
The following patches are meant to test for the issue, fix it, and get some
cleanups.
I'm not exactly sure the soluti
Thanks, a bunch Junio!
On 13:23 Mon 03 Jun , Junio C Hamano wrote:
A release candidate Git v2.22.0-rc3 is now available for testing
at the usual places. It is comprised of 718 non-merge commits
since v2.21.0, contributed by 67 people, 17 of which are new faces.
Hopefully, this will be the last
Hi folks,
I’m one of the Bitbucket Server developers and I just wanted to let
you know of one of our test cases that is now failing on the 2.22.0
release candidates (tested rc2 and rc3). I’m still looking into it,
but figure the release is probably imminent so worth reporting sooner
than later.
T
On 2019-06-03 at 20:45:26, Matthew DeVore wrote:
> There is no reason to allow %00 to terminate a string, so do not allow it.
> Otherwise, we end up returning arbitrary content in the string (that which is
> after the %00) which is effectively hidden from callers and can escape sanity
> checks and
Hi,
Git v2.22.0-rc3 has been released, and there are 3 new localizable strings.
Let's start new round of git l10n based on the following commit:
l10n: git.pot: v2.22.0 round 3 (3 new, 2 removed)
Generate po/git.pot from v2.22.0-rc3 for git v2.22.0 l10n round 3.
Signed-off-by
The ForEachMacros list can reasonably be generated grepping
the C source code for macros with 'for_each' in their name.
Taken almost verbatim from the .clang-format file in the Linux kernel.
Signed-off-by: Miguel Ojeda
---
We wrote this for the Linux kernel a while ago, and it has been working
f
On Mon, Jun 03, 2019 at 03:07:40PM -0700, Jacob Keller wrote:
> > +/*
> > + * Similar to ALLOC_GROW but handles updating of the nr value and
> > + * zeroing the bytes of the newly-grown array elements.
> > + *
> > + * DO NOT USE any expression with side-effect for any of the
> > + * arguments.
> >
Jonathan Tan wrote:
> When fetching, the client sends "have" commit IDs indicating that the
> server does not need to send any object referenced by those commits,
> reducing network I/O. When the client is a partial clone, the client
> still sends "have"s in this way, even if it does not have ever
url_decode_internal could have been tricked into reading past the length
of the **query buffer if there are fewer than 2 characters after a % (in
a null-terminated string, % would have to be the last character).
Prevent this from happening by checking len before decoding the %
sequence.
Signed-off
On Mon, Jun 03, 2019 at 08:34:35AM -0400, Jeff King wrote:
> Great. We might want to stop there, but it's possible could reuse even
> more code. I didn't look closely before, but it seems this code is
> decoding a URL. We already have a url_decode() routine in url.c. Could
> it be reused?
Very nic
On Fri, May 31, 2019 at 5:40 PM Matthew DeVore wrote:
>
> Introduce a new macro ALLOC_GROW_BY which automatically zeros the added
> array elements and takes care of updating the nr value. Use the macro in
> code introduced earlier in this patchset.
>
> Signed-off-by: Matthew DeVore
> ---
> cache
On 6/3/2019 4:18 PM, Derrick Stolee via GitGitGadget wrote:
From: Derrick Stolee
Several advanced config settings are highly recommended for clients
using large repositories. Power users learn these one-by-one and
enable them as they see fit. This could be made simpler, to allow
more users t
Am 03.06.19 um 16:25 schrieb Drew DeVault:
> +--check::
> + Instead of applying the patch(es), see if they are
> + applicable to the current working tree and/or the index
> + file and detects errors.
I have to wonder how --check works when 'am' applies multiple patches.
When the secon
On 6/3/2019 4:18 PM, Derrick Stolee via GitGitGadget wrote:
> 1. (Patches 1-3) Introduce a new 'core.size' config setting that takes
> 'large' as a value.
I do want to point out that this "core.size=large" option is probably a
terrible name and could easily be replaced with something better.
On 5/31/2019 8:35 PM, Matthew DeVore wrote:
Allow combining filters such that only objects accepted by all filters
are shown. The motivation for this is to allow getting directory
listings without also fetching blobs. This can be done by combining
blob:none with tree:. There are massive reposi
Fixing two minor issues related to string-handling corner cases in url.c
Thanks,
Matthew DeVore (2):
url: do not read past end of buffer
url: do not allow %00 to represent NULL in URLs
url.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--
2.17.1
There is no reason to allow %00 to terminate a string, so do not allow it.
Otherwise, we end up returning arbitrary content in the string (that which is
after the %00) which is effectively hidden from callers and can escape sanity
checks and validation, and possible be used in tandem with a securit
On 5/31/2019 8:35 PM, Matthew DeVore wrote:
Here is a roll-up with hopefully all comments applied or responded to. Notable
changes since the last one include:
- Added an ALLOC_GROW_BY which is used twice by this patchset to make growing
arrays safer and cleaner
- Cleaned up the URL-en
On 5/31/2019 4:53 PM, Matthew DeVore wrote:
On Thu, May 30, 2019 at 10:01:47AM -0400, Jeff Hostetler wrote:
BTW, I don't think I've seen this mentioned anywhere and I don't
remember if this got into the code or not. But we discussed having
a repo-local config setting to remember the filter-s
So I gave this a try and it seems not to be behaving as expected:
>git push -u
fatal: The current branch {branchName} has no upstream branch.
To push the current branch and set the remote as upstream, use
git push --set-upstream origin {branchName}
I'm using Git for Windows in a Windows CMD
On Mon, Jun 3, 2019 at 12:58 PM Rafael Ascensão wrote:
>
> I missed this RFC series which fixes this and others issues:
> https://public-inbox.org/git/20180405173446.32372-1-new...@gmail.com
>
> Cheers,
> Rafael Ascensão
Yeah, I've had cleaning that patch series up on my TODO list for quite
some
A release candidate Git v2.22.0-rc3 is now available for testing
at the usual places. It is comprised of 718 non-merge commits
since v2.21.0, contributed by 67 people, 17 of which are new faces.
Hopefully, this will be the last -rc during this cycle.
The tarballs are found at:
https://www.k
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.
The third round of release candida
From: Derrick Stolee
After updating a set of remove refs during a 'git fetch', we walk the
commits in the new ref value and not in the old ref value to discover
if the update was a forced update. This results in two things happening
during the command:
1. The line including the ref update has a
From: Derrick Stolee
Several advanced config settings are highly recommended for clients
using large repositories. Power users learn these one-by-one and
enable them as they see fit. This could be made simpler, to allow
more users to have access to these almost-always beneficial features
(and mor
This patch series includes a few new config options we created to speed up
certain critical commands in VFS for Git. On their own, they would
contribute little value as it is hard to discover new config variables.
Instead, I've created this RFC as a goal for probably three sequential patch
series:
From: Derrick Stolee
Signed-off-by: Derrick Stolee
---
builtin/pull.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/builtin/pull.c b/builtin/pull.c
index 9dd32a115b..f1eaf6e6ed 100644
--- a/builtin/pull.c
+++ b/builtin/pull.c
@@ -128,6 +128,7 @@ static char *opt_update_shallow;
st
From: Derrick Stolee
When a repo has many active contributors, the commit history can
grow very quickly and there can be many branches. During 'git fetch',
after downloading the pack from the remote, the default behavior
checks each remote ref for a forced update. This presents a
somewhat quadrat
From: Jeff Hostetler
Signed-off-by: Jeff Hostetler
Signed-off-by: Derrick Stolee
---
advice.c| 2 ++
advice.h| 1 +
wt-status.c | 17 +
3 files changed, 20 insertions(+)
diff --git a/advice.c b/advice.c
index ce5f374ecd..54f8dea30c 100644
--- a/advice.c
+++ b/advice.
From: Jeff Hostetler
Teach porcelain V[12] formats to ignore the status.aheadbehind
config setting. They only respect the --[no-]ahead-behind
command line argument. This is for backwards compatibility
with existing scripts.
Signed-off-by: Jeff Hostetler
Signed-off-by: Derrick Stolee
---
buil
From: Jeff Hostetler
Add "status.aheadbehind" config setting to change the default
behavior of ALL git status formats.
Signed-off-by: Jeff Hostetler
Signed-off-by: Derrick Stolee
---
Documentation/config/status.txt | 5 +
builtin/commit.c| 17 -
t/t6040-tr
From: Derrick Stolee
If a repo is large, then it probably has a very large working
directory. In this case, a typical developer's edits usually impact
many fewer paths than the full path set. The sparse treewalk
algorithm is optimized for this case, speeding up 'git push' calls.
Use pack.useSpar
From: Derrick Stolee
Signed-off-by: Derrick Stolee
---
builtin/fetch.c | 25 -
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/builtin/fetch.c b/builtin/fetch.c
index 571c255218..f8ff98fdaf 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -24,6 +24,8 @
From: Derrick Stolee
If a repo is large, it likely has many paths in its working directory.
This means the index could be compressed using version 4. Set this as
a default when core.size=large.
Signed-off-by: Derrick Stolee
---
Documentation/config/core.txt | 3 +++
Documentation/config/inde
From: Derrick Stolee
When a repo has many active developers, the commit history can grow
very quickly. This can lead remote branches from being very far from
their local copies.
Set stats.aheadBehind=false by default when core.size=large, so all
'git status' calls have an implied '--no-ahead-beh
I missed this RFC series which fixes this and others issues:
https://public-inbox.org/git/20180405173446.32372-1-new...@gmail.com
Cheers,
Rafael Ascensão
On 6/3/2019 2:11 PM, Barret Rhoden wrote:
> Hi -
>
> On 5/30/19 2:24 PM, Derrick Stolee wrote:
>>> 8934ac8c 1190) ent->ignored == next->ignored &&
>>> 8934ac8c 1191) ent->unblamable == next->unblamable) {
>> These lines are part of this diff:
>>
>> --- a/blame.c
>> +++ b/blame.c
>> @@ -479
On Mon, Jun 3, 2019 at 5:47 AM Duy Nguyen wrote:
> On Sun, Jun 2, 2019 at 2:11 PM Eric Sunshine wrote:
> > On Mon, May 27, 2019 at 11:32 AM Ingo Wolf wrote:
> > > I would like to attach an existing dir to git (make it a workdir) and
> > > then update the index with git reset and checkin the diff
Duy Nguyen writes:
> On Mon, Jun 3, 2019 at 4:29 PM Christian Couder
> wrote:
>>
>> On Sun, Jun 2, 2019 at 7:38 PM Drew DeVault wrote:
>> >
>> > This flag would behave similarly to git apply --check, or in other words
>> > would exit with a nonzero status if the patch is not applicable without
Hi -
On 5/30/19 2:24 PM, Derrick Stolee wrote:
8934ac8c 1190) ent->ignored == next->ignored &&
8934ac8c 1191) ent->unblamable == next->unblamable) {
These lines are part of this diff:
--- a/blame.c
+++ b/blame.c
@@ -479,7 +479,9 @@ void blame_coalesce(struct blame_scoreboard *sb)
Johannes Schindelin writes:
> Hi Jian Xin,
>
> On Sun, 2 Jun 2019, Jiang Xin wrote:
>
>> + ed8b4132c8 (remote-curl: mark all error messages for translation,
>> 2019-03-05)
>
> Urgh. Sorry for that, and thank you for cleaning up my mess...
>
> Ciao,
> Dscho
Thanks for a fix and a quick ack. Ve
Barret Rhoden writes:
> Hi Michael -
>
> On 6/1/19 5:09 PM, mich...@platin.gs wrote:
>> From: Michael Platings
>>
>> Thanks to Derrick Stolee for highlighting missing coverage.
>>
>> In the case of "certainties[i] = CERTAINTY_NOT_CALCULATED" this was
>> defeating an optimization that preserved r
Todd Zullinger writes:
> Signed-off-by: Todd Zullinger
> ---
> These are all just minor typos I noticed while reading the
> release notes.
>
> I did find the first entry on the checkout --no-overlay read
> a bit strangely with the multiple "out's" in '... checking
> out paths out ...'.
Ah, of c
Philip Oakley writes:
> From a user perspective, implementation issues shouldn't be part of
> the description unless absolutely essential.
> Most user aren't aware of the implementation so don't grok/understand
> what the fuss is about and ignore it...
Oh, absolutely. But unfortunately I do not
From: Derrick Stolee
If we write a commit-graph file without the split option, then
we write to $OBJDIR/info/commit-graph and start to ignore
the chains in $OBJDIR/info/commit-graphs/.
Unlink the commit-graph-chain file and expire the graph-{hash}.graph
files in $OBJDIR/info/commit-graphs/ durin
From: Derrick Stolee
If we wrote a commit-graph chain, we only modified the tip file in
the chain. It is valuable to verify what we wrote, but not waste
time checking files we did not write.
Add a '--shallow' option to the 'git commit-graph verify' subcommand
and check that it does not read the
From: Derrick Stolee
When searching for a commit in a commit-graph chain of G graphs with N
commits, the search takes O(G log N) time. If we always add a new tip
graph with every write, the linear G term will start to dominate and
slow the lookup process.
To keep lookups fast, but also keep most
From: Derrick Stolee
The split commit-graph feature is now fully implemented, but needs
some more run-time configurability. Allow direct callers to 'git
commit-graph write --split' to specify the values used in the
merge strategy and the expire time.
Update the documentation to specify these val
From: Derrick Stolee
As we merge commit-graph files in a commit-graph chain, we should clean
up the files that are no longer used.
This change introduces an 'expiry_window' value to the context, which is
always zero (for now). We then check the modified time of each
graph-{hash}.graph file in th
From: Derrick Stolee
Extend write_commit_graph() to write a commit-graph chain when given the
COMMIT_GRAPH_SPLIT flag.
This implementation is purposefully simplistic in how it creates a new
chain. The commits not already in the chain are added to a new tip
commit-graph file.
Much of the logic a
From: Derrick Stolee
In an environment like a fork network, it is helpful to have a
commit-graph chain that spans both the base repo and the fork repo. The
fork is usually a small set of data on top of the large repo, but
sometimes the fork is much larger. For example, git-for-windows/git has
alm
From: Derrick Stolee
Add a new "--split" option to the 'git commit-graph write' subcommand. This
option allows the optional behavior of writing a commit-graph chain.
The current behavior will add a tip commit-graph containing any commits that
are not in the existing commit-graph or commit-graph
From: Derrick Stolee
The number of chunks in a commit-graph file can change depending on
whether we need the Extra Edges Chunk. We are going to add more optional
chunks, and it will be helpful to rearrange this logic around the chunk
count before doing so.
Specifically, we need to finalize the n
From: Derrick Stolee
Add a basic description of commit-graph chains. More details about the
feature will be added as we add functionality. This introduction gives a
high-level overview to the goals of the feature and the basic layout of
commit-graph chains.
Signed-off-by: Derrick Stolee
---
Do
From: Derrick Stolee
The helper function commit_compare() actually compares object_id
structs, not commits. A future change to commit-graph.c will need
to sort commit structs, so rename this function in advance.
Signed-off-by: Derrick Stolee
---
commit-graph.c | 4 ++--
1 file changed, 2 inser
This version is now ready for review.
The commit-graph is a valuable performance feature for repos with large
commit histories, but suffers from the same problem as git repack: it
rewrites the entire file every time. This can be slow when there are
millions of commits, especially after we stopped
From: Derrick Stolee
To quickly verify a commit-graph chain is valid on load, we will
read from the new "Base Graphs Chunk" of each file in the chain.
This will prevent accidentally loading incorrect data from manually
editing the commit-graph-chain file or renaming graph-{hash}.graph
files.
The
From: Derrick Stolee
Prepare the logic for reading a chain of commit-graphs.
First, look for a file at $OBJDIR/info/commit-graph. If it exists,
then use that file and stop.
Next, look for the chain file at $OBJDIR/info/commit-graphs/commit-graph-chain.
If this file exists, then load the hash va
From: Derrick Stolee
To prepare for a chain of commit-graph files, augment the
commit_graph struct to point to a base commit_graph. As we load
commits from the graph, we may actually want to read from a base
file according to the graph position.
The "graph position" of a commit is given by conca
On Mon, Jun 03, 2019 at 10:25:23AM -0400, Drew DeVault wrote:
> ---
> Documentation/git-am.txt | 7 ++-
> builtin/am.c | 13 +
> 2 files changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt
> index fc3b993c33..b
Hi Michael -
On 6/1/19 5:09 PM, mich...@platin.gs wrote:
From: Michael Platings
Thanks to Derrick Stolee for highlighting missing coverage.
In the case of "certainties[i] = CERTAINTY_NOT_CALCULATED" this was
defeating an optimization that preserved results of calculations
between line-matchin
Hi Johannes,
Thank you for your kind and detailed explanation. I really appreciate
that. By the way, I just saw it passed all the Azure Pipeline checks.
Please consider merging it into nd/switch-and-restore. Thank you.
Best,
John Lin
Johannes Schindelin 於 2019年6月3日 週一 下午10:17寫道：
>
> Hi John Lin
Teach difftool and mergetool about VS Code.
---
git-mergetool--lib.sh | 2 +-
mergetools/code | 7 +++
2 files changed, 8 insertions(+), 1 deletion(-)
create mode 100644 mergetools/code
diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh
index 204a5acd66..59512ae673 100644
--- a
Hi
On 03/06/2019 14:40, Johannes Schindelin wrote:
Hi Phillip,
On Sun, 2 Jun 2019, Phillip Wood wrote:
On 22/03/2019 14:06, Johannes Schindelin wrote:
On Thu, 13 Sep 2018, Phillip Wood wrote:
On 03/09/2018 20:01, Jochen Sprickerhof wrote:
* Phillip Wood [2018-08-30 14:47]:
We could r
---
Documentation/git-am.txt | 7 ++-
builtin/am.c | 13 +
2 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt
index fc3b993c33..bc01e87d85 100644
--- a/Documentation/git-am.txt
+++ b/Documentation/git-am.t
Hi John Lin,
On Sat, 1 Jun 2019, 林自均 wrote:
> Johannes Schindelin 於 2019年5月29日 週三
> 下午7:51寫道：
> >
> > You could already rebase it on top of
> > https://github.com/gitgitgadget/git/tree/nd/switch-and-restore, say so in
> > your cover letter, and send a new iteration.
>
> Thanks for the suggestion
On Monday, June 3, 2019 9:50 AM, Johannes Schindelin wrote:
> To: Randall S. Becker
> Cc: 'Junio C Hamano' ; git@vger.kernel.org
> Subject: RE: [ANNOUNCE] Git v2.22.0-rc2
>
> Hi Randall,
>
> On Sun, 2 Jun 2019, Randall S. Becker wrote:
>
> > Just a few small nits from RC2 test results on the No
Hi Randall,
On Sun, 2 Jun 2019, Randall S. Becker wrote:
> Just a few small nits from RC2 test results on the NonStop TNS/E
> platform:
>
> 1. t0021 subtest 15 is being flakey. It fails on the first run (make -k
> test) but succeeds when run in isolation. This is new on the NonStop
> TNS/E platfo
Hi Jian Xin,
On Sun, 2 Jun 2019, Jiang Xin wrote:
> + ed8b4132c8 (remote-curl: mark all error messages for translation,
> 2019-03-05)
Urgh. Sorry for that, and thank you for cleaning up my mess...
Ciao,
Dscho
Hi Phillip,
On Sun, 2 Jun 2019, Phillip Wood wrote:
> On 22/03/2019 14:06, Johannes Schindelin wrote:
>
> > On Thu, 13 Sep 2018, Phillip Wood wrote:
> >
> > > On 03/09/2018 20:01, Jochen Sprickerhof wrote:
> > >
> > > > * Phillip Wood [2018-08-30 14:47]:
> > > >
> > > > > We could restore the ol
On Fri, May 31, 2019 at 05:12:31PM -0700, Matthew DeVore wrote:
> On Fri, May 31, 2019 at 05:10:42PM -0400, Jeff King wrote:
> > On Fri, May 31, 2019 at 01:48:21PM -0700, Matthew DeVore wrote:
> >
> > > > > +static int digit_value(int c, struct strbuf *errbuf) {
> > > > > + if (c >= '0' && c
On Mon, Jun 03, 2019 at 08:06:54AM +0200, Ulrich Windl wrote:
> > Imagine you have only v1.0.0 (which is with known issues) but
> > somebody did "cd .git/refs/tags && mv v1.0.0 v1.1.0" in an attempt
> > to fool you. The fact that your 'master' is a bit ahead of the
> > commit that was tagged with
Hi Jeffrey,
On Sun, 2 Jun 2019, Jeffrey Walton wrote:
> On Sun, Jun 2, 2019 at 7:21 AM Michal Suchánek wrote:
> >
> > On Sun, 2 Jun 2019 06:43:07 -0400
> > Jeffrey Walton wrote:
> >
> > > I have a lot of experience with cutting in SHA acceleration. I have
> > > no experience with Git.
> >
> > s
On Sun, Jun 2, 2019 at 2:11 PM Eric Sunshine wrote:
>
> On Mon, May 27, 2019 at 11:32 AM Ingo Wolf wrote:
> > $ ls -a barework
> > ./ ../ test.txt
> > $ git -C bare worktree add --no-checkout ../barework
> > Preparing worktree (new branch 'barework')
> > fatal: '../barework' already exists
> >
On Mon, Jun 3, 2019 at 4:29 PM Christian Couder
wrote:
>
> On Sun, Jun 2, 2019 at 7:38 PM Drew DeVault wrote:
> >
> > This flag would behave similarly to git apply --check, or in other words
> > would exit with a nonzero status if the patch is not applicable without
> > actually applying the patc
On Sun, Jun 2, 2019 at 7:38 PM Drew DeVault wrote:
>
> This flag would behave similarly to git apply --check, or in other words
> would exit with a nonzero status if the patch is not applicable without
> actually applying the patch otherwise.
`git am` uses the same code as `git apply` to apply pa
Hi all
Interesting discussion.
Though it's a pretty distant memory now, this "forgot to commit"
scenario was really frequent for me when I started using git. Then I'd
run commit and forget that it's split (from an outsider's perspective)
into add and then commit. I like the design of git, trees,
88 matches
Mail list logo
