Re: What's cooking in git.git (Apr 2018, #01; Mon, 9)
On Wed, Apr 11 2018, Jakub Narebski wrote:
> Junio C Hamano writes:
>
>
>> * ab/nuke-emacs-contrib (2018-03-13) 1 commit
>> (merged to 'next' on 2018-03-15 at 13eb4e2d8b)
>> + git{,-blame}.el: remove old bitrotting Emacs code
>>
>> The scripts in contrib/emacs/ have outlived their usefulness and
>> have been removed.
>>
>> Will kick back to 'pu'.
>>
>> There were some noises about better migration strategy that lets
>> git.el to nudge users to magit or something when used. Is it
>> something we want to pursue further?
>
> Maybe simply delete all files, leaving only README pointing to Magit?
I've just submitted a v4 which should address the issue raised in v3,
which was that we don't want to delete the files, but instead have a
boilerplate *.el file that errors out, thus helping e.g. users of git-el
in Debian to migrate.
See
https://public-inbox.org/git/20180411204206.28498-1-ava...@gmail.com/
Re: What's cooking in git.git (Apr 2018, #01; Mon, 9)
Junio C Hamano writes:
> * ab/nuke-emacs-contrib (2018-03-13) 1 commit
> (merged to 'next' on 2018-03-15 at 13eb4e2d8b)
> + git{,-blame}.el: remove old bitrotting Emacs code
>
> The scripts in contrib/emacs/ have outlived their usefulness and
> have been removed.
>
> Will kick back to 'pu'.
>
> There were some noises about better migration strategy that lets
> git.el to nudge users to magit or something when used. Is it
> something we want to pursue further?
Maybe simply delete all files, leaving only README pointing to Magit?
Best,
--
Jakub Narębski
Re: What's cooking in git.git (Apr 2018, #01; Mon, 9)
On 09/04/18 11:21, Junio C Hamano wrote: * pw/add-p-select (2018-03-16) 3 commits (merged to 'next' on 2018-03-30 at eae69f5ded) + add -p: optimize line selection for short hunks + add -p: allow line selection to be inverted + add -p: select individual hunk lines "git add -p" interactive interface learned to let users choose individual added/removed lines to be used in the operation, instead of accepting or rejecting a whole hunk. Will kick back to 'pu'. There was a brief discussion about this topic not doing as good a job as it is advertised as---has it been resolved, or do we want to run with what we have for now? cf. <878ta8vyqe@evledraar.gmail.com> I've been working on a re-roll that has handles modified lines better. I'm not sure what to do about the cases where it cannot pair up the insertions and deletions automatically - I think I'll clean up what I've got, post it and see where the discussion goes from there. Thanks Phillip
Re: git-gui branches, was Re: What's cooking in git.git (Apr 2018, #01; Mon, 9)
Hi Junio, On Wed, 11 Apr 2018, Junio C Hamano wrote: > Johannes Schindelin writes: > > > On Mon, 9 Apr 2018, Junio C Hamano wrote: > > > >> * bb/git-gui-ssh-key-files (2018-03-02) 2 commits > >> * bp/git-gui-bind-kp-enter (2018-03-02) 2 commits > >> * cb/git-gui-ttk-style (2018-03-05) 2 commits > > > > What is your plan with those? I thought they were on track for v2.17.0, > > but now I see that they are not even in `next`... > > There is no plan. I was waiting for somebody to raise noises, get > irritated by lack of active subsystem maintainer(s), which would > eventually lead us to find a replacement for Pat. > > I can play patch-monkey for git-gui part but I do not want to be the > one who judges if proposed changes to it are good ones. Have they > been reviewed by git-gui competent people? I would call myself "reasonably literate" in Tcl/Tk, not "git-gui competent", but for what it is worth: I remember having reviewed those patches and AFAIR they looked fine enough for inclusion. Certainly the ssk-key-files one. Ciao, Dscho
Re: git-gui branches, was Re: What's cooking in git.git (Apr 2018, #01; Mon, 9)
On Tue, Apr 10, 2018 at 2:38 PM, Junio C Hamano wrote: > Johannes Schindelin writes: > >> On Mon, 9 Apr 2018, Junio C Hamano wrote: >> >>> * bb/git-gui-ssh-key-files (2018-03-02) 2 commits This looks good to me. Please merge down. >>> * bp/git-gui-bind-kp-enter (2018-03-02) 2 commits I tested and reviewed this, and it also looks good to me. >>> * cb/git-gui-ttk-style (2018-03-05) 2 commits While this looks like it doesn't break anything, and it does what it intends to do, I am not sure if that is the best approach. I'll look into Tcl and experiment to have an opinion. >> What is your plan with those? I thought they were on track for v2.17.0, >> but now I see that they are not even in `next`... > > There is no plan. I was waiting for somebody to raise noises, get > irritated by lack of active subsystem maintainer(s), which would > eventually lead us to find a replacement for Pat. Ok, glad that Johannes made noise then. I am a heavy user of git-gui myself so I would feel sad if it wasn't properly maintained. (On the other hand it "just works" -- for me) I'd be ok to step up as a maintainer there in the long run if nobody else steps up. > I can play patch-monkey for git-gui part but I do not want to be the > one who judges if proposed changes to it are good ones. Have they > been reviewed by git-gui competent people? For now please apply (or monkey-patch as you put it) the first and second. Thanks, Stefan
Re: What's cooking in git.git (Apr 2018, #01; Mon, 9)
Derrick Stolee writes: > On 4/9/2018 6:08 PM, Junio C Hamano wrote: >> >> I guess we'd want a final cleaned-up round after all ;-) Thanks. > > v8 sent [1]. Thanks. Thanks, will take a look and queue.
Re: git-gui branches, was Re: What's cooking in git.git (Apr 2018, #01; Mon, 9)
Johannes Schindelin writes: > On Mon, 9 Apr 2018, Junio C Hamano wrote: > >> * bb/git-gui-ssh-key-files (2018-03-02) 2 commits >> * bp/git-gui-bind-kp-enter (2018-03-02) 2 commits >> * cb/git-gui-ttk-style (2018-03-05) 2 commits > > What is your plan with those? I thought they were on track for v2.17.0, > but now I see that they are not even in `next`... There is no plan. I was waiting for somebody to raise noises, get irritated by lack of active subsystem maintainer(s), which would eventually lead us to find a replacement for Pat. I can play patch-monkey for git-gui part but I do not want to be the one who judges if proposed changes to it are good ones. Have they been reviewed by git-gui competent people?
git-gui branches, was Re: What's cooking in git.git (Apr 2018, #01; Mon, 9)
Hi Junio, On Mon, 9 Apr 2018, Junio C Hamano wrote: > * bb/git-gui-ssh-key-files (2018-03-02) 2 commits > - Merge branch 'bb/ssh-key-files' of git-gui into bb/git-gui-ssh-key-files > - git-gui: search for all current SSH key types > > "git gui" learned that "~/.ssh/id_ecdsa.pub" and > "~/.ssh/id_ed25519.pub" are also possible SSH key files. > > > * bp/git-gui-bind-kp-enter (2018-03-02) 2 commits > - Merge branch 'bp/bind-kp-enter' of git-gui into bp/git-gui-bind-kp-enter > - git-gui: bind CTRL/CMD+numpad ENTER to do_commit > > "git gui" performs commit upon CTRL/CMD+ENTER but the > CTRL/CMD+KP_ENTER (i.e. enter key on the numpad) did not have the > same key binding. It now does. > > > * cb/git-gui-ttk-style (2018-03-05) 2 commits > - Merge branch 'cb/ttk-style' of git-gui into cb/git-gui-ttk-style > - git-gui: workaround ttk:style theme use > > "git gui" has been taught to work with old versions of tk (like > 8.5.7) that do not support "ttk::style theme use" as a way to query > the current theme. What is your plan with those? I thought they were on track for v2.17.0, but now I see that they are not even in `next`... Ciao, Dscho
Re: What's cooking in git.git (Apr 2018, #01; Mon, 9)
On 10/04/18 21:22, Ramsay Jones wrote: > > > On 10/04/18 20:35, Derrick Stolee wrote: >> On 4/10/2018 3:21 PM, Ramsay Jones wrote: >>> >>> On 10/04/18 13:57, Derrick Stolee wrote: On 4/9/2018 6:08 PM, Junio C Hamano wrote: > I guess we'd want a final cleaned-up round after all ;-) Thanks. v8 sent [1]. Thanks. >>> I just tried to 'git am' this series and I could not get it >>> to apply cleanly to current 'master', 'next' or 'pu'. I fixed >>> up a few patches, but just got bored ... ;-) >>> >> >> In my cover letter, I did mention that my patch started here (using >> 'format-patch --base'): >> >> base-commit: 468165c1d8a442994a825f3684528361727cd8c0 >> >> >> This corresponds to v2.17.0. > > Yep, I forgot to mention that I had already tried that too: > > $ git log --oneline -1 > 468165c1d (HEAD -> master-graph, tag: v2.17.0, origin/maint, maint, build) > Git 2.17 > $ git am patches/* > Applying: csum-file: rename hashclose() to finalize_hashfile() > Applying: csum-file: refactor finalize_hashfile() method > Applying: commit-graph: add format document > Applying: graph: add commit graph design document > Applying: commit-graph: create git-commit-graph builtin > Applying: commit-graph: create git-commit-graph builtin > error: patch failed: .gitignore:34 > error: .gitignore: patch does not apply > error: Documentation/git-commit-graph.txt: already exists in index > error: patch failed: Makefile:952 > error: Makefile: patch does not apply > error: patch failed: builtin.h:149 > error: builtin.h: patch does not apply > error: builtin/commit-graph.c: already exists in index > error: patch failed: command-list.txt:34 > error: command-list.txt: patch does not apply > error: patch failed: contrib/completion/git-completion.bash:878 > error: contrib/completion/git-completion.bash: patch does not apply > error: patch failed: git.c:388 > error: git.c: patch does not apply > Patch failed at 0006 commit-graph: create git-commit-graph builtin > Use 'git am --show-current-patch' to see the failed patch > When you have resolved this problem, run "git am --continue". > If you prefer to skip this patch, run "git am --skip" instead. > To restore the original branch and stop patching, run "git am --abort". > $ Ah, OK, it helps if you don't have an edited patch backup file in the patches directory! patches now apply cleanly. sparse is also now clean - thanks! ATB, Ramsay Jones
Re: What's cooking in git.git (Apr 2018, #01; Mon, 9)
On 10/04/18 20:35, Derrick Stolee wrote: > On 4/10/2018 3:21 PM, Ramsay Jones wrote: >> >> On 10/04/18 13:57, Derrick Stolee wrote: >>> On 4/9/2018 6:08 PM, Junio C Hamano wrote: I guess we'd want a final cleaned-up round after all ;-) Thanks. >>> v8 sent [1]. Thanks. >> I just tried to 'git am' this series and I could not get it >> to apply cleanly to current 'master', 'next' or 'pu'. I fixed >> up a few patches, but just got bored ... ;-) >> > > In my cover letter, I did mention that my patch started here (using > 'format-patch --base'): > > base-commit: 468165c1d8a442994a825f3684528361727cd8c0 > > > This corresponds to v2.17.0. Yep, I forgot to mention that I had already tried that too: $ git log --oneline -1 468165c1d (HEAD -> master-graph, tag: v2.17.0, origin/maint, maint, build) Git 2.17 $ git am patches/* Applying: csum-file: rename hashclose() to finalize_hashfile() Applying: csum-file: refactor finalize_hashfile() method Applying: commit-graph: add format document Applying: graph: add commit graph design document Applying: commit-graph: create git-commit-graph builtin Applying: commit-graph: create git-commit-graph builtin error: patch failed: .gitignore:34 error: .gitignore: patch does not apply error: Documentation/git-commit-graph.txt: already exists in index error: patch failed: Makefile:952 error: Makefile: patch does not apply error: patch failed: builtin.h:149 error: builtin.h: patch does not apply error: builtin/commit-graph.c: already exists in index error: patch failed: command-list.txt:34 error: command-list.txt: patch does not apply error: patch failed: contrib/completion/git-completion.bash:878 error: contrib/completion/git-completion.bash: patch does not apply error: patch failed: git.c:388 error: git.c: patch does not apply Patch failed at 0006 commit-graph: create git-commit-graph builtin Use 'git am --show-current-patch' to see the failed patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". $ ATB, Ramsay Jones
Re: What's cooking in git.git (Apr 2018, #01; Mon, 9)
On 4/10/2018 3:21 PM, Ramsay Jones wrote: On 10/04/18 13:57, Derrick Stolee wrote: On 4/9/2018 6:08 PM, Junio C Hamano wrote: I guess we'd want a final cleaned-up round after all ;-) Thanks. v8 sent [1]. Thanks. I just tried to 'git am' this series and I could not get it to apply cleanly to current 'master', 'next' or 'pu'. I fixed up a few patches, but just got bored ... ;-) In my cover letter, I did mention that my patch started here (using 'format-patch --base'): base-commit: 468165c1d8a442994a825f3684528361727cd8c0 This corresponds to v2.17.0. Thanks, -Stolee
Re: What's cooking in git.git (Apr 2018, #01; Mon, 9)
On 10/04/18 13:57, Derrick Stolee wrote: > On 4/9/2018 6:08 PM, Junio C Hamano wrote: >> >> I guess we'd want a final cleaned-up round after all ;-) Thanks. > > v8 sent [1]. Thanks. I just tried to 'git am' this series and I could not get it to apply cleanly to current 'master', 'next' or 'pu'. I fixed up a few patches, but just got bored ... ;-) ATB, Ramsay Jones
Re: What's cooking in git.git (Apr 2018, #01; Mon, 9)
On Tue, Apr 10, 2018 at 5:57 AM, Derrick Stolee wrote: > On 4/9/2018 6:08 PM, Junio C Hamano wrote: >> >> >> I guess we'd want a final cleaned-up round after all ;-) Thanks. > > > v8 sent [1]. Thanks. > > -Stolee I gave the series another read and think it is ready. Stefan
Re: What's cooking in git.git (Apr 2018, #01; Mon, 9)
On 4/9/2018 6:08 PM, Junio C Hamano wrote: I guess we'd want a final cleaned-up round after all ;-) Thanks. v8 sent [1]. Thanks. -Stolee [1] https://public-inbox.org/git/20180410125608.39443-1-dsto...@microsoft.com/T/#u
Re: What's cooking in git.git (Apr 2018, #01; Mon, 9)
Hi Junio, On Mon, 9 Apr 2018, Junio C Hamano wrote: > * js/t5404-path-fix (2018-04-09) 1 commit > - t5404: relax overzealous test > > Test fix. Please note that it is not a "path fix". It is a fix for when the test is looking for an error message, and may currently mistake something else for an error. Specifically, it changes the regex looking for the error message. Hence my (IMO superior) branch name fix-t5404-error Ciao, Dscho
Re: What's cooking in git.git (Apr 2018, #01; Mon, 9)
Ramsay Jones writes: > On 09/04/18 14:37, Derrick Stolee wrote: >> On 4/9/2018 6:21 AM, Junio C Hamano wrote: >>> * ds/commit-graph (2018-04-02) 16 commits >>> - commit-graph: implement "--additive" option >>> ... >>> Ready??? >>> It seems that this topic is getting there. >> >> I think this patch is ready to go, barring ... > > Also, it seems that the 'static' keyword has been dropped from the > declaration of 'commit_graph' (commit-graph.c #183) again: > > $ diff nsp-out psp-out > 18a19 > > SP chdir-notify.c > 23a25,26 > > SP commit-graph.c > > commit-graph.c:183:21: warning: symbol 'commit_graph' was not declared. > Should it be static? > 66a70 > > SP json-writer.c > 209a214,215 > > SP builtin/commit-graph.c > > builtin/commit-graph.c:34:38: warning: Using plain integer as NULL pointer > 299d304 > < fast-import.c:303:40: warning: Using plain integer as NULL pointer > 312a318 > > SP t/helper/test-json-writer.c > 315a322 > > SP t/helper/test-print-larger-than-ssize.c > $ I guess we'd want a final cleaned-up round after all ;-) Thanks.
Re: What's cooking in git.git (Apr 2018, #01; Mon, 9)
Hi, On Mon, 9 Apr 2018, Johannes Schindelin wrote: > On Mon, 9 Apr 2018, Junio C Hamano wrote: > > > * js/rebase-recreate-merge (2018-02-23) 12 commits (merged to 'next' > > on 2018-03-15 at 3d1671756f) + rebase -i: introduce > > --recreate-merges=[no-]rebase-cousins + pull: accept --rebase=recreate > > to recreate the branch topology + sequencer: handle post-rewrite for > > merge commands + sequencer: make refs generated by the `label` command > > worktree-local + rebase: introduce the --recreate-merges option + > > rebase-helper --make-script: introduce a flag to recreate merges + > > sequencer: fast-forward merge commits, if possible + sequencer: > > introduce the `merge` command + sequencer: introduce new commands to > > reset the revision + git-rebase--interactive: clarify arguments + > > sequencer: make rearrange_squash() a bit more obvious + sequencer: > > avoid using errno clobbered by rollback_lock_file() > > > > "git rebase" learned "--recreate-merges" to transplant the whole > > topology of commit graph elsewhere. > > > > This serise has been reverted out of 'next', expecting that it will > > be replaced by a reroll on top of a couple of topics by Phillip. > > [.,..] I will send out a new iteration of the patch series (the > --rebase-merges one, formerly known as --recreate-merges) soon > (hopefully still today). I encountered one more scenario I need to handle: when all the patches in a topic branch were already applied upstream, I typically want to skip merging a now-empty branch. Since upstream might have changed the patches subtly (so that --cherry-pick does not skip them), the user may have had to `git rebase --skip` the unmodified version of the now-upstream patches. Therefore, we cannot test at todo list generation time whether a merge can be skipped because it would merge an ancestor of its first parent. I plan on introducing a flag similar to "rebase-cousins" for this: probably "skip-empty-merges", defaulting to skipping them (because why would you want to merge something that is already part of the HEAD's commit history?). However, I won't be able to finish this today. Thanks for your patience, Dscho
Re: What's cooking in git.git (Apr 2018, #01; Mon, 9)
Hi Junio, On Mon, 9 Apr 2018, Junio C Hamano wrote: > * js/rebase-recreate-merge (2018-02-23) 12 commits > (merged to 'next' on 2018-03-15 at 3d1671756f) > + rebase -i: introduce --recreate-merges=[no-]rebase-cousins > + pull: accept --rebase=recreate to recreate the branch topology > + sequencer: handle post-rewrite for merge commands > + sequencer: make refs generated by the `label` command worktree-local > + rebase: introduce the --recreate-merges option > + rebase-helper --make-script: introduce a flag to recreate merges > + sequencer: fast-forward merge commits, if possible > + sequencer: introduce the `merge` command > + sequencer: introduce new commands to reset the revision > + git-rebase--interactive: clarify arguments > + sequencer: make rearrange_squash() a bit more obvious > + sequencer: avoid using errno clobbered by rollback_lock_file() > > "git rebase" learned "--recreate-merges" to transplant the whole > topology of commit graph elsewhere. > > This serise has been reverted out of 'next', expecting that it will > be replaced by a reroll on top of a couple of topics by Phillip. Sorry, it took a little longer. I did decide in the end that --rebase-merges is a better name for the option. And I worked on the add-on patch series, too, mainly to prove that we can switch to a better strategy than blindly re-create recursive merges from scratch. That part is not really done to my satisfaction, though: while I already demonstrated that Sergey's approach causes way too many merge conflicts to be useful in practice, I now have a reproducer to show that even Phillip's strategy *can* cause awful (and avoidable) merge conflicts. For anybody who is interested in the specifics, I'd like to point you to the `sequencer-shears` branch thicket in https://github.com/dscho/git (it is a moving target, but you should find the commit called "t3430: add some realistic tests for --rebase-merges" that demonstrates the issues. Be that as it may, I will send out a new iteration of the patch series (the --rebase-merges one, formerly known as --recreate-merges) soon (hopefully still today). Ciao, Dscho
Re: What's cooking in git.git (Apr 2018, #01; Mon, 9)
On Mon, Apr 9, 2018 at 8:31 AM, Duy Nguyen wrote: > On Mon, Apr 9, 2018 at 12:21 PM, Junio C Hamano wrote: >> * sb/packfiles-in-repository (2018-03-26) 12 commits >> (merged to 'next' on 2018-03-30 at caa68db14d) >> + packfile: keep prepare_packed_git() private >> + packfile: allow find_pack_entry to handle arbitrary repositories >> + packfile: add repository argument to find_pack_entry >> + packfile: allow reprepare_packed_git to handle arbitrary repositories >> + packfile: allow prepare_packed_git to handle arbitrary repositories >> + packfile: allow prepare_packed_git_one to handle arbitrary repositories >> + packfile: add repository argument to reprepare_packed_git >> + packfile: add repository argument to prepare_packed_git >> + packfile: add repository argument to prepare_packed_git_one >> + packfile: allow install_packed_git to handle arbitrary repositories >> + packfile: allow rearrange_packed_git to handle arbitrary repositories >> + packfile: allow prepare_packed_git_mru to handle arbitrary repositories >> (this branch uses nd/remove-ignore-env-field and sb/object-store; is >> tangled with sb/submodule-move-nested.) >> >> Refactoring of the internal global data structure continues. >> >> Is this ready for 'master' by now? > > I think so. Things start to look much nicer. I think so, too. I am working on top of that series now for the third part, assuming this is good to go. https://public-inbox.org/git/20180406232136.253950-1-sbel...@google.com/ Thanks, Stefan
Re: What's cooking in git.git (Apr 2018, #01; Mon, 9)
On 09/04/18 14:37, Derrick Stolee wrote:
> On 4/9/2018 6:21 AM, Junio C Hamano wrote:
>> * ds/commit-graph (2018-04-02) 16 commits
>> - commit-graph: implement "--additive" option
>> - commit-graph: build graph from starting commits
>> - commit-graph: read only from specific pack-indexes
>> - commit: integrate commit graph with commit parsing
>> - commit-graph: close under reachability
>> - commit-graph: add core.commitGraph setting
>> - commit-graph: implement git commit-graph read
>> - commit-graph: implement git-commit-graph write
>> - commit-graph: implement write_commit_graph()
>> - commit-graph: create git-commit-graph builtin
>> - graph: add commit graph design document
>> - commit-graph: add format document
>> - csum-file: refactor finalize_hashfile() method
>> - csum-file: rename hashclose() to finalize_hashfile()
>> - Merge branch 'jk/cached-commit-buffer' into HEAD
>> - Merge branch 'jt/binsearch-with-fanout' into HEAD
>> (this branch is used by ds/lazy-load-trees.)
>>
>> Precompute and store information necessary for ancestry traversal
>> in a separate file to optimize graph walking.
>>
>> Ready???
>> It seems that this topic is getting there.
>
> I think this patch is ready to go, barring the edit of "--additive" to
> "--append" in the final commit message and squashing following diff into
> "commit-graph: implement git commit-graph read":
>
> @@ -31,7 +31,7 @@ static struct opts_commit_graph {
>
> static int graph_read(int argc, const char **argv)
> {
> - struct commit_graph *graph = 0;
> + struct commit_graph *graph = NULL;
> char *graph_name;
>
> static struct option builtin_commit_graph_read_options[] = {
>
Also, it seems that the 'static' keyword has been dropped from the
declaration of 'commit_graph' (commit-graph.c #183) again:
$ diff nsp-out psp-out
18a19
> SP chdir-notify.c
23a25,26
> SP commit-graph.c
> commit-graph.c:183:21: warning: symbol 'commit_graph' was not declared.
Should it be static?
66a70
> SP json-writer.c
209a214,215
> SP builtin/commit-graph.c
> builtin/commit-graph.c:34:38: warning: Using plain integer as NULL pointer
299d304
< fast-import.c:303:40: warning: Using plain integer as NULL pointer
312a318
> SP t/helper/test-json-writer.c
315a322
> SP t/helper/test-print-larger-than-ssize.c
$
ATB,
Ramsay Jones
Re: What's cooking in git.git (Apr 2018, #01; Mon, 9)
On Mon, Apr 9, 2018 at 12:21 PM, Junio C Hamano wrote: > * sb/packfiles-in-repository (2018-03-26) 12 commits > (merged to 'next' on 2018-03-30 at caa68db14d) > + packfile: keep prepare_packed_git() private > + packfile: allow find_pack_entry to handle arbitrary repositories > + packfile: add repository argument to find_pack_entry > + packfile: allow reprepare_packed_git to handle arbitrary repositories > + packfile: allow prepare_packed_git to handle arbitrary repositories > + packfile: allow prepare_packed_git_one to handle arbitrary repositories > + packfile: add repository argument to reprepare_packed_git > + packfile: add repository argument to prepare_packed_git > + packfile: add repository argument to prepare_packed_git_one > + packfile: allow install_packed_git to handle arbitrary repositories > + packfile: allow rearrange_packed_git to handle arbitrary repositories > + packfile: allow prepare_packed_git_mru to handle arbitrary repositories > (this branch uses nd/remove-ignore-env-field and sb/object-store; is tangled > with sb/submodule-move-nested.) > > Refactoring of the internal global data structure continues. > > Is this ready for 'master' by now? I think so. Things start to look much nicer. -- Duy
Re: What's cooking in git.git (Apr 2018, #01; Mon, 9)
On 4/9/2018 6:21 AM, Junio C Hamano wrote:
* ds/commit-graph (2018-04-02) 16 commits
- commit-graph: implement "--additive" option
- commit-graph: build graph from starting commits
- commit-graph: read only from specific pack-indexes
- commit: integrate commit graph with commit parsing
- commit-graph: close under reachability
- commit-graph: add core.commitGraph setting
- commit-graph: implement git commit-graph read
- commit-graph: implement git-commit-graph write
- commit-graph: implement write_commit_graph()
- commit-graph: create git-commit-graph builtin
- graph: add commit graph design document
- commit-graph: add format document
- csum-file: refactor finalize_hashfile() method
- csum-file: rename hashclose() to finalize_hashfile()
- Merge branch 'jk/cached-commit-buffer' into HEAD
- Merge branch 'jt/binsearch-with-fanout' into HEAD
(this branch is used by ds/lazy-load-trees.)
Precompute and store information necessary for ancestry traversal
in a separate file to optimize graph walking.
Ready???
It seems that this topic is getting there.
I think this patch is ready to go, barring the edit of "--additive" to
"--append" in the final commit message and squashing following diff into
"commit-graph: implement git commit-graph read":
@@ -31,7 +31,7 @@ static struct opts_commit_graph {
static int graph_read(int argc, const char **argv)
{
- struct commit_graph *graph = 0;
+ struct commit_graph *graph = NULL;
char *graph_name;
static struct option builtin_commit_graph_read_options[] = {
If you prefer that I re-roll with those changes, I can send a v8.
I'm currently working on new series based on this feature:
* [1] Lazy-load trees when reading commit-graph (ds/lazy-load-trees)
* [2] Compute and consume generation numbers
* Move commit-graph.c globals to the_repository
* Implement 'fsck' functionality for the commit-graph file
* Integrate 'commit-graph write' into 'gc --auto'
I would also like to open the feature to other contributors, especially
for others who can contribute performance improvements using generation
numbers. We had a very valuable discussion on the list [2], and I look
forward to more collaborations like that.
Thanks,
-Stolee
[1]
https://public-inbox.org/git/20180403120057.173849-1-dsto...@microsoft.com/T/#u
[2]
https://public-inbox.org/git/20180403165143.80661-1-dsto...@microsoft.com/T/#u
What's cooking in git.git (Apr 2018, #01; Mon, 9)
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.
I try to summarize what each topic is about immediately after the
list of commits on the topic, which may be followed by a short term
plan for the topic ("Will merge to 'next'", etc.), possibly followed
by a reminder (e.g. "cf. ") to help me recall the reason
behind the plan. Please do not read more than that into "cf." (e.g.
the ones listed are not more important than other messages in the
same thread).
The tip of 'next' has not been rewind post 2.17 release. I plan to
flush as many solid topics that have been cooking there down to
'master' first without merging anything new to 'next', and then
do so sometime in this week. Let's see how it goes.
You can find the changes described here in the integration branches
of the repositories listed at
http://git-blame.blogspot.com/p/git-public-repositories.html
--
[Graduated to "master"]
* pw/add-p-single (2018-03-31) 1 commit
(merged to 'next' on 2018-03-31 at 43a177f941)
+ add -p: fix 2.17.0-rc* regression due to moved code
Hotfix.
--
[New Topics]
* ab/simplify-perl-makefile (2018-04-09) 2 commits
- SQUASH???
- perl: fix installing modules from contrib
Recent simplification of build procedure forgot a bit of tweak to
the build procedure of contrib/mw-to-git/
* ak/bisect-doc-typofix (2018-04-07) 1 commit
- Documentation/git-bisect.txt: git bisect term → git bisect terms
Docfix.
Will merge to 'next'.
* bw/commit-partial-from-subdirectory-fix (2018-04-05) 1 commit
- commit: allow partial commits with relative paths
"cd sub/dir && git commit ../path" ought to record the changes to
the file "sub/path", but this regressed long time ago.
Will merge to 'next'.
* ds/lazy-load-trees (2018-04-07) 5 commits
- commit-graph: lazy-load trees for commits
- treewide: replace maybe_tree with accessor methods
- commit: create get_commit_tree() method
- treewide: rename tree to maybe_tree
- Merge branch 'bw/c-plus-plus' into ds/lazy-load-trees
(this branch uses ds/commit-graph.)
* jk/t5561-missing-curl (2018-04-05) 2 commits
- t5561: skip tests if curl is not available
- t5561: drop curl stderr redirects
Test fixes.
Will merge to 'next'.
* ks/branch-list-detached-rebase-i (2018-04-05) 2 commits
- t3200: verify "branch --list" sanity when rebasing from detached HEAD
- branch --list: print useful info whilst interactive rebasing a detached HEAD
"git branch --list" during an interrupted "rebase -i" now lets
users distinguish the case where a detached HEAD is being rebased
and a normal branch is being rebased.
Will merge to 'next'.
* lw/daemon-log-destination (2018-04-09) 1 commit
- daemon.c: fix condition for redirecting stderr
Recent introduction of "--log-destination" option to "git daemon"
did not work well when the daemon was run under "--inetd" mode.
Will merge to 'next'.
* mn/send-email-credential-doc (2018-04-08) 1 commit
- send-email: simplify Gmail example in the documentation
Doc update.
Will merge to 'next'.
* nd/worktree-move (2018-04-05) 1 commit
- t2028: tighten grep expression to make "move worktree" test more robust
(this branch is used by es/worktree-docs.)
Test update.
Will merge to 'next'.
* ab/git-svn-get-record-typofix (2018-04-09) 1 commit
- git-svn: avoid warning on undef readline()
"git svn" had a minor thinko/typo which has been fixed.
* br/mergetools-guiffy (2018-04-06) 1 commit
- mergetools: add support for guiffy
"git mergetools" learned talking to guiffy.
Will merge to 'next'.
* en/doc-typoes (2018-04-09) 2 commits
- Documentation: normalize spelling of 'normalised'
- Documentation: fix several one-character-off spelling errors
Docfix.
Will merge to 'next'.
* hn/sort-ls-remote (2018-04-09) 1 commit
- ls-remote: create '--sort' option
(this branch uses jk/ref-array-push.)
"git ls-remote" learned an option to allow sorting its output based
on the refnames being shown.
* jk/ref-array-push (2018-04-09) 3 commits
- ref-filter: factor ref_array pushing into its own function
- ref-filter: make ref_array_item allocation more consistent
- ref-filter: use "struct object_id" consistently
(this branch is used by hn/sort-ls-remote.)
API clean-up aournd ref-filter code.
Will merge to 'next'.
* js/empty-config-section-fix (2018-04-06) 14 commits
- git_config_set: reuse empty sections
- git config --unset: remove empty sections (in the common case)
- git_config_set: make use of the config parser's event stream
- git_config_set: do not use a state machine
- config_set_store: rename some fields for consistency
- config: avoid using the global variable `store`
- config: introduce an optiona
