Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Commits on May 20, 2007
  1. GIT 1.5.2

    Junio C Hamano authored
    Signed-off-by: Junio C Hamano <junkio@cox.net>
  2. git-cvsserver: exit with 1 upon "I HATE YOU"

    Junio C Hamano authored
    Signed-off-by: Junio C Hamano <junkio@cox.net>
  3. Merge branch 'maint' to synchronize with 1.5.1.6

    Junio C Hamano authored
    * maint:
      GIT 1.5.1.6
      git-svn: don't minimize-url when doing an init that tracks multiple paths
      git-svn: avoid crashing svnserve when creating new directories
      user-manual: Add section on ignoring files
      user-manual: finding commits referencing given file content
      user-manual: discourage shared repository
      tutorial: revise index introduction
      tutorials: add user-manual links
    
    Conflicts:
    
    	GIT-VERSION-GEN
    	RelNotes
  4. GIT 1.5.1.6

    Junio C Hamano authored
    Signed-off-by: Junio C Hamano <junkio@cox.net>
  5. Merge branch 'maint' of git://linux-nfs.org/~bfields/git into maint

    Junio C Hamano authored
    * 'maint' of git://linux-nfs.org/~bfields/git:
      user-manual: Add section on ignoring files
      user-manual: finding commits referencing given file content
      user-manual: discourage shared repository
      tutorial: revise index introduction
      tutorials: add user-manual links
Commits on May 19, 2007
  1. git-svn: don't minimize-url when doing an init that tracks multiple p…

    Eric Wong authored Junio C Hamano committed
    …aths
    
    I didn't have a chance to test the off-by-default minimize-url
    stuff enough before, but it's quite broken for people passing
    the --trunk/-T, --tags/-t, --branches/-b switches to "init" or
    "clone" commands.
    
    Additionally, follow-parent functionality seems broken when we're
    not connected to the root of the repository.
    
    Default behavior for "traditional" git-svn users who only track
    one directory (without needing follow-parent) should be
    reasonable, as those users started using things before
    minimize-url functionality existed.
    
    Behavior for users more used to the git-svnimport-like command
    line will also benefit from a more-flexible command-line than
    svnimport given the assumption they're working with
    non-restrictive read permissions on the repository.
    
    I hope to properly fix these bugs when I get a chance to in the
    next week or so, but I would like to get this stopgap measure of
    reverting to the old behavior as soon as possible.
    
    Signed-off-by: Eric Wong <normalperson@yhbt.net>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
  2. git-svn: avoid crashing svnserve when creating new directories

    Eric Wong authored Junio C Hamano committed
    When sorting directory names by depth (slash ("/") count) and
    closing the deepest directories first (as the protocol
    requires), we failed to put the root baton (with an empty string
    as its key "") after top-level directories (which did not have
    any slashes).
    
    This resulted in svnserve being in a situation it couldn't
    handle and caused a segmentation fault on the remote server.
    
    This bug did not affect users of DAV and filesystem repositories.
    
    Signed-off-by: Eric Wong <normalperson@yhbt.net>
    Confirmed-by: Matthieu Moy <Matthieu.Moy@imag.fr>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
  3. @jherland

    user-manual: Add section on ignoring files

    jherland authored J. Bruce Fields committed
    The todo list at the end of the user manual says that something must be
    said about .gitignore. Also, there seems to be a lack of documentation
    on how to choose between the various types of ignore files (.gitignore
    vs. .git/info/exclude, etc.).
    
    This patch adds a section on ignoring files which try to introduce how
    to tell git about ignored files, and how the different strategies
    complement eachother.
    
    The syntax of exclude patterns is explained in a simplified manner, with
    a reference to git-ls-files(1) which already contains a more thorough
    explanation.
    
    Signed-off-by: Johan Herland <johan@herland.net>
  4. user-manual: finding commits referencing given file content

    J. Bruce Fields authored
    Another amusing git exploration example brought up in irc.  (Credit to
    aeruder for the complete solution.)
    
    Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
  5. user-manual: discourage shared repository

    J. Bruce Fields authored
    I don't really want to look like we're encouraging the shared repository
    thing.  Take down some of the argument for using purely
    single-developer-owned repositories and collaborating using patches and
    pulls instead.
    
    Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
  6. tutorial: revise index introduction

    J. Bruce Fields authored
    The embarassing history of this tutorial is that I started it without
    really understanding the index well, so I avoided mentioning it.
    
    And we all got the idea that "index" was a word to avoid using around
    newbies, but it was reluctantly mentioned that *something* had to be
    said.  The result is a little awkward: the discussion of the index never
    actually uses that word, and isn't well-integrated into the surrounding
    material.
    
    Let's just go ahead and use the word "index" from the very start, and
    try to demonstrate its use with a minimum of lecturing.
    
    Also, remove discussion of using git-commit with explicit filenames.
    We're already a bit slow here to get people to their first commit, and
    I'm not convinced this is really so important.
    
    Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
  7. tutorials: add user-manual links

    J. Bruce Fields authored
    Mention the user manual, especially as an alternative introduction for
    user's mainly interested in read-only operations.
    
    And fix a typo while we're there.
    
    Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
  8. Merge branch 'maint'

    Junio C Hamano authored
    * maint:
      Documentation: Reformatted SYNOPSIS for several commands
      Documentation: Added [verse] to SYNOPSIS where necessary
  9. @matthiask

    Documentation: Reformatted SYNOPSIS for several commands

    matthiask authored Junio C Hamano committed
    Signed-off-by: Matthias Kestenholz <matthias@spinlock.ch>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
  10. @matthiask

    Documentation: Added [verse] to SYNOPSIS where necessary

    matthiask authored Junio C Hamano committed
    Signed-off-by: Matthias Kestenholz <matthias@spinlock.ch>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
  11. Documentation/git.txt: Update links to older documentation pages.

    Junio C Hamano authored
    It's starting to take too much space at the beginning of the
    main documentation page.
    
    Signed-off-by: Junio C Hamano <junkio@cox.net>
  12. @jnareb

    gitweb: Fix "Use of uninitialized value" warning in git_feed

    jnareb authored Junio C Hamano committed
    Initial (root) commit has no parents, and $co{'parent'} is
    undefined. Use '--root' for initial commit.
    
    This fixes "Use of uninitialized value in open at gitweb/gitweb.perl
    line 4925." warning.
    
    Signed-off-by: Jakub Narebski <jnareb@gmail.com>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
  13. Merge branch 'sp/cvsexport'

    Junio C Hamano authored
    * sp/cvsexport:
      Optimized cvsexportcommit: calling 'cvs status' once instead of once per touched file.
  14. Add link to 1.5.1.5 release notes.

    Junio C Hamano authored
    Signed-off-by: Junio C Hamano <junkio@cox.net>
  15. Merge 1.5.1.5 in

    Junio C Hamano authored
    Signed-off-by: Junio C Hamano <junkio@cox.net>
  16. GIT v1.5.1.5

    Junio C Hamano authored
    Signed-off-by: Junio C Hamano <junkio@cox.net>
  17. Merge branch 'maint' of git://linux-nfs.org/~bfields/git into maint

    Junio C Hamano authored
    * 'maint' of git://linux-nfs.org/~bfields/git:
      user-manual: reorganize public git repo discussion
      user-manual: listing commits reachable from some refs not others
      user-manual: introduce git
      user-manual: add a "counting commits" example
      user-manual: move howto/using-topic-branches into manual
      user-manual: move howto/make-dist.txt into user manual
      Documentation: remove howto's now incorporated into manual
      user-manual: move quick-start to an appendix
      glossary: expand and clarify some definitions, prune cross-references
      user-manual: revise birdseye-view chapter
      Add a birdview-on-the-source-code section to the user manual
  18. gitweb: Remove redundant $searchtype setup

    Petr Baudis authored Junio C Hamano committed
    Sorry, this was inadverently introduced by my grep search patch. It causes
    annoying "redefined" warnings.
    
    Signed-off-by: Petr Baudis <pasky@suse.cz>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
  19. Documentation: git-rev-list's "patterns"

    Petr Baudis authored Junio C Hamano committed
    git-rev-list(1) talks about patterns as values for the
    --grep, --committed etc. parameters, without going into detail.
    This patch mentions that these patterns are actually regexps.
    
    Signed-off-by: Petr Baudis <pasky@suse.cz>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
  20. @andyparkins

    Fix crlf attribute handling to match documentation

    andyparkins authored Junio C Hamano committed
    gitattributes.txt says, of the crlf attribute:
    
     Set::
        Setting the `crlf` attribute on a path is meant to mark
        the path as a "text" file.  'core.autocrlf' conversion
        takes place without guessing the content type by
        inspection.
    
    That is to say that the crlf attribute does not force the file to have
    CRLF line endings, instead it removes the autocrlf guesswork and forces
    the file to be treated as text.  Then, whatever line ending is defined
    by the autocrlf setting is applied.
    
    However, that is not what convert.c was doing.  The conversion to CRLF
    was being skipped in crlf_to_worktree() when the following condition was
    true:
    
     action == CRLF_GUESS && auto_crlf <= 0
    
    That is to say conversion took place when not in guess mode (crlf attribute
    not specified) or core.autocrlf set to true.  This was wrong.  It meant
    that the crlf attribute being on for a given file _forced_ CRLF
    conversion, when actually it should force the file to be treated as
    text, and converted accordingly.  The real test should simply be
    
     auto_crlf <= 0
    
    That is to say, if core.autocrlf is falsei (or input), conversion from
    LF to CRLF is never done.  When core.autocrlf is true, conversion from
    LF to CRLF is done only when in CRLF_GUESS (and the guess is "text"), or
    CRLF_TEXT mode.
    
    Similarly for crlf_to_worktree(), if core.autocrlf is false, no conversion
    should _ever_ take place.  In reality it was only not taking place if
    core.autocrlf was false _and_ the crlf attribute was unspecified.
    
    Signed-off-by: Andy Parkins <andyparkins@gmail.com>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
Commits on May 18, 2007
  1. git-archive: convert archive entries like checkouts do

    René Scharfe authored Junio C Hamano committed
    As noted by Johan Herland, git-archive is a kind of checkout and needs
    to apply any checkout filters that might be configured.
    
    This patch adds the convenience function convert_sha1_file which returns
    a buffer containing the object's contents, after converting, if necessary
    (i.e. it's a combination of read_sha1_file and convert_to_working_tree).
    Direct calls to read_sha1_file in git-archive are then replaced by calls
    to convert_sha1_file.
    
    Since convert_sha1_file expects its path argument to be NUL-terminated --
    a convention it inherits from convert_to_working_tree -- the patch also
    changes the path handling in archive-tar.c to always NUL-terminate the
    string.  It used to solely rely on the len field of struct strbuf before.
    
    archive-zip.c already NUL-terminates the path and thus needs no such
    change.
    
    Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
  2. user-manual: reorganize public git repo discussion

    J. Bruce Fields authored
    Helping a couple people set up public repos recently, I wanted to point
    them at this piece of the user manual, but found it wasn't as helpful as
    it could be:
    
    	- It starts with a big explanation of why you'd want a public
    	  repository, not necessary in their case since they already knew
    	  why they wanted that.  So, separate that out.
    	- It skimps on some of the git-daemon details, and puts the http
    	  export information first.  Fix that.
    
    Also group all the public repo subsections into a single section, and do
    some miscellaneous related editing.
    
    Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
  3. user-manual: listing commits reachable from some refs not others

    J. Bruce Fields authored
    This is just an amusing example raised by someone in irc.
    
    Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
  4. user-manual: introduce git

    J. Bruce Fields authored
    Well, we should say at least something about what git is.
    
    Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
  5. user-manual: add a "counting commits" example

    J. Bruce Fields authored
    This is partly just an excuse to mention --pretty= and rev-list.
    
    Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
  6. user-manual: move howto/using-topic-branches into manual

    J. Bruce Fields authored
    Move howto/using-topic-branches into the user manual as an example for
    the "sharing development" chapter.  While we're at it, remove some
    discussion that's covered in earlier chapters, modernize somewhat (use
    separate-heads setup, remotes, replace "whatchanged" by "log", etc.),
    and replace syntax we'd need to explain by syntax we've already covered
    (e.g. old..new instead of new ^old).
    
    The result may not really describe what Tony Luck does any more.... Hope
    that's not annoying.
    
    Cc: Tony Luck <tony.luck@intel.com>
    Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
  7. user-manual: move howto/make-dist.txt into user manual

    J. Bruce Fields authored
    There seems to be a perception that the howto's are bit-rotting a
    little.  The manual might be a more visible location for some of them,
    and make-dist.txt seems like a good candidate to include as an example
    in the manual.
    
    For now, incorporate much of it verbatim.  Later we may want to update
    the example a bit.
    
    Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
  8. Documentation: remove howto's now incorporated into manual

    J. Bruce Fields authored
    These two howto's have both been copied into the manual.  I'd rather not
    maintain both versions if possible, and I think the user-manual will be
    more visible than the howto directory.  (Though I wouldn't mind some
    duplication if people really like having them here.)
    
    Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
  9. user-manual: move quick-start to an appendix

    J. Bruce Fields authored
    The quick start interrupts the flow of the manual a bit.  Move it to
    "appendix A" but add a reference to it in the preface.  Also rename the
    todo chapter to "appendix B", and revise the preface a little.
    
    Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
  10. glossary: expand and clarify some definitions, prune cross-references

    J. Bruce Fields authored
    Revise and expand some of the definitions in the glossary, based in part
    on a recent thread started by a user looking for help with some of the
    jargon.  I've borrowed some of the language from Linus's email on that
    thread.  (I'm assuming standing permission to plagiarize Linus's
    email....)
    
    Also start making a few changes to mitigate the appearance of
    "circularity" mentioned in that thread:
    	- feel free to use somewhat longer definitions and to explain
    	  some things more than once instead of relying purely on
    	  cross-references
    	- don't use cross-references when they're redundant: eliminate
    	  self-references and repeated references to the same entry.
    
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Something went wrong with that request. Please try again.