1. 21 Sep, 2006 2 commits
    • Junio C Hamano's avatar
      Tell between packed, unpacked and symbolic refs. · 8da19775
      Junio C Hamano authored
      This adds a "int *flag" parameter to resolve_ref() and makes
      for_each_ref() family to call callback function with an extra
      "int flag" parameter.  They are used to give two bits of
      information (REF_ISSYMREF and REF_ISPACKED) about the ref.
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      8da19775
    • Junio C Hamano's avatar
      Add callback data to for_each_ref() family. · cb5d709f
      Junio C Hamano authored
      This is a long overdue fix to the API for for_each_ref() family
      of functions.  It allows the callers to specify a callback data
      pointer, so that the caller does not have to use static
      variables to communicate with the callback funciton.
      
      The updated for_each_ref() family takes a function of type
      
      	int (*fn)(const char *, const unsigned char *, void *)
      
      and a void pointer as parameters, and calls the function with
      the name of the ref and its SHA-1 with the caller-supplied void
      pointer as parameters.
      
      The commit updates two callers, builtin-name-rev.c and
      builtin-pack-refs.c as an example.
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      cb5d709f
  2. 16 Aug, 2006 1 commit
  3. 29 Jul, 2006 1 commit
  4. 07 Jul, 2006 1 commit
  5. 04 Jul, 2006 1 commit
  6. 28 Jun, 2006 1 commit
  7. 06 Jun, 2006 1 commit
  8. 04 Jun, 2006 1 commit
  9. 14 May, 2006 1 commit
  10. 26 Apr, 2006 1 commit
    • Linus Torvalds's avatar
      Fix filename verification when in a subdirectory · e23d0b4a
      Linus Torvalds authored
      When we are in a subdirectory of a git archive, we need to take the prefix
      of that subdirectory into accoung when we verify filename arguments.
      
      Noted by Matthias Lederhofer
      
      This also uses the improved error reporting for all the other git commands
      that use the revision parsing interfaces, not just git-rev-parse. Also, it
      makes the error reporting for mixed filenames and argument flags clearer
      (you cannot put flags after the start of the pathname list).
      
      [jc: with fix to a trivial typo noticed by Timo Hirvonen]
      Signed-off-by: default avatarLinus Torvalds <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      e23d0b4a
  11. 25 Apr, 2006 1 commit
    • Paul Mackerras's avatar
      rev-parse: better error message for ambiguous arguments · 3e1a70d9
      Paul Mackerras authored
      Currently, if git-rev-parse encounters an argument that is neither a
      recognizable revision name nor the name of an existing file or
      directory, and it hasn't encountered a "--" argument, it prints an
      error message saying "No such file or directory".  This can be
      confusing for users, including users of programs such as gitk that
      use git-rev-parse, who may then think that they can't ask about the
      history of files that no longer exist.
      
      This makes it print a better error message, one that points out the
      ambiguity and tells the user what to do to fix it.
      Signed-off-by: default avatarPaul Mackerras <[email protected]>
      3e1a70d9
  12. 30 Mar, 2006 1 commit
  13. 27 Mar, 2006 1 commit
    • Linus Torvalds's avatar
      Fix error handling for nonexistent names · fb18a2ed
      Linus Torvalds authored
      When passing in a pathname pattern without the "--" separator on the
      command line, we verify that the pathnames in question exist. However,
      there were two bugs in that verification:
      
       - git-rev-parse would only check the first pathname, and silently allow
         any invalid subsequent pathname, whether it existed or not (which
         defeats the purpose of the check, and is also inconsistent with what
         git-rev-list actually does)
      
       - git-rev-list (and "git log" etc) would check each filename, but if the
         check failed, it would print the error using the first one, i.e.:
      
      	[[email protected] git]$ git log Makefile bad-file
      	fatal: 'Makefile': No such file or directory
      
         instead of saying that it's 'bad-file' that doesn't exist.
      
      This fixes both bugs.
      Signed-off-by: default avatarLinus Torvalds <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      fb18a2ed
  14. 24 Mar, 2006 1 commit
  15. 01 Mar, 2006 1 commit
  16. 20 Feb, 2006 1 commit
    • Junio C Hamano's avatar
      rev-list --objects-edge · c6496575
      Junio C Hamano authored
      This new flag is similar to --objects, but causes rev-list to
      show list of "uninteresting" commits that appear on the edge
      commit prefixed with '-'.
      
      Downstream pack-objects will be changed to take these as hints
      to use the trees and blobs contained with them as base objects
      of resulting pack, producing an incomplete (not self-contained)
      pack.
      
      Such a pack cannot be used in .git/objects/pack (it is prevented
      by git-index-pack erroring out if it is fed to git-fetch-pack -k
      or git-clone-pack), but would be useful when transferring only
      small changes to huge blobs.
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      c6496575
  17. 18 Feb, 2006 1 commit
  18. 16 Feb, 2006 1 commit
  19. 06 Feb, 2006 1 commit
  20. 05 Feb, 2006 1 commit
  21. 01 Feb, 2006 2 commits
  22. 28 Jan, 2006 4 commits
  23. 25 Jan, 2006 1 commit
    • Linus Torvalds's avatar
      Make git-rev-list and git-rev-parse argument parsing stricter · d8f6b342
      Linus Torvalds authored
      If you pass it a filename without the "--" marker to separate it from
      revision information and flags, we now require that the file in question
      actually exists. This makes mis-typed revision information not be silently
      just considered a strange filename.
      
      With the "--" marker, you can continue to pass in filenames that do not
      actually exists - useful for querying what happened to a file that you
      no longer have in the repository.
      
      [ All scripts should use the "--" format regardless, to make things
        unambiguous. So this change should not affect any existing tools ]
      Signed-off-by: default avatarLinus Torvalds <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      d8f6b342
  24. 23 Dec, 2005 1 commit
    • Junio C Hamano's avatar
      rev-parse: --show-cdup · 5f94c730
      Junio C Hamano authored
      When --show-prefix is useful, sometimes it is easier to cd up to
      the toplevel of the tree.  This is equivalent to:
      
          git rev-parse --show-prefix | sed -e 's|[^/][^/]*|..|g'
      
      but we do not have to invoke sed for that.
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      5f94c730
  25. 17 Nov, 2005 1 commit
    • Linus Torvalds's avatar
      git's rev-parse.c function show_datestring presumes gnu date · 3c07b1d1
      Linus Torvalds authored
      Ok. This is the insane patch to do this.
      
      It really isn't very careful, and the reason I call it "approxidate()"
      will become obvious when you look at the code. It is very liberal in what
      it accepts, to the point where sometimes the results may not make a whole
      lot of sense.
      
      It accepts "last week" as a date string, by virtue of "last" parsing as
      the number 1, and it totally ignoring superfluous fluff like "ago", so
      "last week" ends up being exactly the same thing as "1 week ago". Fine so
      far.
      
      It has strange side effects: "last december" will actually parse as "Dec
      1", which actually _does_ turn out right, because it will then notice that
      it's not December yet, so it will decide that you must be talking about a
      date last year. So it actually gets it right, but it's kind of for the
      "wrong" reasons.
      
      It also accepts the numbers 1..10 in string format ("one" .. "ten"), so
      you can do "ten weeks ago" or "ten hours ago" and it will do the right
      thing.
      
      But it will do some really strange thigns too: the string "this will last
      forever", will not recognize anyting but "last", which is recognized as
      "1", which since it doesn't understand anything else it will think is the
      day of the month. So if you do
      
      	gitk --since="this will last forever"
      
      the date will actually parse as the first day of the current month.
      
      And it will parse the string "now" as "now", but only because it doesn't
      understand it at all, and it makes everything relative to "now".
      
      Similarly, it doesn't actually parse the "ago" or "from now", so "2 weeks
      ago" is exactly the same as "2 weeks from now". It's the current date
      minus 14 days.
      
      But hey, it's probably better (and certainly faster) than depending on GNU
      date. So now you can portably do things like
      
      	gitk --since="two weeks and three days ago"
      	git log --since="July 5"
      	git-whatchanged --since="10 hours ago"
      	git log --since="last october"
      
      and it will actually do exactly what you thought it would do (I think). It
      will count 17 days backwards, and it will do so even if you don't have GNU
      date installed.
      
      (I don't do "last monday" or similar yet, but I can extend it to that too
      if people want).
      
      It was kind of fun trying to write code that uses such totally relaxed
      "understanding" of dates yet tries to get it right for the trivial cases.
      The result should be mixed with a few strange preprocessor tricks, and be
      submitted for the IOCCC ;)
      
      Feel free to try it out, and see how many strange dates it gets right. Or
      wrong.
      
      And if you find some interesting (and valid - not "interesting" as in
      "strange", but "interesting" as in "I'd be interested in actually doing
      this) thing it gets wrong - usually by not understanding it and silently
      just doing some strange things - please holler.
      
      Now, as usual this certainly hasn't been getting a lot of testing. But my
      code always works, no?
      
      		Linus
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      3c07b1d1
  26. 31 Oct, 2005 1 commit
  27. 28 Oct, 2005 1 commit
    • Linus Torvalds's avatar
      Be more careful about reference parsing · af13cdf2
      Linus Torvalds authored
      This does two things:
      
       - we don't allow "." and ".." as components of a refname. Thus get_sha1()
         will not accept "./refname" as being the same as "refname" any more.
      
       - git-rev-parse stops doing revision translation after seeing a pathname,
         to match the brhaviour of all the tools (once we see a pathname,
         everything else will also be parsed as a pathname).
      
      Basically, if you did
      
      	git log *
      
      and "gitk" was somewhere in the "*", we don't want to replace the filename
      "gitk" with the SHA1 of the branch with the same name.
      
      Of course, if there is any change of ambiguity, you should always use "--"
      to make it explicit what are filenames and what are revisions, but this
      makes the normal cases sane. The refname rule also means that instead of
      the "--", you can do the same thing we're used to doing with filenames
      that start with a slash: use "./filename" instead, and now it's a
      filename, not an option (and not a revision).
      
      So "git log ./*.c" is now actually a perfectly valid thing to do, even if
      the first C-file might have the same name as a branch.
      
      Trivial test:
      
      	git-rev-parse gitk ./gitk gitk
      
      should output something like
      
      	9843c307
      	./gitk
      	gitk
      
      where the "./gitk" isn't seen as a revision, and the second "gitk" is a
      filename simply because we've seen filenames already, and thus stopped
      doing revision parsing.
      Signed-off-by: default avatarLinus Torvalds <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      af13cdf2
  28. 26 Oct, 2005 1 commit
    • Linus Torvalds's avatar
      git-rev-list: make --dense the default (and introduce "--sparse") · 7b34c2fa
      Linus Torvalds authored
      This actually does three things:
      
       - make "--dense" the default for git-rev-list. Since dense is a no-op if
         no filenames are given, this doesn't actually change any historical
         behaviour, but it's logically the right default (if we want to prune on
         filenames, do it fully. The sparse "merge-only" thing may be useful,
         but it's not what you'd normally expect)
      
       - make "git-rev-parse" show the default revision control before it shows
         any pathnames.
      
         This was a real bug, but nobody would ever have noticed, because
         the default thing tends to only make sense for git-rev-list, and
         git-rev-list didn't use to take pathnames.
      
       - it changes "git-rev-list" to match the other commands that take a mix
         of revisions and filenames - it no longer requires the "--" before
         filenames (although you still need to do it if a filename could be
         confused with a revision name, eg "gitk" in the git archive)
      
      This all just makes for much more pleasant and obvous usage. Just doing a
      
      	gitk t/
      
      does the obvious thing: it will show the history as it concerns the "t/"
      subdirectory.
      Signed-off-by: default avatarLinus Torvalds <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      7b34c2fa
  29. 21 Oct, 2005 1 commit
  30. 18 Oct, 2005 1 commit
  31. 05 Oct, 2005 1 commit
    • Junio C Hamano's avatar
      upload-pack: Do not choke on too many heads request. · e091eb93
      Junio C Hamano authored
      Cloning from a repository with more than 256 refs (heads and tags
      included) will choke, because upload-pack has a built-in limit of
      feeding not more than MAX_NEEDS (currently 256) heads to underlying
      git-rev-list.  This is a problem when cloning a repository with many
      tags, like http://www.linux-mips.org/pub/scm/linux.git, which has 290+
      tags.
      
      This commit introduces a new flag, --all, to git-rev-list, to include
      all refs in the repository.  Updated upload-pack detects requests that
      ask more than MAX_NEEDS refs, and sends everything back instead.
      
      We may probably want to tweak the definitions of MAX_NEEDS and
      MAX_HAS, but that is a separate topic.
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      e091eb93
  32. 21 Sep, 2005 1 commit
    • Linus Torvalds's avatar
      [PATCH] Teach "git-rev-parse" about date-based cut-offs · c1babb1d
      Linus Torvalds authored
      This adds the options "--since=date" and "--before=date" to git-rev-parse,
      which knows how to translate them into seconds since the epoch for
      git-rev-list.
      
      With this, you can do
      
      	git log --since="2 weeks ago"
      
      or
      
      	git log --until=yesterday
      
      to show the commits that have happened in the last two weeks or are
      older than 24 hours, respectively.
      
      The flags "--after=" and "--before" are synonyms for --since and --until,
      and you can combine them, so
      
      	git log --after="Aug 5" --before="Aug 10"
      
      is a valid (but strange) thing to do.
      Signed-off-by: default avatarLinus Torvalds <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      c1babb1d
  33. 18 Sep, 2005 1 commit
  34. 24 Aug, 2005 1 commit
    • Junio C Hamano's avatar
      Rationalize output selection in rev-parse. · 4866ccf0
      Junio C Hamano authored
      Earlier rounds broke 'whatchanged -p'.  In attempting to fix this,
      make two axis of output selection in rev-parse orthogonal:
      
        --revs-only	tells it not to output things that are not revisions nor
      		flags that rev-list would take.
        --no-revs	tells it not to output things that are revisions or
      		flags that rev-list would take.
        --flags	tells it not to output parameters that do not start with
      		a '-'.
        --no-flags	tells it not to output parameters that starts with a '-'.
      
      So for example 'rev-parse --no-revs -p arch/i386' would yield '-p arch/i386',
      while 'rev-parse --no-revs --flags -p archi/i386' would give just '-p'.
      
      Also the meaning of --verify has been made stronger.  It now rejects
      anything but a single valid rev argument.  Earlier it passed some flags
      through without complaining.
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      4866ccf0
  35. 23 Aug, 2005 1 commit