On Friday, September 7, 2018 3:31:55 PM MST Junio C Hamano wrote:
> For example, I noticed that both of the old
> callsites of wt_status_get_state() have free() of a few fiedls in
> the structure, and I kept the code as close to the original, but I
> suspect they should not be freed there in the fu
On 2018-09-23 06:23 PM, Jeff King wrote:
> On Sun, Sep 23, 2018 at 05:56:03PM -0700, Stas Bekman wrote:
>
>>> You probably want "--ext-diff", not "--textconv".
>> [...]
>> Would it be safe to ask the maintainer of the application to include
>> both --textconv and --ext-diff in that 'git diff-tree'
On Sun, Sep 23, 2018 at 05:56:03PM -0700, Stas Bekman wrote:
> > You probably want "--ext-diff", not "--textconv".
> [...]
> Would it be safe to ask the maintainer of the application to include
> both --textconv and --ext-diff in that 'git diff-tree' call? I only need
> the latter, but someone nee
On 2018-09-23 05:43 PM, Jeff King wrote:
> On Sun, Sep 23, 2018 at 03:41:45PM -0700, Stas Bekman wrote:
>
>> $ git config --get diff.jupyternotebook.command
>> git-nbdiffdriver diff
>
> That's an "external diff driver", not a textconv driver.
>
> So here:
>
>> $ GIT_TRACE=1 git diff-tree -p HEA
On Sun, Sep 23, 2018 at 03:41:45PM -0700, Stas Bekman wrote:
> $ git config --get diff.jupyternotebook.command
> git-nbdiffdriver diff
That's an "external diff driver", not a textconv driver.
So here:
> $ GIT_TRACE=1 git diff-tree -p HEAD --textconv test/test.ipynb
>
You probably want "--ext-
Apologies for I don't know how this project manages issues, so I'm not
sure whether it is my responsibility to make sure this issue gets
resolved, or do you have some tracking mechanism where you have it
registered? There is no rush, I'm asking because the discussion about
this issue has suddenly d
Hi,
I'm using a 3rd party application that internally uses 'git diff-tree'
instead of 'git diff'. I'm trying to add filter and it works with 'git
diff' but it gets ignored with 'git diff-tree' despite having --textconv.
I was able to reproduce the problem with the following much more
simplified s
Hello,
On 21.09.2018 08:22, Junio C Hamano wrote:
The tip of 'next' hasn't been rewound yet. The three GSoC "rewrite
in C" topics are still unclassified in this "What's cooking" report,
but I am hoping that we can have them in 'next' sooner rather than
later. I got an impression that Dscho wan
On Sun, Sep 23, 2018 at 1:04 PM Nguyễn Thái Ngọc Duy wrote:
> A new repo extension is added, worktreeConfig. When it is present:
>
> - Repository config reading by default includes $GIT_DIR/config _and_
>$GIT_DIR/config.worktree. "config" file remains shared in multiple
>worktree setup.
>
On September 23, 2018 3:54 PM, John Austin wrote:
> On Sun, Sep 23, 2018 at 10:57 AM Randall S. Becker
> wrote:
> > I would even like to help with your effort and have non-unixy platforms I'd
> like to do this on.
> > Having this separate from git LFS is an even better idea IMO, and I would
> sug
Hi,
I was actually trying to automae the building and installation of Git
source code to reduce my burden. I tried to automate it with the help
of a script that runs daily via cron and a separate worktree used only
by the build script.y run
The script typically fetches new changes for the next br
Regarding integration into LFS, I'd like to build the library in such
a way that it would easy to bundle with LFS (so they could share the
same git hooks), but also make it flexible enough to work for other
workflows.
On Sun, Sep 23, 2018 at 12:53 PM John Austin wrote:
>
> On Sun, Sep 23, 2018 at
On Sun, Sep 23, 2018 at 10:57 AM Randall S. Becker
wrote:
> I would even like to help with your effort and have non-unixy platforms I'd
> like to do this on.
> Having this separate from git LFS is an even better idea IMO, and I would
> suggest implementing this using the same set of build tools
On September 23, 2018 1:29 PM, John Austin wrote:
> I've been putting together a prototype file-locking implementation for a
> system that plays better with git. What are everyone's thoughts on
> something like the following? I'm tentatively labeling this system git-sync or
> sync-server. There are
I've been putting together a prototype file-locking implementation for
a system that plays better with git. What are everyone's thoughts on
something like the following? I'm tentatively labeling this system
git-sync or sync-server. There are two pieces:
1. A centralized repository called the Globa
* Phillip Wood [2018-09-13 11:20]:
Yes in the long term we want to be able to coalesce edited hunks, but I
think it is confusing to call coalesce_overlapping_hunks() at the moment
as it will not coalesce the edited hunks.
I would see it as a first step into that direction.
I think that if yo
A new repo extension is added, worktreeConfig. When it is present:
- Repository config reading by default includes $GIT_DIR/config _and_
$GIT_DIR/config.worktree. "config" file remains shared in multiple
worktree setup.
- The special treatment for core.bare and core.worktree, to stay
e
On Sun, Sep 23, 2018 at 03:53:38PM +, brian m. carlson wrote:
> I suspect you're gaining speed mostly because you're running three
> processes total instead of at least one process (sh) per commit. So I
> don't think there's anything that Git can do to make this faster on our
> end without a
> On Sep 23, 2018, at 4:55 PM, Eric Sunshine wrote:
>
> On Sun, Sep 23, 2018 at 9:05 AM Lars Schneider
> wrote:
>> I recently had to purge files from large Git repos (many files, many
>> commits).
>> The usual recommendation is to use `git filter-branch --index-filter` to
>> purge
>> files
On Sun, Sep 23, 2018 at 03:04:58PM +0200, Lars Schneider wrote:
> Hi,
>
> I recently had to purge files from large Git repos (many files, many commits).
> The usual recommendation is to use `git filter-branch --index-filter` to purge
> files. However, this is *very* slow for large repos (e.g. it t
On Sun, Sep 23, 2018 at 9:05 AM Lars Schneider wrote:
> I recently had to purge files from large Git repos (many files, many commits).
> The usual recommendation is to use `git filter-branch --index-filter` to purge
> files. However, this is *very* slow for large repos (e.g. it takes 45min to
> re
On Sat, Sep 22, 2018 at 03:52:58PM -0400, Jeff King wrote:
> On Sat, Sep 22, 2018 at 06:02:31PM +, brian m. carlson wrote:
>
> > On Fri, Sep 21, 2018 at 02:47:43PM -0400, Taylor Blau wrote:
> > > +expect_haves () {
> > > + printf "%s .have\n" $(git rev-parse $@) >expect
> > > +}
> > > +
> > >
On Sun, Sep 23, 2018 at 10:25 AM Eric Sunshine wrote:
> > @@ -487,6 +487,28 @@ int submodule_uses_worktrees(const char *path)
> > +void strbuf_worktree_ref(const struct worktree *wt,
> > +struct strbuf *sb,
> > +const char *refname)
> > +{
> > +
On Sun, Sep 23, 2018 at 10:06 AM Eric Sunshine wrote:
>
> On Sat, Sep 22, 2018 at 2:05 PM Nguyễn Thái Ngọc Duy
> wrote:
> > [...]
> > The main worktree has to be treated specially because well.. it's
> > special from the beginning. So HEAD from the main worktree is
> > acccessible via the name "
On Sat, Sep 22, 2018 at 1:30 AM Ævar Arnfjörð Bjarmason
wrote:
> Duy's
> https://public-inbox.org/git/20180920161928.ga13...@duynguyen.home/ is
> another recent thing that reminded me of this, i.e. that suggested
> "\\|/-" spinner could be made much neater with non-ASCII.
>
> > 1. Add a trace_ke
Hi,
I recently had to purge files from large Git repos (many files, many commits).
The usual recommendation is to use `git filter-branch --index-filter` to purge
files. However, this is *very* slow for large repos (e.g. it takes 45min to
remove the `builtin` directory from git core). I realized
On Sat, Sep 22, 2018 at 2:05 PM Nguyễn Thái Ngọc Duy wrote:
> fsck is a repo-wide operation and should check all references no
> matter which worktree they are associated to.
>
> Reported-by: Jeff King
> Helped-by: Elijah Newren
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> diff --git a/t/t1450
On Sat, Sep 22, 2018 at 2:05 PM Nguyễn Thái Ngọc Duy wrote:
> Make use of the new ref aliases to pass refs from another worktree
> around and access them from the current ref store instead. This does
> not change any functionality, but when a problem shows up, we would
> report something like
>Fr
On Sat, Sep 22, 2018 at 2:05 PM Nguyễn Thái Ngọc Duy wrote:
> [...]
> The main worktree has to be treated specially because well.. it's
> special from the beginning. So HEAD from the main worktree is
> acccessible via the name "main/HEAD" (we can't use
> "worktrees/main/HEAD" because "main" under
On Sat, Sep 22, 2018 at 2:05 PM Nguyễn Thái Ngọc Duy wrote:
> When multiple worktrees are used, we need rules to determine if
> something belongs to one worktree or all of them. Instead of keeping
> adding rules when new stuff comes, have a generic rule:
> [...]
> Signed-off-by: Nguyễn Thái Ngọc D
30 matches
Mail list logo