What's in git.git (stable)

Together with fixes to pack-objects mode bits gotcha that caused
quite a traffic on the list this morning, and crlf conversion
bug from Alex, I've fast-tracked a few topics to 'master' tonight:

 - Nico's progress meter clean-up.
 - My custom diff driver in gitattributes series.

By "fast-track", I mean there might still be bugs in the code
but there do not seem to be anything contentious in the design,
and I trust the people who can fix possible breakages are
responsive.  I think "ident" attribute to expand "$ident$" in
blobs is probably less controversial as it is a stateless
transformation, but I left it out for now.

The tip of 'master' tonight is v1.5.2-rc0.  I am reasonably sure
that I have missed a few topics that we saw/reviewed patches for
the past several days.  Please do not get discouraged as I have
not necessarily rejected them; I was just busy whipping v1.5.1.2
and the 'master' branch into shape tonight.  Please discuss the
patches that are missing from tonight's 'master' for possible
inclusion in the coming few days, and then let's declare feature
freeze by the end of the week with v1.5.2-rc1.  After that, the
usual rules for stabilization period applies (no new features,
only fixes including documentation updates).

----------------------------------------------------------------

* The 'master' branch has these since the last announcement
  in addition to the above.

 Alex Riesen (2):
  Fix a typo in crlf conversion code
  Fix crash in t0020 (crlf conversion)

 Junio C Hamano (8):
  Update documentation links to point at v1.5.1.2
  Documentation/Makefile: fix section (5) installation
  Update draft release notes for v1.5.2
  pack-objects: quickfix for permission modes.
  Fix 'quickfix' on pack-objects.
  Update tests not to assume that generated packfiles are writable.
  pack-objects: make generated packfile read-only
  Support 'diff=pgm' attribute

 Martin Koegler (1):
  gitweb: Show "no difference" message for empty diff

 Nicolas Pitre (4):
  common progress display support
  make progress "title" part of the common progress interface
  provide a facility for "delayed" progress reporting
  delay progress display when checking out files

 Shawn O. Pearce (1):
  Cleanup variables in cat-file

We've accumulated quite a bit of fixes on 'maint', so I need to
do a 1.5.1.3 release soonish, as we will go into feature freeze
on 'master' shortly in preparation for 1.5.2.

On the 'master' front, things have been stabilizing.  Modulo
documentation updates and bugfixes, I expect what we have here
tonight will be pretty much what the final 1.5.2 would look
like.  I already know Shawn has plans to feed git-gui 0.6.6
updates, which should also be included in the final one.

But I might have missed or dismissed patches we have seen and
reviewed on the list recently that deserve to be in 1.5.2, so
please raise hand if you see something missing.  After that,
I'll tag v1.5.2-rc1 and from there we will do the usual "no new
features, options, commands -- only fixes", which hopefully will
happen on Monday.

----------------------------------------------------------------

* The 'maint' branch has these fixes since the last announcement.

 Adam Roben (3):
  Remove usernames from all commit messages, not just when using svmprops
  git-svn: Don't rely on $_ after making a function call
  git-svn: Ignore usernames in URLs in find_by_url

 Alex Riesen (1):
  Fix handle leak in write_tree

 Andrew Ruder (8):
  Removing -n option from git-diff-files documentation
  Document additional options for git-fetch
  Update git-fmt-merge documentation
  Update git-grep documentation
  Update -L documentation for git-blame/git-annotate
  Update git-http-push documentation
  Update git-local-fetch documentation
  Update git-http-fetch documentation

 Brian Gernhardt (2):
  Reverse the order of -b and --track in the man page.
  Ignore all man sections as they are generated files.

 Gerrit Pape (1):
  Documentation/git-reset.txt: suggest git commit --amend in example.

 Johannes Schindelin (1):
  dir.c(common_prefix): Fix two bugs

 Josh Triplett (2):
  Fix typo in git-am: s/Was is/Was it/
  Create a sysconfdir variable, and use it for ETC_GITCONFIG

 Junio C Hamano (3):
  Build RPM with ETC_GITCONFIG=/etc/gitconfig
  applymbox & quiltimport: typofix.
  Start preparing for 1.5.1.3

 Robin H. Johnson (10):
  Document --dry-run parameter to send-email.
  Prefix Dry- to the message status to denote dry-runs.
  Debugging cleanup improvements
  Change the scope of the $cc variable as it is not needed outside of send_message.
  Perform correct quoting of recipient names.
  Validate @recipients before using it for sendmail and Net::SMTP.
  Ensure clean addresses are always used with Net::SMTP
  Allow users to optionally specify their envelope sender.
  Document --dry-run and envelope-sender for git-send-email.
  Sanitize @to recipients.

 Shawn O. Pearce (1):
  Actually handle some-low memory conditions


* The 'master' branch has these since the last announcement
  in addition to the above.

 Alex Riesen (3):
  Avoid excessive rewrites in merge-recursive
  Add a test for merging changed and rename-changed branches
  Ignore merged status of the file-level merge

 Andy Parkins (3):
  post-receive-email example hook: fastforward should have been fast_forward
  post-receive-email example hook: detect rewind-only updates and output sensible message
  post-receive-email example hook: sed command for getting description was wrong

 Johannes Schindelin (1):
  t4201: Do not display weird characters on the terminal

 Josh Triplett (1):
  Add clean.requireForce option, and add -f option to git-clean to override it

 Junio C Hamano (9):
  Move index-related variables into a structure.
  Make read-cache.c "the_index" free.
  Document "diff=driver" attribute
  t5302: avoid using tail -c
  t6030: grab commit object name as we go
  Diff between two blobs should take mode changes into account now.
  t/test-lib.sh: Protect ourselves from common misconfiguration
  gitattributes documentation: clarify overriding
  Add --date={local,relative,default}

 Luiz Fernando N. Capitulino (5):
  remove_subtree(): Use strerror() when possible
  entry.c: Use const qualifier for 'struct checkout' parameters
  read_cache_from(): small simplification
  core-tutorial: minor fixes
  init_buffer(): Kill buf pointer

 Martin Koegler (5):
  Add S_IFINVALID mode
  add get_sha1_with_mode
  add add_object_array_with_mode
  store mode in rev_list, if <tree>:<filename> syntax is used
  use mode of the tree in git-diff, if <tree>:<file> syntax is used

 Nicolas Pitre (1):
  add file checkout progress

 OGAWA Hirofumi (1):
  git-fetch: Fix "argument list too long"

 Sami Farin (1):
  fast-import: size_t vs ssize_t

 Shawn O. Pearce (1):
  Don't repack existing objects in fast-import

 Uwe Kleine-König (1):
  fix importing of subversion tars

On Friday 2007 April 27, Junio C Hamano wrote:

We've accumulated quite a bit of fixes on 'maint', so I need to
do a 1.5.1.3 release soonish, as we will go into feature freeze
on 'master' shortly in preparation for 1.5.2.

I am still concerned about the submodule thing - once we push a mainline 
version out with the format decided, that will be that and we'll be stuck 
with it.  Are we _really_ sure that it's right to have a non-object hash in 
the tree objects?

It's a fundamental change in the form of the tree: at the moment every hash in 
the tree object represents another object in the same repository; with 
gitlink as it is, that convention is broken.

Let's be really, really sure.  I'm not sure a big enough fuss has been made of 
the fact that this is a change of repository format.  Before this you could 
pretty much access any repository with any version.


Andy
-- 
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com

On Fri, 27 Apr 2007, Andy Parkins wrote:

I am still concerned about the submodule thing - once we push a mainline 
version out with the format decided, that will be that and we'll be stuck 
with it.  Are we _really_ sure that it's right to have a non-object hash in 
the tree objects?

It's a fundamental change in the form of the tree: at the moment every hash in 
the tree object represents another object in the same repository; with 
gitlink as it is, that convention is broken.

Let's be really, really sure.  I'm not sure a big enough fuss has been made of 
the fact that this is a change of repository format.  Before this you could 
pretty much access any repository with any version.

I think it is reasonable to say that if you intend to work with a repo 
that contains references to submodules, then you need to upgrade your 
Git version.  It is not like if the Git licensing fees are really 
prohibitive.


Nicolas

On Friday 2007 April 27, Nicolas Pitre wrote:

I think it is reasonable to say that if you intend to work with a repo
that contains references to submodules, then you need to upgrade your
Git version.  It is not like if the Git licensing fees are really
prohibitive.

:-)  Absolutely.

The case I was thinking about was when the server hosting your project doesn't 
have submodule support and isn't under your direct control.  For example: 
kernel.org and repo.or.cz.  The same is true for those people for whom the IT 
department manage their central server, and aren't very helpful.

In those cases, that repository is being used as storage, it's bare, doesn't 
have an index and doesn't ever checkout the files.  If submodule support were 
capable of being stored (not checked out) by an older git, then people can 
use submodules merely if they have support on the client side.

There's also the distributions to think about - taking Debian as an example - 
a lot of people stick with stable only (especially for servers) - and stable 
is stuck with 1.4.4.4.  It's going to be a long time before a 
submodule-capable git hits Debian stable.



Andy

-- 
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com

On Fri, 27 Apr 2007, Andy Parkins wrote:

Let's be really, really sure.  I'm not sure a big enough fuss has been made of 
the fact that this is a change of repository format.  Before this you could 
pretty much access any repository with any version.

I'm personally really really sure. The whole point of subprojects (at 
least the way _I_ envisioned them) was to have them point to objects 
outside the same repository, so it's more than just an implementation 
detail, it's very much design.

And yes, of course we could have made it point to a blob inside the 
superproject, and have that blob then contain a SHA1 that old versions of 
git wouldn't have known to follow. But that would have been pretty hacky, 
and old versions of git would _still_ have had trouble with the new 
feature: at a minimum, git-fsck would always complain about the invalid 
mode (and things like "git diff" would too - I think it used to just die 
on unknown modes).

The "git-fsck/diff not working" thing might be seen as something that 
isn't important on the server side, but I think it ends up being critial, 
both for gitweb, and simply because I'd expect server side to want to 
verify the projects they export too. So I do think you'd want to have a 
recent git to support recent featurs.

So I think it boils down to: 
 - old git versions will obviously happily continue to  export all normal 
   repositories (including the submodules themselves).
 - but the actual supermodule support for embedding those submodules 
   really is a fundamentally new linkage, and if you want to use 
   supermodules, you have to have a recent enough git. Even if it's just 
   exporting them.
 - with 1.5.2, git will be good enough to _serve_ stuff, even if it might 
   not be very usable for the client-side operations. So especially since 
   there won't be a whole lot of users (due to the client limitations), I 
   think it's fine to expect a "sufficiently capable" git version if you 
   start serving subproject content.

But, yeah, this is just my personal view of sub/superproject support, and 
I've never actually _used_ it myself apart from my small test-repo thing.

		Linus

On Friday 2007, April 27, Linus Torvalds wrote:

I'm personally really really sure. The whole point of subprojects (at

Fair enough.  I just hadn't seen very much talk about this issue and 
wanted to make sure.

trouble with the new feature: at a minimum, git-fsck would always
complain about the invalid mode (and things like "git diff" would too
- I think it used to just die on unknown modes).

That kind of settles it really - if neither implementation would have 
worked with non-submodule git then the decision must come down to which 
is technically better - and I'm persuaded that the extra layer of 
indirection doesn't actually gain anything other than some extra 
objects to track.

 - with 1.5.2, git will be good enough to _serve_ stuff, even if it
might not be very usable for the client-side operations. So

From my point of view, I don't really mind manually fetching the 

submodules.  I very much appreciate that I don't _have_ to have the 
submodules for the superproject to continue to work.

I was actually surprised how little I'm finding I need submodule support 
in the porcelain.  The only slight problem at the moment is with 
git-checkout; switching from a branch with the supermodule to a branch 
without it and back needs a bit of hoop jumping, but nothing too 
painful.  All in all - success all over.


Andy

-- 
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com

On Fri, 27 Apr 2007, Andy Parkins wrote:

I was actually surprised how little I'm finding I need submodule support 
in the porcelain.  The only slight problem at the moment is with 
git-checkout; switching from a branch with the supermodule to a branch 
without it and back needs a bit of hoop jumping, but nothing too 
painful.  All in all - success all over.

Heh, good to hear, but I suspect your habits may differ from other 
peoples...

I agree that "git checkout" needs to have that .gitmodules thing. It 
should actually be fairly straightforward, although there are subtle 
issues (ie right now we can *atomically* say "cannot check out, it's 
dirty" - what happens when you've already checked out five subprojects, 
and the sixth one is dirty?).

"git diff --subprojects" is likely also something people will want, and 
that should be _reasonably_ straigtforward.

"git merge" is the big one. 

		Linus