1. 05 8月, 2006 1 次提交
  2. 01 8月, 2006 1 次提交
  3. 29 7月, 2006 2 次提交
  4. 28 7月, 2006 1 次提交
    • J
      log and diff family: honor config even from subdirectories · ef1d9c5a
      Junio C Hamano 提交于
      There currently is an unfortunate circular dependency between
      what init_revisions (the command line revision specification
      parser) does and setting up the log and diff options.  The
      function uses setup_git_directory() to find the root of the
      project relative to the current directory and calls diff_setup()
      to prepare diff generation.  However, some of the things that
      diff_setup() does needs to depend on the configuration variable,
      which needs to be read after setup_git_directory() is called.
      
      This patch is a low impact workaround.  It first lets
      init_revisions() to run and do its thing, then uses git_config()
      and diff_setup() after it returns, so that configuration
      variables that affects the diff operation can be used from
      subdirectories.
      Signed-off-by: NJunio C Hamano <junkio@cox.net>
      ef1d9c5a
  5. 15 7月, 2006 4 次提交
  6. 09 7月, 2006 1 次提交
  7. 08 7月, 2006 1 次提交
    • J
      diff: do not use configuration magic at the core-level · 83ad63cf
      Junio C Hamano 提交于
      The Porcelainish has become so much usable as the UI that there
      is not much reason people should be using the core programs by
      hand anymore.  At this point we are better off making the
      behaviour of the core programs predictable by keeping them
      unaffected by the configuration variables.  Otherwise they will
      become very hard to use as reliable building blocks.
      
      For example, "git-commit -a" internally uses git-diff-files to
      figure out the set of paths that need to be updated in the
      index, and we should never allow diff.renames that happens to be
      in the configuration to interfere (or slow down the process).
      
      The UI level configuration such as showing renamed diff and
      coloring are still honored by the Porcelainish ("git log" family
      and "git diff"), but not by the core anymore.
      Signed-off-by: NJunio C Hamano <junkio@cox.net>
      83ad63cf
  8. 07 7月, 2006 1 次提交
  9. 29 6月, 2006 1 次提交
  10. 28 6月, 2006 2 次提交
  11. 27 6月, 2006 6 次提交
  12. 25 6月, 2006 1 次提交
  13. 20 6月, 2006 1 次提交
    • L
      Add "named object array" concept · 1f1e895f
      Linus Torvalds 提交于
      We've had this notion of a "object_list" for a long time, which eventually
      grew a "name" member because some users (notably git-rev-list) wanted to
      name each object as it is generated.
      
      That object_list is great for some things, but it isn't all that wonderful
      for others, and the "name" member is generally not used by everybody.
      
      This patch splits the users of the object_list array up into two: the
      traditional list users, who want the list-like format, and who don't
      actually use or want the name. And another class of users that really used
      the list as an extensible array, and generally wanted to name the objects.
      
      The patch is fairly straightforward, but it's also biggish. Most of it
      really just cleans things up: switching the revision parsing and listing
      over to the array makes things like the builtin-diff usage much simpler
      (we now see exactly how many members the array has, and we don't get the
      objects reversed from the order they were on the command line).
      
      One of the main reasons for doing this at all is that the malloc overhead
      of the simple object list was actually pretty high, and the array is just
      a lot denser. So this patch brings down memory usage by git-rev-list by
      just under 3% (on top of all the other memory use optimizations) on the
      mozilla archive.
      
      It does add more lines than it removes, and more importantly, it adds a
      whole new infrastructure for maintaining lists of objects, but on the
      other hand, the new dynamic array code is pretty obvious. The change to
      builtin-diff-tree.c shows a fairly good example of why an array interface
      is sometimes more natural, and just much simpler for everybody.
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      Signed-off-by: NJunio C Hamano <junkio@cox.net>
      1f1e895f
  14. 18 6月, 2006 2 次提交
    • E
      Fix git-format-patch -s · 6c4cca1c
      Eric W. Biederman 提交于
      When git-format-patch was converted to a builtin an appropriate call
      to setup_ident was missed and thus git-format-patch -s fails because
      it doesn't look up anything in the password file.
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: NJunio C Hamano <junkio@cox.net>
      6c4cca1c
    • L
      Some more memory leak avoidance · cb115748
      Linus Torvalds 提交于
      This is really the dregs of my effort to not waste memory in git-rev-list,
      and makes barely one percent of a difference in the memory footprint, but
      hey, it's also a pretty small patch.
      
      It discards the parent lists and the commit buffer after the commit has
      been shown by git-rev-list (and "git log" - which already did the commit
      buffer part), and frees the commit list entry that was used by the
      revision walker.
      
      The big win would be to get rid of the "refs" pointer in the object
      structure (another 5%), because it's only used by fsck. That would require
      some pretty major surgery to fsck, though, so I'm timid and did the less
      interesting but much easier part instead.
      
      This (percentually) makes a bigger difference to "git log" and friends,
      since those are walking _just_ commits, and thus the list entries tend to
      be a bigger percentage of the memory use. But the "list all objects" case
      does improve too.
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      Signed-off-by: NJunio C Hamano <junkio@cox.net>
      cb115748
  15. 17 6月, 2006 2 次提交
    • L
      gitweb.cgi history not shown · 9202434c
      Linus Torvalds 提交于
      This does:
      
       - add a "rev.simplify_history" flag which defaults to on
       - it turns it off for "git whatchanged" (which thus now has real
         semantics outside of "git log")
       - it adds a command line flag ("--full-history") to turn it off for
         others (ie you can make "git log" and "gitk" etc get the semantics if
         you want to.
      
      Now, just as an example of _why_ you really really really want to simplify
      history by default, apply this patch, install it, and try these two
      command lines:
      
      	gitk --full-history -- git.c
      	gitk -- git.c
      
      and compare the output.
      
      So with this, you can also now do
      
      	git whatchanged -p -- gitweb.cgi
      	git log -p --full-history -- gitweb.cgi
      
      and it will show the old history of gitweb.cgi, even though it's not
      relevant to the _current_ state of the name "gitweb.cgi"
      
      NOTE NOTE NOTE! It will still actually simplify away merges that didn't
      change anything at all into either child. That creates these bogus strange
      discontinuities if you look at it with "gitk" (look at the --full-history
      gitk output for git.c, and you'll see a few strange cases).
      
      So the whole "--parent" thing ends up somewhat bogus with --full-history
      because of this, but I'm not sure it's worth even worrying about. I don't
      think you'd ever want to really use "--full-history" with the graphical
      representation, I just give it as an example exactly to show _why_ doing
      so would be insane.
      
      I think this is trivial enough and useful enough to be worth merging into
      the stable branch.
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      Signed-off-by: NJunio C Hamano <junkio@cox.net>
      9202434c
    • P
      bfbd0bb6
  16. 07 6月, 2006 1 次提交
    • J
      git-format-patch: add --output-directory long option again · efd02016
      Junio C Hamano 提交于
      Additionally notices and complains to an -o option without
      directory or a duplicated -o option, -o and --stdout given
      together.  Also delays the creation of directory until all
      arguments are parsed, so that the command does not leave an
      empty directory behind when it exits after seeing an unrelated
      invalid option.
      
      [jc: originally from Dennis Stosberg but with minor fixes, and
       documentation updates from Dennis.]
      Signed-off-by: NJunio C Hamano <junkio@cox.net>
      efd02016
  17. 02 6月, 2006 1 次提交
  18. 01 6月, 2006 1 次提交
  19. 29 5月, 2006 1 次提交
  20. 27 5月, 2006 1 次提交
  21. 26 5月, 2006 1 次提交
    • J
      git-format-patch --start-number <n> · fa0f02df
      Johannes Schindelin 提交于
      Since the "a..b c..d" syntax is interpreted as "b ^a d ^c" as other
      range-ish commands, if you want to format a..b and then c..d and end
      up with files consecutively numbered, the second run needs to be able
      to tell the command what number to start from.
      
      This does not imply --numbered (which gives [PATCH n/m] to the subject).
      Signed-off-by: NJunio C Hamano <junkio@cox.net>
      fa0f02df
  22. 21 5月, 2006 1 次提交
  23. 20 5月, 2006 1 次提交
  24. 07 5月, 2006 1 次提交
  25. 06 5月, 2006 4 次提交