Skip to content
This repository

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Sep 18, 2006

  1. giladtest

    Start handling references internally as a sorted in-memory list

    This also adds some very rudimentary support for the notion of packed
    refs.  HOWEVER! At this point it isn't used to actually look up a ref
    yet, only for listing them (ie "for_each_ref()" and friends see the
    packed refs, but none of the other single-ref lookup routines).
    
    Note how we keep two separate lists: one for the loose refs, and one for
    the packed refs we read. That's so that we can easily keep the two apart,
    and read only one set or the other (and still always make sure that the
    loose refs take precedence).
    
    [ From this, it's not actually obvious why we'd keep the two separate
      lists, but it's important to have the packed refs on their own list
      later on, when I add support for looking up a single loose one.
    
      For that case, we will want to read _just_ the packed refs in case the
      single-ref lookup fails, yet we may end up needing the other list at
      some point in the future, so keeping them separated is important ]
    
    Signed-off-by: Linus Torvalds <torvalds@osdl.org>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    authored Junio C Hamano committed

Sep 16, 2006

  1. giladtest

    Add "git show-ref" builtin command

    It's kind of like "git peek-remote", but works only locally (and thus
    avoids the whole overhead of git_connect()) and has some extra
    verification features.
    
    For example, it allows you to filter the results, and to choose whether
    you want the tag dereferencing or not. You can also use it to just test
    whether a particular ref exists.
    
    For example:
    
    	git show-ref master
    
    will show all references called "master", whether tags or heads or
    anything else, and regardless of how deep in the reference naming
    hierarchy they are (so it would show "refs/heads/master" but also
    "refs/remote/other-repo/master").
    
    When using the "--verify" flag, the command requires an exact ref path:
    
    	git show-ref --verify refs/heads/master
    
    will only match the exact branch called "master".
    
    If nothing matches, show-ref will return an error code of 1, and in the
    case of verification, it will show an error message.
    
    For scripting, you can ask it to be quiet with the "--quiet" flag, which
    allows you to do things like
    
    	git-show-ref --quiet --verify -- "refs/heads/$headname" ||
    		echo "$headname is not a valid branch"
    
    to check whether a particular branch exists or not (notice how we don't
    actually want to show any results, and we want to use the full refname for
    it in order to not trigger the problem with ambiguous partial matches).
    
    To show only tags, or only proper branch heads, use "--tags" and/or
    "--heads" respectively (using both means that it shows tags _and_ heads,
    but not other random references under the refs/ subdirectory).
    
    To do automatic tag object dereferencing, use the "-d" or "--dereference"
    flag, so you can do
    
    	git show-ref --tags --dereference
    
    to get a listing of all tags together with what they dereference.
    
    Signed-off-by: Linus Torvalds <torvalds@osdl.org>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    authored Junio C Hamano committed

Jul 29, 2006

  1. giladtest

    Call setup_git_directory() much earlier

    This changes the calling convention of built-in commands and
    passes the "prefix" (i.e. pathname of $PWD relative to the
    project root level) down to them.
    
    Signed-off-by: Linus Torvalds <torvalds@osdl.org>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    authored Junio C Hamano committed

Jul 09, 2006

  1. giladtest

    builtin "git prune"

    This actually removes the objects to be pruned, unless you specify "-n"
    (at which point it will just tell you which files it would prune).
    
    This doesn't do the pack-file pruning that the shell-script used to do,
    but if somebody really wants to, they could add it easily enough. I wonder
    how useful it is, though, considering that "git repack -a -d" is just a
    lot more efficient and generates a better end result.
    
    Signed-off-by: Linus Torvalds <torvalds@osdl.org>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    authored Junio C Hamano committed

May 20, 2006

  1. giladtest

    Add builtin "git rm" command

    This changes semantics very subtly, because it adds a new atomicity
    guarantee.
    
    In particular, if you "git rm" several files, it will now do all or
    nothing. The old shell-script really looped over the removed files one by
    one, and would basically randomly fail in the middle if "-f" was used and
    one of the files didn't exist in the working directory.
    
    This C builtin one will not re-write the index after each remove, but
    instead remove all files at once. However, that means that if "-f" is used
    (to also force removal of the file from the working directory), and some
    files have already been removed from the workspace, it won't stop in the
    middle in some half-way state like the old one did.
    
    So what happens is that if the _first_ file fails to be removed with "-f",
    we abort the whole "git rm". But once we've started removing, we don't
    leave anything half done. If some of the other files don't exist, we'll
    just ignore errors of removal from the working tree.
    
    This is only an issue with "-f", of course.
    
    I think the new behaviour is strictly an improvement, but perhaps more
    importantly, it is _different_. As a special case, the semantics are
    identical for the single-file case (which is the only one our test-suite
    seems to test).
    
    The other question is what to do with leading directories. The old "git
    rm" script didn't do anything, which is somewhat inconsistent. This one
    will actually clean up directories that have become empty as a result of
    removing the last file, but maybe we want to have a flag to decide the
    behaviour?
    
    Signed-off-by: Linus Torvalds <torvalds@osdl.org>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    authored Junio C Hamano committed

May 18, 2006

  1. giladtest

    Make "git rev-list" be a builtin

    This was surprisingly easy. The diff is truly minimal: rename "main()" to
    "cmd_rev_list()" in rev-list.c, and rename the whole file to reflect its
    new built-in status.
    
    Signed-off-by: Linus Torvalds <torvalds@osdl.org>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    authored Junio C Hamano committed

May 17, 2006

  1. giladtest

    Do "git add" as a builtin

    First try. Let's see how well this works.
    
    In many ways, the hard parts of "git commit" are not so different from
    this, and a builtin commit would share a lot of the code, I think.
    
    Signed-off-by: Linus Torvalds <torvalds@osdl.org>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    authored Junio C Hamano committed

Apr 30, 2006

  1. giladtest

    git builtin "push"

    This adds a builtin "push" command, which is largely just a C'ification of
    the "git-push.sh" script.
    
    Now, the reason I did it as a built-in is partly because it's yet another
    step on relying less on shell, but it's actually mostly because I've
    wanted to be able to push to _multiple_ repositories, and the most obvious
    and simplest interface for that would seem be to just have a "remotes"
    file that has multiple URL entries.
    
    (For "pull", having multiple entries should either just select the first
    one, or you could fall back on the others on failure - your choice).
    
    And quite frankly, it just became too damn messy to do that in shell.
    Besides, we actually have a fair amount of infrastructure in C, so it just
    wasn't that hard to do.
    
    Of course, this is almost totally untested. It probably doesn't work for
    anything but the one trial I threw at it. "Simple" doesn't necessarily
    mean "obviously correct".
    
    Signed-off-by: Linus Torvalds <torvalds@osdl.org>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    authored Junio C Hamano committed

Apr 27, 2006

  1. giladtest

    Fix "git help -a" terminal autosizing

    When I split out the builtin commands into their own files, I left the
    include of <sys/ioctl.h> in git.c rather than moving it to the file that
    needed it (builtin-help.c).
    
    Nobody seems to have noticed, because everything still worked, but because
    the TIOCGWINSZ macro was now no longer defined when compiling the
    "term_columns()" function, it would no longer automatically notice the
    terminal size unless your system used the ancient "COLUMNS" environment
    variable approach.
    
    Trivially fixed by just moving the header include to the file that
    actually needs it.
    
    Signed-off-by: Linus Torvalds <torvalds@osdl.org>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    authored Junio C Hamano committed

Apr 21, 2006

  1. giladtest

    Split up builtin commands into separate files from git.c

    Right now it split it into "builtin-log.c" for log-related commands
    ("log", "show" and "whatchanged"), and "builtin-help.c" for the
    informational commands (usage printing and "help" and "version").
    
    This just makes things easier to read, I find.
    
    Signed-off-by: Linus Torvalds <torvalds@osdl.org>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    authored Junio C Hamano committed

Apr 19, 2006

  1. giladtest

    git log: don't do merge diffs by default

    I personally prefer "ignore_merges" to be on by default, because quite
    often the merge diff is distracting and not interesting. That's true both
    with "-p" and with "--stat" output.
    
    If you want output from merges, you can trivially use the "-m", "-c" or
    "--cc" flags to tell that you're interested in merges, which also tells
    the diff generator what kind of diff to do (for --stat, any of the three
    will do, of course, but they differ for plain patches or for
    --patch-with-stat).
    
    This trivial patch just removes the two lines that tells "git log" not to
    ignore merges. It will still show the commit log message, of course, due
    to the "always_show_header" part.
    
    Signed-off-by: Linus Torvalds <torvalds@osdl.org>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    authored Junio C Hamano committed

Apr 17, 2006

  1. giladtest

    Log message printout cleanups

    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: Linus Torvalds <torvalds@osdl.org>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    authored Junio C Hamano committed

Apr 16, 2006

  1. giladtest

    Fixes for option parsing

    Make sure "git show" always show the header, regardless of whether there
    is a diff or not.
    
    Also, make sure "always_show_header" actually works, since generate_header
    only tested it in one out of three return paths.
    
    Signed-off-by: Linus Torvalds <torvalds@osdl.org>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    authored Junio C Hamano committed
  2. giladtest

    Tentative built-in "git show"

    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: Linus Torvalds <torvalds@osdl.org>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    authored Junio C Hamano committed
  3. giladtest

    Support "git cmd --help" syntax

    The "--help" argument is special, in that it is (along with "--version")
    in that is taken by the "git" program itself rather than the sub-command,
    and thus we've had the syntax "git --help cmd".
    
    However, as anybody who has ever used CVS or some similar devil-spawn
    program, it's confusing as h*ll when options before the sub-command act
    differently from options after the sub-command, so this quick hack just
    makes it acceptable to do "git cmd --help" instead, and get the exact same
    result.
    
    It may be hacky, but it's simple and does the trick.
    
    Of course, this does not help if you use one of the non-builtin commands
    without using the "git" helper. Ie you won't be getting a man-page just
    because you do "git-rev-list --help". Don't expect us to be quite _that_
    helpful.
    
    Signed-off-by: Linus Torvalds <torvalds@osdl.org>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    authored Junio C Hamano committed

Apr 15, 2006

  1. giladtest

    Common option parsing for "git log --diff" and friends

    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: Linus Torvalds <torvalds@osdl.org>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    authored Junio C Hamano committed

Apr 13, 2006

  1. giladtest

    Use less memory in "git log"

    This trivially avoids keeping the commit message data around after we
    don't need it any more, avoiding a continually growing "git log" memory
    footprint.
    
    It's not a huge deal, but it's somewhat noticeable. For the current kernel
    tree, doing a full "git log" I got
    
     - before: /usr/bin/time git log > /dev/null
    	0.81user 0.02system 0:00.84elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
    	0inputs+0outputs (0major+8851minor)pagefaults 0swaps
    
     - after: /usr/bin/time git log > /dev/null
    	0.79user 0.03system 0:00.83elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
    	0inputs+0outputs (0major+5039minor)pagefaults 0swaps
    
    ie the touched pages dropped from 8851 to 5039. For the historic kernel
    archive, the numbers are 18357->11037 minor page faults.
    
    We could/should in theory free the commits themselves, but that's really a
    lot harder, since during revision traversal we may hit the same commit
    twice through different children having it as a parent, even after we've
    shown it once (when that happens, we'll silently ignore it next time, but
    we still need the "struct commit" to know).
    
    And as the commit message data is clearly the biggest part of the commit,
    this is the really easy 60% solution.
    
    Signed-off-by: Linus Torvalds <torvalds@osdl.org>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    authored Junio C Hamano committed

Apr 01, 2006

  1. giladtest

    Move "--parent" parsing into generic revision.c library code

    Not only do we do it in both rev-list.c and git.c, the revision walking
    code will soon want to know whether we should rewrite parenthood
    information or not.
    
    Signed-off-by: Linus Torvalds <torvalds@osdl.org>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    authored Junio C Hamano committed

Feb 28, 2006

  1. giladtest

    Tie it all together: "git log"

    This is what the previous diffs all built up to.
    
    We can do "git log" as a trivial small helper function inside git.c,
    because the infrastructure is all there for us to use as a library.
    
    Signed-off-by: Linus Torvalds <torvalds@osdl.org>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    authored Junio C Hamano committed

Feb 26, 2006

  1. giladtest

    Teach the "git" command to handle some commands internally

    This is another patch in the "prepare to do more in C" series, where the
    git wrapper command is taught about the notion of handling some
    functionality internally.
    
    Right now, the only internal commands are "version" and "help", but the
    point being that we can now easily extend it to handle some of the trivial
    scripts internally. Things like "git log" and "git diff" wouldn't need
    separate external scripts any more.
    
    This also implies that to support the old "git-log" and "git-diff" syntax,
    the "git" wrapper now automatically looks at the name it was executed as,
    and if it is "git-xxxx", it will assume that it is to internally do what
    "git xxxx" would do.
    
    In other words, you can (once you implement an internal command) soft- or
    hard-link that command to the "git" wrapper command, and it will do the
    right thing, whether you use the "git xxxx" or the "git-xxxx" format.
    
    There's one other change: the search order for external programs is
    modified slightly, so that the first entry remains GIT_EXEC_DIR, but the
    second entry is the same directory as the git wrapper itself was executed
    out of - if we can figure it out from argv[0], of course.
    
    Signed-off-by: Linus Torvalds <torvalds@osdl.org>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    authored Junio C Hamano committed

Dec 18, 2005

  1. giladtest

    Make "git help" sort git commands in columns

    This changes "pretty_print_string_list()" to show the git commands
    alphabetically in column order, which is the normal one.
    
    Ie instead of doing
    
    	git commands available in '/home/torvalds/bin'
    	----------------------------------------------
    	  add                am                 ...
    	  applypatch         archimport         ...
    	  cat-file           check-ref-format   ...
    	...
    
    it does
    
    	git commands available in '/home/torvalds/bin'
    	----------------------------------------------
    	  add                diff-tree          ...
    	  am                 fetch              ...
    	  apply              fetch-pack         ...
    	...
    
    where each column is sorted.
    
    This is how "ls" sorts things too, and since visually the columns are much
    more distinct than the rows, so it _looks_ more sorted.
    
    The "ls" command has a "-x" option that lists entries by lines (the way
    git.c used to): if somebody wants to do that, the new print-out logic
    could be easily accomodated to that too. Matter of taste and preference, I
    guess.
    
    Signed-off-by: Linus Torvalds <torvalds@osdl.org>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    authored Junio C Hamano committed
  2. giladtest

    Make "git help" react to window size correctly

    Currently the git "show commands" function will react to the environment
    variable COLUMNS, or just default to a width of 80 characters.
    
    That's just soo eighties. Nobody sane sets COLUMNS any more, unless they
    need to support some stone-age software from before the age of steam
    engines, SIGWINCH and TIOCGWINSZ.
    
    So get with the new century, and use TIOCGWINSZ to get the terminal size.
    
    Signed-off-by: Linus Torvalds <torvalds@osdl.org>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    authored Junio C Hamano committed
Something went wrong with that request. Please try again.