Here's a series warns about git-filter-branch usage and avoids it
ourselves.
Changes since v3
* Incorporated Eric's detailed feedback on the git-filter-branch
manpage, some notes:
* s/filter-branch/git-&/ (and similar for ls-files)
* Multiple sections removed (and existing sectio
filter-branch suffers from a deluge of disguised dangers that disfigure
history rewrites (i.e. deviate from the deliberate changes). Many of
these problems are unobtrusive and can easily go undiscovered until the
new repository is in use. This can result in problems ranging from an
even messier h
fast-export and fast-import can easily handle the simple rewrite that
was being done by filter-branch, and should be significantly faster on
systems with a slow fork. Timings from before and after on two laptops
that I have access to (measured via `time ./t3427-rebase-subtree.sh`,
i.e. including e
Test t6006.71 ("oneline with empty message") was creating two commits
with simple commit messages, and then running filter-branch to rewrite
the commit messages to be empty. This test was written this way because
the --allow-empty-message option to git commit did not exist at the
time. Simplify t
t9902 had a list of three random porcelain commands as a sanity check,
one of which was filter-branch. Since we are recommending people not
use filter-branch, let's update this test to use rebase instead of
filter-branch.
Signed-off-by: Elijah Newren
---
t/t9902-completion.sh | 12 ++--
On Thu, 29 Aug 2019 at 23:06, David Turner wrote:
> -Optionally may output a 'lock ' line indicating a file under
> -GIT_DIR/objects/pack which is keeping a pack until refs can be
> -suitably updated.
> +Optionally may output a 'lock ' line indicating the full path of
> +a file under under GIT_DI
On Thu, 29 Aug 2019 at 22:08, René Scharfe wrote:
>
> Am 29.08.19 um 21:40 schrieb Martin Ågren:
> > On Thu, 29 Aug 2019 at 21:15, René Scharfe wrote:
> >> diff --git a/help.h b/help.h
> >> index b8780fbd0f..7a455beeb7 100644
> >> --- a/help.h
> >> +++ b/help.h
> >> @@ -42,8 +42,8 @@ void list_co
Hi Elijah,
On Thu, Aug 29, 2019 at 05:19:44PM -0700, Elijah Newren wrote:
> On Thu, Aug 29, 2019 at 2:42 PM Pratyush Yadav wrote:
> >
> > On 30/08/19 02:00AM, Pratyush Yadav wrote:
> > > On 29/08/19 04:07PM, Derrick Stolee wrote:
> > > > On 8/29/2019 2:54 PM, Phillip Wood wrote:
> > > > > Hi Stol
On 8/29/19 4:48 PM, Eric Sunshine wrote:
On Thu, Aug 29, 2019 at 7:12 PM Jon Simons wrote:
On 8/29/19 3:45 PM, Eric Sunshine wrote:
On Thu, Aug 29, 2019 at 6:38 PM Jon Simons wrote:
+ test_write_lines /* >sparse-src/all-files &&
Hmm, does this work correctly? I would expect the /* to
On Thu, Aug 29, 2019 at 2:42 PM Pratyush Yadav wrote:
>
> On 30/08/19 02:00AM, Pratyush Yadav wrote:
> > On 29/08/19 04:07PM, Derrick Stolee wrote:
> > > On 8/29/2019 2:54 PM, Phillip Wood wrote:
> > > > Hi Stolee
> > > >
> > > > On 29/08/2019 18:01, Derrick Stolee via GitGitGadget wrote:
> > > >>
Hi Eric,
Thanks for the careful and thoughtful review.
On Thu, Aug 29, 2019 at 11:11 AM Eric Sunshine wrote:
>
> On Wed, Aug 28, 2019 at 8:07 PM Elijah Newren wrote:
> > filter-branch suffers from a deluge of disguised dangers that disfigure
> > history rewrites (i.e. deviate from the deliberat
On Thu, Aug 29, 2019 at 7:12 PM Jon Simons wrote:
> On 8/29/19 3:45 PM, Eric Sunshine wrote:
> > On Thu, Aug 29, 2019 at 6:38 PM Jon Simons wrote:
> >> + test_write_lines /* >sparse-src/all-files &&
> >
> > Hmm, does this work correctly? I would expect the /* to expand to all
> > names at t
Handle a potential NULL 'sparse_oid_value' when attempting to load
sparse filter exclusions by blob, to avoid segfaulting later during
'add_excludes_from_blob_to_list'.
While here, uniquify the errors emitted to distinguish between the
case that a given OID is NULL due to an earlier failure to res
Fix a bug in partial cloning with sparse filters by ensuring to check
for 'have_git_dir' before attempting to resolve the sparse filter OID.
Otherwise the client will trigger:
BUG: refs.c:1851: attempting to get main_ref_store outside of repository
when attempting to git clone with a sparse
Included here are two fixes for partial cloning with sparse filters.
These issues were uncovered in early testing internally at GitHub,
where Taylor and Peff have provided early offlist review feedback.
This third revision includes a fix for a test bug introduced in the
second revision.
Jon Simon
On 8/29/19 3:45 PM, Eric Sunshine wrote:
On Thu, Aug 29, 2019 at 6:38 PM Jon Simons wrote:
Fix a bug in partial cloning with sparse filters by ensuring to check
for 'have_git_dir' before attempting to resolve the sparse filter OID.
[...]
Signed-off-by: Jon Simons
---
diff --git a/t/t5616-parti
On 2019-08-28 at 11:30:53, Johannes Schindelin wrote:
> > diff --git a/convert.c b/convert.c
> > index 94ff837649..0e6e9d2d75 100644
> > --- a/convert.c
> > +++ b/convert.c
> > @@ -8,6 +8,7 @@
> > #include "pkt-line.h"
> > #include "sub-process.h"
> > #include "utf8.h"
> > +#include "ll-merge.h"
Handle a potential NULL 'sparse_oid_value' when attempting to load
sparse filter exclusions by blob, to avoid segfaulting later during
'add_excludes_from_blob_to_list'.
While here, uniquify the errors emitted to distinguish between the
case that a given OID is NULL due to an earlier failure to res
Included here are two fixes for partial cloning with sparse filters.
These issues were uncovered in early testing internally at GitHub,
where Taylor and Peff have provided early offlist review feedback.
In this second revision I've adopted Eric and Peff's additional
feedback on some of the test de
Fix a bug in partial cloning with sparse filters by ensuring to check
for 'have_git_dir' before attempting to resolve the sparse filter OID.
Otherwise the client will trigger:
BUG: refs.c:1851: attempting to get main_ref_store outside of repository
when attempting to git clone with a sparse
On Thu, Aug 29, 2019 at 6:38 PM Jon Simons wrote:
> Fix a bug in partial cloning with sparse filters by ensuring to check
> for 'have_git_dir' before attempting to resolve the sparse filter OID.
> [...]
> Signed-off-by: Jon Simons
> ---
> diff --git a/t/t5616-partial-clone.sh b/t/t5616-partial-cl
On Thu, Aug 29, 2019 at 11:58:18PM +0200, SZEDER Gábor wrote:
> On Thu, Aug 29, 2019 at 10:38:05AM -0400, Jeff King wrote:
> > So any fixes there have to happen on the client side. I am still
> > confused about why the client is writing in this case, per the argument
> > in 014ade7484 (upload-pack:
On Thu, Aug 29, 2019 at 10:38:05AM -0400, Jeff King wrote:
> So any fixes there have to happen on the client side. I am still
> confused about why the client is writing in this case, per the argument
> in 014ade7484 (upload-pack: send ERR packet for non-tip objects,
> 2019-04-13). It would be nice
On 30/08/19 02:00AM, Pratyush Yadav wrote:
> On 29/08/19 04:07PM, Derrick Stolee wrote:
> > On 8/29/2019 2:54 PM, Phillip Wood wrote:
> > > Hi Stolee
> > >
> > > On 29/08/2019 18:01, Derrick Stolee via GitGitGadget wrote:
> > >> +
> > >> + if (argc == 3 && !strcmp(argv[1], "-b")) {
> > >> +
Signed-off-by: David Turner
---
This doesn't address the connectivity-ok problem, which I continue to
worry is a real bug. But it would have saved me a few minutes of
debugging.
Documentation/gitremote-helpers.txt | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Docume
On 29/08/19 04:07PM, Derrick Stolee wrote:
> On 8/29/2019 2:54 PM, Phillip Wood wrote:
> > Hi Stolee
> >
> > On 29/08/2019 18:01, Derrick Stolee via GitGitGadget wrote:
> >> +
> >> + if (argc == 3 && !strcmp(argv[1], "-b")) {
> >> + /*
> >> + * User ran 'git checkout -b ' and
Am 29.08.19 um 21:40 schrieb Martin Ågren:
> On Thu, 29 Aug 2019 at 21:15, René Scharfe wrote:
>> diff --git a/help.h b/help.h
>> index b8780fbd0f..7a455beeb7 100644
>> --- a/help.h
>> +++ b/help.h
>> @@ -42,8 +42,8 @@ void list_commands(unsigned int colopts, struct cmdnames
>> *main_cmds, struct
On 8/29/2019 2:54 PM, Phillip Wood wrote:
> Hi Stolee
>
> On 29/08/2019 18:01, Derrick Stolee via GitGitGadget wrote:
>> +
>> + if (argc == 3 && !strcmp(argv[1], "-b")) {
>> + /*
>> + * User ran 'git checkout -b ' and expects
>
> What if the user ran 'git checkout -b'? Then a
On Thu, 29 Aug 2019 at 21:15, René Scharfe wrote:
>
> Announce that calling help_unknown_ref() exits the program.
>
> Signed-off-by: René Scharfe
> ---
> Patch generated with --function-context for easier review.
>
> help.c | 3 ++-
> help.h | 2 +-
> 2 files changed, 3 insertions(+), 2 deletion
Announce that calling help_unknown_ref() exits the program.
Signed-off-by: René Scharfe
---
Patch generated with --function-context for easier review.
help.c | 3 ++-
help.h | 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/help.c b/help.c
index 5261d83ecf..9ff2be6b18 10064
Am 26.08.19 um 19:20 schrieb Junio C Hamano:
> Stefan Sperling writes:
>
>> The root cause of this bug seems to be that the valid assumption
>> that obj->parsed implies a successfully parsed object is broken by
>> parse_tag_buffer() because this function sets the 'parsed' flag even
>> if errors oc
Hi Stolee
On 29/08/2019 18:01, Derrick Stolee via GitGitGadget wrote:
From: Derrick Stolee
The 'git switch' command was created to separate half of the
behavior of 'git checkout'. It specifically has the mode to
do nothing with the index and working directory if the user
only specifies to crea
On 29/08/19 11:27AM, Paul Mackerras wrote:
> This makes gitk look for http or https URLs in the commit description
> and make the URLs clickable. Clicking on them will invoke an external
> web browser with the URL.
>
> The web browser command is by default "xdg-open" on Linux, "open" on
> MacOS,
Getting the lock for the index, refreshing it and then writing it is a
pattern that happens more than once throughout the codebase. Factor
out the refresh_and_write_cache function from builtin/am.c to
read-cache.c, so it can be re-used in other places in a subsequent
commit.
Note that we return d
When converting stash into C, calls to 'git update-index --refresh'
were replaced with the 'refresh_cache()' function. That is fine as
long as the index is only needed in-core, and not re-read from disk.
However in many cases we do actually need the refreshed index to be
written to disk, for exam
Thanks Martin for the review of the last round!
Changes compared to the previous round:
- always pass COMMIT_LOCK to write_locked_index
- don't write the error message in repo_refresh_and_write_index, but
let the caller handle that. This means that we no longer change any
error messages. Pot
Use the 'refresh_and_write_cache()' convenience function introduced in
the last commit, instead of refreshing and writing the index manually
in merge.c
Signed-off-by: Thomas Gummerer
---
builtin/merge.c | 13 +++--
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/builtin/me
On Wed, Aug 28, 2019 at 8:07 PM Elijah Newren wrote:
> filter-branch suffers from a deluge of disguised dangers that disfigure
> history rewrites (i.e. deviate from the deliberate changes). [...]
> Signed-off-by: Elijah Newren
> ---
> diff --git a/Documentation/git-filter-branch.txt
> b/Document
On 08/28, Martin Ågren wrote:
> On Tue, 27 Aug 2019 at 12:15, Thomas Gummerer wrote:
>
> > struct lock_file lock = LOCK_INIT;
> > const char *head_arg = "HEAD";
> >
> > - hold_locked_index(&lock, LOCK_DIE_ON_ERROR);
> > - refresh_cache(REFRESH_QUIET);
> > - if (w
On 08/28, Martin Ågren wrote:
> On Tue, 27 Aug 2019 at 12:14, Thomas Gummerer wrote:
> >
> > Getting the lock for the index, refreshing it and then writing it is a
> > pattern that happens more than once throughout the codebase. Factor
> > out the refresh_and_write_cache function from builtin/am.
On Thu, Aug 29, 2019 at 1:04 PM Elijah Newren wrote:
>
> Perhaps put all the changes in a specific branch and run:
> git config branch.${personalBranchName}.pushRemote
> Do.Not.Push.Changes.From.This.Branch
> ? (And make sure that push.default is not set to 'matching'.)
I imagine putting all t
I don't know whether this is new behaviour following changes to stash, but
here goes.
Suppose I have files a,b,c,d modified, but only file d is in the index.
After stash push (or save) --include-untracked, stash show only displays
file d. A subsequent pop will restore files a,b,c,d. So functional
On Thu, Aug 29, 2019 at 10:04 AM Derrick Stolee via GitGitGadget
wrote:
>
> From: Derrick Stolee
>
> The 'git switch' command was created to separate half of the
> behavior of 'git checkout'. It specifically has the mode to
> do nothing with the index and working directory if the user
> only spec
On Thu, Aug 29, 2019 at 7:34 AM Matthew McClure
wrote:
>
> Hi,
>
> I'm looking for a way to track history of personal changes in a repository.
> I'd
> like to protect against accidentally pushing the changes to a remote branch. I
> imagine this working a little like `git ignore`, and a little lik
From: Derrick Stolee
The 'git switch' command was created to separate half of the
behavior of 'git checkout'. It specifically has the mode to
do nothing with the index and working directory if the user
only specifies to create a new branch and change HEAD to that
branch. This is also the behavior
This series replaces "[RFC] Revert/delay performance regression in 'git
checkout -b'" [1].
The community response to that series seems to be:
1. 'git switch' is still experimental, so don't warn that users should
adopt it right away.
2. 'git checkout -b ' should do the fast thing,
When doing 'git rebase --autostash ' with a dirty worktree
a 'HEAD is now at ...' message is emitted, which is pointless as it refers to
the old active branch which isn't actually moved.
This commit removes the 'HEAD is now at...' message.
Signed-off-by: Ben Wijen
---
builtin/rebase.c
Consider the following scenario:
git checkout not-the-master
work work work
git rebase --autostash upstream master
Here 'rebase --autostash ' incorrectly moves the
active branch (not-the-master) to master (before the rebase).
The expected behavior: (58794775:/git-rebase.sh:526)
A
Here are my "fix things without making unnecessary changes"
Ben Wijen (2):
builtin/rebase.c: make sure the active branch isn't moved when
autostashing
builtin/rebase.c: Remove obsolete message
builtin/rebase.c| 13 +
t/t3420-rebase-autostash.sh | 12
On Thu, Aug 29, 2019 at 11:00 AM Jeff King wrote:
>
> On Thu, Aug 29, 2019 at 04:31:34PM +0700, Duy Nguyen wrote:
>
> > > If so, how could we get R there? I mean, we could pass it through this
> > > chain, but the chain already passes a "struct config_options", which
> > > carries the "commondir"
Hi Mike
On 29/08/2019 00:25, Mike Hommey wrote:
Hi,
This just happened to me while cherry-pick'ing:
$ git cherry-pick HEAD@{1}
error: could not apply 614fe5e629b84... try
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add ' or 'git rm '
hint: and commit the resul
On Thu, Aug 29, 2019 at 10:27:16AM -0400, Derrick Stolee wrote:
> > I don't think we should need such a call. For one thing, if it were
> > necessary, that would mean we're not writing out the packet at all. But
> > your whole problem is that we're writing the message twice, one of which
> > comes
Thank you for the reply.
On Thu, 29 Aug 2019 at 06:54, Junio C Hamano wrote:
> $ git diff -M branch1 branch2 -- file1 file2
>
> if file1 and file2 have similar-enough contents, may have a better
> chance of what you wanted to ask Git (if I am guessing what it is,
> that is).
The context here
Hi,
I'm looking for a way to track history of personal changes in a repository. I'd
like to protect against accidentally pushing the changes to a remote branch. I
imagine this working a little like `git ignore`, and a little like a separate
branch. It might be like a personal sub-branch that is ig
On 8/29/2019 9:44 AM, Jeff King wrote:
> On Thu, Aug 29, 2019 at 09:12:38AM -0400, Derrick Stolee wrote:
>
>>> +test_expect_success 'partial clone with unresolvable sparse filter fails
>>> cleanly' '
>>> + test_must_fail git clone --no-local --no-checkout
>>> --filter=sparse:oid=master:sparse-
On 8/29/2019 10:13 AM, Jeff King wrote:
> On Thu, Aug 29, 2019 at 08:58:55AM -0400, Derrick Stolee wrote:
>
>> However, I do have a theory: the process exits before flushing the
>> packet line. Adding this line before exit(1) should fix it:
>>
>> packet_writer_flush(writer);
>>
>> I can send
On Thu, Aug 29, 2019 at 08:58:55AM -0400, Derrick Stolee wrote:
> However, I do have a theory: the process exits before flushing the
> packet line. Adding this line before exit(1) should fix it:
>
> packet_writer_flush(writer);
>
> I can send this in a v2, but it would be nice if you could
On Thu, Aug 29, 2019 at 09:34:57AM -0400, Konstantin Ryabitsev wrote:
> As you know, for the Linux kernel we provide both tag signatures and
> detached PGP signatures on tarballs (and the same is true for git). The
> argument I hear frequently is that providing detached tarball signatures is
> red
On Thu, Aug 29, 2019 at 04:31:34PM +0700, Duy Nguyen wrote:
> > If so, how could we get R there? I mean, we could pass it through this
> > chain, but the chain already passes a "struct config_options", which
> > carries the "commondir" and "git_dir" fields. So it would probably be
> > confusing to
On Thu, Aug 29, 2019 at 08:22:49PM +0900, Mike Hommey wrote:
> It is possible to end up in situations where a replace ref points to
> itself. In that case, it would seem better to stop the lookup rather
> than try to follow the link infinitely and fail with "replace depth too
> high".
I don't thi
On Thu, Aug 29, 2019 at 09:12:38AM -0400, Derrick Stolee wrote:
> > +test_expect_success 'partial clone with unresolvable sparse filter fails
> > cleanly' '
> > + test_must_fail git clone --no-local --no-checkout
> > --filter=sparse:oid=master:sparse-filter "file://$(pwd)/sparse-src" sc1
> >
On Wed, Aug 28, 2019 at 07:47:06PM -0400, Jeff King wrote:
On Wed, Aug 28, 2019 at 04:32:24PM -0400, Konstantin Ryabitsev wrote:
If I know that a project uses tag signing, would "git clone" followed by
"git verify-tag" be meaningful without a "git fsck" in-between? I.e. if an
attacker has contr
On 8/28/2019 4:18 PM, Jon Simons wrote:
> Handle a potential NULL 'sparse_oid_value' when attempting to load
> sparse filter exclusions by blob, to avoid segfaulting later during
> 'add_excludes_from_blob_to_list'.
>
> While here, uniquify the errors emitted to distinguish between the
> case that
On 8/28/2019 12:15 PM, SZEDER Gábor wrote:
> On Wed, Aug 28, 2019 at 11:39:44AM -0400, Jeff King wrote:
>> On Wed, Aug 28, 2019 at 10:54:12AM -0400, Jeff King wrote:
>>
Unfortunately, however, while running './t5516-fetch-push.sh -r 1,79
--stress' to try to reproduce a failure caused by t
Hi Junio,
On Wed, 28 Aug 2019, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > Yes, this was me trying to re-send the patch via GMail's web UI because
> > the first time GitGitGadget sent it, it did not get through (only the
> > cover letter did).
>
> As long as that was manual screw-u
It is possible to end up in situations where a replace ref points to
itself. In that case, it would seem better to stop the lookup rather
than try to follow the link infinitely and fail with "replace depth too
high".
Signed-off-by: Mike Hommey
---
replace-object.c | 2 +-
1 file changed, 1 inser
Martin Ågren writes:
> Hiya,
This one was new to me :-)
>
> On Wed, 28 Aug 2019 at 21:15, Sergey Organov wrote:
>> > I was sort of expecting these to be listed in the order "--ff, --no-ff,
>> > --ff-only", and I see Sergey suggested the same ordering. The way your
>> > proposed text reads does
On Thu, Aug 29, 2019 at 11:24 AM Matheus Tavares Bernardino
wrote:
>
> On Tue, Aug 27, 2019 at 8:46 PM Matheus Tavares Bernardino
> wrote:
> >
> > Hi, Duy
> >
> > On Tue, Aug 27, 2019 at 6:26 AM Duy Nguyen wrote:
> > >
> > > On Tue, Aug 27, 2019 at 6:57 AM Matheus Tavares
> > > wrote:
> > > >
>
Elijah Newren writes:
> On Wed, Aug 28, 2019 at 12:15 PM Sergey Organov wrote:
>>
>> Hi,
>>
> [...]
>> Dunno if it helps, but here is what I came up with somewhere in previous
>> discussions:
>>
>> --ff::
>> --no-ff::
>> --ff-only::
>> When the merge resolves as a fast-forward, only upda
69 matches
Mail list logo
