Re: What's cooking in git.git (Jul 2017, #01; Wed, 5)

[Stefan Beller]

On Thu, Jul 6, 2017 at 7:13 PM, Junio C Hamano  wrote:
> Stefan Beller  writes:
>
>> Speaking of submodules, It's not just features, but I also send bug fixes. ;)
>> https://public-inbox.org/git/20170630003851.17288-1-sbel...@google.com/
>> (That patch is not related to this series, except for working in the 
>> submodule
>> area, but I consider that patch more important than e.g. this series.)
>
> I did not see the patch as fixing a bug, though.
>
> I do agree that overwriting the branch tips in the submodule
> repositories, possibly rewinding and discarding user's work done on
> the local branches, is indeed a problem.  It however is unclear why
> detaching HEAD is a good solution to solve that problem.

I am not saying detaching a HEAD is a good solution, but I am saying
it is a better solution than corrupting the submodule branch, such
that commits are lost in the submodule, only to be recorvered via the
reflog.

> After all, there must have been a reason why the user had checked
> out a branch and had pointed it at a specific commit (presumably,
> so that further work would be done while on the branch, to make it
> easier and safer to eventually push the result back to the upstream
> of the submodule's project).  So another solution that seems equally
> viable, if not even more so, could be to fail the recursive checkout
> saying why the checkout cannot be done, just like we fail a checkout
> when a local change interferes with updating the contents in the
> working tree and the index with an error message explaining which
> paths are problematic.

That seems like a better model to me for now.

> I am *not* saying which one among the above two is better; I am not
> even saying that there could be only these two possible solutions.
> I just found the posted patch unsatisfactory because it did not make
> it clear why the chosen solution is a good one.

ok. My long term plan is to introduce another type of symbolic ref,
which references a gitlink in another repository, such that the submodule
can have a clear distinction between "follows the superproject",
"has its own authoritative branch" and "its detached HEAD can mean
anything, e.g. historical submodule behavior"

> Perhaps I misread the description; but that would mean the
> description was prone to be misread and has room for improvement ;-)

ok.

Re: What's cooking in git.git (Jul 2017, #01; Wed, 5)

[Junio C Hamano]

Stefan Beller  writes:

> Speaking of submodules, It's not just features, but I also send bug fixes. ;)
> https://public-inbox.org/git/20170630003851.17288-1-sbel...@google.com/
> (That patch is not related to this series, except for working in the submodule
> area, but I consider that patch more important than e.g. this series.)

I did not see the patch as fixing a bug, though.  

I do agree that overwriting the branch tips in the submodule
repositories, possibly rewinding and discarding user's work done on
the local branches, is indeed a problem.  It however is unclear why
detaching HEAD is a good solution to solve that problem.

After all, there must have been a reason why the user had checked
out a branch and had pointed it at a specific commit (presumably,
so that further work would be done while on the branch, to make it
easier and safer to eventually push the result back to the upstream
of the submodule's project).  So another solution that seems equally
viable, if not even more so, could be to fail the recursive checkout
saying why the checkout cannot be done, just like we fail a checkout
when a local change interferes with updating the contents in the
working tree and the index with an error message explaining which
paths are problematic.

I am *not* saying which one among the above two is better; I am not
even saying that there could be only these two possible solutions.
I just found the posted patch unsatisfactory because it did not make
it clear why the chosen solution is a good one.

Perhaps I misread the description; but that would mean the
description was prone to be misread and has room for improvement ;-)

Re: What's cooking in git.git (Jul 2017, #01; Wed, 5)

[Stefan Beller]

> [Graduated to "master"]
>
> * bw/repo-object (2017-06-23) 21 commits
...
>
>  Introduce a "repository" object to eventually make it easier to
>  work in multiple repositories (the primary focus is to work with
>  the superproject and its submodules) in a single process.

It's pretty rad to see this advancing to master.
FYI: I started working on teaching the object store how to work
with repository objects. This would allow us to get rid of hacks in
submodule.c: namely add_submodule_odb, which adds submodule
objects to the (main) object store for processing. Ideally we want
to free the objects of a submodule once we are done with a submodule.
(or integrate it into our try_to_free_routine)

> * sb/hashmap-cleanup (2017-07-05) 10 commits
...
>  Will wait for feedback, then merge to and cook in 'next'.

Thanks.

> * sb/pull-rebase-submodule (2017-06-27) 4 commits
>  - builtin/fetch cleanup: always set default value for submodule recursing
>  - pull: optionally rebase submodules (remote submodule changes only)
>  - builtin/fetch: parse recurse-submodules-default at default options parsing
>  - builtin/fetch: factor submodule recurse parsing out to submodule config
>
>  "git pull --rebase --recurse-submodules" learns to rebase the
>  branch in the submodules to an updated base.

Speaking of submodules, It's not just features, but I also send bug fixes. ;)
https://public-inbox.org/git/20170630003851.17288-1-sbel...@google.com/
(That patch is not related to this series, except for working in the submodule
area, but I consider that patch more important than e.g. this series.)

> * sb/submodule-doc (2017-06-22) 1 commit
>  - submodules: overhaul documentation
>
>  Doc update.
>
>  What's the status of this thing?

There was some review on the list (mostly from Brandon and Jonathan T.),
but I felt like it was bikeshedding, as there is no black/white correctness
with words. (Same for code, but for code it is easier to come to a
consensus at least.)

So I had a couple of internal rounds with them on a Google doc, hence
I assume they agree on this patch being ok as-is.  But it has been a while
I can reread it myself to check. But I guess most valuable input
would come from others.

> * sb/diff-color-move (2017-06-30) 26 commits
...
>  Will merge to 'next'.

cool. Let's see how a larger audience reacts to this one. Maybe there
is more input for a good heuristic.

Thanks,
Stefan

What's cooking in git.git (Jul 2017, #01; Wed, 5)

[Junio C Hamano]

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.

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"]

* bw/repo-object (2017-06-23) 21 commits
  (merged to 'next' on 2017-06-26 at ed9c0b77c3)
 + ls-files: use repository object
 + repository: enable initialization of submodules
 + submodule: convert is_submodule_initialized to work on a repository
 + submodule: add repo_read_gitmodules
 + submodule-config: store the_submodule_cache in the_repository
 + repository: add index_state to struct repo
 + config: read config from a repository object
 + path: add repo_worktree_path and strbuf_repo_worktree_path
 + path: add repo_git_path and strbuf_repo_git_path
 + path: worktree_git_path() should not use file relocation
 + path: convert do_git_path to take a 'struct repository'
 + path: convert strbuf_git_common_path to take a 'struct repository'
 + path: always pass in commondir to update_common_dir
 + path: create path.h
 + environment: store worktree in the_repository
 + environment: place key repository state in the_repository
 + repository: introduce the repository object
 + environment: remove namespace_len variable
 + setup: add comment indicating a hack
 + setup: don't perform lazy initialization of repository state
 + Merge branches 'bw/ls-files-sans-the-index' and 'bw/config-h' into 
bw/repo-object

 Introduce a "repository" object to eventually make it easier to
 work in multiple repositories (the primary focus is to work with
 the superproject and its submodules) in a single process.


* cc/shared-index-permfix (2017-06-25) 3 commits
  (merged to 'next' on 2017-06-26 at bb41584bf0)
 + t1700: make sure split-index respects core.sharedrepository
 + t1301: move modebits() to test-lib-functions.sh
 + read-cache: use shared perms when writing shared index

 The split index code did not honor core.sharedrepository setting
 correctly.


* jt/unify-object-info (2017-06-26) 8 commits
  (merged to 'next' on 2017-06-26 at 540ea81983)
 + sha1_file: refactor has_sha1_file_with_flags
 + sha1_file: do not access pack if unneeded
 + sha1_file: teach sha1_object_info_extended more flags
 + sha1_file: refactor read_object
 + sha1_file: move delta base cache code up
 + sha1_file: rename LOOKUP_REPLACE_OBJECT
 + sha1_file: rename LOOKUP_UNKNOWN_OBJECT
 + sha1_file: teach packed_object_info about typename

 Code clean-ups.


* rs/sha1-name-readdir-optim (2017-06-24) 4 commits
  (merged to 'next' on 2017-06-26 at a70587f2b9)
 + sha1_file: guard against invalid loose subdirectory numbers
 + sha1_file: let for_each_file_in_obj_subdir() handle subdir names
 + p4205: add perf test script for pretty log formats
 + sha1_name: cache readdir(3) results in find_short_object_filename()

 Optimize "what are the object names already taken in an alternate
 object database?" query that is used to derive the length of prefix
 an object name is uniquely abbreviated to.

--
[New Topics]

* bc/object-id (2017-07-04) 12 commits
 - sha1_name: convert GET_SHA1* flags to GET_OID*
 - sha1_name: convert get_sha1* to get_oid*
 - Convert remaining callers of get_sha1 to get_oid.
 - builtin/verify-tag: convert to struct object_id
 - builtin/unpack-file: convert to struct object_id
 - bisect: convert bisect_checkout to struct object_id
 - builtin/update_ref: convert to struct object_id
 - sequencer: convert to struct object_id
 - remote: convert struct push_cas to struct object_id
 - submodule: convert submodule config lookup to use object_id
 - builtin/merge-tree: convert remaining caller of get_sha1 to object_id
 - builtin/fsck: convert remaining caller of get_sha1 to object_id

 Conversion from uchar[20] to struct object_id continues.


* jk/reflog-walk (2017-07-05) 7 commits
 - reflog-walk: stop using fake parents
 - rev-list: check reflog_info before showing usage
 - get_revision_1(): replace do-while with an early return
 - log: do not free parents when walking reflog
 - [SQUASH LOG MESSAGE ONLY] t1414: document some reflog-walk oddities
 - t1414: document some reflog-walk oddities
 - Merge branch 'jk/reflog-walk-maint' into jk/reflog-walk
 (this branch uses jk/reflog-walk-maint.)

 Numerous bugs in walking of reflogs via "log -g" and friends have
 been fixed.


* jk/reflog-walk-maint (2017-07-05) 1 commit
 - reflog-walk: skip over double-null oid due to HEAD rename
 (this branch is used by jk/reflog-walk.)

 After "git branch --move" of the currently checked out branch, the
 code to walk the reflog of HEAD via "log -g" and friends
 incorrectly stopped at the reflog entry that records the renaming
 of