[Announce] GIT v1.5.0-rc2

[Announce] GIT v1.5.0-rc2

[Junio C Hamano]

This hopefully is pretty much it for 1.5.0 modulo potential bugs
especially in newer topics.  Aside from many bugfixes, changes
since -rc1 are:

 - 'git log' is now reflog aware, and 'git show-branch' which
   knew about reflog already has become much more useful with
   reflogs.

 - the porcelain/ancillary/plumbing categorization in the git
   main documentation has been reviewed and updated.

 - merge and pull operations are much less chatty.

 - operation in a bare repositories is more pleasant.

 - the default file extension for format-patch output is .patch
   now.

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

Bob Proulx (1):
      git-revert: Fix die before git-sh-setup defines it.

Chris Wedgwood (1):
      cache.h; fix a couple of prototypes

David Kågedal (2):
      Shell syntax fix in git-reset
      Document --ignore-if-in-upstream in git-format-patch

Doug Maxey (1):
      gitk: add current directory to main window title

Eric Wong (2):
      git-svn: fix tests to work with older svn
      git-svn: print and flush authentication prompts to STDERR

Jason Riedy (4):
      Start all test scripts with /bin/sh.
      Set _ALL_SOURCE for AIX, but avoid its struct list.
      Replace "echo -n" with printf in shell scripts.
      Solaris 5.8 returns ENOTDIR for inappropriate renames.

Jeff King (1):
      git-pull: disallow implicit merging to detached HEAD

Johannes Schindelin (9):
      Fix spurious compile error
      config_set_multivar(): disallow newlines in keys
      show_date(): fix relative dates
      apply --cached: fix crash in subdirectory
      Do not verify filenames in a bare repository
      Teach the revision walker to walk by reflogs with --walk-reflogs
      --walk-reflogs: disallow uninteresting commits
      --walk-reflogs: actually find the right commit by date.
      --walk-reflogs: do not crash with cyclic reflog ancestry

Junio C Hamano (69):
      reflog-expire: brown paper bag fix.
      merge-recursive: do not report the resulting tree object name
      Explain "Not a git repository: '.git'".
      glossary typofix
      Make git-prune-packed a bit more chatty.
      Define cd_to_toplevel shell function in git-sh-setup
      Use cd_to_toplevel in scripts that implement it by hand.
      Allow whole-tree operations to be started from a subdirectory
      Use log output encoding in --pretty=email headers.
      t3901: test "format-patch | am" pipe with i18n
      git-commit documentation: -a adds and also removes
      Consistent message encoding while reusing log from an existing commit.
      More tests in t3901.
      git log documentation: teach -<n> form.
      Add describe test.
      Documentation: merge-output is not too verbose now.
      Use merge-recursive in git-revert/git-cherry-pick
      git reflog expire: document --stale-fix option.
      Fix git-fetch while on detached HEAD not to give needlessly alarming
        errors
      git-push documentation: remaining bits
      git-rm documentation: remove broken behaviour from the example.
      tutorial: shorthand for remotes but show distributed nature of git
      git-commit documentation: remove comment on unfixed git-rm
      Use merge-recursive in git-checkout -m (branch switching)
      Document where configuration files are in config.txt
      git-commit: document log message formatting convention
      Documentation/SubmittingPatches: Gnus tips
      Documentation/git-tag: the command can be used to also verify a tag.
      Documentation/git-tools.txt: mention tig and refer to wiki
      Documentation/git-tar-tree.txt: default umask is now 002
      Documentation/git-status.txt: mention color configuration
      Documentation/git-whatchanged.txt: show -<n> instead of --max-count.
      Documentation/git-sh-setup.txt: programmer's docs
      Documentation: detached HEAD
      Make a short-and-sweet "git-add -i" synonym for "git-add --interactive"
      Documentation: describe shallow repository
      Documentation/glossary.txt: unpacked objects are loose.
      Documentation/glossary.txt: describe remotes/ tracking and packed-refs
      Introduce 'git-format-patch --suffix=.patch'
      git-format-patch: do not crash with format.headers without value.
      Documentation/git-resolve: deprecated.
      Documentation: suggest corresponding Porcelain-level in plumbing docs.
      Documentation: m can be relative in "git-blame -Ln,m"
      Documentation/git-parse-remote.txt: we deal with config vars as well
      git-format-patch -3
      Add --summary to git-format-patch by default
      git-format-patch: make --binary on by default
      git-format-patch: the default suffix is now .patch, not .txt
      Use fixed-size integers for .idx file I/O
      Documentation: move command list in git.txt into separate files.
      Documentation: sync git.txt command list and manual page title
      Documentation: Generate command lists.
      for_each_reflog_ent: do not leak FILE *
      refs.c::read_ref_at(): fix bogus munmap() call.
      Documentation: generated cmds-*.txt does not depend on git.txt
      Documentation/git.txt: command re-classification
      dwim_ref(): Separate name-to-ref DWIM code out.
      Extend read_ref_at() to be usable from places other than sha1_name.
      show-branch --reflog: show the reflog message at the top.
      show-branch --reflog: tighten input validation.
      show-branch --reflog: fix show_date() call
      Stop ignoring Documentation/README
      git-tag -d: allow deleting multiple tags at once.
      branch -f: no reason to forbid updating the current branch in a
        bare repo.
      git-rebase: allow rebasing a detached HEAD.
      log --walk-reflog: documentation
      reflog-walk: build fixes
      Fix --walk-reflog with --pretty=oneline
      GIT v1.5.0-rc2

Linus Torvalds (2):
      Clean up write_in_full() users
      Fix up totally buggered read_or_die()

Matthias Lederhofer (2):
      prune-packed: add -q to usage
      prune: --grace=time

Michael S. Tsirkin (1):
      fix documentation for git-commit --no-verify

Nicolas Pitre (4):
      use 'init' instead of 'init-db' for shipped docs and tools
      simplify the "no changes added to commit" message
      some doc updates
      sanitize content of README file

Peter Baumann (1):
      Make gitk work when launched in a subdirectory

Quy Tonthat (1):
      git-remote: no longer silent on unknown commands.

René Scharfe (1):
      Documentation: a few spelling fixes

Santi Béjar (1):
      tutorial: Use only separate layout

Shawn O. Pearce (18):
      Improve merge performance by avoiding in-index merges.
      Hide output about SVN::Core not being found during tests.
      Remove read_or_die in favor of better error messages.
      Remove unnecessary call_depth parameter in merge-recursive.
      Allow the user to control the verbosity of merge-recursive.
      Enable output buffering in merge-recursive.
      Display a progress meter during merge-recursive.
      Convert output messages in merge-recursive to past tense.
      Always perfer annotated tags in git-describe.
      Hash tags by commit SHA1 in git-describe.
      Use binary searching on large buckets in git-describe.
      Improve git-describe performance by reducing revision listing.
      Correct priority of lightweight tags in git-describe.
      Remove hash in git-describe in favor of util slot.
      Use nice names in conflict markers during cherry-pick/revert.
      Document the master@{n} reflog query syntax.
      Refer users to git-rev-parse for revision specification syntax.
      Document pack .idx file format upgrade strategy.

Simon 'corecode' Schubert (2):
      Use fixed-size integers for the on-disk pack structure.
      Use standard -t option for touch.

Uwe Kleine-König (4):
      document --exec for git-push
      Update documentation of fetch-pack, push and send-pack
      make --exec=... option to git-push configurable
      rename --exec to --receive-pack for push and send-pack

Re: [Announce] GIT v1.5.0-rc2

[Jakub Narebski]

By the way, was the pager configured to saner values, so "git diff"
on a repository with no changes does not output empty page?

What about my Documentation/config.txt changes?
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: [Announce] GIT v1.5.0-rc2

[Junio C Hamano]

Jakub Narebski <jnareb@gmail.com> writes:

> By the way, was the pager configured to saner values, so "git diff"
> on a repository with no changes does not output empty page?

That's been set to the right way since commit 0abc0260 (October
22, 2006, v1.4.3.2~6) as far as I know.

> What about my Documentation/config.txt changes?

I was not sure about that one, given a lot of commentary in your
message, suggesting more research and revision is needed, like
these...

>>> +All the other lines are recognized as setting variables, in the form
>>> +'name = value'. If there is no equal sign on the line, the entire line
>>> +is taken as 'name' and the variable is recognized as boolean "true".
>>> +Variable names are case insensitive.
>> 
>> They cannot contain anything else than alphanumeric characters, in 
>> particular no whitespace.
>
> It is mentioned above "Syntax" section, but perhaps it should be repeated.
> I haven't took a look at code to check what values for section names and
> for key/variable names are allowed.
> ...
>> One thing that left me puzzled after reading the description was
>> what a user can do with "subsection".  It is unclear from the
>> description if [section "sub.section"], [section "sub.sec=ti.on"]
>> or worse yet, [section "sub\nsection with an embbedded LF"] are
>> allowed.  The rest seemed sane.
>
> I'm not sure what is allowed in section name, and in subsection name,
> so for now I have left it as is. I can amend this commit, or add new
> commit explaining this.

Re: [Announce] GIT v1.5.0-rc2

[Johannes Schindelin]

Hi,

On Sun, 21 Jan 2007, Jakub Narebski wrote:

> By the way, was the pager configured to saner values, so "git diff" on a 
> repository with no changes does not output empty page?

As Junio mentioned: it already does. Maybe you have set the environment 
variable "LESS", and forgot to include "-F"?

Hth,
Dscho

Re: [Announce] GIT v1.5.0-rc2

[Junio C Hamano]

BTW, as the upcoming v1.5.0 release will introduce quite a bit of
surface changes (although at the really core it still is the old
git and old ways should continue to work), I am wondering if it
would help people to try out and find wrinkles before the real
thing for me to cut a tarball and a set of RPM packages.

Comments?

Also, in the same spirit of giving the release an early
exposure, here is the current draft of 1.5.0 release notes.

-- >8 -- cut here -- >8 --

GIT v1.5.0 Release Notes (draft)
================================

Old news
--------

This section is for people who are upgrading from ancient
versions of git.  Although all of the changes in this section
happened before the current v1.4.4 release, they are summarized
here in the v1.5.0 release notes for people who skipped earlier
versions.

In general, you should not have to worry about incompatibility,
and there is no need to perform "repository conversion" if you
are updating to v1.5.0.  However, some of the changes are
one-way street upgrades; once you use them your repository
can no longer be used with ancient git.

 - There is a configuration variable core.legacyheaders that
   changes the format of loose objects so that they are more
   efficient to pack and to send out of the repository over git
   native protocol, since v1.4.2.  However, loose objects
   written in the new format cannot be read by git older than
   that version; people fetching from your repository using
   older clients over dumb transports (e.g. http) using older
   versions of git will also be affected.

 - Since v1.4.3, configuration repack.usedeltabaseoffset allows
   packfile to be created in more space efficient format, which
   cannot be read by git older than that version.

The above two are not enabled by default and you explicitly have
to ask for them, because these two features make repositories
unreadable by older versions of git, and in v1.5.0 we still do
not enable them by default for the same reason.  We will change
this default probably 1 year after 1.4.2's release, when it is
reasonable to expect everybody to have new enough version of
git.

 - 'git pack-refs' appeared in v1.4.4; this command allows tags
   to be accessed much more efficiently than the traditional
   'one-file-per-tag' format.  Older git-native clients can
   still fetch from a repository that packed and pruned refs
   (the server side needs to run the up-to-date version of git),
   but older dumb transports cannot.  Packing of refs is done by
   an explicit user action, either by use of "git pack-refs
   --prune" command or by use of "git gc" command.

 - 'git -p' to paginate anything -- many commands do pagination
   by default on a tty.  Introduced between v1.4.1 and v1.4.2;
   this may surprise old timers.

 - 'git archive' superseded 'git tar-tree' in v1.4.3;

 - 'git cvsserver' was new invention in v1.3.0;

 - 'git repo-config', 'git grep', 'git rebase' and 'gitk' were
   seriously enhanced during v1.4.0 timeperiod.

 - 'gitweb' became part of git.git during v1.4.0 timeperiod and
   seriously modified since then.

 - reflog is an v1.4.0 invention.  This allows you to name a
   revision that a branch used to be at (e.g. "git diff
   master@{yesterday} master" allows you to see changes since
   yesterday's tip of the branch).


Updates in v1.5.0 since v1.4.4 series
-------------------------------------

* Index manipulation

 - git-add is to add contents to the index (aka "staging area"
   for the next commit), whether the file the contents happen to
   be is an existing one or a newly created one.

 - git-add without any argument does not add everything
   anymore.  Use 'git-add .' instead.  Also you can add
   otherwise ignored files with an -f option.

 - git-add tries to be more friendly to users by offering an
   interactive mode.

 - git-commit <path> used to refuse to commit if <path> was
   different between HEAD and the index (i.e. update-index was
   used on it earlier).  This check was removed.

 - git-rm is much saner and safer.  It is used to remove paths
   from both the index file and the working tree, and makes sure
   you are not losing any local modification before doing so.

 - git-reset <tree> <paths>... can be used to revert index
   entries for selected paths.

 - git-update-index is much less visible.


* Repository layout and objects transfer

 - The data for origin repository is stored in the configuration
   file $GIT_DIR/config, not in $GIT_DIR/remotes/, for newly
   created clones.  The latter is still supported and there is
   no need to convert your existing repository if you are
   already comfortable with your workflow with the layout.

 - git-clone always uses what is known as "separate remote"
   layout for a newly created repository with a working tree;
   i.e. tracking branches in $GIT_DIR/refs/remotes/origin/ are
   used to track branches from the origin.  

 - New branches that appear on the origin side after a clone is
   made are also tracked automatically.  This is done with an
   wildcard refspec "refs/heads/*:refs/remotes/origin/*", which
   older git does not understand, so if you clone with 1.5.0,
   you would need to downgrade remote.*.fetch in the
   configuration file to specify each branch you are interested
   in individually if you plan to fetch into the repository with
   older versions of git (but why would you?).

 - git-branch and git-show-branch know remote tracking branches.

 - git-push can now be used to delete a remote branch or a tag.
   This requires the updated git on the remote side.

 - git-push more agressively keeps the transferred objects
   packed.  Earlier we recommended to monitor amount of loose
   objects and repack regularly, but you should repack when you
   accumulated too many small packs this way as well.  Updated
   git-count-objects helps you with this.

 - A new command, git-remote, can help you manage your remote
   tracking branch definitions.


* Bare repositories

 - Certain commands change their behaviour in a bare repository
   (i.e. a repository without associated working tree).  We use
   a fairly conservative heuristic (if $GIT_DIR is ".git", or
   ends with "/.git", the repository is not bare) to decide if a
   repository is bare, but "core.bare" configuration variable
   can be used to override the heuristic when it misidentifies
   your repository.

 - git-fetch used to complain updating the current branch but
   this is now allowed for a bare repository.  So is the use of
   'git-branch -f' to update the current branch.

 - Porcelain-ish commands that require a working tree refuses to
   work in a bare repository.


* Reflog

 - Reflog records the history of where the tip of each branch
   was at each moment.  This facility is enabled by default for
   repositories with working trees, and can be accessed with the
   "branch@{time}" and "branch@{Nth}" notation.

 - "git show-branch" learned showing the reflog data with the
   new --reflog option.  "git log" has --walk-reflogs option to
   view reflog entries in a more verbose manner.

 - git-branch knows how to rename branches and moves existing
   reflog data from the old branch to the new one.

 - The commits referred to by reflog entries are now protected
   against pruning.  The new command "git reflog expire" can be
   used to truncate older reflog entries and entries that refer
   to commits that have been pruned away previously with older
   versions of git.

   Existing repositories that have been using reflog may get
   complaints from fsck-objects and may not be able to run
   git-repack, if you had run git-prune from older git; please
   run "git reflog expire --stale-fix --all" first to remove
   reflog entries that refer to commits that are no longer in
   the repository when that happens.


* Crufts removal

 - We used to say "old commits are retrievable using reflog and
   'master@{yesterday}' syntax as long as you haven't run
   git-prune".  We no longer have to say the latter half of the
   above sentence, as git-prune does not remove things reachable
   from reflog entries.

 - 'git-prune' by default does not remove _everything_
   unreachable, as there is a one-day grace period built-in.

 - There is a toplevel garbage collector script, 'git-gc', that
   is an easy way to run 'git-repack -a -d', 'git-reflog gc',
   and 'git-prune'.


* Detached HEAD

 - You can give non-branch to "git checkout" now.  This will
   dissociate your HEAD from any of your branches.  A typical
   use of this feature is to "look around".  E.g.

	$ git checkout v2.6.16
	... compile, test, etc.
	$ git checkout v2.6.17
	... compile, test, etc.

 - After detaching your HEAD, you can go back to an existing
   branch with usual "git checkout $branch".  Also you can
   start a new branch using "git checkout -b $newbranch".

 - You can even pull from other repositories, make merges and
   commits while your HEAD is detached.  Also you can use "git
   reset" to jump to arbitrary commit.

   Going back to undetached state by "git checkout $branch" can
   lose the current stat you arrived in these ways, and "git
   checkout" refuses when the detached HEAD is not pointed by
   any existing ref (an existing branch, a remote tracking
   branch or a tag).  This safety can be overriden with "git
   checkout -f $branch".


* Packed refs

 - Repositories with hundreds of tags have been paying large
   overhead, both in storage and in runtime, due to the
   traditional one-ref-per-file format.  A new command,
   git-pack-refs, can be used to "pack" them in more efficient
   representation.

 - Clones and fetches over dumb transports are now aware of
   packed refs and can download from repositories that use
   them.


* Configuration

 - configuration related to color setting are consolidated under
   color.* namespace (older diff.color.*, status.color.* are
   still supported).


* Less external dependency

 - We no longer require the "merge" program from the RCS suite.
   All 3-way file-level merges are now done internally.

 - The original implementation of git-merge-recursive which was
   in Python has been removed; we have C implementation of it
   now.

 - git-shortlog is no longer a Perl script.  It no longer
   requires output piped from git-log; it can accept revision
   parameters directly on the command line.


* I18n

 - We have always encouraged the commit message to be encoded in
   UTF-8, but the users are allowed to use legacy encoding as
   appropriate for their projects.  This will continue to be the
   case.  However, a non UTF-8 commit encoding _must_ be
   explicitly set with i18n.commitencoding in the repository
   where a commit is made; otherwise git-commit-tree will
   complain if the log message does not look like a valid UTF-8
   string.

 - The value of i18n.commitencoding in the originating
   repository is recorded in the commit object on the "encoding"
   header, if it is not UTF-8.  git-log and friends notice this,
   and reencodes the message to the log output encoding when
   displaying, if they are different.  The log output encoding
   is determined by "git log --encoding=<encoding>",
   i18n.logoutputencoding configuration, or i18n.commitencoding
   configuration, in the decreasing order of preference, and
   defaults to UTF-8. 

 - Tools for e-mailed patch application now default to -u
   behaviour; i.e. it always re-codes from the e-mailed encoding
   to the encoding specified with i18n.commitencoding.  This
   unfortunately forces projects that have happily been using a
   legacy encoding without setting i18n.commitencoding to set
   the configuration, but taken with other improvement, please
   excuse us for this very minor one-time inconvenience.


* e-mailed patches

 - See the above I18n section.

 - git-format-patch now enables --binary without being asked.
   git-am does _not_ default to it, as sending binary patch via
   e-mail is unusual and is harder to review than textual
   patches and it is prudent to require the person who is
   applying the patch to explicitly ask for it.

 - The default suffix for git-format-patch output is now ".patch",
   not ".txt".  This can be changed with --suffix=.txt option,
   or "format.suffix = .txt" in the configuration.


* Foreign SCM interfaces

  - git-svn now requires the Perl SVN:: libraries, the
    command-line backend was too slow and limited.

  - the 'commit' subcommand of git-svn has been renamed to
    'set-tree', and 'dcommit' is the recommended replacement for
    day-to-day work.


* User support

 - Quite a lot of documentation updates.

 - Bash completion scripts have been updated heavily.

 - Better error messages for often used Porcelainish commands.


* Sliding mmap

 - We used to assume that we can mmap the whole packfile while
   in use, but with a large project this consumes huge virtual
   memory space and truly huge ones would not fit in the
   userland address space on 32-bit platforms.  We now mmap huge
   packfile in pieces to avoid this problem.


* Shallow clones

 - There is a partial support for 'shallow' repositories that
   keeps only recent history.  A 'shallow clone' is created by
   specifying how deep that truncated history should be.

   Currently a shallow repository has number of limitations:

   - Cloning and fetching _from_ a shallow clone are not
     supported (nor tested -- so they might work by accident but
     they are not expected to).

   - Pushing from nor into a shallow clone are not expected to
     work.

   - Merging inside a shallow repository would work as long as a
     merge base is found in the recent history, but otherwise it
     will be like merging unrelated histories and may result in
     huge conflicts.

   but this would be more than adequate for people who want to
   look at near the tip of a big project with a deep history and
   send patches in e-mail format.

Re: [Announce] GIT v1.5.0-rc2

[Bill Lear]

On Sunday, January 21, 2007 at 03:20:06 (-0800) Junio C Hamano writes:
>BTW, as the upcoming v1.5.0 release will introduce quite a bit of
>surface changes (although at the really core it still is the old
>git and old ways should continue to work), I am wondering if it
>would help people to try out and find wrinkles before the real
>thing for me to cut a tarball and a set of RPM packages.
>
>Comments?

I asked this in the context of the "fatal: protocol error"
thread, but can I install the 1.5.0rcX on my machine and use
it with our company repository, running 1.4.4.1?

In any case, I think trying to find wrinkles before the real
thing is certainly healthy.


Bill

Re: [Announce] GIT v1.5.0-rc2

[Willy Tarreau]

Hi Junio !

On Sun, Jan 21, 2007 at 03:20:06AM -0800, Junio C Hamano wrote:
> BTW, as the upcoming v1.5.0 release will introduce quite a bit of
> surface changes (although at the really core it still is the old
> git and old ways should continue to work), I am wondering if it
> would help people to try out and find wrinkles before the real
> thing for me to cut a tarball and a set of RPM packages.
> 
> Comments?

Anything you can do to make tester's life easier will always slightly
increase the number of testers. Hint: how often do you try random
software that requires that you first install CVS, SVN or arch just to
get it, compared to how often you try random software provided as tar.gz ?
Pre-release tar.gz and rpms coupled with a freshmeat announcement should
get you a bunch of testers and newcomers. This will give the new doc a
real trial, and will help discover traps in which beginners often fall.

> Also, in the same spirit of giving the release an early
> exposure, here is the current draft of 1.5.0 release notes.

(...)

>  - There is a configuration variable core.legacyheaders that
>    changes the format of loose objects so that they are more
>    efficient to pack and to send out of the repository over git
>    native protocol, since v1.4.2.  However, loose objects
>    written in the new format cannot be read by git older than
>    that version; people fetching from your repository using
>    older clients over dumb transports (e.g. http) using older
>    versions of git will also be affected.
> 
>  - Since v1.4.3, configuration repack.usedeltabaseoffset allows
>    packfile to be created in more space efficient format, which
>    cannot be read by git older than that version.

I know it's a bit late to ask, but if new on-disk format changes, isn't
it time to bump the version to 2.0 ? It would be easier for many people to
remember that GIT 1.X uses format version 1 and that GIT 2.X uses format
version 2 with backwards compatibility with 1.X. I also think that 1.5
is much more different from 1.0 than a mid-term 2.0 would be from current
1.5.

That said, kudos for the nice changelog !

Regards,
Willy

Re: [Announce] GIT v1.5.0-rc2

[Bill Lear]

Also (apologies for the ignorance), how do I get the 1.5.0-rc2 release?


Bill

On Sunday, January 21, 2007 at 07:42:56 (-0600) Bill Lear writes:
>On Sunday, January 21, 2007 at 03:20:06 (-0800) Junio C Hamano writes:
>>BTW, as the upcoming v1.5.0 release will introduce quite a bit of
>>surface changes (although at the really core it still is the old
>>git and old ways should continue to work), I am wondering if it
>>would help people to try out and find wrinkles before the real
>>thing for me to cut a tarball and a set of RPM packages.
>>
>>Comments?
>
>I asked this in the context of the "fatal: protocol error"
>thread, but can I install the 1.5.0rcX on my machine and use
>it with our company repository, running 1.4.4.1?
>
>In any case, I think trying to find wrinkles before the real
>thing is certainly healthy.
>
>
>Bill
>-
>To unsubscribe from this list: send the line "unsubscribe git" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Announce] GIT v1.5.0-rc2

[Michael]

Bill Lear:
> Also (apologies for the ignorance), how do I get the 1.5.0-rc2 release?

git clone git://git.kernel.org/pub/scm/git/git.git

Then checkout the commit tagged 'v1.5.0-rc2'.

There are no such tarballs (yet) on:

http://www.kernel.org/pub/software/scm/git/

Re: [Announce] GIT v1.5.0-rc2

[Jakub Narebski]

Willy Tarreau wrote:
> On Sun, Jan 21, 2007 at 03:20:06AM -0800, Junio C Hamano wrote:

>> BTW, as the upcoming v1.5.0 release will introduce quite a bit of
>> surface changes (although at the really core it still is the old
>> git and old ways should continue to work), I am wondering if it
>> would help people to try out and find wrinkles before the real
>> thing for me to cut a tarball and a set of RPM packages.
>> 
>> Comments?
> 
> Anything you can do to make tester's life easier will always slightly
> increase the number of testers. Hint: how often do you try random
> software that requires that you first install CVS, SVN or arch just to
> get it, compared to how often you try random software provided as tar.gz ?
> Pre-release tar.gz and rpms coupled with a freshmeat announcement should
> get you a bunch of testers and newcomers. This will give the new doc a
> real trial, and will help discover traps in which beginners often fall.

RPMS are nicely divided into (sub)packages, so you need CVS indtalled
only if you install git-cvs package, for example to interact with CVS.
git-core has minimal dependencies.

To compile git you truly don't need other software installed (1.5.0
for example does not require RCS anymore for RCS merge).
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: [Announce] GIT v1.5.0-rc2

[Jakub Narebski]

Willy Tarreau wrote:
> On Sun, Jan 21, 2007 at 03:20:06AM -0800, Junio C Hamano wrote:

>> BTW, as the upcoming v1.5.0 release will introduce quite a bit of
>> surface changes (although at the really core it still is the old
>> git and old ways should continue to work), I am wondering if it
>> would help people to try out and find wrinkles before the real
>> thing for me to cut a tarball and a set of RPM packages.
>> 
>> Comments?
> 
> Anything you can do to make tester's life easier will always slightly
> increase the number of testers. Hint: how often do you try random
> software that requires that you first install CVS, SVN or arch just to
> get it, compared to how often you try random software provided as tar.gz ?
> Pre-release tar.gz and rpms coupled with a freshmeat announcement should
> get you a bunch of testers and newcomers. This will give the new doc a
> real trial, and will help discover traps in which beginners often fall.

RPMS are nicely divided into (sub)packages, so you need CVS indtalled
only if you install git-cvs package, for example to interact with CVS.
git-core has minimal dependencies.

To compile git you truly don't need other software installed (1.5.0
for example does not require RCS anymore for RCS merge).
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: [Announce] GIT v1.5.0-rc2

[Junio C Hamano]

Willy Tarreau <w@1wt.eu> writes:

> Anything you can do to make tester's life easier will always slightly
> increase the number of testers.
> ...
> Pre-release tar.gz and rpms coupled with a freshmeat announcement should
> get you a bunch of testers and newcomers. This will give the new doc a
> real trial, and will help discover traps in which beginners often fall.

One worry I had about releasing git-1.5.0-rc2-1.rpm and friends
just like the "official" ones was that people might have scripts
to automate downloading & updating of packages, and they may not
like to get "beta" installed for them.

I wonder if kernel.org machines are also affected...

>> Also, in the same spirit of giving the release an early
>> exposure, here is the current draft of 1.5.0 release notes.
>
> (...)
>
>>  - There is a configuration variable core.legacyheaders that
>>    changes the format of loose objects so that they are more
>>    efficient to pack and to send out of the repository over git
>>    native protocol, since v1.4.2.  However, loose objects
>>    written in the new format cannot be read by git older than
>>    that version; people fetching from your repository using
>>    older clients over dumb transports (e.g. http) using older
>>    versions of git will also be affected.
>> 
>>  - Since v1.4.3, configuration repack.usedeltabaseoffset allows
>>    packfile to be created in more space efficient format, which
>>    cannot be read by git older than that version.
>
> I know it's a bit late to ask, but if new on-disk format changes, isn't
> it time to bump the version to 2.0? It would be easier for many people to
> remember that GIT 1.X uses format version 1 and that GIT 2.X uses format
> version 2 with backwards compatibility with 1.X. I also think that 1.5
> is much more different from 1.0 than a mid-term 2.0 would be from current
> 1.5.

I think we could have gone either way (as you said, it is
probably a bit too late to discuss this), but it should probably
be Ok to stay at 1.X as long as these one-way-street format
updates are turned off by default.

And the above happened way before this round and people have
hopefully been happily using.  For example, v1.4.2 was done
early August 2006.

Re: [Announce] GIT v1.5.0-rc2

[Horst H. von Brand]

Junio C Hamano <junkio@cox.net> wrote:
> BTW, as the upcoming v1.5.0 release will introduce quite a bit of
> surface changes (although at the really core it still is the old
> git and old ways should continue to work), I am wondering if it
> would help people to try out and find wrinkles before the real
> thing for me to cut a tarball and a set of RPM packages.
> 
> Comments?
> 
> Also, in the same spirit of giving the release an early
> exposure, here is the current draft of 1.5.0 release notes.
> 
> -- >8 -- cut here -- >8 --
> 
> GIT v1.5.0 Release Notes (draft)
> ================================
> 
> Old news
> --------

[...]

>  - There is a configuration variable core.legacyheaders that
>    changes the format of loose objects so that they are more
>    efficient to pack and to send out of the repository over git
>    native protocol, since v1.4.2.  However, loose objects
>    written in the new format cannot be read by git older than
>    that version; people fetching from your repository using
>    older clients over dumb transports (e.g. http) using older
>    versions of git will also be affected.

Huh?

What are possible values of that variable? What happens if it is set/unset?
I'd suppose that if it is set, you get the old format, but that isn't clear.

>  - Since v1.4.3, configuration repack.usedeltabaseoffset allows
>    packfile to be created in more space efficient format, which
>    cannot be read by git older than that version.

Same as above.

> The above two are not enabled by default and you explicitly have
> to ask for them, because these two features make repositories
> unreadable by older versions of git, and in v1.5.0 we still do
> not enable them by default for the same reason.  We will change
> this default probably 1 year after 1.4.2's release, when it is
> reasonable to expect everybody to have new enough version of
> git.

I don't see an upgrade path here that doesn't involve keeping cruft "new
feature is on" variables around indefinitely... Why not just a repository
version?

[...]

> Updates in v1.5.0 since v1.4.4 series
> -------------------------------------
> 
> * Index manipulation

[...]

>  - git-add without any argument does not add everything
>    anymore.  Use 'git-add .' instead.  Also you can add
>    otherwise ignored files with an -f option.

I suppose "git add ." works for 'adding everything' only at the top?

>  - git-add tries to be more friendly to users by offering an
>    interactive mode.

Why not tell about "git add -i"?

[...]

> * Detached HEAD

[...]

>  - After detaching your HEAD, you can go back to an existing
>    branch with usual "git checkout $branch".  Also you can
>    start a new branch using "git checkout -b $newbranch".

Where is such a branch rooted?

>  - You can even pull from other repositories, make merges and
>    commits while your HEAD is detached.  Also you can use "git
>    reset" to jump to arbitrary commit.

Does this leave you on that branch, or still in limbo?

>    Going back to undetached state by "git checkout $branch" can

s/undetached/attached/

>    lose the current stat you arrived in these ways, and "git
>    checkout" refuses when the detached HEAD is not pointed by
>    any existing ref (an existing branch, a remote tracking
>    branch or a tag).  This safety can be overriden with "git
>    checkout -f $branch".

What happens if there are changes in the tracked files?

[...]

> * Shallow clones
> 
>  - There is a partial support for 'shallow' repositories that
>    keeps only recent history.  A 'shallow clone' is created by
>    specifying how deep that truncated history should be.

A bit of detail on how to specify shallowness would be nice here...


Very nice work, thanks!
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria             +56 32 2654239
Casilla 110-V, Valparaiso, Chile               Fax:  +56 32 2797513

Re: [Announce] GIT v1.5.0-rc2

[H. Peter Anvin]

Junio C Hamano wrote:
> 
> One worry I had about releasing git-1.5.0-rc2-1.rpm and friends
> just like the "official" ones was that people might have scripts
> to automate downloading & updating of packages, and they may not
> like to get "beta" installed for them.
> 
> I wonder if kernel.org machines are also affected...
> 

Put them in a different directory hierarchy if you don't want to make 
them installed.

>> I know it's a bit late to ask, but if new on-disk format changes, isn't
>> it time to bump the version to 2.0? It would be easier for many people to
>> remember that GIT 1.X uses format version 1 and that GIT 2.X uses format
>> version 2 with backwards compatibility with 1.X. I also think that 1.5
>> is much more different from 1.0 than a mid-term 2.0 would be from current
>> 1.5.
> 
> I think we could have gone either way (as you said, it is
> probably a bit too late to discuss this), but it should probably
> be Ok to stay at 1.X as long as these one-way-street format
> updates are turned off by default.
> 
> And the above happened way before this round and people have
> hopefully been happily using.  For example, v1.4.2 was done
> early August 2006.

In general, though, I would agree that the major number should change if 
there is an incompatible change.

	-hpa

Re: [Announce] GIT v1.5.0-rc2

[Horst H. von Brand]

Junio C Hamano <junkio@cox.net> wrote:
> Willy Tarreau <w@1wt.eu> writes:
> > Anything you can do to make tester's life easier will always slightly
> > increase the number of testers.
> > ...
> > Pre-release tar.gz and rpms coupled with a freshmeat announcement should
> > get you a bunch of testers and newcomers. This will give the new doc a
> > real trial, and will help discover traps in which beginners often fall.
> 
> One worry I had about releasing git-1.5.0-rc2-1.rpm and friends
> just like the "official" ones was that people might have scripts
> to automate downloading & updating of packages, and they may not
> like to get "beta" installed for them.

Then put them into a "testing" or "pre-release" directory...
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria             +56 32 2654239
Casilla 110-V, Valparaiso, Chile               Fax:  +56 32 2797513

Re: [Announce] GIT v1.5.0-rc2

[Junio C Hamano]

"Horst H. von Brand" <vonbrand@inf.utfsm.cl> writes:

> What are possible values of that variable? What happens if it is set/unset?
> I'd suppose that if it is set, you get the old format, but that isn't clear.

All are valid questions, but the release notes will be too long
if it made into "migration manual plus full documentation of new
features".  Its purpose is to list things you would want to pay
attention to.

> ...
> I don't see an upgrade path here that doesn't involve keeping cruft "new
> feature is on" variables around indefinitely...

The new feature will be on regardless of the configuration at
some point, perhaps in GIT 2.0.  For now it isn't, and that is
another reason the release notes do not have to (and probably
should not for the sake of brevity) talk about gory details to
turn the feature on.  If we were to do the feature in
"incompatible by default" way, the release notes should talk
about how to turn it off and keep the old way.

>>  - git-add tries to be more friendly to users by offering an
>>    interactive mode.
>
> Why not tell about "git add -i"?

Thanks, will update.  s/mode\.$/mode ("git-add -i")./

>>  - After detaching your HEAD, you can go back to an existing
>>    branch with usual "git checkout $branch".  Also you can
>>    start a new branch using "git checkout -b $newbranch".
>
> Where is such a branch rooted?

I did not think it needs to be mentioned as "git checkout -b
$newbranch" has always been "git checkout -b $newbranch HEAD"
and this is not changed with detached HEAD.  Maybe I should add
"... to start a new branch at that commit" at the end of the
sentence.  Thanks.

>>  - You can even pull from other repositories, make merges and
>>    commits while your HEAD is detached.  Also you can use "git
>>    reset" to jump to arbitrary commit.
>
> Does this leave you on that branch, or still in limbo?

Perhaps "s/\.$/, while still keeping your HEAD detached./".
Will update.

>>    lose the current stat you arrived in these ways, and "git
>>    checkout" refuses when the detached HEAD is not pointed by
>>    any existing ref (an existing branch, a remote tracking
>>    branch or a tag).  This safety can be overriden with "git
>>    checkout -f $branch".
>
> What happens if there are changes in the tracked files?

The answer is "just like normal checkout does", but I think that
level of detail does not belong to the release notes.  The list
of features is meant to be just to introduce what new things
there are, and people interested should learn the details from
the documentation.

> A bit of detail on how to specify shallowness would be nice here...

The same comment as the above applies here.

Re: [Announce] GIT v1.5.0-rc2

[Johannes Schindelin]

Hi,

On Sun, 21 Jan 2007, Bill Lear wrote:

> Also (apologies for the ignorance), how do I get the 1.5.0-rc2 release?

Direct your browser to

http://repo.or.cz/w/git.git?a=snapshot;h=eaf6459e4d482af51429f9464125621b805eb5f

BTW please don't top post. It uses bandwidth unnecessarily (both in terms 
of megabytes and attention).

Ciao,
Dscho

Re: [Announce] GIT v1.5.0-rc2

[Jakub Narebski]

Johannes Schindelin wrote:

> On Sun, 21 Jan 2007, Bill Lear wrote:
> 
>> Also (apologies for the ignorance), how do I get the 1.5.0-rc2 release?
> 
> Direct your browser to
> 
> http://repo.or.cz/w/git.git?a=snapshot;h=eaf6459e4d482af51429f9464125621b805eb5f

Better URL is

  http://repo.or.cz/w/git.git?a=snapshot;h=v1.5.0-rc2

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: [Announce] GIT v1.5.0-rc2

[Jakub Narebski]

Johannes Schindelin wrote:

> On Sun, 21 Jan 2007, Bill Lear wrote:
> 
>> Also (apologies for the ignorance), how do I get the 1.5.0-rc2 release?
> 
> Direct your browser to
> 
> http://repo.or.cz/w/git.git?a=snapshot;h=eaf6459e4d482af51429f9464125621b805eb5f

Better URL is

  http://repo.or.cz/w/git.git?a=snapshot;h=v1.5.0-rc2

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: [Announce] GIT v1.5.0-rc2

[Johannes Schindelin]

Hi,

On Sun, 21 Jan 2007, Junio C Hamano wrote:

>  - 'git pack-refs' appeared in v1.4.4;

You should probably mention that it is not necessary to run git-pack-refs 
by hand: git-gc is what you want.

BTW have I praised y'all for inventing git-gc? It is _awesome_. I think I 
will turn into a DWIM geek yet; it is soooo much more convenient to issue 
"git gc" from time to time, than to think exactly about what I want to 
clean up right now.

>  - 'git repo-config', 'git grep', 'git rebase' and 'gitk' were
>    seriously enhanced during v1.4.0 timeperiod.

Should we introduce "git config" in time for the "let's please end-users" 
release (1.5.0)?

>  - git-clone always uses what is known as "separate remote"
>    layout for a newly created repository with a working tree;
>    i.e. tracking branches in $GIT_DIR/refs/remotes/origin/ are
>    used to track branches from the origin.  

... instead of $GIT_DIR/refs/heads/, making the difference between 
remotely tracked and local branches more obvious.

>  - git-branch and git-show-branch know remote tracking branches.

... (use the command line switch "-r" to list only tracked branches.)

>  - git-push can now be used to delete a remote branch or a tag.
>    This requires the updated git on the remote side.

... (use "git push <remote> :refs/heads/<branch>" to delete "branch".)

>  - git-push more agressively keeps the transferred objects
>    packed.  Earlier we recommended to monitor amount of loose
>    objects and repack regularly, but you should repack when you
>    accumulated too many small packs this way as well.  Updated
>    git-count-objects helps you with this.

It might make sense to enable something similar for git-fetch in time for 
1.5.0.

> * Reflog
> 
>  - Reflog records the history of where the tip of each branch
>    was at each moment.

It might make sense to reformulate that:

	Reflog records the history from the view point of the local 
	repository. In other words, regardless of the real history,
	the reflog shows the history as seen by one particular repository
	(this enables you to ask "what was the current revision in _this_
	repository, yesterday at 1pm?").

>  - There is a toplevel garbage collector script, 'git-gc', that
>    is an easy way to run 'git-repack -a -d', 'git-reflog gc',
>    and 'git-prune'.

Did I mention that I really _love_ git-gc?

>  - The original implementation of git-merge-recursive which was
>    in Python has been removed; we have C implementation of it
>    now.

I am no native speaker, but should that not be "we have a C 
implementation" instead?

>  - The default suffix for git-format-patch output is now ".patch",
>    not ".txt".  This can be changed with --suffix=.txt option,
>    or "format.suffix = .txt" in the configuration.

I fully expect people to complain that a config like this

	format.suffix = .txt

does not work. better say ...

	or setting the config variable "format.suffix" to ".txt".

>  - Better error messages for often used Porcelainish commands.

Amen. I think this really helped a lot of people already.

>    - Cloning and fetching _from_ a shallow clone are not
>      supported (nor tested -- so they might work by accident but
>      they are not expected to).

Maybe we should go the "restrict first, and loosen later" approach? I.e. 
forbid git-upload-pack to run if is_repository_shallow()?

>    - Pushing from nor into a shallow clone are not expected to
>      work.

Maybe forbid git-push and git-receive-pack to run if 
is_repository_shallow()?

(I _think_ git-push should be safe, but not git-receive-pack.)

Ciao,
Dscho

Re: [Announce] GIT v1.5.0-rc2

[Johannes Schindelin]

Hi,

On Sun, 21 Jan 2007, Jakub Narebski wrote:

> Johannes Schindelin wrote:
> 
> > On Sun, 21 Jan 2007, Bill Lear wrote:
> > 
> >> Also (apologies for the ignorance), how do I get the 1.5.0-rc2 release?
> > 
> > Direct your browser to
> > 
> > http://repo.or.cz/w/git.git?a=snapshot;h=eaf6459e4d482af51429f9464125621b805eb5f
> 
> Better URL is
> 
>   http://repo.or.cz/w/git.git?a=snapshot;h=v1.5.0-rc2

It is a better URL. Somehow I fscked up when I tried it, so I had the 
impression that does not work. But it does.

Sorry,
Dscho

Re: [Announce] GIT v1.5.0-rc2

[Jakub Narebski]

Johannes Schindelin wrote:
> On Sun, 21 Jan 2007, Jakub Narebski wrote:
>> Johannes Schindelin wrote:
>>> On Sun, 21 Jan 2007, Bill Lear wrote:
>>> 
>>>> Also (apologies for the ignorance), how do I get the 1.5.0-rc2 release?
>>> 
>>> Direct your browser to
>>> 
>>> http://repo.or.cz/w/git.git?a=snapshot;h=eaf6459e4d482af51429f9464125621b805eb5f
>> 
>> Better URL is
>> 
>>   http://repo.or.cz/w/git.git?a=snapshot;h=v1.5.0-rc2
> 
> It is a better URL. Somehow I fscked up when I tried it, so I had the 
> impression that does not work. But it does.

Most probably you wrote '1.5.0-rc2' instead of 'v1.5.0-rc2'
(with 'v' prefix).

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: [Announce] GIT v1.5.0-rc2

[Jakub Narebski]

Johannes Schindelin wrote:
> On Sun, 21 Jan 2007, Jakub Narebski wrote:
>> Johannes Schindelin wrote:
>>> On Sun, 21 Jan 2007, Bill Lear wrote:
>>> 
>>>> Also (apologies for the ignorance), how do I get the 1.5.0-rc2 release?
>>> 
>>> Direct your browser to
>>> 
>>> http://repo.or.cz/w/git.git?a=snapshot;h=eaf6459e4d482af51429f9464125621b805eb5f
>> 
>> Better URL is
>> 
>>   http://repo.or.cz/w/git.git?a=snapshot;h=v1.5.0-rc2
> 
> It is a better URL. Somehow I fscked up when I tried it, so I had the 
> impression that does not work. But it does.

Most probably you wrote '1.5.0-rc2' instead of 'v1.5.0-rc2'
(with 'v' prefix).

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: [Announce] GIT v1.5.0-rc2

[Jakub Narebski]

Johannes Schindelin wrote:

> On Sun, 21 Jan 2007, Junio C Hamano wrote:

>> * Reflog
>> 
>>  - Reflog records the history of where the tip of each branch
>>    was at each moment.
> 
> It might make sense to reformulate that:
> 
>       Reflog records the history from the view point of the local 
>       repository. In other words, regardless of the real history,
>       the reflog shows the history as seen by one particular repository
>       (this enables you to ask "what was the current revision in _this_
>       repository, yesterday at 1pm?").

I think that _both_ sentences are right. Reflog records history of where the
tip of each branch was at each moment, logging also what command was used
to move tip of branch (was it commit, amending commit, rebase, reset, or
creating branch anew, git-am or pull).

But where tip of each branch was is purely local matter. What is global
is DAG of commits, refs are always as seen by one particular repository.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: [Announce] GIT v1.5.0-rc2

[Jakub Narebski]

Johannes Schindelin wrote:

> On Sun, 21 Jan 2007, Junio C Hamano wrote:

>> * Reflog
>> 
>>  - Reflog records the history of where the tip of each branch
>>    was at each moment.
> 
> It might make sense to reformulate that:
> 
>       Reflog records the history from the view point of the local 
>       repository. In other words, regardless of the real history,
>       the reflog shows the history as seen by one particular repository
>       (this enables you to ask "what was the current revision in _this_
>       repository, yesterday at 1pm?").

I think that _both_ sentences are right. Reflog records history of where the
tip of each branch was at each moment, logging also what command was used
to move tip of branch (was it commit, amending commit, rebase, reset, or
creating branch anew, git-am or pull).

But where tip of each branch was is purely local matter. What is global
is DAG of commits, refs are always as seen by one particular repository.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: [Announce] GIT v1.5.0-rc2

[Johannes Schindelin]

Hi,

On Sun, 21 Jan 2007, Jakub Narebski wrote:

> Johannes Schindelin wrote:
> 
> > On Sun, 21 Jan 2007, Junio C Hamano wrote:
> 
> >> * Reflog
> >> 
> >>  - Reflog records the history of where the tip of each branch
> >>    was at each moment.
> > 
> > It might make sense to reformulate that:
> > 
> >       Reflog records the history from the view point of the local 
> >       repository. In other words, regardless of the real history,
> >       the reflog shows the history as seen by one particular repository
> >       (this enables you to ask "what was the current revision in _this_
> >       repository, yesterday at 1pm?").
> 
> I think that _both_ sentences are right. Reflog records history of where the
> tip of each branch was at each moment, logging also what command was used
> to move tip of branch (was it commit, amending commit, rebase, reset, or
> creating branch anew, git-am or pull).
> 
> But where tip of each branch was is purely local matter. What is global
> is DAG of commits, refs are always as seen by one particular repository.

What I meant was: people not familiar with git development will probably 
not understand the shorter, concise statement. They will not know off-hand 
that there is a difference between the history of development, and the 
history, as seen from the local repository's viewpoint.

So of course, both sentences are right.

Your point -- that reflog also records the action -- is less important 
IMHO. It is just meta-data of the local view.

To your second point: the global history remains global, of course. But 
this is what you _usually_ refer to, when talking about the development 
history, anyway. Therefore, to motivate reflogs, you should point out the 
differences between local and global history.

And this means to at least _mention_ the word "local".

Ciao,
Dscho

Re: [Announce] GIT v1.5.0-rc2

[Jakub Narebski]

Johannes Schindelin wrote:

> On Sun, 21 Jan 2007, Jakub Narebski wrote:
> 
>> Johannes Schindelin wrote:
>> 
>>> On Sun, 21 Jan 2007, Junio C Hamano wrote:
>> 
>>>> * Reflog
>>>> 
>>>>  - Reflog records the history of where the tip of each branch
>>>>    was at each moment.
>>> 
>>> It might make sense to reformulate that:
>>> 
>>>       Reflog records the history from the view point of the local 
>>>       repository. In other words, regardless of the real history,
>>>       the reflog shows the history as seen by one particular repository
>>>       (this enables you to ask "what was the current revision in _this_
>>>       repository, yesterday at 1pm?").
>> 
>> I think that _both_ sentences are right. Reflog records history of where the
>> tip of each branch was at each moment, logging also what command was used
>> to move tip of branch (was it commit, amending commit, rebase, reset, or
>> creating branch anew, git-am or pull).
>> 
>> But where tip of each branch was is purely local matter. What is global
>> is DAG of commits, refs are always as seen by one particular repository.
> 
> What I meant was: people not familiar with git development will probably 
> not understand the shorter, concise statement. They will not know off-hand 
> that there is a difference between the history of development, and the 
> history, as seen from the local repository's viewpoint.
> 
> So of course, both sentences are right.
> 
> Your point -- that reflog also records the action -- is less important 
> IMHO. It is just meta-data of the local view.
> 
> To your second point: the global history remains global, of course. But 
> this is what you _usually_ refer to, when talking about the development 
> history, anyway. Therefore, to motivate reflogs, you should point out the 
> differences between local and global history.
> 
> And this means to at least _mention_ the word "local".

So I'd say:

  - Reflog records local history of where the tip of each branch
    was at each moment.

I think both "local" and "tip of branch" are important
for understanding reflog.

-- 
Jakub Narebski
Poland

Re: [Announce] GIT v1.5.0-rc2

[Johannes Schindelin]

Hi,

On Mon, 22 Jan 2007, Jakub Narebski wrote:

> So I'd say:
> 
>   - Reflog records local history of where the tip of each branch
>     was at each moment.
> 
> I think both "local" and "tip of branch" are important
> for understanding reflog.

'kay. Probably the simple addition of "local" is enough. Like it.

Ciao,
Dscho

Re: [Announce] GIT v1.5.0-rc2

[Jakub Narebski]

Johannes Schindelin wrote:
> On Mon, 22 Jan 2007, Jakub Narebski wrote:
> 
>> So I'd say:
>> 
>>   - Reflog records local history of where the tip of each branch
>>     was at each moment.
>> 
>> I think both "local" and "tip of branch" are important
>> for understanding reflog.
> 
> 'kay. Probably the simple addition of "local" is enough. Like it.

Or perhaps this would be better:

   - Reflog records the history of where the tip of each branch
     was at each moment in given repository.

Just nitpicking.
-- 
Jakub Narebski
Poland

Re: [Announce] GIT v1.5.0-rc2

[Junio C Hamano]

I've read your message only once (may have to come back to think
about ramifications of some finer points), but I generally
agree.  I'd appreciate a patch to the 'todo' branch ;-).

Re: [Announce] GIT v1.5.0-rc2

[Junio C Hamano]

"Horst H. von Brand" <vonbrand@inf.utfsm.cl> writes:

> Junio C Hamano <junkio@cox.net> wrote:
>> Willy Tarreau <w@1wt.eu> writes:
>> > Anything you can do to make tester's life easier will always slightly
>> > increase the number of testers.
>> > ...
>> > Pre-release tar.gz and rpms coupled with a freshmeat announcement should
>> > get you a bunch of testers and newcomers. This will give the new doc a
>> > real trial, and will help discover traps in which beginners often fall.
>> 
>> One worry I had about releasing git-1.5.0-rc2-1.rpm and friends
>> just like the "official" ones was that people might have scripts
>> to automate downloading & updating of packages, and they may not
>> like to get "beta" installed for them.
>
> Then put them into a "testing" or "pre-release" directory...

Ok, thanks for the suggestion.

The preview RPMs for i386 and x86_64 and an SRPM are available at:

	/pub/software/scm/git/testing/

The tarball for 1.5.0-rc2 is found at:

	/pub/software/scm/git/git-1.5.0.rc2.tar.gz

along with tarballs of preformatted htmldocs and manpages.

Re: [Announce] GIT v1.5.0-rc2

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

>>    - Cloning and fetching _from_ a shallow clone are not
>>      supported (nor tested -- so they might work by accident but
>>      they are not expected to).
>
> Maybe we should go the "restrict first, and loosen later" approach? I.e. 
> forbid git-upload-pack to run if is_repository_shallow()?
>
>>    - Pushing from nor into a shallow clone are not expected to
>>      work.
>
> Maybe forbid git-push and git-receive-pack to run if 
> is_repository_shallow()?
>
> (I _think_ git-push should be safe, but not git-receive-pack.)

I think that is sensible.  Let's do this.

-- >8 --
[PATCH] shallow repository: disable unsupported operations for now.

We currently do not support fetching/cloning from a shallow repository
nor pushing into one.  Make sure these are not attempted so that we
do not have to worry about corrupting repositories needlessly.

Signed-off-by: Junio C Hamano <junkio@cox.net>
---
 receive-pack.c |    3 +++
 upload-pack.c  |    3 ++-
 2 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/receive-pack.c b/receive-pack.c
index c176d8f..6333f00 100644
--- a/receive-pack.c
+++ b/receive-pack.c
@@ -421,6 +421,9 @@ int main(int argc, char **argv)
 	if (!enter_repo(dir, 0))
 		die("'%s': unable to chdir or not a git archive", dir);
 
+	if (is_repository_shallow())
+		die("attempt to push into a shallow repository");
+
 	setup_ident();
 	/* don't die if gecos is empty */
 	ignore_missing_committer_name();
diff --git a/upload-pack.c b/upload-pack.c
index 3a466c6..3648aae 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -672,7 +672,8 @@ int main(int argc, char **argv)
 
 	if (!enter_repo(dir, strict))
 		die("'%s': unable to chdir or not a git archive", dir);
-
+	if (is_repository_shallow())
+		die("attempt to fetch/clone from a shallow repository");
 	upload_pack();
 	return 0;
 }
-- 
1.5.0.rc2

Re: [Announce] GIT v1.5.0-rc2

[Nicolas Pitre]

On Sun, 21 Jan 2007, H. Peter Anvin wrote:

> In general, though, I would agree that the major number should change if there
> is an incompatible change.

Maybe when those incompatible features are enabled by default.  Right 
now they're not.


Nicolas

Re: [Announce] GIT v1.5.0-rc2

[Carl Worth]

[-- Attachment #1: Type: text/plain, Size: 4897 bytes --]

On Sun, 21 Jan 2007 03:20:06 -0800, Junio C Hamano wrote:
> Also, in the same spirit of giving the release an early
> exposure, here is the current draft of 1.5.0 release notes.

Thanks, these are very good and really show how much great progress
has gone into git recently. Congratulations to everyone who has helped
with this!

A few comments:

> In general, you should not have to worry about incompatibility,
> and there is no need to perform "repository conversion" if you
> are updating to v1.5.0.  However, some of the changes are
> one-way street upgrades; once you use them your repository
> can no longer be used with ancient git.

This "one-way street upgrades" sentence makes the upgrade to 1.5 sound
scarier than it really is. It's only after two more paragraphs of
fairly dense technical content that the reader is told that none of
this stuff is enabled by default yet.

Maybe replace the second sentence with something like:

	As of git v1.5.0 there are some optional changes to the
	repository that allow data to be stored and transferred more
	efficiently. These changes are not enabled by default as they
	will make the repository unusable with git versions before
	v1.4.2. Specifically the available options are:

or something along those lines.

>  - git-update-index is much less visible.

It's not clear what this sentence means. Perhaps add something like:

	, (many mentions of update-index in git output and
	documentation have now been replaced by simpler commands such
	as "git add" or "git rm").

>  - git-clone always uses what is known as "separate remote"
>    layout for a newly created repository with a working tree;
>    i.e. tracking branches in $GIT_DIR/refs/remotes/origin/ are
>    used to track branches from the origin.

This change has some workflow impact that is not at all obvious from
the above description. For example, after cloning git.git, things that
used to work like "git checkout -b my-next next" now no longer work,
(needing to use "origin/next" instead). And these branches also won't
appear in "git branch" output, (without the new -r option).

I think the release notes should spend a little more attention on an
issue like this. Maybe a separate section on changes to existing
interfaces, (as opposed to most of the other changes which are
improvements in the implementation of existing interfaces or just
plain new interfaces such as "git remote", "git gc", etc.)

If there is a new section, the previous paragraphs describing the move
of cloned origin information from .git/remotes/origin to .git/config
might belong there as well, (depending on whether you consider those
file contents a user-visible interface or not).

>  - git-branch and git-show-branch know remote tracking branches.

Should mention "-r" here.

>  - git-push can now be used to delete a remote branch or a tag.
>    This requires the updated git on the remote side.

What's the syntax for this? I know you don't want to turn the release
notes into a user manual, but it'd be nice to have brief mentions of
the new interfaces, (like the nice mention of "git add -i" for
example). Even with a quick skim through the git-push documentation,
I'm not immediately seeing how to delete a remote branch or tag.

>  - There is a toplevel garbage collector script, 'git-gc', that
>    is an easy way to run 'git-repack -a -d', 'git-reflog gc',
>    and 'git-prune'.

I think it's definitely worthwhile to note the fix of race conditions,
etc. here. It would be nice to have some short rule such as:

	"git gc" is free from any known race conditions with
	simultaneous git processes modifying the repository. So it's
	perfectly safe to run "git gc" from a cron job.

Or a similarly succinct rule that's actually true, (I think the recent
thread suggested "git gc" would only be safe with an extra
option---I'd much rather see it be safe by default and make the user
ask for extra unsafe pruning with an option).

>  - You can give non-branch to "git checkout" now.

Rather than "non-branch" I think it would be nice to say something
that mentioned tags. Maybe something like:

	You can now use 'git checkout' to checkout tags or any other
	revision, rather than just named branches."

>  - Repositories with hundreds of tags have been paying large
>    overhead, both in storage and in runtime, due to the
>    traditional one-ref-per-file format.  A new command,
>    git-pack-refs, can be used to "pack" them in more efficient
>    representation.

Is git-gc doing this housekeeping? If not, should it be? If so, should
it be mentioned here (and in the description of git-gc above)?

>  - There is a partial support for 'shallow' repositories that
>    keeps only recent history.  A 'shallow clone' is created by
>    specifying how deep that truncated history should be.

Here's another description that could definitely benefit from a very
short example command.

-Carl

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [Announce] GIT v1.5.0-rc2

[Jakub Narebski]

Junio C Hamano wrote:

> GIT v1.5.0 Release Notes (draft)
> ================================

Would they be somewhere besides todo branch of git.git repository, like the
v1.5.0 tag comment (content), or the NEWS file?
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: [Announce] GIT v1.5.0-rc2

[Jakub Narebski]

Junio C Hamano wrote:

> GIT v1.5.0 Release Notes (draft)
> ================================

Would they be somewhere besides todo branch of git.git repository, like the
v1.5.0 tag comment (content), or the NEWS file?
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: [Announce] GIT v1.5.0-rc2

[Junio C Hamano]

Jakub Narebski <jnareb@gmail.com> writes:

> Junio C Hamano wrote:
>
>> GIT v1.5.0 Release Notes (draft)
>> ================================
>
> Would they be somewhere besides todo branch of git.git repository, like the
> v1.5.0 tag comment (content), or the NEWS file?

Most likely the former would happen when the real thing is made.

Re: [Announce] GIT v1.5.0-rc2

[Junio C Hamano]

Thanks for your comments; the attached probably needs
proofreading.

The changes in response to the remainder of your comments are
quite straightforward and I do not think needs proofreading, so
I'll incorporate them and push the result out in 'todo'.

diff --git a/v1.5.0.txt b/v1.5.0.txt
index c0ff071..596bfd2 100644
--- a/v1.5.0.txt
+++ b/v1.5.0.txt
@@ -107,11 +107,40 @@ Updates in v1.5.0 since v1.4.4 series
    already comfortable with your workflow with the layout.
 
  - git-clone always uses what is known as "separate remote"
-   layout for a newly created repository with a working tree;
-   i.e. tracking branches in $GIT_DIR/refs/remotes/origin/ are
-   used to track branches from the origin, instead of
-   $GIT_DIR/refs/heads/, making the difference between remotely
-   tracked and local branches more obvious.
+   layout for a newly created repository with a working tree.
+
+   A repository with the separate remote layout starts with only
+   one default branch, 'master', to be used for your own
+   development.  Unlike the traditional layout that copied all
+   the upstream branches into your branch namespace (while
+   renaming their 'master' to your 'origin'), they are not made
+   into your branches.  Instead, they are kept track of using
+   'refs/remotes/origin/$upstream_branch_name'.
+
+   This layout keeps your own branch namespace less cluttered,
+   avoids name collision with your upstream, makes it possible
+   to automatically track new branches created at the remote
+   after you clone from it, and makes it easier to interact with
+   more than one remote repositories.  There might be some
+   surprises:
+
+   * 'git branch' does not show the branches from your upstream.
+     It only lists your own branches.  Use '-r' option to view
+     the tracking branches.
+
+   * If you are forking off of a branch obtained from the
+     upstream, you would have done something like 'git branch
+     my-next next', because traditional layout dropped the
+     tracking branch 'next' into your own branch namespace.
+     With the separate remote layout, you say 'git branch next
+     origin/next', which allows you to use the matching name
+     'next' for your own branch.  It also allows you to track a
+     remote other than 'origin' (i.e. where you initially cloned
+     from) and fork off of a branch from there the same way
+     (e.g. "git branch mingw j6t/master").
+
+   Repositories initialized with the traditional layout
+   continues to work (and will continue to work).
 
  - New branches that appear on the origin side after a clone is
    made are also tracked automatically.  This is done with an

Re: [Announce] GIT v1.5.0-rc2

[Carl Worth]

[-- Attachment #1: Type: text/plain, Size: 2193 bytes --]

On Mon, 22 Jan 2007 11:28:32 -0800, Junio C Hamano wrote:
> Thanks for your comments;

You're welcome.

> the attached probably needs proofreading.

In general, I like it. The git-branch documentation already talks
about "remote-tracking branches" so I've rewritten a couple of
sentence below to use that same terminology. Also there are a couple
of grammar errors related to pluralization, (likely the fault of
English being quite a bit less consistent than other languages with
subject/verb number agreement, etc.).

> +   A repository with the separate remote layout starts with only
> +   one default branch, 'master', to be used for your own
> +   development.  Unlike the traditional layout that copied all
> +   the upstream branches into your branch namespace (while
> +   renaming their 'master' to your 'origin'), they are not made
> +   into your branches.  Instead, they are kept track of using
> +   'refs/remotes/origin/$upstream_branch_name'.

      renaming remote 'master' to local 'origin'), the new approach
      puts upstream branches into local "remote-tracking branches"
      with their own namespace. These can be referenced with names
      such as "origin/$upstream_branch_name" and are stored in
      .git/refs/remotes rather than .git/refs/heads where normal
      branches are stored.

> +   This layout keeps your own branch namespace less cluttered,
> +   avoids name collision with your upstream, makes it possible
> +   to automatically track new branches created at the remote
> +   after you clone from it, and makes it easier to interact with
> +   more than one remote repositories.  There might be some

Should be "more than one remote repository.". Also I'd add, ", (see
the new 'git remote' command)" before the end of that sentence.

> +   * 'git branch' does not show the branches from your upstream.

Again to use the same terminology, "does not show the remote-tracking
branches.".

> +   Repositories initialized with the traditional layout
> +   continues to work (and will continue to work).

The 's' on "continues" is incorrect. Perhaps:

	continue to work (and will work in the future as well).

or just drop the parenthetical phrase.

-Carl

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[PATCH 1/2] Refactor the pack header reading function out of receive-pack.c

[Junio C Hamano]

I'll be reusing it on the fetch-pack side as well.

Signed-off-by: Junio C Hamano <junkio@cox.net>
---

  Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

  >>  - git-push more agressively keeps the transferred objects
  >>    packed.  Earlier we recommended to monitor amount of loose
  >>    objects and repack regularly, but you should repack when you
  >>    accumulated too many small packs this way as well.  Updated
  >>    git-count-objects helps you with this.
  >
  > It might make sense to enable something similar for git-fetch in time for 
  > 1.5.0.

  I have two patches that could become the beginning of this, not
  much tested.  This is the first of the two.

 pack.h         |    5 +++++
 receive-pack.c |   26 ++++++++++++++------------
 sha1_file.c    |   21 +++++++++++++++++++++
 3 files changed, 40 insertions(+), 12 deletions(-)

diff --git a/pack.h b/pack.h
index 821706f..deb427e 100644
--- a/pack.h
+++ b/pack.h
@@ -44,4 +44,9 @@ struct pack_header {
 #define PACK_IDX_SIGNATURE 0xff744f63	/* "\377tOc" */
 
 extern int verify_pack(struct packed_git *, int);
+
+#define PH_ERROR_EOF		(-1)
+#define PH_ERROR_PACK_SIGNATURE	(-2)
+#define PH_ERROR_PROTOCOL	(-3)
+extern int read_pack_header(int fd, struct pack_header *);
 #endif
diff --git a/receive-pack.c b/receive-pack.c
index 6333f00..b3a4552 100644
--- a/receive-pack.c
+++ b/receive-pack.c
@@ -250,20 +250,22 @@ static void read_head_info(void)
 
 static const char *parse_pack_header(struct pack_header *hdr)
 {
-	char *c = (char*)hdr;
-	ssize_t remaining = sizeof(struct pack_header);
-	do {
-		ssize_t r = xread(0, c, remaining);
-		if (r <= 0)
-			return "eof before pack header was fully read";
-		remaining -= r;
-		c += r;
-	} while (remaining > 0);
-	if (hdr->hdr_signature != htonl(PACK_SIGNATURE))
+	switch (read_pack_header(0, hdr)) {
+	case PH_ERROR_EOF:
+		return "eof before pack header was fully read";
+
+	case PH_ERROR_PACK_SIGNATURE:
 		return "protocol error (pack signature mismatch detected)";
-	if (!pack_version_ok(hdr->hdr_version))
+
+	case PH_ERROR_PROTOCOL:
 		return "protocol error (pack version unsupported)";
-	return NULL;
+
+	default:
+		return "unknown error in parse_pack_header";
+
+	case 0:
+		return NULL;
+	}
 }
 
 static const char *pack_lockfile;
diff --git a/sha1_file.c b/sha1_file.c
index 43ff402..498665e 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -2048,3 +2048,24 @@ int index_path(unsigned char *sha1, const char *path, struct stat *st, int write
 	}
 	return 0;
 }
+
+int read_pack_header(int fd, struct pack_header *header)
+{
+	char *c = (char*)header;
+	ssize_t remaining = sizeof(struct pack_header);
+	do {
+		ssize_t r = xread(fd, c, remaining);
+		if (r <= 0)
+			/* "eof before pack header was fully read" */
+			return PH_ERROR_EOF;
+		remaining -= r;
+		c += r;
+	} while (remaining > 0);
+	if (header->hdr_signature != htonl(PACK_SIGNATURE))
+		/* "protocol error (pack signature mismatch detected)" */
+		return PH_ERROR_PACK_SIGNATURE;
+	if (!pack_version_ok(header->hdr_version))
+		/* "protocol error (pack version unsupported)" */
+		return PH_ERROR_PROTOCOL;
+	return 0;
+}
-- 
1.5.0.rc2.gc9a89

[PATCH 2/2] Allow fetch-pack to decide keeping the fetched pack without exploding

[Junio C Hamano]

With --keep-auto option, fetch-pack decides to keep the pack
without exploding it just like receive-pack does.

We may want to later make this the default.

Signed-off-by: Junio C Hamano <junkio@cox.net>
---

 And this is the second half.  It looks larger than it really
 is, because it involves some code movements; it removes two
 separate functions that called get_pack() and moves what they
 did to get_pack() after setup_sideband() happens.

 Although I did test it with --keep-auto with large and small
 packs once each. I haven't tested this at all with the
 git-fetch script.

 fetch-pack.c |   91 +++++++++++++++++++++++++++++++++++++--------------------
 1 files changed, 59 insertions(+), 32 deletions(-)

diff --git a/fetch-pack.c b/fetch-pack.c
index 726140a..4ee041c 100644
--- a/fetch-pack.c
+++ b/fetch-pack.c
@@ -4,9 +4,11 @@
 #include "commit.h"
 #include "tag.h"
 #include "exec_cmd.h"
+#include "pack.h"
 #include "sideband.h"
 
 static int keep_pack;
+static int keep_auto;
 static int quiet;
 static int verbose;
 static int fetch_all;
@@ -486,13 +488,58 @@ static pid_t setup_sideband(int fd[2], int xd[2])
 	return side_pid;
 }
 
-static int get_pack(int xd[2], const char **argv)
+static int get_pack(int xd[2])
 {
 	int status;
 	pid_t pid, side_pid;
 	int fd[2];
+	const char *argv[20];
+	char keep_arg[256];
+	char hdr_arg[256];
+	const char **av;
+	int do_keep = keep_pack;
 
 	side_pid = setup_sideband(fd, xd);
+
+	av = argv;
+	*hdr_arg = 0;
+	if (keep_auto) {
+		struct pack_header header;
+
+		if (read_pack_header(fd[0], &header))
+			die("protocol error: bad pack header");
+		snprintf(hdr_arg, sizeof(hdr_arg), "--pack_header=%u,%u",
+			 ntohl(header.hdr_version), ntohl(header.hdr_entries));
+		if (ntohl(header.hdr_entries) < keep_auto)
+			do_keep = 0;
+		else
+			do_keep = 1;
+	}
+
+	if (do_keep) {
+		*av++ = "index-pack";
+		*av++ = "--stdin";
+		if (!quiet)
+			*av++ = "-v";
+		if (use_thin_pack)
+			*av++ = "--fix-thin";
+		if (keep_pack > 1 || keep_auto) {
+			int s = sprintf(keep_arg,
+					"--keep=fetch-pack %d on ", getpid());
+			if (gethostname(keep_arg + s, sizeof(keep_arg) - s))
+				strcpy(keep_arg + s, "localhost");
+			*av++ = keep_arg;
+		}
+	}
+	else {
+		*av++ = "unpack-objects";
+		if (quiet)
+			*av++ = "-q";
+	}
+	if (*hdr_arg)
+		*av++ = hdr_arg;
+	*av++ = NULL;
+
 	pid = fork();
 	if (pid < 0)
 		die("fetch-pack: unable to fork off %s", argv[0]);
@@ -522,39 +569,10 @@ static int get_pack(int xd[2], const char **argv)
 	die("%s died of unnatural causes %d", argv[0], status);
 }
 
-static int explode_rx_pack(int xd[2])
-{
-	const char *argv[3] = { "unpack-objects", quiet ? "-q" : NULL, NULL };
-	return get_pack(xd, argv);
-}
-
-static int keep_rx_pack(int xd[2])
-{
-	const char *argv[6];
-	char keep_arg[256];
-	int n = 0;
-
-	argv[n++] = "index-pack";
-	argv[n++] = "--stdin";
-	if (!quiet)
-		argv[n++] = "-v";
-	if (use_thin_pack)
-		argv[n++] = "--fix-thin";
-	if (keep_pack > 1) {
-		int s = sprintf(keep_arg, "--keep=fetch-pack %i on ", getpid());
-		if (gethostname(keep_arg + s, sizeof(keep_arg) - s))
-			strcpy(keep_arg + s, "localhost");
-		argv[n++] = keep_arg;
-	}
-	argv[n] = NULL;
-	return get_pack(xd, argv);
-}
-
 static int fetch_pack(int fd[2], int nr_match, char **match)
 {
 	struct ref *ref;
 	unsigned char sha1[20];
-	int status;
 
 	get_remote_heads(fd[0], &ref, 0, NULL, 0);
 	if (is_repository_shallow() && !server_supports("shallow"))
@@ -589,8 +607,7 @@ static int fetch_pack(int fd[2], int nr_match, char **match)
 			 */
 			fprintf(stderr, "warning: no common commits\n");
 
-	status = (keep_pack) ? keep_rx_pack(fd) : explode_rx_pack(fd);
-	if (status)
+	if (get_pack(fd))
 		die("git-fetch-pack: fetch failed.");
 
  all_done:
@@ -655,6 +672,16 @@ int main(int argc, char **argv)
 				keep_pack++;
 				continue;
 			}
+			if (!strcmp("--keep-auto", arg)) {
+				keep_auto = 100;
+				continue;
+			}
+			if (!strncmp("--keep-auto=", arg, 12)) {
+				keep_auto = strtoul(arg + 12, NULL, 0);
+				if (keep_auto < 20)
+					keep_auto = 20;
+				continue;
+			}
 			if (!strcmp("--thin", arg)) {
 				use_thin_pack = 1;
 				continue;
-- 
1.5.0.rc2.gc9a89

Re: [PATCH 2/2] Allow fetch-pack to decide keeping the fetched pack without exploding

[Johannes Schindelin]

Hi,

On Mon, 22 Jan 2007, Junio C Hamano wrote:

> With --keep-auto option, fetch-pack decides to keep the pack without 
> exploding it just like receive-pack does.

I like both patches. (Did not have time to test yet, but from looking at 
the patches, it seems indeed to be mostly code moves.)

> We may want to later make this the default.

You have my vote for sooner rather than later.

Ciao,
Dscho

P.S.: These patches make me dream of yet another diff format enhancement: 
code moves! Of course, for this to be really usable, you'd also have to 
automatically determine indent changes... You may say I'm a dreamer. But 
I'm not the only one...

Re: [PATCH 2/2] Allow fetch-pack to decide keeping the fetched pack without exploding

[Jakub Narebski]

Johannes Schindelin wrote:

> P.S.: These patches make me dream of yet another diff format enhancement: 
> code moves! Of course, for this to be really usable, you'd also have to 
> automatically determine indent changes... You may say I'm a dreamer. But 
> I'm not the only one...

I wonder if it could be done with e.g.

--- a/fromfile
+++ b/somefile
<code movement or copying>

--- a/somefile
+++ b/somefile
<other changes>

The problem is that context differs usually for code movement.
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

code movements in diffs, was Re: [PATCH 2/2] Allow fetch-pack to decide keeping the fetched pack without exploding

[Johannes Schindelin]

Hi,

On Tue, 23 Jan 2007, Jakub Narebski wrote:

> Johannes Schindelin wrote:
> 
> > P.S.: These patches make me dream of yet another diff format enhancement: 
> > code moves! Of course, for this to be really usable, you'd also have to 
> > automatically determine indent changes... You may say I'm a dreamer. But 
> > I'm not the only one...
> 
> I wonder if it could be done with e.g.
> 
> --- a/fromfile
> +++ b/somefile
> <code movement or copying>
> 
> --- a/somefile
> +++ b/somefile
> <other changes>
> 
> The problem is that context differs usually for code movement.

There is a more fundamental problem here: both "diff" and "patch" walk the 
file pair in a direction. The whole "code movement" stuff would break this 
paradigm. What you found is just _one_ consequence.

But as I said: a man can still dream, can't he?

Ciao,
Dscho

Re: [PATCH 2/2] Allow fetch-pack to decide keeping the fetched pack without exploding

[Nicolas Pitre]

On Tue, 23 Jan 2007, Johannes Schindelin wrote:

> On Mon, 22 Jan 2007, Junio C Hamano wrote:
> 
> > We may want to later make this the default.
> 
> You have my vote for sooner rather than later.

Seconded.


Nicolas

Re: [PATCH 2/2] Allow fetch-pack to decide keeping the fetched pack without exploding

[Linus Torvalds]

On Tue, 23 Jan 2007, Johannes Schindelin wrote:
> 
> P.S.: These patches make me dream of yet another diff format enhancement: 
> code moves!

It's basically impossible.

Why? You need the context. 

In a _context_less_ diff, it's fairly trivial to indicate code movement: 
you just say "move bytes x-y into z". However, if you want anything 
approaching readability and safety, you want context, and that 
automatically means that you need to have the stuff around the context, 
which in turn means that you can't sanely do that.

Sure, you could do a diff that has the *context* repeated around the code 
that moves (and not actually quoting all the movement itself, except for 
the first and last three lines or something), but that would be really 
unreadable. A lot more unreadable than what we have now, with delete+add 
chunks.

> Of course, for this to be really usable, you'd also have to 
> automatically determine indent changes...

Indeed. Much code movement isn't just pure data movement, it's 
re-indentation too. Making the thing even less tractable.

In other words - you can do it (and we _do_ do it) when you don't do diffs 
at all, but deltas. Our deltas actually do contain block movement. But 
diffs? Forget about it.

> You may say I'm a dreamer. But I'm not the only one...

I am the walrus.

		Linus

Re: [PATCH 2/2] Allow fetch-pack to decide keeping the fetched pack without exploding

[David Kågedal]

Linus Torvalds <torvalds@linux-foundation.org> writes:

> On Tue, 23 Jan 2007, Johannes Schindelin wrote:
>> 
>> P.S.: These patches make me dream of yet another diff format enhancement: 
>> code moves!
>
> It's basically impossible.
>
> Why? You need the context. 

Yes, I think that a diff format for code moves wouldn't be useful.
What could potentially be useful is a graphical diff browser that can
e.g.  show two versions side-by-side and show code moves in that.  I
have a vague memory that the ClearCase merge tool did that.

But as long as the code moves are within a single file, that merge
tool could derive that move from an ordinary diff.

-- 
David Kågedal

Re: [PATCH 2/2] Allow fetch-pack to decide keeping the fetched pack without exploding

[Johannes Schindelin]

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

Hi,

[Re-Cc'ing Linus]

On Tue, 23 Jan 2007, David Kågedal wrote:

> Linus Torvalds <torvalds@linux-foundation.org> writes:
> 
> > On Tue, 23 Jan 2007, Johannes Schindelin wrote:
> >> 
> >> P.S.: These patches make me dream of yet another diff format enhancement: 
> >> code moves!
> >
> > It's basically impossible.
> >
> > Why? You need the context. 
> 
> Yes, I think that a diff format for code moves wouldn't be useful.
> What could potentially be useful is a graphical diff browser that can
> e.g.  show two versions side-by-side and show code moves in that.  I
> have a vague memory that the ClearCase merge tool did that.

I don't need no steenking graphical tools. I want to read me mailing list, 
that's it.

> But as long as the code moves are within a single file, that merge tool 
> could derive that move from an ordinary diff.

Actually, you could even derive a code movement between files from the set 
of diffs. Though not code copies. But then, we don't do code copies.

Seriously again, your comment got me thinking: it could actually make 
sense to include the information of code moves and code copies (for easier 
review) in the "@@ .. @@" lines (or before them, if git apply does not 
choke on inserting garbage lines before them).

But maybe it is not that good after all: if you review code, you should 
inspect it (even if it was only moved), since it might have all kinds of 
side effects, or you might have missed some other aspect before.

Ciao,
Dscho

Re: [PATCH 2/2] Allow fetch-pack to decide keeping the fetched pack without exploding

[Jakub Narebski]

Johannes Schindelin wrote:

> Seriously again, your comment got me thinking: it could actually make 
> sense to include the information of code moves and code copies (for easier 
> review) in the "@@ .. @@" lines (or before them, if git apply does not 
> choke on inserting garbage lines before them).
> 
> But maybe it is not that good after all: if you review code, you should 
> inspect it (even if it was only moved), since it might have all kinds of 
> side effects, or you might have missed some other aspect before.

It would be nice to have extended git header dealing with code copies
(or stuff it in chunk header or above), because sometimes both sides
of code movement (removal from one file, adding in next file) can be
separated by a few pagefulls of chunks.
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: [Announce] GIT v1.5.0-rc2

[Bill Lear]

On Sunday, January 21, 2007 at 12:08:25 (+0100) Johannes Schindelin writes:
>Hi,
>
>On Sun, 21 Jan 2007, Jakub Narebski wrote:
>
>> By the way, was the pager configured to saner values, so "git diff" on a 
>> repository with no changes does not output empty page?
>
>As Junio mentioned: it already does. Maybe you have set the environment 
>variable "LESS", and forgot to include "-F"?

I can't seem to get this to work, no matter what I do, using the
latest 1.5.0-rc2 code.  I have the environment variables LESS, PAGER,
PAGER_FLAGS, and I can't seem to get 'git diff' to not plough through
my screen each time it is run, no matter the combinations...  Could
someone post the magic?


Bill

Re: [Announce] GIT v1.5.0-rc2

[Johannes Schindelin]

Hi,

On Tue, 23 Jan 2007, Bill Lear wrote:

> I can't seem to get this to work, no matter what I do, using the latest 
> 1.5.0-rc2 code.  I have the environment variables LESS, PAGER, 
> PAGER_FLAGS, and I can't seem to get 'git diff' to not plough through my 
> screen each time it is run, no matter the combinations...  Could someone 
> post the magic?

Try this:

	PAGER=less LESS=-FRS git diff

Hth,
Dscho

Re: [Announce] GIT v1.5.0-rc2

[Bill Lear]

On Tuesday, January 23, 2007 at 20:12:36 (+0100) Johannes Schindelin writes:
>Hi,
>
>On Tue, 23 Jan 2007, Bill Lear wrote:
>
>> I can't seem to get this to work, no matter what I do, using the latest 
>> 1.5.0-rc2 code.  I have the environment variables LESS, PAGER, 
>> PAGER_FLAGS, and I can't seem to get 'git diff' to not plough through my 
>> screen each time it is run, no matter the combinations...  Could someone 
>> post the magic?
>
>Try this:
>
>	PAGER=less LESS=-FRS git diff

Replied to Johannes off-line and thought this was working --- sorry
for the false positive.  It is in one regard: it completely suppresses
output if there is less than a full screen of output.

If I do this:

% export PAGER=less
% unset LESS
% git diff

I get 30 lines of output in my current repository, as I should.

If I then do this:

% LESS=-FRS git diff

I get nothing --- I do see a brief blink of output, but it's as if
less swallows it whole and I see nothing but the next prompt.

Hmmm ... I do seem to be using a rather old version of less:

% less --version
less 382
Copyright (C) 2002 Mark Nudelman

Could this be the culprit?  Will try and see...  Nope, downloaded,
built, and installed less-394 and I still see the same problem.  I also
see this problem when I do 'man git-gc', for example --- the manpage
just disappears.

If I set LESS to '-F' it fails.  If set to '-RS', output is seen but
then I see the screen blanked when there is no output from git diff.

This is on Centos 4.3.  I have not yet tried this on my Fedora Core 6
laptop, at home...



Bill

Re: [Announce] GIT v1.5.0-rc2

[Uwe Kleine-König]

Hello Bill,

> 
> % export PAGER=less
> % unset LESS
> % git diff
> 
> I get 30 lines of output in my current repository, as I should.
> 
> If I then do this:
> 
> % LESS=-FRS git diff
What about:

	LESS=-FRSX git diff

?

HTH
Uwe

-- 
Uwe Kleine-König

http://www.google.com/search?q=sin%28pi%2F2%29

Re: [Announce] GIT v1.5.0-rc2

[Johannes Schindelin]

Hi,

On Tue, 23 Jan 2007, Bill Lear wrote:

> % less --version
> less 382

It works here, with 381 _and_ 376+iso254.

> If I set LESS to '-F' it fails.  If set to '-RS', output is seen but 
> then I see the screen blanked when there is no output from git diff.

This looks more like a broken terminal interaction to me.

Ciao,
Dscho

Re: [Announce] GIT v1.5.0-rc2

[Bill Lear]

On Tuesday, January 23, 2007 at 21:22:32 (+0100) Uwe Kleine-König writes:
>> % export PAGER=less
>> % unset LESS
>> % git diff
>> 
>> I get 30 lines of output in my current repository, as I should.
>> 
>> If I then do this:
>> 
>> % LESS=-FRS git diff
>What about:
>
>	LESS=-FRSX git diff

Well, I see output when there is output to show, yes, but it still
blanks the screen --- or, I should say, scrolls all the way to the
bottom --- when there is no difference to show.

I do note that if LESS is not set, git sets it (in pager.c) to just
what you have above (FRSX).


Bill

Re: [Announce] GIT v1.5.0-rc2

[Linus Torvalds]

[ Added "less" author Mark Nudelman to Cc: ]

On Tue, 23 Jan 2007, Bill Lear wrote:
> 
> I can't seem to get this to work, no matter what I do, using the
> latest 1.5.0-rc2 code.  I have the environment variables LESS, PAGER,
> PAGER_FLAGS, and I can't seem to get 'git diff' to not plough through
> my screen each time it is run, no matter the combinations...  Could
> someone post the magic?

I think "less" is actually seriously buggy with -F.

There are two bugs:

 - it will always screw up the screen and move to the end. It does this 
   even if you use -FX which should disable any init sequences, so it's 
   not about that problem.

 - if you resize the terminal while less is waiting for input, less
   will exit entirely without even showing the output. This is very
   noticeable if you do something like "git diff" on a big and cold-cache 
   tree and git takes a few seconds to think, and then you resize the 
   window while it's preparing. Boom. No output AT ALL.

Both bugs are easily seen with this simple command line

	clear ; (sleep 5 ; echo Hello) | less -F

where you would EXPECT that the "Hello" would show up at the first line of 
the screen (since we cleared the screen and moved to the top left corner), 
but in fact it doesn't.

And try resizing the terminal to make it bigger during the five-second 
pause, and now you'll see less not show the "Hello" at _all_. It's just 
gone (this is true even if the output was _more_ than a screen: try with

	(sleep 10 ; yes ) | less -F

and resize the screen, and it will exit silently after 10 seconds - never 
showing any output at all! Even though the output is obviously bigger than 
a screen..

Tested with Kterm, gnome-terminal and xterm. They all behave the same for 
me.

I don't know exactly what the bug is, but I find the "eof" handling very
confusing in the less sources. It makes me suspect that there is something 
that gets confused by the partial read, sets EOF (since we're on the last 
line), and then thinks that it should quit, since EOF is set.

I dunno. Mark?

		Linus

Re: [Announce] GIT v1.5.0-rc2

[Peter Baumann]

Bill Lear <rael@zopyra.com> schrieb:
> On Tuesday, January 23, 2007 at 20:12:36 (+0100) Johannes Schindelin writes:
>>Hi,
>>
>>On Tue, 23 Jan 2007, Bill Lear wrote:
>>
>>> I can't seem to get this to work, no matter what I do, using the latest 
>>> 1.5.0-rc2 code.  I have the environment variables LESS, PAGER, 
>>> PAGER_FLAGS, and I can't seem to get 'git diff' to not plough through my 
>>> screen each time it is run, no matter the combinations...  Could someone 
>>> post the magic?
>>
>>Try this:
>>
>>	PAGER=less LESS=-FRS git diff
>
> Replied to Johannes off-line and thought this was working --- sorry
> for the false positive.  It is in one regard: it completely suppresses
> output if there is less than a full screen of output.
>
> If I do this:
>
> % export PAGER=less
> % unset LESS
> % git diff
>
> I get 30 lines of output in my current repository, as I should.
>
> If I then do this:
>
> % LESS=-FRS git diff
>
> I get nothing --- I do see a brief blink of output, but it's as if
> less swallows it whole and I see nothing but the next prompt.
>

This is propably caused by activating "Enable Alternate Screen Switching"
in xterm. If you have this feature enabled, you get a clean screen (no
fragments of the displayed file are shown after quitting less). Try to
disable it and see if it works.

-Peter

Re: [Announce] GIT v1.5.0-rc2

[Bill Lear]

On Tuesday, January 23, 2007 at 22:09:24 (+0100) Peter Baumann writes:
>Bill Lear <rael@zopyra.com> schrieb:
>>...
>> If I do this:
>>
>> % export PAGER=less
>> % unset LESS
>> % git diff
>>
>> I get 30 lines of output in my current repository, as I should.
>>
>> If I then do this:
>>
>> % LESS=-FRS git diff
>>
>> I get nothing --- I do see a brief blink of output, but it's as if
>> less swallows it whole and I see nothing but the next prompt.
>>
>
>This is propably caused by activating "Enable Alternate Screen Switching"
>in xterm. If you have this feature enabled, you get a clean screen (no
>fragments of the displayed file are shown after quitting less). Try to
>disable it and see if it works.

Tried as instructed: I get output when I should get output.  However,
when I should get no output, it clears/scrolls all the way down to the
bottom of the screen (LESS=-FRS git diff).


Bill

Re: [Announce] GIT v1.5.0-rc2

[Uwe Kleine-König]

Bill Lear wrote:
> On Tuesday, January 23, 2007 at 21:22:32 (+0100) Uwe Kleine-König writes:
> >> % export PAGER=less
> >> % unset LESS
> >> % git diff
> >> 
> >> I get 30 lines of output in my current repository, as I should.
> >> 
> >> If I then do this:
> >> 
> >> % LESS=-FRS git diff
> >What about:
> >
> >	LESS=-FRSX git diff
> 
> Well, I see output when there is output to show, yes, but it still
> blanks the screen --- or, I should say, scrolls all the way to the
> bottom --- when there is no difference to show.
Ah, OK, now I got it.  Sorry, I understood you wrong.  Seems like
something that needs fixing in less.  At least I cannot find an option
for that.  But I'm not sure that all people would consider that being a
bug.

Best regards
Uwe

-- 
Uwe Kleine-König

http://www.google.com/search?q=72+PS+point+in+inch

Re: [Announce] GIT v1.5.0-rc2

[Mark Nudelman]

On 1/23/2007 12:32 PM, Linus Torvalds wrote:
> I think "less" is actually seriously buggy with -F.
> 
> There are two bugs:
> 
>  - it will always screw up the screen and move to the end. It does this 
>    even if you use -FX which should disable any init sequences, so it's 
>    not about that problem.
> 
>  - if you resize the terminal while less is waiting for input, less
>    will exit entirely without even showing the output. This is very
>    noticeable if you do something like "git diff" on a big and cold-cache 
>    tree and git takes a few seconds to think, and then you resize the 
>    window while it's preparing. Boom. No output AT ALL.
> 
> Both bugs are easily seen with this simple command line
> 
> 	clear ; (sleep 5 ; echo Hello) | less -F
> 
> where you would EXPECT that the "Hello" would show up at the first line of 
> the screen (since we cleared the screen and moved to the top left corner), 
> but in fact it doesn't.
> 
> And try resizing the terminal to make it bigger during the five-second 
> pause, and now you'll see less not show the "Hello" at _all_. It's just 
> gone (this is true even if the output was _more_ than a screen: try with
> 
> 	(sleep 10 ; yes ) | less -F
> 
> and resize the screen, and it will exit silently after 10 seconds - never 
> showing any output at all! Even though the output is obviously bigger than 
> a screen..
> 
> Tested with Kterm, gnome-terminal and xterm. They all behave the same for 
> me.
> 
> I don't know exactly what the bug is, but I find the "eof" handling very
> confusing in the less sources. It makes me suspect that there is something 
> that gets confused by the partial read, sets EOF (since we're on the last 
> line), and then thinks that it should quit, since EOF is set.
> 
> I dunno. Mark?
> 
> 		Linus


Hi Linus,

The first issue that you mention (that we move to the bottom of the 
screen before printing the first line) is behavior that has always 
existed in less.  It's not the init sequence that's doing it; less 
deliberately moves to lowerleft before printing any output that is 
intended to go at the bottom of the screen, including both file data and 
the prompt.  This was a design decision from the first version of less, 
and I've never been brave enough to try to find all the places that 
would be affected by changing this.  For example, less tries to keep 
track of exactly what's displayed on the screen at all times, and it's 
harder to do this if we don't know whether some output scrolled the 
screen or not.  It may or may not be a big job to make all the changes 
that would be required.  I will move this up the priority list and take 
a look at it for the next release of less.

BTW, this issue is documented as enhancement request #112 at 
http://www.greenwoodsoftware.com/less/bugs.html.

Your second issue is definitely a bug.  Less's handling of -F and eof in 
general is indeed rather baroque and confusing, and probably needs a 
complete revision.  Some of the complexity comes from being portable to 
many (not necessarily Unix-like) systems.  But in this case, I think the 
early exit is happening because less makes the decision about whether to 
quit due to -F based on the state of the input when the first prompt 
occurs.  When less receives SIGWIND, it repaints the screen and 
*reprompts*.  So if it gets this signal before the first screen is 
completely filled, it tries to prompt, somehow gets confused and thinks 
that the partially filled screen is evidence of a short file, and exits. 
  I will add this to the bug list and try to fix it in the next release.

--Mark

Re: [Announce] GIT v1.5.0-rc2

[Linus Torvalds]

On Wed, 24 Jan 2007, Mark Nudelman wrote:
>
> The first issue that you mention (that we move to the bottom of the screen
> before printing the first line) is behavior that has always existed in less.
>
> BTW, this issue is documented as enhancement request #112 at
> http://www.greenwoodsoftware.com/less/bugs.html.

I don't dispute that the "move to the bottom of the screen" is probably a 
good feature in general, but it is _not_ a good feature when -F is in 
effect (similar to the init/exit sequence being a horrible thing to do 
when -F is in effect).

So the problem is that it basically makes -F largely useless.. The whole 
_point_ of anybody using -F is that it turns off the "pager" feature for 
small output that fits on a page, wouldn't you say?

(The reason the init/exit sequence doesn't mix with -F is that many 
terminal descriptions basically have a "switch to secondary screen" for 
init, and "switch back" for exit, which means that together with -F, small 
output simply won't be shown at all - or perhaps it just flickers too 
quickly for the user to see it).

So this really is only a -F issue.

Now, for the init/exit sequence, at least we have -X to turn that off (and 
git does indeed default to using "FRSX" if the user doesn't have any LESS 
environment variable set), so perhaps the "move to end of screen" could 
also get another flag? That way it would be something that users can 
control - but see above on why I pretty much guarantee that anybody who 
uses -F would want to use the new flag too.

> Your second issue is definitely a bug.  Less's handling of -F and eof in
> general is indeed rather baroque and confusing, and probably needs a complete
> revision.  Some of the complexity comes from being portable to many (not
> necessarily Unix-like) systems.

Yeah, I tried to look at the sources, and ran awya screaming ;)

		Linus

Re: [Announce] GIT v1.5.0-rc2

[Linus Torvalds]

On Tue, 23 Jan 2007, Linus Torvalds wrote:
> 
> I think "less" is actually seriously buggy with -F.
> 
> There are two bugs:
> 
>  - it will always screw up the screen and move to the end. It does this 
>    even if you use -FX which should disable any init sequences, so it's 
>    not about that problem.
> 
>  - if you resize the terminal while less is waiting for input, less
>    will exit entirely without even showing the output. This is very
>    noticeable if you do something like "git diff" on a big and cold-cache 
>    tree and git takes a few seconds to think, and then you resize the 
>    window while it's preparing. Boom. No output AT ALL.

Heh. This extremely hacky patch works around the second bug.

It does so by simply adding a "select()" on the input before even starting 
"less", which will mean that by the time less starts, it always has 
something to read, and that in turn hides the bug with resizing the 
terminal window while less is waiting for input.

I'm sure there's still a window for the bug to trigger, but I can no 
longer trivially reproduce the problem any more.

(The way to reproduce the problem is to do some pager operation that takes 
a while in git, and resizing the window while git is thinking about the 
output. I use

	git diff --stat v2.6.12..

in the kernel tree to do something where it takes a while for git to start 
outputting information)

Without this patch, I can easily just resize the window while git is 
thinking, and the end result is that "less" will exit early and indeed 
leave the tty in a broken state with no echo etc. With this patch, less 
doesn't get confused.

NOTE! To see this problem, you must use the LESS environment that git 
provides by default (LESS=FRSX) and not have your own environment set that 
overrides the git ones (or if you do, it must have -F set).

Is it ugly? Yes. Does it work? Yes. Do we want to apply it? You decide.

		Linus

---
diff --git a/pager.c b/pager.c
index 4587fbb..5f280ab 100644
--- a/pager.c
+++ b/pager.c
@@ -1,5 +1,7 @@
 #include "cache.h"
 
+#include <sys/select.h>
+
 /*
  * This is split up from the rest of git so that we might do
  * something different on Windows, for example.
@@ -7,6 +9,16 @@
 
 static void run_pager(const char *pager)
 {
+	/*
+	 * Work around bug in "less" by not starting it until we
+	 * have real input
+	 */
+	fd_set in;
+
+	FD_ZERO(&in);
+	FD_SET(0, &in);
+	select(1, &in, NULL, &in, NULL);
+
 	execlp(pager, pager, NULL);
 	execl("/bin/sh", "sh", "-c", pager, NULL);
 }

Re: [Announce] GIT v1.5.0-rc2

[Junio C Hamano]

Linus Torvalds <torvalds@linux-foundation.org> writes:

> NOTE! To see this problem, you must use the LESS environment that git 
> provides by default (LESS=FRSX) and not have your own environment set that 
> overrides the git ones (or if you do, it must have -F set).
>
> Is it ugly? Yes. Does it work? Yes. Do we want to apply it? You decide.

I would not call it ugly.

I once consiered to fork another process in between the pager
and the caller here and make it buffer "the first screenful"
before actually spawning the pager, or write out the short
output itself without spawning, to fix the "no output but the
cursor goes to the end" problem.  THAT's ugly.

But I do not think your patch is ugly, and it would help normal
people who work in a windowed environment (I did not see the
need for it myself since I usually never resize the terminal --
even working inside X my terminals are usually fixed size and
are always running "screen").

[PATCH] fetch-pack: remove --keep-auto and make it the default.

[Junio C Hamano]

This makes git-fetch over git native protocol to automatically
decide to keep the downloaded pack if the fetch results in more
than 100 objects, just like receive-pack invoked by git-push
does.  This logic is disabled when --keep is explicitly given
from the command line, so that a very small clone still keeps
the downloaded pack as before.

The 100 threshold can be adjusted with fetch.unpacklimit
configuration.  We might want to introduce transfer.unpacklimit
to consolidate the two unpacklimit variables, which will be a
topic for the next patch.

Signed-off-by: Junio C Hamano <junkio@cox.net>
---
  Nicolas Pitre <nico@cam.org> writes:

  > On Tue, 23 Jan 2007, Johannes Schindelin wrote:
  >
  >> On Mon, 22 Jan 2007, Junio C Hamano wrote:
  >> 
  >> > We may want to later make this the default.
  >> 
  >> You have my vote for sooner rather than later.
  >
  > Seconded.
  >
  > Nicolas

  Ok, how about this, on top of the previous ones?

 Documentation/config.txt |   10 ++++++++++
 fetch-pack.c             |   31 +++++++++++++++++--------------
 t/t5500-fetch-pack.sh    |    3 ++-
 3 files changed, 29 insertions(+), 15 deletions(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index d8244b1..383ff29 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -295,6 +295,16 @@ diff.renames::
 	will enable basic rename detection.  If set to "copies" or
 	"copy", it will detect copies, as well.
 
+fetch.unpackLimit::
+	If the number of objects fetched over the git native
+	transfer is below this
+	limit, then the objects will be unpacked into loose object
+	files. However if the number of received objects equals or
+	exceeds this limit then the received pack will be stored as
+	a pack, after adding any missing delta bases.  Storing the
+	pack from a push can make the push operation complete faster,
+	especially on slow filesystems.
+
 format.headers::
 	Additional email headers to include in a patch to be submitted
 	by mail.  See gitlink:git-format-patch[1].
diff --git a/fetch-pack.c b/fetch-pack.c
index dd67e48..fc0534c 100644
--- a/fetch-pack.c
+++ b/fetch-pack.c
@@ -8,7 +8,7 @@
 #include "sideband.h"
 
 static int keep_pack;
-static int keep_auto;
+static int unpack_limit = 100;
 static int quiet;
 static int verbose;
 static int fetch_all;
@@ -503,14 +503,14 @@ static int get_pack(int xd[2])
 
 	av = argv;
 	*hdr_arg = 0;
-	if (keep_auto) {
+	if (unpack_limit) {
 		struct pack_header header;
 
 		if (read_pack_header(fd[0], &header))
 			die("protocol error: bad pack header");
 		snprintf(hdr_arg, sizeof(hdr_arg), "--pack_header=%u,%u",
 			 ntohl(header.hdr_version), ntohl(header.hdr_entries));
-		if (ntohl(header.hdr_entries) < keep_auto)
+		if (ntohl(header.hdr_entries) < unpack_limit)
 			do_keep = 0;
 		else
 			do_keep = 1;
@@ -523,7 +523,7 @@ static int get_pack(int xd[2])
 			*av++ = "-v";
 		if (use_thin_pack)
 			*av++ = "--fix-thin";
-		if (keep_pack > 1 || keep_auto) {
+		if (keep_pack > 1 || unpack_limit) {
 			int s = sprintf(keep_arg,
 					"--keep=fetch-pack %d on ", getpid());
 			if (gethostname(keep_arg + s, sizeof(keep_arg) - s))
@@ -642,6 +642,16 @@ static int remove_duplicates(int nr_heads, char **heads)
 	return dst;
 }
 
+static int fetch_pack_config(const char *var, const char *value)
+{
+	if (strcmp(var, "fetch.unpacklimit") == 0) {
+		unpack_limit = git_config_int(var, value);
+		return 0;
+	}
+
+	return git_default_config(var, value);
+}
+
 static struct lock_file lock;
 
 int main(int argc, char **argv)
@@ -653,6 +663,8 @@ int main(int argc, char **argv)
 	struct stat st;
 
 	setup_git_directory();
+	setup_ident();
+	git_config(fetch_pack_config);
 
 	nr_heads = 0;
 	heads = NULL;
@@ -674,16 +686,7 @@ int main(int argc, char **argv)
 			}
 			if (!strcmp("--keep", arg) || !strcmp("-k", arg)) {
 				keep_pack++;
-				continue;
-			}
-			if (!strcmp("--keep-auto", arg)) {
-				keep_auto = 100;
-				continue;
-			}
-			if (!strncmp("--keep-auto=", arg, 12)) {
-				keep_auto = strtoul(arg + 12, NULL, 0);
-				if (keep_auto < 20)
-					keep_auto = 20;
+				unpack_limit = 0;
 				continue;
 			}
 			if (!strcmp("--thin", arg)) {
diff --git a/t/t5500-fetch-pack.sh b/t/t5500-fetch-pack.sh
index ef78df6..7fd651b 100755
--- a/t/t5500-fetch-pack.sh
+++ b/t/t5500-fetch-pack.sh
@@ -97,7 +97,8 @@ pull_to_client () {
 (
 	mkdir client &&
 	cd client &&
-	git-init 2>> log2.txt
+	git-init 2>> log2.txt &&
+	git repo-config fetch.unpacklimit 0
 )
 
 add A1

[PATCH] Consolidate {receive,fetch}.unpackLimit

[Junio C Hamano]

This allows transfer.unpackLimit to specify what these two
configuration variables want to set.

We would probably want to deprecate the two separate variables,
as I do not see much point in specifying them independently.

Signed-off-by: Junio C Hamano <junkio@cox.net>
---
 Documentation/config.txt |    5 +++++
 fetch-pack.c             |   14 +++++++++++++-
 receive-pack.c           |   24 ++++++++++++++++--------
 t/t5500-fetch-pack.sh    |    2 +-
 4 files changed, 35 insertions(+), 10 deletions(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index 383ff29..8086d75 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -488,3 +488,8 @@ receive.denyNonFastForwards::
 	even if that push is forced. This configuration variable is
 	set when initializing a shared repository.
 
+transfer.unpackLimit::
+	When `fetch.unpackLimit` or `receive.unpackLimit` are
+	not set, the value of this variable is used instead.
+
+
diff --git a/fetch-pack.c b/fetch-pack.c
index fc0534c..83a1d7b 100644
--- a/fetch-pack.c
+++ b/fetch-pack.c
@@ -8,6 +8,8 @@
 #include "sideband.h"
 
 static int keep_pack;
+static int transfer_unpack_limit = -1;
+static int fetch_unpack_limit = -1;
 static int unpack_limit = 100;
 static int quiet;
 static int verbose;
@@ -645,7 +647,12 @@ static int remove_duplicates(int nr_heads, char **heads)
 static int fetch_pack_config(const char *var, const char *value)
 {
 	if (strcmp(var, "fetch.unpacklimit") == 0) {
-		unpack_limit = git_config_int(var, value);
+		fetch_unpack_limit = git_config_int(var, value);
+		return 0;
+	}
+
+	if (strcmp(var, "transfer.unpacklimit") == 0) {
+		transfer_unpack_limit = git_config_int(var, value);
 		return 0;
 	}
 
@@ -666,6 +673,11 @@ int main(int argc, char **argv)
 	setup_ident();
 	git_config(fetch_pack_config);
 
+	if (0 <= transfer_unpack_limit)
+		unpack_limit = transfer_unpack_limit;
+	else if (0 <= fetch_unpack_limit)
+		unpack_limit = fetch_unpack_limit;
+
 	nr_heads = 0;
 	heads = NULL;
 	for (i = 1; i < argc; i++) {
diff --git a/receive-pack.c b/receive-pack.c
index b3a4552..8b59b32 100644
--- a/receive-pack.c
+++ b/receive-pack.c
@@ -10,6 +10,8 @@
 static const char receive_pack_usage[] = "git-receive-pack <git-dir>";
 
 static int deny_non_fast_forwards = 0;
+static int receive_unpack_limit = -1;
+static int transfer_unpack_limit = -1;
 static int unpack_limit = 100;
 static int report_status;
 
@@ -18,21 +20,22 @@ static int capabilities_sent;
 
 static int receive_pack_config(const char *var, const char *value)
 {
-	git_default_config(var, value);
-
-	if (strcmp(var, "receive.denynonfastforwards") == 0)
-	{
+	if (strcmp(var, "receive.denynonfastforwards") == 0) {
 		deny_non_fast_forwards = git_config_bool(var, value);
 		return 0;
 	}
 
-	if (strcmp(var, "receive.unpacklimit") == 0)
-	{
-		unpack_limit = git_config_int(var, value);
+	if (strcmp(var, "receive.unpacklimit") == 0) {
+		receive_unpack_limit = git_config_int(var, value);
 		return 0;
 	}
 
-	return 0;
+	if (strcmp(var, "transfer.unpacklimit") == 0) {
+		transfer_unpack_limit = git_config_int(var, value);
+		return 0;
+	}
+
+	return git_default_config(var, value);
 }
 
 static int show_ref(const char *path, const unsigned char *sha1, int flag, void *cb_data)
@@ -431,6 +434,11 @@ int main(int argc, char **argv)
 	ignore_missing_committer_name();
 	git_config(receive_pack_config);
 
+	if (0 <= transfer_unpack_limit)
+		unpack_limit = transfer_unpack_limit;
+	else if (0 <= receive_unpack_limit)
+		unpack_limit = receive_unpack_limit;
+
 	write_head_info();
 
 	/* EOF */
diff --git a/t/t5500-fetch-pack.sh b/t/t5500-fetch-pack.sh
index 7fd651b..058cce0 100755
--- a/t/t5500-fetch-pack.sh
+++ b/t/t5500-fetch-pack.sh
@@ -98,7 +98,7 @@ pull_to_client () {
 	mkdir client &&
 	cd client &&
 	git-init 2>> log2.txt &&
-	git repo-config fetch.unpacklimit 0
+	git repo-config transfer.unpacklimit 0
 )
 
 add A1
-- 
1.5.0.rc2.gae1d

Re: [PATCH] Consolidate {receive,fetch}.unpackLimit

[Nicolas Pitre]

On Wed, 24 Jan 2007, Junio C Hamano wrote:

> This allows transfer.unpackLimit to specify what these two
> configuration variables want to set.
> 
> We would probably want to deprecate the two separate variables,
> as I do not see much point in specifying them independently.

Well... since they're already there and not hurting anything I would let 
them live.  Never know how they might be useful.


Nicolas

Re: [PATCH] Consolidate {receive,fetch}.unpackLimit

[Shawn O. Pearce]

Junio C Hamano <junkio@cox.net> wrote:
> This allows transfer.unpackLimit to specify what these two
> configuration variables want to set.
> 
> We would probably want to deprecate the two separate variables,
> as I do not see much point in specifying them independently.

Indeed.  I was going to fix this too, but reuse receive.unpackLimit.
From my point of view both fetch and receive-pack are recieving
objects into this repository; and in either case I want the same
behavior with regards to loose object/pack management.

-- 
Shawn.

Re: [PATCH] fetch-pack: remove --keep-auto and make it the default.

[Johannes Schindelin]

Hi,

On Wed, 24 Jan 2007, Junio C Hamano wrote:

>   Ok, how about this, on top of the previous ones?

Thanks!

> @@ -653,6 +663,8 @@ int main(int argc, char **argv)
>  	struct stat st;
>  
>  	setup_git_directory();
> +	setup_ident();
> +	git_config(fetch_pack_config);

Why do you need setup_ident()?

Ciao,
Dscho

Re: [PATCH] fetch-pack: remove --keep-auto and make it the default.

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> On Wed, 24 Jan 2007, Junio C Hamano wrote:
>
>>   Ok, how about this, on top of the previous ones?
>
> Thanks!
>
>> @@ -653,6 +663,8 @@ int main(int argc, char **argv)
>>  	struct stat st;
>>  
>>  	setup_git_directory();
>> +	setup_ident();
>> +	git_config(fetch_pack_config);
>
> Why do you need setup_ident()?

Because presumably you would be updating the reflog that records
who did the fetch?

But then we should do the same ignore_missing_committer_name()
we have in receive-pack to allow anonymous fetchers to fetch
from outside world, I guess.

Re: [PATCH] fetch-pack: remove --keep-auto and make it the default.

[Johannes Schindelin]

Hi,

On Thu, 25 Jan 2007, Junio C Hamano wrote:

> > Why do you need setup_ident()?
> 
> Because presumably you would be updating the reflog that records
> who did the fetch?

Ah yes, that makes sense!

Thank you,
Dscho

Re: [PATCH] fetch-pack: remove --keep-auto and make it the default.

[Junio C Hamano]

Junio C Hamano <junkio@cox.net> writes:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>> On Wed, 24 Jan 2007, Junio C Hamano wrote:
>>
>>>   Ok, how about this, on top of the previous ones?
>>
>> Thanks!
>>
>>> @@ -653,6 +663,8 @@ int main(int argc, char **argv)
>>>  	struct stat st;
>>>  
>>>  	setup_git_directory();
>>> +	setup_ident();
>>> +	git_config(fetch_pack_config);
>>
>> Why do you need setup_ident()?
>
> Because presumably you would be updating the reflog that records
> who did the fetch?
>
> But then we should do the same ignore_missing_committer_name()
> we have in receive-pack to allow anonymous fetchers to fetch
> from outside world, I guess.

This turns out to be more serious than I expected.

The code that uses committer_info() in reflog can barf and die.
And I do not think calling ignore_missing_committer_name()
upfront like recent receive-pack did in the aplication is a
reasonable workaround.

So I am thinking about doing something like the attached patch.

What the patch does.

 - git_committer_info() takes one parameter.  It used to be "if
   this is true, then die() if the name is not available due to
   bad GECOS, otherwise issue a warning once but leave the name
   empty".  The reason was because we wanted to prevent bad
   commits from being made by git-commit-tree (and its
   callers).  The value 0 is only used by "git var -l". 

   Now it takes -1, 0 or 1.  When set to -1, it does not
   complain but uses the pw->pw_name when name is not
   available.  Existing 0 and 1 values mean the same thing as
   they used to mean before.  0 means issue warnings and leave
   it empty, 1 means barf and die.

 - ignore_missing_committer_name() and its existing caller
   (receive-pack, to set the reflog) have been removed.

 - git-format-patch, to come up with the phoney message ID when
   asked to thread, now passes -1 to git_committer_info().  This
   codepath uses only the e-mail part, ignoring the name.  It
   used to barf and die.  The other call in the same program
   when asked to add signed-off-by line based on committer
   identity still passes 1 to make sure it barfs instead of
   adding a bogus s-o-b line.

 - log_ref_write in refs.c, to come up with the name to record
   who initiated the ref update in the reflog, passes -1.  It
   used to barf and die.

The last change means that git-update-ref, git-branch, and
commit walker backends can now be used in a repository with
reflog by somebody who does not have the user identity required
to make a commit.  They all used to barf and die.

I've run tests and all of them seem to pass, and also tried "git
clone" as a user whose GECOS is empty -- git clone works again
now (it was broken when reflog was enabled by default).

But this definitely needs extra sets of eyeballs.

---
diff --git a/builtin-log.c b/builtin-log.c
index 503cd1e..56acc13 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -352,7 +352,7 @@ static void get_patch_ids(struct rev_info *rev, struct diff_options *options, co
 
 static void gen_message_id(char *dest, unsigned int length, char *base)
 {
-	const char *committer = git_committer_info(1);
+	const char *committer = git_committer_info(-1);
 	const char *email_start = strrchr(committer, '<');
 	const char *email_end = strrchr(committer, '>');
 	if(!email_start || !email_end || email_start > email_end - 1)
diff --git a/cache.h b/cache.h
index 473197d..9486132 100644
--- a/cache.h
+++ b/cache.h
@@ -320,7 +320,6 @@ void datestamp(char *buf, int bufsize);
 unsigned long approxidate(const char *);
 
 extern int setup_ident(void);
-extern void ignore_missing_committer_name(void);
 extern const char *git_author_info(int);
 extern const char *git_committer_info(int);
 
diff --git a/fetch-pack.c b/fetch-pack.c
index 4df7450..83a1d7b 100644
--- a/fetch-pack.c
+++ b/fetch-pack.c
@@ -671,8 +671,6 @@ int main(int argc, char **argv)
 
 	setup_git_directory();
 	setup_ident();
-	/* don't die if gecos is empty */
-	ignore_missing_committer_name();
 	git_config(fetch_pack_config);
 
 	if (0 <= transfer_unpack_limit)
diff --git a/ident.c b/ident.c
index 6ad8fed..f967790 100644
--- a/ident.c
+++ b/ident.c
@@ -180,12 +180,21 @@ static const char *get_ident(const char *name, const char *email,
 		email = git_default_email;
 
 	if (!*name) {
-		if (name == git_default_name && env_hint) {
+		struct passwd *pw;
+
+		if (0 <= error_on_no_name &&
+		    name == git_default_name && env_hint) {
 			fprintf(stderr, env_hint, au_env, co_env);
 			env_hint = NULL; /* warn only once, for "git-var -l" */
 		}
-		if (error_on_no_name)
+		if (0 < error_on_no_name)
 			die("empty ident %s <%s> not allowed", name, email);
+		pw = getpwuid(getuid());
+		if (!pw)
+			die("You don't exist. Go away!");
+		strlcpy(git_default_name, pw->pw_name,
+			sizeof(git_default_name));
+		name = git_default_name;
 	}
 
 	strcpy(date, git_default_date);
@@ -218,18 +227,3 @@ const char *git_committer_info(int error_on_no_name)
 			 getenv("GIT_COMMITTER_DATE"),
 			 error_on_no_name);
 }
-
-void ignore_missing_committer_name()
-{
-	/* If we did not get a name from the user's gecos entry then
-	 * git_default_name is empty; so instead load the username
-	 * into it as a 'good enough for now' approximation of who
-	 * this user is.
-	 */
-	if (!*git_default_name) {
-		struct passwd *pw = getpwuid(getuid());
-		if (!pw)
-			die("You don't exist. Go away!");
-		strlcpy(git_default_name, pw->pw_name, sizeof(git_default_name));
-	}
-}
diff --git a/receive-pack.c b/receive-pack.c
index 8b59b32..7d26326 100644
--- a/receive-pack.c
+++ b/receive-pack.c
@@ -430,8 +430,6 @@ int main(int argc, char **argv)
 		die("attempt to push into a shallow repository");
 
 	setup_ident();
-	/* don't die if gecos is empty */
-	ignore_missing_committer_name();
 	git_config(receive_pack_config);
 
 	if (0 <= transfer_unpack_limit)
diff --git a/refs.c b/refs.c
index 8117328..4323e9a 100644
--- a/refs.c
+++ b/refs.c
@@ -958,7 +958,7 @@ static int log_ref_write(struct ref_lock *lock,
 				     lock->log_file, strerror(errno));
 	}
 
-	committer = git_committer_info(1);
+	committer = git_committer_info(-1);
 	if (msg) {
 		maxlen = strlen(committer) + strlen(msg) + 2*40 + 5;
 		logrec = xmalloc(maxlen);

[PATCH] Allow non-developer to clone, checkout and fetch easier.

[Junio C Hamano]

The code that uses committer_info() in reflog can barf and die
whenever it is asked to update a ref.  And I do not think
calling ignore_missing_committer_name() upfront like recent
receive-pack did in the aplication is a reasonable workaround.

What the patch does.

 - git_committer_info() takes one parameter.  It used to be "if
   this is true, then die() if the name is not available due to
   bad GECOS, otherwise issue a warning once but leave the name
   empty".  The reason was because we wanted to prevent bad
   commits from being made by git-commit-tree (and its
   callers).  The value 0 is only used by "git var -l".

   Now it takes -1, 0 or 1.  When set to -1, it does not
   complain but uses the pw->pw_name when name is not
   available.  Existing 0 and 1 values mean the same thing as
   they used to mean before.  0 means issue warnings and leave
   it empty, 1 means barf and die.

 - ignore_missing_committer_name() and its existing caller
   (receive-pack, to set the reflog) have been removed.

 - git-format-patch, to come up with the phoney message ID when
   asked to thread, now passes -1 to git_committer_info().  This
   codepath uses only the e-mail part, ignoring the name.  It
   used to barf and die.  The other call in the same program
   when asked to add signed-off-by line based on committer
   identity still passes 1 to make sure it barfs instead of
   adding a bogus s-o-b line.

 - log_ref_write in refs.c, to come up with the name to record
   who initiated the ref update in the reflog, passes -1.  It
   used to barf and die.

The last change means that git-update-ref, git-branch, and
commit walker backends can now be used in a repository with
reflog by somebody who does not have the user identity required
to make a commit.  They all used to barf and die.

I've run tests and all of them seem to pass, and also tried "git
clone" as a user whose GECOS is empty -- git clone works again
now (it was broken when reflog was enabled by default).

But this definitely needs extra sets of eyeballs.

Signed-off-by: Junio C Hamano <junkio@cox.net>
---

 * Here is an updated patch -- the previous one was on top of
   what was never committed, and was useless.

 builtin-log.c  |    2 +-
 cache.h        |    1 -
 ident.c        |   28 +++++++++++-----------------
 receive-pack.c |    2 --
 refs.c         |    2 +-
 5 files changed, 13 insertions(+), 22 deletions(-)

diff --git a/builtin-log.c b/builtin-log.c
index 503cd1e..56acc13 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -352,7 +352,7 @@ static void get_patch_ids(struct rev_info *rev, struct diff_options *options, co
 
 static void gen_message_id(char *dest, unsigned int length, char *base)
 {
-	const char *committer = git_committer_info(1);
+	const char *committer = git_committer_info(-1);
 	const char *email_start = strrchr(committer, '<');
 	const char *email_end = strrchr(committer, '>');
 	if(!email_start || !email_end || email_start > email_end - 1)
diff --git a/cache.h b/cache.h
index 473197d..9486132 100644
--- a/cache.h
+++ b/cache.h
@@ -320,7 +320,6 @@ void datestamp(char *buf, int bufsize);
 unsigned long approxidate(const char *);
 
 extern int setup_ident(void);
-extern void ignore_missing_committer_name(void);
 extern const char *git_author_info(int);
 extern const char *git_committer_info(int);
 
diff --git a/ident.c b/ident.c
index 6ad8fed..f967790 100644
--- a/ident.c
+++ b/ident.c
@@ -180,12 +180,21 @@ static const char *get_ident(const char *name, const char *email,
 		email = git_default_email;
 
 	if (!*name) {
-		if (name == git_default_name && env_hint) {
+		struct passwd *pw;
+
+		if (0 <= error_on_no_name &&
+		    name == git_default_name && env_hint) {
 			fprintf(stderr, env_hint, au_env, co_env);
 			env_hint = NULL; /* warn only once, for "git-var -l" */
 		}
-		if (error_on_no_name)
+		if (0 < error_on_no_name)
 			die("empty ident %s <%s> not allowed", name, email);
+		pw = getpwuid(getuid());
+		if (!pw)
+			die("You don't exist. Go away!");
+		strlcpy(git_default_name, pw->pw_name,
+			sizeof(git_default_name));
+		name = git_default_name;
 	}
 
 	strcpy(date, git_default_date);
@@ -218,18 +227,3 @@ const char *git_committer_info(int error_on_no_name)
 			 getenv("GIT_COMMITTER_DATE"),
 			 error_on_no_name);
 }
-
-void ignore_missing_committer_name()
-{
-	/* If we did not get a name from the user's gecos entry then
-	 * git_default_name is empty; so instead load the username
-	 * into it as a 'good enough for now' approximation of who
-	 * this user is.
-	 */
-	if (!*git_default_name) {
-		struct passwd *pw = getpwuid(getuid());
-		if (!pw)
-			die("You don't exist. Go away!");
-		strlcpy(git_default_name, pw->pw_name, sizeof(git_default_name));
-	}
-}
diff --git a/receive-pack.c b/receive-pack.c
index 8b59b32..7d26326 100644
--- a/receive-pack.c
+++ b/receive-pack.c
@@ -430,8 +430,6 @@ int main(int argc, char **argv)
 		die("attempt to push into a shallow repository");
 
 	setup_ident();
-	/* don't die if gecos is empty */
-	ignore_missing_committer_name();
 	git_config(receive_pack_config);
 
 	if (0 <= transfer_unpack_limit)
diff --git a/refs.c b/refs.c
index 8117328..4323e9a 100644
--- a/refs.c
+++ b/refs.c
@@ -958,7 +958,7 @@ static int log_ref_write(struct ref_lock *lock,
 				     lock->log_file, strerror(errno));
 	}
 
-	committer = git_committer_info(1);
+	committer = git_committer_info(-1);
 	if (msg) {
 		maxlen = strlen(committer) + strlen(msg) + 2*40 + 5;
 		logrec = xmalloc(maxlen);
-- 
1.5.0.rc2.g1b55

Re: [PATCH] fetch-pack: remove --keep-auto and make it the default.

[Johannes Sixt]

Junio C Hamano wrote:
> 
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > On Wed, 24 Jan 2007, Junio C Hamano wrote:
> >
> >>   Ok, how about this, on top of the previous ones?
> >
> > Thanks!
> >
> >> @@ -653,6 +663,8 @@ int main(int argc, char **argv)
> >>      struct stat st;
> >>
> >>      setup_git_directory();
> >> +    setup_ident();
> >> +    git_config(fetch_pack_config);
> >
> > Why do you need setup_ident()?
> 
> Because presumably you would be updating the reflog that records
> who did the fetch?
> 
> But then we should do the same ignore_missing_committer_name()
> we have in receive-pack to allow anonymous fetchers to fetch
> from outside world, I guess.

Instead of using ignore_missing_committer_name(), use
get_committer_info(0) in refs.c. cherry-pick 4feaf032d3 from my tree at
git://repo.or.cz/git/mingw.git if you want.

Although this approach leaves the name+email in the reflog entry empty
instead of writing "unkown"...

-- Hannes

Re: [PATCH] Allow non-developer to clone, checkout and fetch easier.

[Alex Riesen]

On 1/26/07, Junio C Hamano <junkio@cox.net> wrote:
> The code that uses committer_info() in reflog can barf and die
> whenever it is asked to update a ref.  And I do not think
> calling ignore_missing_committer_name() upfront like recent
> receive-pack did in the aplication is a reasonable workaround.
>
> What the patch does.
>
>  - git_committer_info() takes one parameter.  It used to be "if
>    this is true, then die() if the name is not available due to
>    bad GECOS, otherwise issue a warning once but leave the name
>    empty".  The reason was because we wanted to prevent bad
>    commits from being made by git-commit-tree (and its
>    callers).  The value 0 is only used by "git var -l".
>
>    Now it takes -1, 0 or 1.  When set to -1, it does not
>    complain but uses the pw->pw_name when name is not
>    available.  Existing 0 and 1 values mean the same thing as
>    they used to mean before.  0 means issue warnings and leave
>    it empty, 1 means barf and die.

 enum {
    CMITR_INFO_PW_NAME = -1,
    CMITR_INFO_EMPTY = 0,
    CMITR_INFO_DIE = 1,
 };

-       const char *committer = git_committer_info(CMITR_INFO_DIE);
+       const char *committer = git_committer_info(CMITR_INFO_PW_NAME);

The code becoming increasingly harder to read, doesn't it...

Re: [Announce] GIT v1.5.0-rc2

[Mark Nudelman]

Hi all,
I'm not sure if you are still interested in this, but I have posted a 
beta release of less (less-401) which I believe fixes both of these 
problems.  See http://www.greenwoodsoftware.com/less.  If you try it, 
let me know how it works for you.

--Mark


On 1/23/2007 12:32 PM, Linus Torvalds wrote:
> [ Added "less" author Mark Nudelman to Cc: ]
> 
> On Tue, 23 Jan 2007, Bill Lear wrote:
>> I can't seem to get this to work, no matter what I do, using the
>> latest 1.5.0-rc2 code.  I have the environment variables LESS, PAGER,
>> PAGER_FLAGS, and I can't seem to get 'git diff' to not plough through
>> my screen each time it is run, no matter the combinations...  Could
>> someone post the magic?
> 
> I think "less" is actually seriously buggy with -F.
> 
> There are two bugs:
> 
>  - it will always screw up the screen and move to the end. It does this 
>    even if you use -FX which should disable any init sequences, so it's 
>    not about that problem.
> 
>  - if you resize the terminal while less is waiting for input, less
>    will exit entirely without even showing the output. This is very
>    noticeable if you do something like "git diff" on a big and cold-cache 
>    tree and git takes a few seconds to think, and then you resize the 
>    window while it's preparing. Boom. No output AT ALL.
> 
> Both bugs are easily seen with this simple command line
> 
> 	clear ; (sleep 5 ; echo Hello) | less -F
> 
> where you would EXPECT that the "Hello" would show up at the first line of 
> the screen (since we cleared the screen and moved to the top left corner), 
> but in fact it doesn't.
> 
> And try resizing the terminal to make it bigger during the five-second 
> pause, and now you'll see less not show the "Hello" at _all_. It's just 
> gone (this is true even if the output was _more_ than a screen: try with
> 
> 	(sleep 10 ; yes ) | less -F
> 
> and resize the screen, and it will exit silently after 10 seconds - never 
> showing any output at all! Even though the output is obviously bigger than 
> a screen..
> 
> Tested with Kterm, gnome-terminal and xterm. They all behave the same for 
> me.
> 
> I don't know exactly what the bug is, but I find the "eof" handling very
> confusing in the less sources. It makes me suspect that there is something 
> that gets confused by the partial read, sets EOF (since we're on the last 
> line), and then thinks that it should quit, since EOF is set.
> 
> I dunno. Mark?
> 
> 		Linus
>