Here are the topics that have been cooking.  Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'.

Note.

    Some commits on 'pu' have [comment] in front of their title, primarily
    to remind myself not to accidentally merge them to 'next' before
    issues are resolved.  They will be amended either by replacement patch
    from the author, or when the issue raised on the list gets refuted
    convincingly enough to justify the original patch (in which case only
    the comment like "[questionable???]"  will be removed without changing
    the tree of the commit).

The topics list the commits in reverse chronological order.

A rough timeline from now on.

 * Discussion and review on new feature and enhancement patch series
   begins.  Please resubmit things that you were cooking in your head
   during 1.5.5-rc period after cleaning up and retesting.

 * 1.5.6 merge window closes (2008-05-14).

 * Fixes of 'master' continues; 1.5.6-rc0 gets tagged (2008-05-21).

 * 1.5.6 Final (2008-06-08).

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

* js/rebase-i-sequencer (Mon Apr 14 02:21:09 2008 +0200) 13 commits
 + Add option --preserve-tags
 + Teach rebase interactive the tag command
 + Add option --first-parent
 + Do rebase with preserve merges with advanced TODO list
 + Select all lines with fake-editor
 + Unify the length of $SHORT* and the commits in the TODO list
 + Teach rebase interactive the merge command
 + Move redo merge code in a function
 + Teach rebase interactive the reset command
 + Teach rebase interactive the mark command
 + Move cleanup code into it's own function
 + Don't append default merge message to -m message
 + fake-editor: output TODO list if unchanged

This may complement the proposed "sequencer" GSoC project.

* db/clone-in-c (Thu Apr 17 19:32:43 2008 -0400) 8 commits
 - [mess] Build in clone
 - [strdup() and other clean-ups needed] Provide API access to
   ...
[ message continues ]

I summarize junio's points that says $GIT_DIR/config is authoritative.

1. .gitmodules shouldn't be authoritative and should be just a hint
   to fill $GIT_DIR/config because

   a) url may be rewritten with different protocol, such as from
     "http://" to "git://"
   b) url may be total different between .gitmodules and
      $GIT_DIR/config

2. When going back to an old HEAD of super project and do
   "git submodule update", the url recorded in .gitmodules may be
   stale or not existent anymore, so we should refer to
   $GIT_DIR/config for the right url.

3. We can record what contents we've seen in the .gitmodules, so that
   we can give users a chance to adjust what is in $GIT_DIR/config
   when we notice the entry in .gitmodules has changed.

Any others?

However, i argue the fall back strategy (say fall back to .gitmodules
when we can't find an entries in $GIT_DIR/config) doesn't break the
authority and isn't in contrast with the cases above. It just attachs
more importance to .gitmodules and can make the world better in most
cases.

For 1.a, i think we can keep these entries in .gitmodules, and use
"url.<thisurl>.insteadof = <otherurl>" to override the urls.

For 1.b, i think this is a rare case. And we can override these urls
in $GIT_DIR/config. However, in many cases, we havn't to do that.

For 2, i think it is also a rare case. And before going back, we can
override the urls in $GIT_DIR/config.

For 3, i havn't found a good way to do that. And it doesn't conflict
with the fall back strategy (say, wh

So, my conclusion

* 1.b, 2 and 3 are all rare cases, and these cases don't conflict with
  the fall back strategy

* 1.a is a usual case, and fallback + 'url insteadOf" will make things
  better

* The most common case is that most (even all) entries in .gitmodules
  are the same as entires in $GIT_DIR/config. So with fallback, we
  don't have to copy entries from .gitmodules to $GIT_DIR/config.

* And, in a central environment, i think it's ...
[ message continues ]

A reason you did not mention is security:
You never want your .git/config to be changed behind your back, which
effectivly is the case when using the versioned .gitmodules information
(similar problem as with a .gitconfig in-tree).

Another one:
From a design point of view, submodule URLs are project meta information
unrelated to source history. So, actually, I think it was wrong to put
submodule URLs (even hints only) into the versioned .gitmodules files (*).

The main reason for .gitmodules is to store submodule information which
has to be in sync with commits, such as a submodule name related to some
path where the submodule happens to be checked out in a given commit, and
also related to some config entry holding the URL to allow for fetch/pull.
The idea is that submodules have an identity in the supermodule (in contrast
to files in git), such that related configuration keeps valid when moving
submodules around. This needs simultanous adjusting the path attribute in
.gitmodules when a submodule is moved.

Josef

(*) IMHO, it would be far better if such project meta/policy information could
be in its own history (e.g. branch "gitconfig" to allow for easy propagation
at clone/fetch time). However, any such configuration should need
explicit interaction by the user to take over project config into the
local git config (e.g. via a "git config merge gitconfig:config" after
inspecting via "git show gitconfig:config").
--

[ message continues ]

On Tue, Apr 22, 2008 at 10:55 PM, Josef Weidendorfer

As discussed in another thread about in-tree .gitconfig, security
issues only arise on limited configuration entries. However, there are

But now it actually acts as hints and we don't find a better way. I

If we go back to a old HEAD or switch to another branch with changed
path for a submodule,  what should 'git submodule update' do?
I think entries in .gitmodules should take precedence.

So url in $GIT_DIR/config is authoritative, and path in .gitmodules is
authoritative.




-- 
Ping Yin
--

[ message continues ]

Hi,


Literally the most common reason for a _different_ .gitmodules in an older 
revision is that the repository was moved to another machine.

In this case, your suggestion is actively wrong.

Ciao,
Dscho
--

[ message continues ]

On Wed, Apr 23, 2008 at 1:28 AM, Johannes Schindelin
Another common reason is the adjustment of repository directory in the
central environment
so i said *path*, not *url*. I agree what Josef said in the the
following reply: "It makes no sense to have submodule path
configuration in .git/config, as it has to be in sync with the current
commit". So it should be bettter to store path info only in
.gitmodules instead of $GIT_DIR/config


-- 
Ping Yin
--

[ message continues ]

The case that *path* changes is the submodule is moved to a new path
in some commit. But it is a very rare case.


-- 
Ping Yin
--

[ message continues ]

Hmm... At least, it can be very annoying when git fetches data from repositories
you did not expect, only because submodule URLs change via this
fallback mechanism. Perhaps it is a little far reached, but suppose a project
changes its URL, and the old one becomes occupied by a malicious person.
The problem is that the URL with the now malicious repository is bound in the
history of the project. For sure, you do not want to fetch from that old repository
by accident, after you did a checkout of an old commit. And there would be no
way to protect other people from this malicious repository other than rewriting

For me this sounds like: Now that we have made this bad decision, it does
not matter to make it even worse.

What was the motivation for this fallback mechanism?

In any way, it is preferable to always use the correct URL for submodules.
Thus, when the URL ever changes in the projects livetime (covered by
git history), you want to have the correct URL in your .git/config
(not to accidently use the wrong URL when checking out an old commit).

Of course. It makes no sense to have submodule path configuration in .git/config,
as it has to be in sync with the current commit. That has nothing to do with

No.
These are totally different types of configurations.

Josef


--

[ message continues ]

On Wed, Apr 23, 2008 at 2:07 AM, Josef Weidendorfer


I wonder how the *malicious* repository can hurt us since only the

I should be like: Now that we have made a bad decision (if it is), we
have to improve it to make life better before we can find a better

I havn't found yet how an incorrect URL can hurt us. The worst case i
can imagine is the failure of "git submodule update".

Two of the most common cases which can result in an incorrect/stale url is

 * the repository has been moved to another machine
 * the directory structure of upstream repositories has changed

However, there are also cases that the old version of url in
.gitmodules is correct.

Think about the case that the reposotory maintainer has decided to
replace current submodule with a totoally different one. In this case,
when back to the old HEAD, the url in .gitmodules is correct while url
in $GIT_DIR/config is incorrect.

So, when error happens, we can't judge which url is correct. So just
let the user make the decision by refering the change history of
.gitmodules or asking the repository maintainer.


-- 
Ping Yin
--

[ message continues ]

If one manages to hack on repository one can modify it enormous amount of 
ways, including spoofing on SHA (providing wrong contents for it - does 
git verify that when getting a pack?), utilizing bugs in git etc...

I doubt somebody would spend that much of an effort but you know,
you can not be paranoid *enough* :)

regards,
   Fedor.
--

[ message continues ]

Doable? I dunno.



-- 
Ping Yin
--

[ message continues ]

The pack transfer protocol does not transfer the SHA of objects, only the 
contents is transferred. The SHA-1 is (has to be since it is not sent) 
reconstructed on the receiving end.

-- robin

--

[ message continues ]

Thats nice. Then I agree its difficult to spoil superproject out of 
submodule other than it just does not checkout.

regards,
   Fedor.
--

[ message continues ]

About "git gc --auto", there was a patch sometime ago:

	[PATCH] commit: resurrect "gc --auto" at the end

http://marc.info/?l=git&m=120716427130606&w=2

Was it dropped?
--

[ message continues ]

In the thread, addition of an extra hook to "gc --auto" wasdiscussed.  It
was judged conditionally Ok as long as nobody assumes "gc --auto" is
ultra-cheap.  We used to have a "gc --auto" at the end of git-commit which
violated that condition, but we do not have that anymore.

The patch resurrects the behaviour that makes the extra hook possibly
unacceptable again, dosn't it?





--

[ message continues ]

Yes. I thought there was an unwanted change in behavior in git-commit.
Sorry for the noise.
--

[ message continues ]