1. 01 Sep, 2015 1 commit
  2. 03 Feb, 2014 1 commit
  3. 12 Apr, 2013 1 commit
  4. 25 Feb, 2009 1 commit
  5. 22 Jul, 2008 1 commit
  6. 16 Jul, 2008 1 commit
  7. 13 Jul, 2008 1 commit
    • Stephan Beyer's avatar
      Make usage strings dash-less · 1b1dd23f
      Stephan Beyer authored
      When you misuse a git command, you are shown the usage string.
      But this is currently shown in the dashed form.  So if you just
      copy what you see, it will not work, when the dashed form
      is no longer supported.
      
      This patch makes git commands show the dash-less version.
      
      For shell scripts that do not specify OPTIONS_SPEC, git-sh-setup.sh
      generates a dash-less usage string now.
      Signed-off-by: default avatarStephan Beyer <s-beyer@gmx.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      1b1dd23f
  8. 13 Mar, 2008 1 commit
  9. 10 Mar, 2008 1 commit
  10. 29 Nov, 2007 1 commit
  11. 13 Nov, 2007 1 commit
  12. 06 Nov, 2007 1 commit
  13. 27 Sep, 2007 1 commit
  14. 23 Sep, 2007 1 commit
    • David Kastrup's avatar
      Supplant the "while case ... break ;; esac" idiom · 822f7c73
      David Kastrup authored
      A lot of shell scripts contained stuff starting with
      
      	while case "$#" in 0) break ;; esac
      
      and similar.  I consider breaking out of the condition instead of the
      body od the loop ugly, and the implied "true" value of the
      non-matching case is not really obvious to humans at first glance.  It
      happens not to be obvious to some BSD shells, either, but that's
      because they are not POSIX-compliant.  In most cases, this has been
      replaced by a straight condition using "test".  "case" has the
      advantage of being faster than "test" on vintage shells where "test"
      is not a builtin.  Since none of them is likely to run the git
      scripts, anyway, the added readability should be worth the change.
      
      A few loops have had their termination condition expressed
      differently.
      Signed-off-by: default avatarDavid Kastrup <dak@gnu.org>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      822f7c73
  15. 14 Jul, 2007 1 commit
  16. 03 Jul, 2007 1 commit
  17. 24 Apr, 2007 1 commit
  18. 14 Apr, 2007 1 commit
  19. 30 Mar, 2007 1 commit
  20. 13 Mar, 2007 1 commit
    • Don Zickus's avatar
      builtin-mailinfo.c infrastrcture changes · 87ab7992
      Don Zickus authored
      I am working on a project that required parsing through regular
      mboxes that didn't necessarily have patches embedded in them.  I
      started by creating my own modified copy of git-am and working
      from there.  Very quickly, I noticed git-mailinfo wasn't able to
      handle a big chunk of my email.
      
      After hacking up numerous solutions and running into more
      limitations, I decided it was just easier to rewrite a big chunk
      of it.  The following patch has a bunch of fixes and features
      that I needed in order for me do what I wanted.
      
      Note: I'm didn't follow any email rfc papers but I don't think
      any of the changes I did required much knowledge (besides the
      boundary stuff).
      
      List of major changes/fixes:
      - can't create empty patch files fix
      - empty patch files don't fail, this failure will come inside git-am
      - multipart boundaries are now handled
      - only output inbody headers if a patch exists otherwise assume those
      headers are part of the reply and instead output the original headers
      - decode and filter base64 patches correctly
      - various other accidental fixes
      
      I believe I didn't break any existing functionality or
      compatibility (other than what I describe above, which is really
      only the empty patch file).
      
      I tested this through various mailing list archives and
      everything seemed to parse correctly (a couple thousand emails).
      
      [jc: squashed in another patch from Don's five patch series to
       fix the test case, as this patch exposes the bug in the test.]
      Signed-off-by: Don Zickus's avatarDon Zickus <dzickus@redhat.com>
      Signed-off-by: default avatarJunio C Hamano <junkio@cox.net>
      87ab7992
  21. 04 Feb, 2007 1 commit
  22. 16 Jan, 2007 1 commit
  23. 11 Jul, 2006 1 commit
  24. 10 Jul, 2006 1 commit
  25. 27 Jun, 2006 1 commit
  26. 19 May, 2006 2 commits
    • Eric W. Biederman's avatar
      Implement a --dry-run option to git-quiltimport · d3bd4ee1
      Eric W. Biederman authored
      Since large quilt trees like -mm can easily have patches
      without clear authorship information, add a --dry-run
      option to make the problem patches easy to find.
      Signed-off-by: default avatarJunio C Hamano <junkio@cox.net>
      d3bd4ee1
    • Eric W. Biederman's avatar
      Implement git-quiltimport · d3d8f361
      Eric W. Biederman authored
      Importing a quilt patch series into git is not very difficult
      but parsing the patch descriptions and all of the other
      minutia take a bit of effort to get right, so this automates it.
      
      Since git and quilt complement each other it makes sense
      to make it easy to go back and forth between the two.
      
      If a patch is encountered that it cannot derive the author
      from the user is asked.
      Signed-off-by: default avatarJunio C Hamano <junkio@cox.net>
      d3d8f361