This project is mirrored from https://github.com/git/git. Updated .
  1. 18 Apr, 2013 1 commit
  2. 22 Dec, 2012 2 commits
    • Junio C Hamano's avatar
      get_patch_filename(): split into two functions · d28b5d47
      Junio C Hamano authored
      The function switched between two operating modes depending on the
      NULL-ness of its two parameters, as a hacky way to share small part
      of implementation, sacrificing cleanliness of the API.
      
      Implement "fmt_output_subject()" function that takes a subject
      string and gives the name for the output file, and on top of it,
      implement "fmt_output_commit()" function that takes a commit and
      gives the name for the output file.
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      d28b5d47
    • Junio C Hamano's avatar
      get_patch_filename(): simplify function signature · 021f2f4c
      Junio C Hamano authored
      Most functions that emit to a strbuf take the strbuf as their first
      parameter; make this function follow suit.
      
      The serial number of the patch being emitted (nr) and suffix used
      for patch filename (suffix) are both recorded in rev_info; drop
      these separate parameters and pass the rev_info directly.
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      021f2f4c
  3. 22 May, 2012 1 commit
    • Jeff King's avatar
      format-patch: refactor get_patch_filename · a21c2f94
      Jeff King authored
      The get_patch_filename function expects a commit argument
      and uses it to get the sanitized subject line when making a
      patch filename. However, we also want to use this same
      function for the cover letter, which does not have a commit
      object. The current solution is to create a fake commit with
      the subject "cover letter". Instead, let's make the
      get_patch_filename interface more flexibile, and allow
      passing a direct subject.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      a21c2f94
  4. 24 Jun, 2010 1 commit
  5. 26 Aug, 2009 1 commit
  6. 18 Aug, 2009 1 commit
  7. 23 Mar, 2009 2 commits
  8. 04 Nov, 2008 1 commit
    • Linus Torvalds's avatar
      Add a 'source' decorator for commits · 0f3a290b
      Linus Torvalds authored
      We already support decorating commits by tags or branches that point to
      them, but especially when we are looking at multiple branches together,
      we sometimes want to see _how_ we reached a particular commit.
      
      We can abuse the '->util' field in the commit to keep track of that as
      we walk the commit lists, and get a reasonably useful view into which
      branch or tag first reaches that commit.
      
      Of course, if the commit is reachable through multiple sources (which is
      common), our particular choice of "first" reachable is entirely random
      and depends on the particular path we happened to follow.
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      0f3a290b
  9. 05 Sep, 2008 1 commit
  10. 03 May, 2008 1 commit
  11. 19 Feb, 2008 1 commit
  12. 27 Oct, 2007 1 commit
  13. 26 Jun, 2006 1 commit
  14. 17 Apr, 2006 1 commit
    • 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 <torvalds@osdl.org>
      Signed-off-by: default avatarJunio C Hamano <junkio@cox.net>
      91539833
  15. 15 Apr, 2006 4 commits
    • Junio C Hamano's avatar
      whatchanged options parser fix. · d2e38d3b
      Junio C Hamano authored
      We need to have two sets of diff_options structure and abbrev
      settings, but there is no point having two separate commit
      format setting.  Fix the confusion.
      
      Also properly initialize the command options structure.
      Signed-off-by: default avatarJunio C Hamano <junkio@cox.net>
      d2e38d3b
    • Junio C Hamano's avatar
      Extract "log [diff options]" parser out. · f4235f8b
      Junio C Hamano authored
      Merging of the log-tree-opt structure with rev-info structure
      did not work out very well and it broke things that did not want
      diff options and/or rev options.
      
      This is an alternative approach to define a combined interface
      that can be used by commands that wants both.  The use of it is
      opt-in to reduce the risk of breaking existing programs.
      
      We might want to slurp "setup_revisions() places things in
      pending objects list" part from Linus's earlier attempt.
      Signed-off-by: default avatarJunio C Hamano <junkio@cox.net>
      f4235f8b
    • 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 <torvalds@osdl.org>
      Signed-off-by: default avatarJunio C Hamano <junkio@cox.net>
      cd2bdc53
  16. 09 Apr, 2006 1 commit
    • Junio C Hamano's avatar
      log-tree: separate major part of diff-tree. · 5f1c3f07
      Junio C Hamano authored
      This separates out the part that deals with one-commit diff-tree
      (and --stdin form) into a separate log-tree module.
      
      There are two goals with this.  The more important one is to be
      able to make this part available to "git log --diff", so that we
      can have a native "git whatchanged" command.  Another is to
      simplify the commit log generation part simpler.
      Signed-off-by: default avatarJunio C Hamano <junkio@cox.net>
      5f1c3f07