What's cooking in git.git (May 2009, #02; Sun, 17)

What's cooking in git.git (May 2009, #02; Sun, 17)

[Junio C Hamano]

Here are the topics that have been cooking.  Commits prefixed with '-' are
only in 'pu' while commits prefixed with '+' are in 'next'.  The ones
marked with '.' do not appear in any of the branches, but I am still
holding onto them.

The topics list the commits in reverse chronological order.  The topics
meant to be merged to the maintenance series have "maint-" in their names.

----------------------------------------------------------------
[New Topics]

* jc/mktree (Thu May 14 15:49:10 2009 -0700) 9 commits
 - mktree: validate entry type in input
 - mktree --batch: build more than one tree object
 - mktree --missing: updated usage message and man page
 - mktree --missing: allow missing objects
 - t1010: add mktree test
 - mktree: do not barf on a submodule commit
 - builtin-mktree.c: use a helper function to handle one line of
   input
 - mktree: use parse-options
 - build-in git-mktree

* ar/maint-1.6.2-merge-recursive-d-f (Mon May 11 21:25:36 2009 +0200) 2 commits
 - Fix for a merge where a branch has an F->D transition
 - Add a reminder test case for a merge with F/D transition

Although the reported breakage is covered with the patch, Alex feels the
solution unsatisfactory. Cleaning up D/F conflict handling in merge-recursive
may be long overdue but seems to be a hard problem.

* jc/maint-add-p-coalesce-fix (Sat May 16 10:48:23 2009 -0700) 2 commits
 + Revert "git-add--interactive: remove hunk coalescing"
 + Splitting a hunk that adds a line at the top fails in "add -p"

* sb/format-patch-parseopt (Sat May 16 02:24:46 2009 -0700) 1 commit
 - format-patch: migrate to parse-options API

* fc/decorate-tag (Thu May 14 00:32:53 2009 +0300) 2 commits
 + Prettify log decorations even more
 + Change prettify_ref to prettify_refname

* mg/track (Mon May 11 16:42:54 2009 +0200) 2 commits
 + Fix behavior with non-commit upstream references
 + Test tracking of non-commit upstreams

* jn/gitweb-cleanup (Mon May 11 19:45:11 2009 +0200) 8 commits
 + gitweb: Remove unused $hash_base parameter from
   normalize_link_target
 + gitweb: Simplify snapshot format detection logic in
   evaluate_path_info
 + gitweb: Use capturing parentheses only when you intend to capture
 + gitweb: Replace wrongly added tabs with spaces
 + gitweb: Use block form of map/grep in a few cases more
 + gitweb: Always use three argument form of open
 + gitweb: Always use three argument form of open
 + gitweb: Do not use bareword filehandles

* js/maint-no-ln-across-libexec-and-bin (Mon May 11 13:02:18 2009 +0200) 1 commit
 + Add NO_CROSS_DIRECTORY_HARDLINKS support to the Makefile

* jh/notes (Sat May 16 13:44:17 2009 +0200) 5 commits
 - Teach "-m <msg>" and "-F <file>" to "git notes edit"
 - Add an expensive test for git-notes
 - Speed up git notes lookup
 - Add a script to edit/inspect notes
 - Introduce commit notes

* tp/send-email-from-config (Tue May 12 15:48:56 2009 -0700) 1 commit
 + send-email: Add config option for sender address

* lt/read-directory (Fri May 15 12:01:29 2009 -0700) 3 commits
 - Add initial support for pathname conversion to UTF-8
 - read_directory(): infrastructure for pathname character set
   conversion
 - Add 'fill_directory()' helper function for directory traversal

----------------------------------------------------------------
[Will merge to "master" soon]

* mw/send-email (Mon Apr 13 13:23:52 2009 -0500) 6 commits
 + send-email: Remove superfluous `my $editor = ...'
 + send-email: 'References:' should only reference what is sent
 + send-email: Handle "GIT:" rather than "GIT: " during --compose
 + Docs: send-email: --smtp-server-port can take symbolic ports
 + Docs: send-email: Refer to CONFIGURATION section for
   sendemail.multiedit
 + Docs: send-email: Put options back into alphabetical order

* ae/anon-fetch-info (Fri Apr 17 10:20:11 2009 +0200) 1 commit
 + fetch: Strip usernames from url's before storing them

* ac/graph-horizontal-line (Tue Apr 21 08:47:01 2009 -0400) 1 commit
 + graph API: Use horizontal lines for more compact graphs

* ph/submodule-rebase (Fri Apr 24 09:06:38 2009 +1000) 1 commit
 + git-submodule: add support for --rebase.

* mh/show-branch-color (Sat Apr 25 13:46:14 2009 +0200) 2 commits
 + bash completion: show-branch color support
 + show-branch: color the commit status signs

* mh/diff-stat-color (Sat Apr 25 00:06:47 2009 +0200) 1 commit
 + diff: do not color --stat output like patch context

* js/add-edit (Mon Apr 27 19:51:42 2009 +0200) 2 commits
 + t3702: fix reliance on SHELL_PATH being '/bin/sh'
 + git-add: introduce --edit (to edit the diff vs. the index)

* jk/maint-add-empty (Tue Apr 28 23:21:01 2009 -0400) 1 commit
 + add: don't complain when adding empty project root

When you say "git add ." in an empty directory, you get "No path matches
''", instead of "No path matches '.'", and this "fixes" it by hiding the
error and making the command silently succeed.  Strictly speaking it
introduces inconsistency, but I think an empty directory is so
uninteresting special case that not signalling it as an error is Ok.

* ar/unlink-err (Wed Apr 29 23:24:52 2009 +0200) 3 commits
 + print unlink(2) errno in copy_or_link_directory
 + replace direct calls to unlink(2) with unlink_or_warn
 + Introduce an unlink(2) wrapper which gives warning if unlink
   failed

* ar/merge-one-file-diag (Wed Apr 29 23:40:50 2009 +0200) 1 commit
 + Clarify kind of conflict in merge-one-file helper

* np/push-delta (Fri May 1 16:56:47 2009 -0400) 1 commit
 + allow OFS_DELTA objects during a push

* mt/submodule-reference (Mon May 4 22:30:01 2009 +0300) 1 commit
 + Add --reference option to git submodule.

* fl/git-pm (Thu May 7 15:41:28 2009 +0200) 2 commits
 + Git.pm: Always set Repository to absolute path if autodetecting
 + Git.pm: Set GIT_WORK_TREE if we set GIT_DIR

* rs/grep-parseopt (Thu May 7 21:46:48 2009 +0200) 5 commits
 + grep: use parseopt
 + grep: remove global variable builtin_grep
 + parseopt: add PARSE_OPT_NODASH
 + parseopt: add OPT_NUMBER_CALLBACK
 + parseopt: add OPT_NEGBIT

* jk/no-no-no-empty-directory (Fri May 8 01:01:17 2009 -0400) 2 commits
 + parseopt: add OPT_NEGBIT
 + parseopt: add OPT_NEGBIT

I somehow botched the commit log message of the top one; it is about
fixing "ls-files --no-empty-directory".

* jk/maint-1.6.0-trace-argv (Fri May 8 05:06:15 2009 -0400) 1 commit
 + fix GIT_TRACE segfault with shell-quoted aliases

* hv/sample-update (Fri May 8 17:22:30 2009 +0200) 1 commit
 + Extend sample update hook, disable modifying of existing tags

* rr/forbid-bs-in-ref (Fri May 8 07:32:37 2009 +0200) 1 commit
 + Disallow '\' in ref names

This retroactively forbids use of what people could have been using
happily, which, strictly speaking, is a no-no, but makes sense in the
longer term.

* do/maint-merge-recursive-fix (Sat May 9 14:49:59 2009 -0700) 1 commit
 + merge-recursive: never leave index unmerged while recursing

* jm/format-patch-no-auto-n-when-k-is-given (Sat May 9 10:12:01 2009 +0200) 1 commit
 + format-patch let -k override a config-specified format.numbered

* lt/maint-diff-reduce-lstat (Sat May 9 15:11:17 2009 -0700) 2 commits
 + Teach 'git checkout' to preload the index contents
 + Avoid unnecessary 'lstat()' calls in 'get_stat_data()'

* cc/bisect (Sat May 9 17:55:47 2009 +0200) 20 commits
 + bisect: make "git bisect" use new "--next-all" bisect-helper
   function
 + bisect: add "check_good_are_ancestors_of_bad" function
 + bisect: implement the "check_merge_bases" function
 + bisect: automatically sort sha1_array if needed when looking it up
 + bisect: make skipped array functions more generic
 + bisect: remove too much function nesting
 + bisect: use new "struct argv_array" to prepare argv for
   "setup_revisions"
 + bisect: store good revisions in a "sha1_array"
 + bisect: implement "rev_argv_push" to fill an argv with revs
 + bisect: use "sha1_array" to store skipped revisions
 + am: simplify "sq" function by using "git rev-parse --sq-quote"
 + bisect: use "git rev-parse --sq-quote" instead of a custom "sq"
   function
 + rev-parse: add --sq-quote to shell quote arguments
 + rev-list: remove stringed output flag from "show_bisect_vars"
 + bisect--helper: remove "--next-vars" option as it is now useless
 + bisect: use "git bisect--helper --next-exit" in "git-bisect.sh"
 + bisect--helper: add "--next-exit" to output bisect results
 + bisect: move common bisect functionality to "bisect_common"
 + rev-list: refactor printing bisect vars
 + rev-list: make "estimate_bisect_steps" non static

Rewriting major part of "git-bisect" shell script continues.  The patches
seem to be reasonably clean.

----------------------------------------------------------------
[Stalled and may need help and prodding to go forward]

* ps/blame (Thu Mar 12 21:30:03 2009 +1100) 1 commit
 - blame.c: start libifying the blame infrastructure

A few minor point remains in this initial one.  I hate to do these minor
fix-ups myself, but I may end up doing so...

* jc/log-tz (Tue Mar 3 00:45:37 2009 -0800) 1 commit
 - Allow --date=local --date=other-format to work as expected

The one I posted had a few corner-case bugs that was caught with the test
suite; this one has them fixed.  People did not like the UI so it is kept
out of 'next'

* jc/merge-convert (Mon Jan 26 16:45:01 2009 -0800) 1 commit
 - git-merge-file: allow converting the results for the work tree

This is a feature waiting for a user.

We did not give scripted Porcelains a way to say "this temporary file I am
using for merging is for this path, so use the core.autocrlf and attributes
rules for that final path".  Instead, merge-file simply wrote out the
data in the canonical repository representation.

rerere has the same issue, but it is a lot worse.  It reads the three
files (preimage, postimage and thisimage) from the work tree in the work
tree representation, merges them without converting them to the canonical
representation first but inserts the conflict markers with the canonical
representation and writes the resulting mess out.  It needs to be fixed to
read with convert_to_git(), merge them while they are still in the
canonical representation and possibly add conflict markers, and then write
the results out after convert_to_working_tree().  It also needs to write
in binary mode as well.

* db/foreign-scm (Tue Mar 24 23:04:12 2009 -0400) 3 commits
 - Add option for using a foreign VCS
 - Document details of transport function APIs
 - Allow late reporting of fetched hashes

* hv/cvsps-tests (Sun Apr 5 01:40:50 2009 -0700) 8 commits
 - t/t9600: remove exit after test_done
 - cvsimport: extend testcase about patchset order to contain
   branches
 - cvsimport: add test illustrating a bug in cvsps
 - Add a test of "git cvsimport"'s handling of tags and branches
 - Add some tests of git-cvsimport's handling of vendor branches
 - Test contents of entire cvsimported "master" tree contents
 - Use CVS's -f option if available (ignore user's ~/.cvsrc file)
 - Start a library for cvsimport-related tests

----------------------------------------------------------------
[Actively cooking]

* da/mergetool-lib (Sat May 2 01:57:21 2009 -0700) 1 commit
 - mergetool--lib: specialize diff options for emerge and ecmerge

Can somebody tell me what the current status of this is?  I thought there
was some objection, but I lost track...

* rc/http-push (Sat May 16 11:51:52 2009 +0800) 12 commits
 - http*: add fetch_http_pack_index
 - http: create function end_url_with_slash
 - http*: move common variables and macros to http.[ch]
 - http-push: do not SEGV after fetching a bad pack idx file
 - http*: copy string returned by sha1_to_hex
 - http-walker: verify remote packs
 - http-push, http-walker: style fixes
 - t5550-http-fetch: test fetching of packed objects
 - http-push: fix missing "#ifdef USE_CURL_MULTI" around
   "is_running_queue"
 - http-push: send out fetch requests on queue
 - t5540-http-push: test fetching of packed objects
 - t5540-http-push: test fetching of loose objects

There was an 11-patch updates but in the middle there were some
compilation breakage issues; only early part of that series is queued.

* cc/replace (Tue Apr 14 00:36:59 2009 +0200) 13 commits
 - Documentation: add documentation for "git replace"
 - Add git-replace to .gitignore
 - builtin-replace: use "usage_msg_opt" to give better error messages
 - parse-options: add new function "usage_msg_opt"
 - builtin-replace: teach "git replace" to actually replace
 - Add new "git replace" command
 - environment: add global variable to disable replacement
 - mktag: call "check_sha1_signature" with the replacement sha1
 - replace_object: add a test case
 - object: call "check_sha1_signature" with the replacement sha1
 - sha1_file: add a "read_sha1_file_repl" function
 - replace_object: add mechanism to replace objects found in
   "refs/replace/"
 - refs: add a "for_each_replace_ref" function

I suspect an attempt to replace an object that is directly listed on the
command line would not work very well with this series.

----------------------------------------------------------------
[On Hold]

* jc/deny-delete-current-1.7.0 (Mon Feb 9 00:19:46 2009 -0800) 1 commit
 - receive-pack: default receive.denyDeleteCurrent to refuse

* jc/refuse-push-to-current-1.7.0 (Wed Feb 11 02:28:03 2009 -0800) 1 commit
 - Refuse updating the current branch in a non-bare repository via
   push

These are for 1.7.0, but the messages when they trigger together may need
to be rethought.

----------------------------------------------------------------
[Discarded]

* js/notes (Tue Apr 14 00:03:36 2009 +0200) 15 commits
 . Documentation: fix 'linkgit' macro in "git-notes.txt"
 . tests: fix "export var=val"
 . notes: refuse to edit notes outside refs/notes/
 . t3301: use test_must_fail instead of !
 . t3301: fix confusing quoting in test for valid notes ref
 . notes: use GIT_EDITOR and core.editor over VISUAL/EDITOR
 . notes: only clean up message file when editing
 . handle empty notes gracefully
 . git notes show: test empty notes
 . git-notes: fix printing of multi-line notes
 . notes: fix core.notesRef documentation
 . Add an expensive test for git-notes
 . Speed up git notes lookup
 . Add a script to edit/inspect notes
 . Introduce commit notes

This has been replaced by jh/notes series.

Re: What's cooking in git.git (May 2009, #02; Sun, 17)

[Jakub Narebski]

Junio C Hamano <gitster@pobox.com> writes:

> * jn/gitweb-cleanup (Mon May 11 19:45:11 2009 +0200) 8 commits
>  + gitweb: Remove unused $hash_base parameter from
>    normalize_link_target
>  + gitweb: Simplify snapshot format detection logic in
>    evaluate_path_info
>  + gitweb: Use capturing parentheses only when you intend to capture
>  + gitweb: Replace wrongly added tabs with spaces
>  + gitweb: Use block form of map/grep in a few cases more
>  + gitweb: Always use three argument form of open
>  + gitweb: Always use three argument form of open
>  + gitweb: Do not use bareword filehandles

Why "gitweb: Always use three argument form of open" is twice here?

-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: What's cooking in git.git (May 2009, #02; Sun, 17)

[David Aguilar]

On Sun, May 17, 2009 at 01:05:18AM -0700, Junio C Hamano wrote:
> ----------------------------------------------------------------
> [Actively cooking]
> 
> * da/mergetool-lib (Sat May 2 01:57:21 2009 -0700) 1 commit
>  - mergetool--lib: specialize diff options for emerge and ecmerge
> 
> Can somebody tell me what the current status of this is?  I thought there
> was some objection, but I lost track...

This one was good to go.

The original reporter of the problem w/ emerge was happy with
the patch.  The specialization for ecmerge was also correct.

The objection was about having to translate the ecmerge command
name for mac os x (which the patch doesn't do).  We
settled on not doing it (meaning leave the patch alone
as-is) since it's not customary for os x users to have ecmerge
in their $PATH and thus it's up to them to configure it if
they want it.  The motivation being that we don't want to
start special-casing any platforms.

The patch for araxis was also good (after explaining that the
-title: options don't work correctly which is why the patch
didn't include it).  I can resend again later in case
it got lost.  I also share Dscho's "if it's not free then I
won't touch it" attitude, tho I'm not opposed to helping out
users on under-privileged platforms from time to time.
It seemed like Myagi(?) wasted a lot of time getting araxis
working with msysgit/mergetool so porting the patch to
mergetool--lib felt like the nice thing to do.

-- 

	David

Re: What's cooking in git.git (May 2009, #02; Sun, 17)

[Junio C Hamano]

Jakub Narebski <jnareb@gmail.com> writes:

> Junio C Hamano <gitster@pobox.com> writes:
>
>> * jn/gitweb-cleanup (Mon May 11 19:45:11 2009 +0200) 8 commits
>>  + gitweb: Remove unused $hash_base parameter from
>>    normalize_link_target
>>  + gitweb: Simplify snapshot format detection logic in
>>    evaluate_path_info
>>  + gitweb: Use capturing parentheses only when you intend to capture
>>  + gitweb: Replace wrongly added tabs with spaces
>>  + gitweb: Use block form of map/grep in a few cases more
>>  + gitweb: Always use three argument form of open
>>  + gitweb: Always use three argument form of open
>>  + gitweb: Do not use bareword filehandles
>
> Why "gitweb: Always use three argument form of open" is twice here?

Perhaps you sent in a malformed message and I did not notice nor hand
munge it?  Let's see...

      Message-ID: <200905110329.40666.jnareb@gmail.com>

Yeah, that's it.

Re: What's cooking in git.git (May 2009, #02; Sun, 17)

[Jakub Narebski]

On Sun, 17 May 2009, Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>> Junio C Hamano <gitster@pobox.com> writes:
>>
>>> * jn/gitweb-cleanup (Mon May 11 19:45:11 2009 +0200) 8 commits
>>>  + gitweb: Remove unused $hash_base parameter from
>>>    normalize_link_target
>>>  + gitweb: Simplify snapshot format detection logic in
>>>    evaluate_path_info
>>>  + gitweb: Use capturing parentheses only when you intend to capture
>>>  + gitweb: Replace wrongly added tabs with spaces
>>>  + gitweb: Use block form of map/grep in a few cases more
>>>  + gitweb: Always use three argument form of open
>>>  + gitweb: Always use three argument form of open
>>>  + gitweb: Do not use bareword filehandles
>>
>> Why "gitweb: Always use three argument form of open" is twice here?
> 
> Perhaps you sent in a malformed message and I did not notice nor hand
> munge it?  Let's see...
> 
>       Message-ID: <200905110329.40666.jnareb@gmail.com>
> 
> Yeah, that's it.

Ooops. I have put v2 of 'gitweb: Localize magic variable $/' as a reply
to a wrong post, and forgot to massage the email... still, shouldn't
git-am pick up "Subject:" from a body of email?

Well, it is in 'next' already, so resend wouldn't help...

I'm sorry about that...
-- 
Jakub Narebski
Poland

Re: What's cooking in git.git (May 2009, #02; Sun, 17)

[Johan Herland]

On Sunday 17 May 2009, Junio C Hamano wrote:
> [Will merge to "master" soon]
>
> * ph/submodule-rebase (Fri Apr 24 09:06:38 2009 +1000) 1 commit 
>  + git-submodule: add support for --rebase.

Just a quick question before this ends up in 'master'. I'm sorry if this 
has already been answered:

Why only --rebase, and not also --merge?

I certainly don't have anything against "git submodule update --rebase", 
and I support its inclusion, but why not also "--merge"? While --rebase 
calls "git rebase" instead of "git checkout", --merge would call "git 
merge" instead. I believe there are useful workflows where --merge 
would be a better fit than --rebase.

Now, my question should not stop this feature from going into 'master', 
except for the fact that if we also want to support merge, we should 
rename the associated config variable:

Instead of

  submodule.<name>.rebase = true/false (false if unset)

we should have something like

  submodule.<name>.resolve = checkout/rebase/merge (checkout if unset)


Hmm?

...Johan

-- 
Johan Herland, <johan@herland.net>
www.herland.net

Re: What's cooking in git.git (May 2009, #02; Sun, 17)

[Markus Heidelberg]

Johan Herland, 18.05.2009:
> On Sunday 17 May 2009, Junio C Hamano wrote:
> > [Will merge to "master" soon]
> >
> > * ph/submodule-rebase (Fri Apr 24 09:06:38 2009 +1000) 1 commit 
> >  + git-submodule: add support for --rebase.
> 
> [..]
> 
> Now, my question should not stop this feature from going into 'master', 
> except for the fact that if we also want to support merge, we should 
> rename the associated config variable:
> 
> Instead of
> 
>   submodule.<name>.rebase = true/false (false if unset)
> 
> we should have something like
> 
>   submodule.<name>.resolve = checkout/rebase/merge (checkout if unset)

At least this would be inconsistent with options like
branch.<name>.merge and branch.<name>.rebase

Markus

Re: What's cooking in git.git (May 2009, #02; Sun, 17)

[Johan Herland]

On Monday 18 May 2009, Markus Heidelberg wrote:
> Johan Herland, 18.05.2009:
> > On Sunday 17 May 2009, Junio C Hamano wrote:
> > > [Will merge to "master" soon]
> > >
> > > * ph/submodule-rebase (Fri Apr 24 09:06:38 2009 +1000) 1 commit
> > >  + git-submodule: add support for --rebase.
> >
> > [..]
> >
> > Now, my question should not stop this feature from going into 'master',
> > except for the fact that if we also want to support merge, we should
> > rename the associated config variable:
> >
> > Instead of
> >
> >   submodule.<name>.rebase = true/false (false if unset)
> >
> > we should have something like
> >
> >   submodule.<name>.resolve = checkout/rebase/merge (checkout if unset)
>
> At least this would be inconsistent with options like
> branch.<name>.merge and branch.<name>.rebase

No. We cannot "reuse" the branch.<name>.merge/rebase semantics in this case: 
branch.<name>.merge takes a remote branch name to merge with, while 
submodule.<name>.merge needs no such name (the merge is well-specified 
without that extra name: the new submodule commit is merged into the 
submodule's current branch). Thus, submodule.<name>.merge is reduced to a 
simple bool indicating whether or not we should merge. At this point, 
however, it is not only inconsistent with branch.<name>.merge, it also 
directly conflicts with submodule.<name>.rebase (they cannot both be "true" 
simultaneously). They should therefore be collapsed into one tri-state 
config variable set to either 'rebase', 'merge' or 'false'/unset (which 
triggers the default 'checkout' behaviour). This is pretty much what I 
propose above.

After some thinking, I don't like my original name submodule.<name>.resolve, 
since ".resolve" sounds more like a merge strategy or conflict resolution 
method, than a "how to deal with submodule update" choice. I propose 
submodule.<name>.update instead.


...Johan

-- 
Johan Herland, <johan@herland.net>
www.herland.net

[PATCH] git-submodule: add support for --merge.

[Johan Herland]

'git submodule update --merge' merges the commit referenced by the
superproject into your local branch, instead of checking it out on
a detached HEAD.

As evidenced by the addition of "git submodule update --rebase", it
is useful to provide alternatives to the default 'checkout' behaviour
of "git submodule update". Another such alternative is, when updating
a submodule to a new commit, to merge that commit into the current
branch. This is useful in workflows where you cannot use --rebase,
because you have downstream people working on top of your submodule
branch, and you don't want to disrupt their work with a rebase, but
you still want to update your submodule from its upstream.

Config variables: The --rebase patch added submodule.<name>.rebase
for turning on --rebase by default for a given submodule. However,
a similar submodule.<name>.merge variable cannot be added since it
would conflict with submodule.<name>.rebase (they cannot both be
true). This patch therefore replaces submodule.<name>.rebase with
submodule.<name>.update, which can be set to the following values:

- 'checkout': This specifies the default behaviour in which "git
  submodule update" checks out the new commit to a detached HEAD.
  Leaving submodule.<name>.update unset also causes this behaviour.

- 'rebase': This specifies the --rebase behaviour (and thus replaces
  submodule.<name>.rebase == true), where the local branch in the
  submodule is rebased onto the new commit.

- 'merge': This specifies the new --merge behaviour in which the new
  commit is merged into the submodule's local branch.

Signed-off-by: Johan Herland <johan@herland.net>
---

Here's a patch implementing my suggestion. I have chosen to avoid
backwards-compatibility for the submodule.<name>.rebase config
variable, since it is not yet present in a released version.


Have fun! :)

...Johan

 Documentation/git-submodule.txt |   19 ++++++++--
 Documentation/gitmodules.txt    |   12 +++++-
 git-submodule.sh                |   43 ++++++++++++++--------
 t/t7406-submodule-update.sh     |   76 ++++++++++++++++++++++++++++++++++-----
 4 files changed, 119 insertions(+), 31 deletions(-)

diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index acd16ac..1cbb181 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -13,7 +13,7 @@ SYNOPSIS
 	      [--reference <repository>] [--] <repository> <path>
 'git submodule' [--quiet] status [--cached] [--] [<path>...]
 'git submodule' [--quiet] init [--] [<path>...]
-'git submodule' [--quiet] update [--init] [-N|--no-fetch] [--rebase]
+'git submodule' [--quiet] update [--init] [-N|--no-fetch] [--rebase|--merge]
 	      [--reference <repository>] [--] [<path>...]
 'git submodule' [--quiet] summary [--summary-limit <n>] [commit] [--] [<path>...]
 'git submodule' [--quiet] foreach <command>
@@ -115,8 +115,9 @@ init::
 update::
 	Update the registered submodules, i.e. clone missing submodules and
 	checkout the commit specified in the index of the containing repository.
-	This will make the submodules HEAD be detached unless '--rebase' is
-	specified or the key `submodule.$name.rebase` is set to `true`.
+	This will make the submodules HEAD be detached unless '--rebase' or
+	'--merge' is specified or the key `submodule.$name.update` is set to
+	`rebase` or `merge`.
 +
 If the submodule is not yet initialized, and you just want to use the
 setting as stored in .gitmodules, you can automatically initialize the
@@ -186,7 +187,17 @@ OPTIONS
 	superproject. If this option is given, the submodule's HEAD will not
 	be detached. If a a merge failure prevents this process, you will have
 	to resolve these failures with linkgit:git-rebase[1].
-	If the key `submodule.$name.rebase` is set to `true`, this option is
+	If the key `submodule.$name.update` is set to `rebase`, this option is
+	implicit.
+
+--merge::
+	This option is only valid for the update command.
+	Merge the commit recorded in the superproject into the current branch
+	of the submodule. If this option is given, the submodule's HEAD will
+	not be detached. If a merge failure prevents this process, you will
+	have to resolve the resulting conflicts within the submodule with the
+	usual conflict resolution tools.
+	If the key `submodule.$name.update` is set to `merge`, this option is
 	implicit.
 
 --reference <repository>::
diff --git a/Documentation/gitmodules.txt b/Documentation/gitmodules.txt
index 7c22c40..5daf750 100644
--- a/Documentation/gitmodules.txt
+++ b/Documentation/gitmodules.txt
@@ -30,8 +30,16 @@ submodule.<name>.path::
 submodule.<name>.url::
 	Defines an url from where the submodule repository can be cloned.
 
-submodule.<name>.rebase::
-	Defines that the submodule should be rebased by default.
+submodule.<name>.update::
+	Defines what to do when the submodule is updated by the superproject.
+	If 'checkout' (the default), the new commit specified in the
+	superproject will be checked out in the submodule on a detached HEAD.
+	If 'rebase', the current branch of the submodule will be rebased onto
+	the commit specified in the superproject. If 'merge', the commit
+	specified in the superproject will be merged into the current branch
+	in the submodule.
+	This config option is overridden if 'git submodule update' is given
+	the '--merge' or '--rebase' options.
 
 
 EXAMPLES
diff --git a/git-submodule.sh b/git-submodule.sh
index bbca183..2a1e73c 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -5,7 +5,7 @@
 # Copyright (c) 2007 Lars Hjemli
 
 USAGE="[--quiet] [--cached] \
-[add [-b branch] <repo> <path>]|[status|init|update [-i|--init] [-N|--no-fetch]|summary [-n|--summary-limit <n>] [<commit>]] \
+[add [-b branch] <repo> <path>]|[status|init|update [-i|--init] [-N|--no-fetch] [--rebase|--merge]|summary [-n|--summary-limit <n>] [<commit>]] \
 [--] [<path>...]|[foreach <command>]|[sync [--] [<path>...]]"
 OPTIONS_SPEC=
 . git-sh-setup
@@ -18,7 +18,7 @@ quiet=
 reference=
 cached=
 nofetch=
-rebase=
+update=
 
 #
 # print stuff on stdout unless -q was specified
@@ -311,10 +311,10 @@ cmd_init()
 		git config submodule."$name".url "$url" ||
 		die "Failed to register url for submodule path '$path'"
 
-		test true != "$(git config -f .gitmodules --bool \
-			submodule."$name".rebase)" ||
-		git config submodule."$name".rebase true ||
-		die "Failed to register submodule path '$path' as rebasing"
+		upd="$(git config -f .gitmodules submodule."$name".update)"
+		test -z "$upd" ||
+		git config submodule."$name".update "$upd" ||
+		die "Failed to register update mode for submodule path '$path'"
 
 		say "Submodule '$name' ($url) registered for path '$path'"
 	done
@@ -345,7 +345,11 @@ cmd_update()
 			;;
 		-r|--rebase)
 			shift
-			rebase=true
+			update="rebase"
+			;;
+		-m|--merge)
+			shift
+			update="merge"
 			;;
 		--reference)
 			case "$2" in '') usage ;; esac
@@ -379,7 +383,7 @@ cmd_update()
 	do
 		name=$(module_name "$path") || exit
 		url=$(git config submodule."$name".url)
-		rebase_module=$(git config --bool submodule."$name".rebase)
+		update_module=$(git config submodule."$name".update)
 		if test -z "$url"
 		then
 			# Only mention uninitialized submodules when its
@@ -400,9 +404,9 @@ cmd_update()
 			die "Unable to find current revision in submodule path '$path'"
 		fi
 
-		if test true = "$rebase"
+		if ! test -z "$update"
 		then
-			rebase_module=true
+			update_module=$update
 		fi
 
 		if test "$subsha1" != "$sha1"
@@ -420,16 +424,23 @@ cmd_update()
 				die "Unable to fetch in submodule path '$path'"
 			fi
 
-			if test true = "$rebase_module"
-			then
-				command="git-rebase"
+			case "$update_module" in
+			rebase)
+				command="git rebase"
 				action="rebase"
 				msg="rebased onto"
-			else
-				command="git-checkout $force -q"
+				;;
+			merge)
+				command="git merge"
+				action="merge"
+				msg="merged in"
+				;;
+			*)
+				command="git checkout $force -q"
 				action="checkout"
 				msg="checked out"
-			fi
+				;;
+			esac
 
 			(unset GIT_DIR; cd "$path" && $command "$sha1") ||
 			die "Unable to $action '$sha1' in submodule path '$path'"
diff --git a/t/t7406-submodule-update.sh b/t/t7406-submodule-update.sh
index 3442c05..2d33d9e 100755
--- a/t/t7406-submodule-update.sh
+++ b/t/t7406-submodule-update.sh
@@ -6,7 +6,7 @@
 test_description='Test updating submodules
 
 This test verifies that "git submodule update" detaches the HEAD of the
-submodule and "git submodule update --rebase" does not detach the HEAD.
+submodule and "git submodule update --rebase/--merge" does not detach the HEAD.
 '
 
 . ./test-lib.sh
@@ -76,9 +76,23 @@ test_expect_success 'submodule update --rebase staying on master' '
 	)
 '
 
-test_expect_success 'submodule update - rebase true in .git/config' '
+test_expect_success 'submodule update --merge staying on master' '
+	(cd super/submodule &&
+	  git reset --hard HEAD~1
+	) &&
+	(cd super &&
+	 (cd submodule &&
+	  compare_head
+	 ) &&
+	 git submodule update --merge submodule &&
+	 cd submodule &&
+	 compare_head
+	)
+'
+
+test_expect_success 'submodule update - rebase in .git/config' '
 	(cd super &&
-	 git config submodule.submodule.rebase true
+	 git config submodule.submodule.update rebase
 	) &&
 	(cd super/submodule &&
 	  git reset --hard HEAD~1
@@ -93,9 +107,9 @@ test_expect_success 'submodule update - rebase true in .git/config' '
 	)
 '
 
-test_expect_success 'submodule update - rebase false in .git/config but --rebase given' '
+test_expect_success 'submodule update - checkout in .git/config but --rebase given' '
 	(cd super &&
-	 git config submodule.submodule.rebase false
+	 git config submodule.submodule.update checkout
 	) &&
 	(cd super/submodule &&
 	  git reset --hard HEAD~1
@@ -110,9 +124,43 @@ test_expect_success 'submodule update - rebase false in .git/config but --rebase
 	)
 '
 
-test_expect_success 'submodule update - rebase false in .git/config' '
+test_expect_success 'submodule update - merge in .git/config' '
 	(cd super &&
-	 git config submodule.submodule.rebase false
+	 git config submodule.submodule.update merge
+	) &&
+	(cd super/submodule &&
+	  git reset --hard HEAD~1
+	) &&
+	(cd super &&
+	 (cd submodule &&
+	  compare_head
+	 ) &&
+	 git submodule update submodule &&
+	 cd submodule &&
+	 compare_head
+	)
+'
+
+test_expect_success 'submodule update - checkout in .git/config but --merge given' '
+	(cd super &&
+	 git config submodule.submodule.update checkout
+	) &&
+	(cd super/submodule &&
+	  git reset --hard HEAD~1
+	) &&
+	(cd super &&
+	 (cd submodule &&
+	  compare_head
+	 ) &&
+	 git submodule update --merge submodule &&
+	 cd submodule &&
+	 compare_head
+	)
+'
+
+test_expect_success 'submodule update - checkout in .git/config' '
+	(cd super &&
+	 git config submodule.submodule.update checkout
 	) &&
 	(cd super/submodule &&
 	  git reset --hard HEAD^
@@ -131,9 +179,19 @@ test_expect_success 'submodule init picks up rebase' '
 	(cd super &&
 	 git config submodule.rebasing.url git://non-existing/git &&
 	 git config submodule.rebasing.path does-not-matter &&
-	 git config submodule.rebasing.rebase true &&
+	 git config submodule.rebasing.update rebase &&
 	 git submodule init rebasing &&
-	 test true = $(git config --bool submodule.rebasing.rebase)
+	 test "rebase" = $(git config submodule.rebasing.update)
+	)
+'
+
+test_expect_success 'submodule init picks up merge' '
+	(cd super &&
+	 git config submodule.merging.url git://non-existing/git &&
+	 git config submodule.merging.path does-not-matter &&
+	 git config submodule.merging.update merge &&
+	 git submodule init merging &&
+	 test "merge" = $(git config submodule.merging.update)
 	)
 '
 
-- 
1.6.3.rc0.1.gf800

Re: What's cooking in git.git (May 2009, #02; Sun, 17)

[Junio C Hamano]

Johan Herland <johan@herland.net> writes:

> After some thinking, I don't like my original name submodule.<name>.resolve, 
> since ".resolve" sounds more like a merge strategy or conflict resolution 
> method, than a "how to deal with submodule update" choice. I propose 
> submodule.<name>.update instead.

Sounds like a plan, even though I do not necessarily agree with the idea
of automatically rebinding what is at the submodule path every time you
update the toplevel project tree.  And from my point of view, "rebind" (or
"autorebind") would be more appropriate name than "update" (and I would
probably set it to "never").

Re: What's cooking in git.git (May 2009, #02; Sun, 17)

[Johan Herland]

On Tuesday 19 May 2009, Junio C Hamano wrote:
> Johan Herland <johan@herland.net> writes:
> > After some thinking, I don't like my original name
> > submodule.<name>.resolve, since ".resolve" sounds more like a merge
> > strategy or conflict resolution method, than a "how to deal with
> > submodule update" choice. I propose submodule.<name>.update instead.
>
> Sounds like a plan, even though I do not necessarily agree with the idea
> of automatically rebinding what is at the submodule path every time you
> update the toplevel project tree.

I agree that in many workflows this does not make sense, but I believe that 
(as with 'git submodule update --rebase') there are some cases where it does 
make sense, and I see no reason to support one, but not the other.

> And from my point of view, "rebind" (or "autorebind") would be more
> appropriate name than "update"

Feel free to fix up my patch with whatever the community finds most 
appropriate. Personally, I still like "update" better because it determines 
what "happens" on a git submodule update, but I'm not religious about this.

> (and I would probably set it to "never").

That's perfectly ok. So will I, in most of my repos. But there are cases 
(e.g. in the workflows at $dayjob) where this feature will be very valuable.


...Johan

-- 
Johan Herland, <johan@herland.net>
www.herland.net

Re: What's cooking in git.git (May 2009, #02; Sun, 17)

[Johannes Schindelin]

Hi,

On Tue, 19 May 2009, Johan Herland wrote:

> On Tuesday 19 May 2009, Junio C Hamano wrote:
> > Johan Herland <johan@herland.net> writes:
> > > After some thinking, I don't like my original name 
> > > submodule.<name>.resolve, since ".resolve" sounds more like a merge 
> > > strategy or conflict resolution method, than a "how to deal with 
> > > submodule update" choice. I propose submodule.<name>.update instead.
> >
> > Sounds like a plan, even though I do not necessarily agree with the 
> > idea of automatically rebinding what is at the submodule path every 
> > time you update the toplevel project tree.
> 
> I agree that in many workflows this does not make sense, but I believe 
> that (as with 'git submodule update --rebase') there are some cases 
> where it does make sense, and I see no reason to support one, but not 
> the other.

We have a _lot_ of obscure things that are not supported by core Git, but 
are _very_ easy to add as _tiny_ add-on scripts by the user, without the 
need for "official" feature support.

Just like this one,
Dscho

Re: What's cooking in git.git (May 2009, #02; Sun, 17)

[Johan Herland]

On Tuesday 19 May 2009, Johannes Schindelin wrote:
> On Tue, 19 May 2009, Johan Herland wrote:
> > On Tuesday 19 May 2009, Junio C Hamano wrote:
> > > Johan Herland <johan@herland.net> writes:
> > > > After some thinking, I don't like my original name
> > > > submodule.<name>.resolve, since ".resolve" sounds more like a
> > > > merge strategy or conflict resolution method, than a "how to
> > > > deal with submodule update" choice. I propose
> > > > submodule.<name>.update instead.
> > >
> > > Sounds like a plan, even though I do not necessarily agree with
> > > the idea of automatically rebinding what is at the submodule path
> > > every time you update the toplevel project tree.
> >
> > I agree that in many workflows this does not make sense, but I
> > believe that (as with 'git submodule update --rebase') there are
> > some cases where it does make sense, and I see no reason to support
> > one, but not the other.
>
> We have a _lot_ of obscure things that are not supported by core Git,
> but are _very_ easy to add as _tiny_ add-on scripts by the user,
> without the need for "official" feature support.
>
> Just like this one

Does that mean you're also opposed to 'git submodule update --rebase' 
(which is already in 'next', and is even Signed-off-by yourself)?

I still don't see any reason why one should be added (--rebase), and not 
the other (--merge).

Dropping both would at least be consistent from core Git's POV, but 
following that thread, we should probably also drop "git pull" (which 
is just a simple wrapper around "git fetch" and "git merge"), and maybe 
also "git clone" (which can easily be scripted, using "git init", "git 
remote", "git fetch" and "git branch")...


...Johan

-- 
Johan Herland, <johan@herland.net>
www.herland.net

Re: What's cooking in git.git (May 2009, #02; Sun, 17)

[Johannes Schindelin]

Hi,

On Tue, 19 May 2009, Johan Herland wrote:

> On Tuesday 19 May 2009, Johannes Schindelin wrote:
> > On Tue, 19 May 2009, Johan Herland wrote:
> > > On Tuesday 19 May 2009, Junio C Hamano wrote:
> > > > Johan Herland <johan@herland.net> writes:
> > > > > After some thinking, I don't like my original name 
> > > > > submodule.<name>.resolve, since ".resolve" sounds more like a 
> > > > > merge strategy or conflict resolution method, than a "how to 
> > > > > deal with submodule update" choice. I propose 
> > > > > submodule.<name>.update instead.
> > > >
> > > > Sounds like a plan, even though I do not necessarily agree with 
> > > > the idea of automatically rebinding what is at the submodule path 
> > > > every time you update the toplevel project tree.
> > >
> > > I agree that in many workflows this does not make sense, but I 
> > > believe that (as with 'git submodule update --rebase') there are 
> > > some cases where it does make sense, and I see no reason to support 
> > > one, but not the other.
> >
> > We have a _lot_ of obscure things that are not supported by core Git, 
> > but are _very_ easy to add as _tiny_ add-on scripts by the user, 
> > without the need for "official" feature support.
> >
> > Just like this one
> 
> Does that mean you're also opposed to 'git submodule update --rebase' 
> (which is already in 'next', and is even Signed-off-by yourself)?

No, because -- as I said myself already a couple of times -- I can see 
this supporting a common workflow.

> I still don't see any reason why one should be added (--rebase), and not 
> the other (--merge).

When you rebase, you see your personal stuff (i.e. stuff that you do not 
want to submit, or not in its current form, or that you submitted and it 
waits for inclusion) on top of things right away.

In contrast, if you merge, you will have a different state from the 
upstream _forever_.  Even if your stuff gets included.

Needless to say, I do not see much use for the latter case, but tons for 
the former.

> Dropping both would at least be consistent from core Git's POV, but 
> following that thread, we should probably also drop "git pull" (which is 
> just a simple wrapper around "git fetch" and "git merge"), and maybe 
> also "git clone" (which can easily be scripted, using "git init", "git 
> remote", "git fetch" and "git branch")...

I will not bother to comment on this.

Ciao,
Dscho

Re: git submodule update --merge (Was: What's cooking in git.git (May 2009, #02; Sun, 17))

[Johan Herland]

On Tuesday 19 May 2009, Johannes Schindelin wrote:
> On Tue, 19 May 2009, Johan Herland wrote:
> > On Tuesday 19 May 2009, Johannes Schindelin wrote:
> > > On Tue, 19 May 2009, Johan Herland wrote:
> > > > [git submodule update --merge]
> > >
> > > We have a _lot_ of obscure things that are not supported by core
> > > Git, but are _very_ easy to add as _tiny_ add-on scripts by the
> > > user, without the need for "official" feature support.
> > >
> > > Just like this one
> >
> > Does that mean you're also opposed to 'git submodule update
> > --rebase' (which is already in 'next', and is even Signed-off-by
> > yourself)?
>
> No, because -- as I said myself already a couple of times -- I can
> see this supporting a common workflow.
>
> > I still don't see any reason why one should be added (--rebase),
> > and not the other (--merge).
>
> When you rebase, you see your personal stuff (i.e. stuff that you do
> not want to submit, or not in its current form, or that you submitted
> and it waits for inclusion) on top of things right away.

But if there are developers downstream whose work is based on your 
submodule branch, the rebase will disrupt _their_ work, in the same way 
that rebasing any other public branch would disrupt people's work.

> In contrast, if you merge, you will have a different state from the
> upstream _forever_.  Even if your stuff gets included.

Correct, but there are cases where reconciliation with the upstream repo 
is less important than not disrupting downstream developers (see 
below).

> Needless to say, I do not see much use for the latter case, but tons
> for the former.

I fully agree that for a regular downstream (or "leaf") developer, there 
is not much use for git submodule rebase --merge.

But not all developers fit nicely into your scenario above. Please 
consider the following scenario (loosely based on the setup at my 
$dayjob):

1. There is a collection of "core" repositories that provide common 
platform-independent functionality that is useful to several projects.

2. There is a group of "core" developers that work directly on 
the "core" repos in #1. These developers are not much concerned with 
submodule functionality at all.

3. There are multiple projects that each have their own project 
super-repo, which contains a set of submodules. Most of these 
submodules are clones of the "core" repos in #1.

4. Each project has a group of developers that work on that project. 
These developers clone the project super-repo in #3, and do their work, 
both directly in the super-repo, and within the submodules. Their 
changes (both in the super-repo and its submodules), are pushed back 
into the shared project repos (i.e. the project super-repo, and the 
project's clones of the "core" repos). The project developers will 
typically use "git submodule update --rebase" to keep their own 
unfinished changes on top of submodule updates.

5. Finally, there is the last group of developers, in between the two 
other groups - call them "branch managers" or "integration developers". 
These developers are responsible for synchronizing the work done by the 
downstream project developers (#4) and the work done by the 
upstream "core" developers (#2):

a) Some of the changes done by the project developers are useful to 
_all_ projects using that "core" module, and are sent as patches to 
the "core" developers for inclusion upstream.

b) Some changes are NOT useful to the upstream project, and are kept on 
the project-specific branch of the submodule.

Now, consider what happens when a new version of a "core" module (#1) is 
released/published: The new version contains general improvements to 
that module, and all projects that use the module should upgrade to the 
new version. The integration developers (#5) for a given project is 
responsible for this upgrade. How are they going to do the upgrade 
without disrupting the work of the project developers (#4)?

- They obviously cannot use the default "git submodule update", since 
that would lose all project-specific changes (see b), and it would also 
disrupt the downstream project developers.

- Using "git submodule update --rebase" is certainly better (they don't 
lose the project-specific changes), but they still rebase the project 
branch (which disrupts the downstream project developers).

Therefore, the straightforward solution is to merge the new upstream 
version into the existing project branch. This preserves the 
project-specific changes, AND it does not disrupt the downstream 
developers.

Hence, support for "git submodule update --merge" is a very welcome 
feature for these integration developers.


I understand that the above scenario is not common in the free software 
world, but I believe it is much more common in an enterprise/company 
setting. Therefore, the support of such workflows is important to 
companies that are currently considering (or have already chosen) Git. 
I believe there is value in supporting such workflows, especially when 
doing so is as straightforward as my patch shows.


Thanks for your attention,

...Johan

-- 
Johan Herland, <johan@herland.net>
www.herland.net

Re: git submodule update --merge (Was: What's cooking in git.git (May 2009, #02; Sun, 17))

[Johan Herland]

On Tuesday 19 May 2009, Johan Herland wrote:
> On Tuesday 19 May 2009, Johannes Schindelin wrote:
> > On Tue, 19 May 2009, Johan Herland wrote:
> > > I still don't see any reason why one should be added (--rebase),
> > > and not the other (--merge).
> >
> > When you rebase, you see your personal stuff (i.e. stuff that you
> > do not want to submit, or not in its current form, or that you
> > submitted and it waits for inclusion) on top of things right away.
>
> But if there are developers downstream whose work is based on your
> submodule branch, the rebase will disrupt _their_ work, in the same
> way that rebasing any other public branch would disrupt people's
> work.
>
> > In contrast, if you merge, you will have a different state from the
> > upstream _forever_.  Even if your stuff gets included.
>
> Correct, but there are cases where reconciliation with the upstream
> repo is less important than not disrupting downstream developers (see
> below).
>
> > Needless to say, I do not see much use for the latter case, but
> > tons for the former.
>
> I fully agree that for a regular downstream (or "leaf") developer,
> there is not much use for git submodule rebase --merge.
>
> But not all developers fit nicely into your scenario above.
> 
> [Workflow description in which "git submodule update --merge" would
>  be a helpful addition]
>
> I understand that the above scenario is not common in the free
> software world, but I believe it is much more common in an
> enterprise/company setting. Therefore, the support of such workflows
> is important to companies that are currently considering (or have
> already chosen) Git. I believe there is value in supporting such
> workflows, especially when doing so is as straightforward as my patch
> shows.

I haven't received any replies to my attempt to describe the context in 
which "git submodule update --merge" is useful. A hint as to whether my 
argument is valid, or just crap, would be nice.

In any case, even if we don't include "git submodule update --merge", 
could we _please_ consider changing the associated config variable from

  submodule.<name>.rebase = true/false (false if unset)

to something like

  submodule.<name>.update = checkout/rebase (checkout if unset)

or (Junio's suggestion)

  submodule.<name>.rebind = never/rebase (never if unset)

so that we at least have the _option_ of adding other alternatives in 
the future?


Have fun! :)

...Johan

-- 
Johan Herland, <johan@herland.net>
www.herland.net

Re: git submodule update --merge

[Junio C Hamano]

Johan Herland <johan@herland.net> writes:

> I haven't received any replies to my attempt to describe the context in 
> which "git submodule update --merge" is useful. A hint as to whether my 
> argument is valid, or just crap, would be nice.

FWIW, I didn't find "rebase makes sense but merge doesn't" argument very
convincing to begin with.  Because the configuration variable is about
"update" action, I agree it makes sense to do

>   submodule.<name>.update = checkout/rebase (checkout if unset)

from the UI standpoint.

I do not know what the sensible repertoire of options nor what the default
should be, though.  That's up to the submodule using people to sort out.

Re: git submodule update --merge

[Johannes Schindelin]

Hi,

On Mon, 25 May 2009, Junio C Hamano wrote:

> Johan Herland <johan@herland.net> writes:
> 
> > I haven't received any replies to my attempt to describe the context 
> > in which "git submodule update --merge" is useful. A hint as to 
> > whether my argument is valid, or just crap, would be nice.
> 
> FWIW, I didn't find "rebase makes sense but merge doesn't" argument very
> convincing to begin with.

Well, that is probably because you are not forced by me to use submodules.

Because in the project I use submodules most heavily, there is one 
recurring theme: you cannot push to the submodules.  And by "you" I mean 
"a regular user".

So virtually all you do in these submodules cannot be pushed at all.  It 
has to be submitted to the respective submodule maintainer.

And guess what happens in such a case when you set that tentative "update" 
variable to "merge"?

Exactly.

FWIW I consider any scenario where the average users have push access to 
the submodule a toy scenario.

The rebase workflow is very useful in my project, so if it does not go 
into git.git, I'll just force my users to install a Git compiled from my 
git tree.

Ciao,
Dscho

Re: git submodule update --merge

[Avery Pennarun]

On Mon, May 25, 2009 at 2:57 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Because in the project I use submodules most heavily, there is one
> recurring theme: you cannot push to the submodules.  And by "you" I mean
> "a regular user".
>
> So virtually all you do in these submodules cannot be pushed at all.  It
> has to be submitted to the respective submodule maintainer.
>
> And guess what happens in such a case when you set that tentative "update"
> variable to "merge"?
>
> Exactly.
>
> FWIW I consider any scenario where the average users have push access to
> the submodule a toy scenario.

I have the same problem.  Out of curiosity, how do you handle the case
where you really need to make a change to the submodule and let your
team members see that change, even though the submodule's upstream is
slow and/or doesn't accept the patch?

In that situation, we've had to make local shared mirrors of all the
submodules and point .gitmodules at that.  But that would be your
"toy" scenario - our local users have push access to the submodule.

Thanks,

Avery

Re: git submodule update --merge

[Johannes Schindelin]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1843 bytes --]

Hi,

On Mon, 25 May 2009, Avery Pennarun wrote:

> On Mon, May 25, 2009 at 2:57 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> > Because in the project I use submodules most heavily, there is one
> > recurring theme: you cannot push to the submodules.  And by "you" I mean
> > "a regular user".
> >
> > So virtually all you do in these submodules cannot be pushed at all.  It
> > has to be submitted to the respective submodule maintainer.
> >
> > And guess what happens in such a case when you set that tentative "update"
> > variable to "merge"?
> >
> > Exactly.
> >
> > FWIW I consider any scenario where the average users have push access to
> > the submodule a toy scenario.
> 
> I have the same problem.  Out of curiosity, how do you handle the case
> where you really need to make a change to the submodule and let your
> team members see that change, even though the submodule's upstream is
> slow and/or doesn't accept the patch?
> 
> In that situation, we've had to make local shared mirrors of all the
> submodules and point .gitmodules at that.  But that would be your
> "toy" scenario - our local users have push access to the submodule.

Happily enough, our changes were accepted so far.

For a few branches, though, the patches are not ready to be sent upstream 
(or, from a certain viewpoint, sometimes downstream) yet, so we do have 
local forks for those working on that.

Note, however, that even in this case, it is better to use 'rebase' rather 
than 'merge', for exactly the same (I almost wrote "unconvincing") reason 
as before.

Ciao,
Dscho

P.S.: in some cases, the submodules' "upstreams" are maintained by team 
members, but that is very much on purpose.  They are trusted maintainers, 
and there is no reason to let some young and maybe overly energetic 
friends push to such a trusted repository.

Re: git submodule update --merge

[Johan Herland]

On Monday 25 May 2009, Junio C Hamano wrote:
> Johan Herland <johan@herland.net> writes:
> > I haven't received any replies to my attempt to describe the context in
> > which "git submodule update --merge" is useful. A hint as to whether my
> > argument is valid, or just crap, would be nice.
>
> FWIW, I didn't find "rebase makes sense but merge doesn't" argument very
> convincing to begin with.  Because the configuration variable is about
> "update" action, I agree it makes sense to do
>
> >   submodule.<name>.update = checkout/rebase (checkout if unset)
>
> from the UI standpoint.
>
> I do not know what the sensible repertoire of options nor what the
> default should be, though.  That's up to the submodule using people to
> sort out.

I suggest the default should be whatever "git submodule update" does today, 
which is what I've called 'checkout' above (i.e. it simply checks out the 
submodule commit, which naturally detaches the head).

If you prefer, I can split my previous patch in two; one that fixes the 
config variable, and one that adds "submodule update --merge", so that they 
can be evaluated separately. Hmm?


Have fun! :)

...Johan

-- 
Johan Herland, <johan@herland.net>
www.herland.net

Re: git submodule update --merge

[Johan Herland]

On Monday 25 May 2009, Johannes Schindelin wrote:
> On Mon, 25 May 2009, Avery Pennarun wrote:
> > On Mon, May 25, 2009 at 2:57 PM, Johannes Schindelin wrote:
> > > Because in the project I use submodules most heavily, there is one
> > > recurring theme: you cannot push to the submodules.  And by "you" I
> > > mean "a regular user".
> > >
> > > So virtually all you do in these submodules cannot be pushed at all.
> > >  It has to be submitted to the respective submodule maintainer.
> > >
> > > And guess what happens in such a case when you set that tentative
> > > "update" variable to "merge"?
> > >
> > > Exactly.
> > >
> > > FWIW I consider any scenario where the average users have push access
> > > to the submodule a toy scenario.

Well, in the scenario I described earlier, the project developers (your 
"average users") _do_ have push access to the submodules. And that scenario 
is certainly not a toy scenario.

> > I have the same problem.  Out of curiosity, how do you handle the case
> > where you really need to make a change to the submodule and let your
> > team members see that change, even though the submodule's upstream is
> > slow and/or doesn't accept the patch?
> >
> > In that situation, we've had to make local shared mirrors of all the
> > submodules and point .gitmodules at that.  But that would be your
> > "toy" scenario - our local users have push access to the submodule.

For the purposes of this discussion, this is pretty close to the use case I 
described earlier in my scenario as well. Thanks, Avery, for presenting the 
argument in a more readable manner.

> Happily enough, our changes were accepted so far.
>
> For a few branches, though, the patches are not ready to be sent upstream
> (or, from a certain viewpoint, sometimes downstream) yet, so we do have
> local forks for those working on that.
>
> Note, however, that even in this case, it is better to use 'rebase'
> rather than 'merge', for exactly the same (I almost wrote "unconvincing")
> reason as before.

Yes, and I have never argued that your "average users" should use 'merge'. 
Indeed I have not argued that 'merge' is suitable for your workflow _at_ 
_all_.

One of the guiding principles I have learned from earlier submodule 
discussions on this list, is that the git submodule commands should NOT 
impose restrictions on the workflows available to its users. But in this 
case you are using your own workflow to argue what should, and should not be 
part of the git submodule repertoire. I am arguing that there are 
_different_ workflows, with _different_ requirements where 'merge' would be 
a useful addition. Just because you won't ever use it, does not mean that it 
will not be useful to anybody else.

> P.S.: in some cases, the submodules' "upstreams" are maintained by team
> members, but that is very much on purpose.  They are trusted maintainers,
> and there is no reason to let some young and maybe overly energetic
> friends push to such a trusted repository.

Do you argue that protecting these "young and maybe overly energetic" 
developers from themselves should be hardcoded into the git submodule 
behaviour, in such a way that it obscures the availability of other 
alternative submodule workflows?


Have fun! :)

...Johan

-- 
Johan Herland, <johan@herland.net>
www.herland.net

Re: git submodule update --merge (Was: What's cooking in git.git (May 2009, #02; Sun, 17))

[Peter Hutterer]

On Mon, May 25, 2009 at 01:59:37PM +0200, Johan Herland wrote:
> On Tuesday 19 May 2009, Johan Herland wrote:
> > On Tuesday 19 May 2009, Johannes Schindelin wrote:
> > > On Tue, 19 May 2009, Johan Herland wrote:
> > > > I still don't see any reason why one should be added (--rebase),
> > > > and not the other (--merge).
> > >
> > > When you rebase, you see your personal stuff (i.e. stuff that you
> > > do not want to submit, or not in its current form, or that you
> > > submitted and it waits for inclusion) on top of things right away.
> >
> > But if there are developers downstream whose work is based on your
> > submodule branch, the rebase will disrupt _their_ work, in the same
> > way that rebasing any other public branch would disrupt people's
> > work.
> >
> > > In contrast, if you merge, you will have a different state from the
> > > upstream _forever_.  Even if your stuff gets included.
> >
> > Correct, but there are cases where reconciliation with the upstream
> > repo is less important than not disrupting downstream developers (see
> > below).
> >
> > > Needless to say, I do not see much use for the latter case, but
> > > tons for the former.
> >
> > I fully agree that for a regular downstream (or "leaf") developer,
> > there is not much use for git submodule rebase --merge.
> >
> > But not all developers fit nicely into your scenario above.
> > 
> > [Workflow description in which "git submodule update --merge" would
> >  be a helpful addition]
> >
> > I understand that the above scenario is not common in the free
> > software world, but I believe it is much more common in an
> > enterprise/company setting. Therefore, the support of such workflows
> > is important to companies that are currently considering (or have
> > already chosen) Git. I believe there is value in supporting such
> > workflows, especially when doing so is as straightforward as my patch
> > shows.
> 
> I haven't received any replies to my attempt to describe the context in 
> which "git submodule update --merge" is useful. A hint as to whether my 
> argument is valid, or just crap, would be nice.
> 
> In any case, even if we don't include "git submodule update --merge", 
> could we _please_ consider changing the associated config variable from
> 
>   submodule.<name>.rebase = true/false (false if unset)
> 
> to something like
> 
>   submodule.<name>.update = checkout/rebase (checkout if unset)
> 
> or (Junio's suggestion)
> 
>   submodule.<name>.rebind = never/rebase (never if unset)
> 
> so that we at least have the _option_ of adding other alternatives in 
> the future?

I can't really chime in on the merge debate since it's not part of my
workflow, but I definitely support the above. Even if we never add any
options other than checkout/rebase, it's still better than the prospect of
having possibly conflicting boolean settings in the future.

Cheers,
  Peter