1. 20 Sep, 2006 2 commits
    • Junio C Hamano's avatar
      git log: Unify header_filter and message_filter into one. · 2d10c555
      Junio C Hamano authored
      Now we can tell the built-in grep to grep only in head or in
      body, use that to update --author, --committer, and --grep.
      
      Unfortunately, to make --and, --not and other grep boolean
      expressions useful, as in:
      
      	# Things written by Junio committed and by Linus and log
      	# does not talk about diff.
      
      	git log --author=Junio --and --committer=Linus \
      		--grep-not --grep=diff
      
      we will need to do another round of built-in grep core
      enhancement, because grep boolean expressions are designed to
      work on one line at a time.
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      2d10c555
    • Junio C Hamano's avatar
      revision traversal: prepare for commit log match. · 8ecae9b0
      Junio C Hamano authored
      This is from a suggestion by Linus, just to mark the locations where we
      need to modify to actually implement the filtering.
      
      We do not have any actual filtering code yet.
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      8ecae9b0
  2. 07 Sep, 2006 1 commit
    • Junio C Hamano's avatar
      pack-objects --unpacked=<existing pack> option. · 106d710b
      Junio C Hamano authored
      Incremental repack without -a essentially boils down to:
      
      	rev-list --objects --unpacked --all |
              pack-objects $new_pack
      
      which picks up all loose objects that are still live and creates
      a new pack.
      
      This implements --unpacked=<existing pack> option to tell the
      revision walking machinery to pretend as if objects in such a
      pack are unpacked for the purpose of object listing.  With this,
      we could say:
      
      	rev-list --objects --unpacked=$active_pack --all |
      	pack-objects $new_pack
      
      instead, to mean "all live loose objects but pretend as if
      objects that are in this pack are also unpacked".  The newly
      created pack would be perfect for updating $active_pack by
      replacing it.
      
      Since pack-objects now knows how to do the rev-list's work
      itself internally, you can also write the above example by:
      
      	pack-objects --unpacked=$active_pack --all $new_pack </dev/null
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      106d710b
  3. 06 Sep, 2006 1 commit
    • Junio C Hamano's avatar
      revision.c: allow injecting revision parameters after setup_revisions(). · 5d6f0935
      Junio C Hamano authored
      setup_revisions() wants to get all the parameters at once and
      then postprocesses the resulting revs structure after it is done
      with them.  This code structure is a bit cumbersome to deal with
      efficiently when we want to inject revision parameters from the
      side (e.g. read from standard input).
      
      Fortunately, the nature of this postprocessing is not affected by
      revision parameters; they are affected only by flags.  So it is
      Ok to do add_object() after the it returns.
      
      This splits out the code that deals with the revision parameter
      out of the main loop of setup_revisions(), so that we can later
      call it from elsewhere after it returns.
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      5d6f0935
  4. 28 Aug, 2006 1 commit
  5. 29 Jul, 2006 1 commit
    • Linus Torvalds's avatar
      Call setup_git_directory() early · db6296a5
      Linus Torvalds authored
      Any git command that expects to work in a subdirectory of a project, and
      that reads the git config files (which is just about all of them) needs to
      make sure that it does the "setup_git_directory()" call before it tries to
      read the config file.
      
      This means, among other things, that we need to move the call out of
      "init_revisions()", and into the caller.
      
      This does the mostly trivial conversion to do that.
      Signed-off-by: default avatarLinus Torvalds <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      db6296a5
  6. 15 Jul, 2006 1 commit
  7. 20 Jun, 2006 1 commit
    • Linus Torvalds's avatar
      Add "named object array" concept · 1f1e895f
      Linus Torvalds authored
      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: default avatarLinus Torvalds <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      1f1e895f
  8. 17 Jun, 2006 1 commit
    • Linus Torvalds's avatar
      gitweb.cgi history not shown · 9202434c
      Linus Torvalds authored
      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: default avatarLinus Torvalds <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      9202434c
  9. 02 Jun, 2006 1 commit
  10. 31 May, 2006 1 commit
  11. 21 May, 2006 1 commit
  12. 05 May, 2006 1 commit
  13. 17 Apr, 2006 2 commits
    • Linus Torvalds's avatar
      Log message printout cleanups · 91539833
      Linus Torvalds authored
      On Sun, 16 Apr 2006, Junio C Hamano wrote:
      >
      > In the mid-term, I am hoping we can drop the generate_header()
      > callchain _and_ the custom code that formats commit log in-core,
      > found in cmd_log_wc().
      
      Ok, this was nastier than expected, just because the dependencies between
      the different log-printing stuff were absolutely _everywhere_, but here's
      a patch that does exactly that.
      
      The patch is not very easy to read, and the "--patch-with-stat" thing is
      still broken (it does not call the "show_log()" thing properly for
      merges). That's not a new bug. In the new world order it _should_ do
      something like
      
      	if (rev->logopt)
      		show_log(rev, rev->logopt, "---\n");
      
      but it doesn't. I haven't looked at the --with-stat logic, so I left it
      alone.
      
      That said, this patch removes more lines than it adds, and in particular,
      the "cmd_log_wc()" loop is now a very clean:
      
      	while ((commit = get_revision(rev)) != NULL) {
      		log_tree_commit(rev, commit);
      		free(commit->buffer);
      		commit->buffer = NULL;
      	}
      
      so it doesn't get much prettier than this. All the complexity is entirely
      hidden in log-tree.c, and any code that needs to flush the log literally
      just needs to do the "if (rev->logopt) show_log(...)" incantation.
      
      I had to make the combined_diff() logic take a "struct rev_info" instead
      of just a "struct diff_options", but that part is pretty clean.
      
      This does change "git whatchanged" from using "diff-tree" as the commit
      descriptor to "commit", and I changed one of the tests to reflect that new
      reality. Otherwise everything still passes, and my other tests look fine
      too.
      Signed-off-by: default avatarLinus Torvalds <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      91539833
    • Junio C Hamano's avatar
      rev-list --boundary: show boundary commits even when limited otherwise. · 1b65a5aa
      Junio C Hamano authored
      The boundary commits are shown for UI like gitk to draw them as
      soon as topo-order sorting allows, and should not be omitted by
      get_revision() filtering logic.  As long as their immediate
      child commits are shown, we should not filter them out.
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      1b65a5aa
  14. 16 Apr, 2006 3 commits
    • Junio C Hamano's avatar
      log/whatchanged/show - log formatting cleanup. · cb8f64b4
      Junio C Hamano authored
      This moves the decision to print the log message, while diff
      options are in effect, to log-tree.  It gives behaviour closer
      to the traditional one.
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      cb8f64b4
    • Linus Torvalds's avatar
      Tentative built-in "git show" · ba1d4505
      Linus Torvalds authored
      This uses the "--no-walk" flag that I never actually implemented (but I'm
      sure I mentioned it) to make "git show" be essentially the same thing as
      "git whatchanged --no-walk".
      
      It just refuses to add more interesting parents to the revision walking
      history, so you don't actually get any history, you just get the commit
      you asked for.
      
      I was going to add "--no-walk" as a real argument flag to git-rev-list
      too, but I'm not sure anybody actually needs it. Although it might be
      useful for porcelain, so I left the door open.
      
      [jc: ported to the unified option structure by Linus]
      Signed-off-by: default avatarLinus Torvalds <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      ba1d4505
    • Linus Torvalds's avatar
      Tentative built-in "git show" · c5ccd8be
      Linus Torvalds authored
      This uses the "--no-walk" flag that I never actually implemented (but I'm
      sure I mentioned it) to make "git show" be essentially the same thing as
      "git whatchanged --no-walk".
      
      It just refuses to add more interesting parents to the revision walking
      history, so you don't actually get any history, you just get the commit
      you asked for.
      
      I was going to add "--no-walk" as a real argument flag to git-rev-list
      too, but I'm not sure anybody actually needs it. Although it might be
      useful for porcelain, so I left the door open.
      Signed-off-by: default avatarLinus Torvalds <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      c5ccd8be
  15. 15 Apr, 2006 2 commits
    • Junio C Hamano's avatar
      183df639
    • Linus Torvalds's avatar
      Common option parsing for "git log --diff" and friends · cd2bdc53
      Linus Torvalds authored
      This basically does a few things that are sadly somewhat interdependent,
      and nontrivial to split out
      
       - get rid of "struct log_tree_opt"
      
         The fields in "log_tree_opt" are moved into "struct rev_info", and all
         users of log_tree_opt are changed to use the rev_info struct instead.
      
       - add the parsing for the log_tree_opt arguments to "setup_revision()"
      
       - make setup_revision set a flag (revs->diff) if the diff-related
         arguments were used. This allows "git log" to decide whether it wants
         to show diffs or not.
      
       - make setup_revision() also initialize the diffopt part of rev_info
         (which we had from before, but we just didn't initialize it)
      
       - make setup_revision() do all the "finishing touches" on it all (it will
         do the proper flag combination logic, and call "diff_setup_done()")
      
      Now, that was the easy and straightforward part.
      
      The slightly more involved part is that some of the programs that want to
      use the new-and-improved rev_info parsing don't actually want _commits_,
      they may want tree'ish arguments instead. That meant that I had to change
      setup_revision() to parse the arguments not into the "revs->commits" list,
      but into the "revs->pending_objects" list.
      
      Then, when we do "prepare_revision_walk()", we walk that list, and create
      the sorted commit list from there.
      
      This actually cleaned some stuff up, but it's the less obvious part of the
      patch, and re-organized the "revision.c" logic somewhat. It actually paves
      the way for splitting argument parsing _entirely_ out of "revision.c",
      since now the argument parsing really is totally independent of the commit
      walking: that didn't use to be true, since there was lots of overlap with
      get_commit_reference() handling etc, now the _only_ overlap is the shared
      (and trivial) "add_pending_object()" thing.
      
      However, I didn't do that file split, just because I wanted the diff
      itself to be smaller, and show the actual changes more clearly. If this
      gets accepted, I'll do further cleanups then - that includes the file
      split, but also using the new infrastructure to do a nicer "git diff" etc.
      
      Even in this form, it actually ends up removing more lines than it adds.
      
      It's nice to note how simple and straightforward this makes the built-in
      "git log" command, even though it continues to support all the diff flags
      too. It doesn't get much simpler that this.
      
      I think this is worth merging soonish, because it does allow for future
      cleanup and even more sharing of code. However, it obviously touches
      "revision.c", which is subtle. I've tested that it passes all the tests we
      have, and it passes my "looks sane" detector, but somebody else should
      also give it a good look-over.
      
      [jc: squashed the original and three "oops this too" updates, with
       another fix-up.]
      Signed-off-by: default avatarLinus Torvalds <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      cd2bdc53
  16. 11 Apr, 2006 1 commit
  17. 09 Apr, 2006 1 commit
    • Linus Torvalds's avatar
      Make "--parents" logs also be incremental · 3381c790
      Linus Torvalds authored
      The parent rewriting feature caused us to create the whole history in one
      go, and then simplify it later, because of how rewrite_parents() had been
      written. However, with a little tweaking, it's perfectly possible to do
      even that one incrementally.
      
      Right now, this doesn't really much matter, because every user of
      "--parents" will probably generally _also_ use "--topo-order", which will
      cause the old non-incremental behaviour anyway. However, I'm hopeful that
      we could make even the topological sort incremental, or at least
      _partially_ so (for example, make it incremental up to the first merge).
      
      In the meantime, this at least moves things in the right direction, and
      removes a strange special case.
      Signed-off-by: default avatarLinus Torvalds <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      3381c790
  18. 01 Apr, 2006 1 commit
  19. 29 Mar, 2006 1 commit
    • Junio C Hamano's avatar
      rev-list --boundary · 384e99a4
      Junio C Hamano authored
      With the new --boundary flag, the output from rev-list includes
      the UNINTERESING commits at the boundary, which are usually not
      shown.  Their object names are prefixed with '-'.
      
      For example, with this graph:
      
                    C side
                   /
      	A---B---D master
      
      You would get something like this:
      
      	$ git rev-list --boundary --header --parents side..master
      	D B
              tree D^{tree}
              parent B
              ... log message for commit D here ...
              \0-B A
              tree B^{tree}
              parent A
              ... log message for commit B here ...
              \0
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      384e99a4
  20. 11 Mar, 2006 1 commit
  21. 01 Mar, 2006 2 commits
    • Junio C Hamano's avatar
      git-log (internal): more options. · 7ae0b0cb
      Junio C Hamano authored
      This ports the following options from rev-list based git-log
      implementation:
      
       * -<n>, -n<n>, and -n <n>.  I am still wondering if we want
          this natively supported by setup_revisions(), which already
          takes --max-count.  We may want to move them in the next
          round.  Also I am not sure if we can get away with not
          setting revs->limited when we set max-count.  The latest
          rev-list.c and revision.c in this series do not, so I left
          them as they are.
      
       * --pretty and --pretty=<fmt>.
      
       * --abbrev=<n> and --no-abbrev.
      
      The previous commit already handles time-based limiters
      (--since, --until and friends).  The remaining things that
      rev-list based git-log happens to do are not useful in a pure
      log-viewing purposes, and not ported:
      
       * --bisect (obviously).
      
       * --header.  I am actually in favor of doing the NUL
         terminated record format, but rev-list based one always
         passed --pretty, which defeated this option.  Maybe next
         round.
      
       * --parents.  I do not think of a reason a log viewer wants
         this.  The flag is primarily for feeding squashed history
         via pipe to downstream tools.
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      7ae0b0cb
    • Linus Torvalds's avatar
      Rip out merge-order and make "git log <paths>..." work again. · 765ac8ec
      Linus Torvalds authored
      Well, assuming breaking --merge-order is fine, here's a patch (on top of
      the other ones) that makes
      
      	git log <filename>
      
      actually work, as far as I can tell.
      
      I didn't add the logic for --before/--after flags, but that should be
      pretty trivial, and is independent of this anyway.
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      765ac8ec
  22. 28 Feb, 2006 1 commit
  23. 27 Feb, 2006 1 commit
  24. 26 Feb, 2006 1 commit
    • Linus Torvalds's avatar
      First cut at libifying revlist generation · ae563542
      Linus Torvalds authored
      This really just splits things up partially, and creates the
      interface to set things up by parsing the command line.
      
      No real code changes so far, although the parsing of filenames is a bit
      stricter. In particular, if there is a "--", then we do not accept any
      filenames before it, and if there isn't any "--", then we check that _all_
      paths listed are valid, not just the first one.
      
      The new argument parsing automatically also gives us "--default" and
      "--not" handling as in git-rev-parse.
      Signed-off-by: default avatarLinus Torvalds <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      ae563542
  25. 21 Apr, 2005 1 commit
  26. 17 Apr, 2005 4 commits
  27. 14 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Use common "revision.h" header for both fsck and rev-tree. · 458754a9
      Linus Torvalds authored
      It's really a very generic thing: the notion of one sha1 revision
      referring to another one. "fsck" uses it for all nodes, and "rev-tree"
      only tracks commit-node relationships, but the code was already
      the same - now we just make that explicit by moving it to a common
      header file.
      458754a9