Skip to content


Subversion checkout URL

You can clone with
Download ZIP
Branch: master
Commits on May 30, 2014
  1. @torvalds

    git log: support "auto" decorations

    torvalds authored committed
    This works kind of like "--color=auto" - add decorations for interactive
    use, but do not change defaults when scripting or when piping the output
    to anything but a terminal.
    You can use either
    in the git config files, or the "--decorate=auto" command line option to
    choose this behavior.
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Junio C Hamano <>
Commits on Feb 25, 2014
  1. @torvalds

    request-pull: allow "local:remote" to specify names on both ends

    torvalds authored committed
    This allows a user to say that a local branch has a different name on
    the remote server, using the same syntax that "git push" uses to create
    that situation.
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Junio C Hamano <>
  2. @torvalds

    request-pull: more strictly match local/remote branches

    torvalds authored committed
    The current 'request-pull' will try to find matching commit on the given
    remote, and rewrite the "please pull" line to match that remote ref.
    That may be very helpful if your local tree doesn't match the layout of
    the remote branches, but for the common case it's been a recurring
    disaster, when "request-pull" is done against a delayed remote update, and
    it rewrites the target branch randomly to some other branch name that
    happens to have the same expected SHA1 (or more commonly, leaves it
    To avoid that recurring problem, this changes "git request-pull" so that
    it matches the ref name to be pulled against the *local* repository, and
    then warns if the remote repository does not have that exact same branch
    or tag name and content.
    This means that git request-pull will never rewrite the ref-name you gave
    it.  If the local branch name is "xyzzy", that is the only branch name
    that request-pull will ask the other side to fetch.
    If the remote has that branch under a different name, that's your problem
    and git request-pull will not try to fix it up (but git request-pull will
    warn about the fact that no exact matching branch is found, and you can
    edit the end result to then have the remote name you want if it doesn't
    match your local one).
    The new "find local ref" code will also complain loudly if you give an
    ambiguous refname (eg you have both a tag and a branch with that same
    name, and you don't specify "heads/name" or "tags/name").
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Junio C Hamano <>
Commits on Oct 17, 2012
  1. @torvalds

    Fix "git diff --stat" for interesting - but empty - file changes

    torvalds authored committed
    The behavior of "git diff --stat" is rather odd for files that have
    zero lines of changes: it will discount them entirely unless they were
    Which means that the stat output will simply not show files that only
    had "other" changes: they were created or deleted, or their mode was
    Now, those changes do show up in the summary, but so do renames, so
    the diffstat logic is inconsistent. Why does it show renames with zero
    lines changed, but not mode changes or added files with zero lines
    So change the logic to not check for "is_renamed", but for
    "is_interesting" instead, where "interesting" is judged to be any
    action but a pure data change (because a pure data change with zero
    data changed really isn't worth showing, if we ever get one in our
    So if you did
       chmod +x Makefile
       git diff --stat
    before, it would show empty (" 0 files changed"), with this it shows
     Makefile | 0
     1 file changed, 0 insertions(+), 0 deletions(-)
    which I think is a more correct diffstat (and then with "--summary" it
    shows *what* the metadata change to Makefile was - this is completely
    consistent with our handling of renamed files).
    Side note: the old behavior was *really* odd. With no changes at all,
    "git diff --stat" output was empty. With just a chmod, it said "0
    files changed". No way is our legacy behavior sane.
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Junio C Hamano <>
Commits on Oct 1, 2012
  1. @torvalds

    mailinfo: don't require "text" mime type for attachments

    torvalds authored committed
    Currently "git am" does insane things if the mbox it is given contains
    attachments with a MIME type that aren't "text/*".
    In particular, it will still decode them, and pass them "one line at a
    time" to the mail body filter, but because it has determined that they
    aren't text (without actually looking at the contents, just at the mime
    type) the "line" will be the encoding line (eg 'base64') rather than a
    line of *content*.
    Which then will cause the text filtering to fail, because we won't
    correctly notice when the attachment text switches from the commit message
    to the actual patch. Resulting in a patch failure, even if patch may be a
    perfectly well-formed attachment, it's just that the message type may be
    (for example) "application/octet-stream" instead of "text/plain".
    Just remove all the bogus games with the message_type. The only difference
    that code creates is how the data is passed to the filter function
    (chunked per-pred-code line or per post-decode line), and that difference
    is *wrong*, since chunking things per pre-decode line can never be a
    sensible operation, and cannot possibly matter for binary data anyway.
    This code goes all the way back to March of 2007, in commit 87ab799
    ("builtin-mailinfo.c infrastrcture changes"), and apparently Don used to
    pass random mbox contents to git. However, the pre-decode vs post-decode
    logic really shouldn't matter even for that case, and more importantly, "I
    fed git am crap" is not a valid reason to break *real* patch attachments.
    If somebody really cares, and determines that some attachment is binary
    data (by looking at the data, not the MIME-type), the whole attachment
    should be dismissed, rather than fed in random-sized chunks to
    Signed-off-by: Linus Torvalds <>
    Cc: Don Zickus <>
    Signed-off-by: Junio C Hamano <>
Commits on Aug 21, 2012
  1. @torvalds

    commit/commit-tree: correct latin1 to utf-8

    torvalds authored committed
    When a line in the message is not a valid utf-8, "git mailinfo"
    attempts to convert it to utf-8 assuming the input is latin1 (and
    punt if it does not convert cleanly).  Using the same heuristics in
    "git commit" and "git commit-tree" lets the editor output be in
    latin1 to make the overall system more consistent.
    Signed-off-by: Junio C Hamano <>
Commits on May 25, 2012
  1. @torvalds

    fmt-merge-message: add empty line between tag and signature verification

    torvalds authored committed
    When adding the information from a tag, put an empty line between the
    message of the tag and the commented-out signature verification
    At least for the kernel workflow, I often end up re-formatting the message
    that people send me in the tag data. In that situation, putting the tag
    message and the tag signature verification back-to-back then means that
    normal editor "reflow parapgraph" command will get confused and think that
    the signature is a continuation of the last message paragraph.
    So I always end up having to first add an empty line, and then go back and
    reflow the last paragraph. Let's just do it in git directly.
    The extra vertical space also makes the verification visually stand out
    more from the user-supplied message, so it looks a bit more readable to me
    too, but that may be just an odd personal preference.
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Junio C Hamano <>
Commits on Feb 13, 2012
  1. @torvalds

    "git pull" doesn't know "--edit"

    torvalds authored committed
    Ok, so now "git merge" defaults to editing when interactive - lovely. But
    when testing that, I noticed that while you can say
       git merge --[no-]edit ..branch..
    that does not work with "git pull". You get a message like
      error: unknown option `no-edit'
      usage: git fetch [<options>] [<repository> [<refspec>...]]
         or: git fetch [<options>] <group>
         or: git fetch --multiple [<options>] [(<repository> | <group>)...]
         or: git fetch --all [<options>]
          -v, --verbose         be more verbose
          -q, --quiet           be more quiet
          --all                 fetch from all remotes
    which is because that stupid shell script doesn't know about the new
    flags, and just passes it to "git fetch" instead.
    Now, I really wanted to just make "git pull" a built-in instead of that
    nasty shell script, but I'm lazy. So here's the trivial updates to to at least teach it about -e/--edit/--no-edit.
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Junio C Hamano <>
Commits on Nov 5, 2011
  1. @torvalds

    fetch: do not store peeled tag object names in FETCH_HEAD

    torvalds authored committed
    We do not want to record tags as parents of a merge when the user does
    "git pull $there tag v1.0" to merge tagged commit, but that is not a good
    enough excuse to peel the tag down to commit when storing in FETCH_HEAD.
    The caller of underlying "git fetch $there tag v1.0" may have other uses
    of information contained in v1.0 tag in mind.
    [jc: the test adjustment is to update for the new expectation]
    Signed-off-by: Junio C Hamano <>
Commits on Mar 11, 2011
  1. @torvalds

    Make the default abbrev length configurable

    torvalds authored committed
    The default of 7 comes from fairly early in git development, when
    seven hex digits was a lot (it covers about 250+ million hash
    values). Back then I thought that 65k revisions was a lot (it was what
    we were about to hit in BK), and each revision tends to be about 5-10
    new objects or so, so a million objects was a big number.
    These days, the kernel isn't even the largest git project, and even
    the kernel has about 220k revisions (_much_ bigger than the BK tree
    ever was) and we are approaching two million objects. At that point,
    seven hex digits is still unique for a lot of them, but when we're
    talking about just two orders of magnitude difference between number
    of objects and the hash size, there _will_ be collisions in truncated
    hash values. It's no longer even close to unrealistic - it happens all
    the time.
    We should both increase the default abbrev that was unrealistically
    small, _and_ add a way for people to set their own default per-project
    in the git config file.
    This is the first step to first make it configurable; the default of 7
    is not raised yet.
    Signed-off-by: Junio C Hamano <>
Commits on Feb 19, 2011
  1. @torvalds

    diffcore-rename: improve estimate_similarity() heuristics

    torvalds authored committed
    The logic to quickly dismiss potential rename pairs was broken.  It
    would too eagerly dismiss possible renames when all of the difference
    was due to pure new data (or deleted data).
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Junio C Hamano <>
  2. @torvalds

    diffcore-rename: properly honor the difference between -M and -C

    torvalds authored committed
    We would allow rename detection to do copy detection even when asked
    purely for renames.  That confuses users, but more importantly it can
    terminally confuse the recursive merge rename logic.
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Junio C Hamano <>
  3. @torvalds

    for_each_hash: allow passing a 'void *data' pointer to callback

    torvalds authored committed
    For the find_exact_renames() function, this allows us to pass the
    diff_options structure pointer to the low-level routines.  We will use
    that to distinguish between the "rename" and "copy" cases.
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Junio C Hamano <>
Commits on Sep 27, 2010
  1. @torvalds

    Fix missing 'does' in man-page for 'git checkout'

    torvalds authored committed
    Reported-by: Rainer Standke <>
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Junio C Hamano <>
Commits on Aug 25, 2010
  1. @torvalds

    Fix 'git log' early pager startup error case

    torvalds authored committed
    We start the pager too early for several git commands, which results in
    the errors sometimes going to the pager rather than show up as errors.
    This is often hidden by the fact that we pass in '-X' to less by default,
    which causes 'less' to exit for small output, but if you do
      export LESS=-S
    you can then clearly see the problem by doing
      git log --prretty
    which shows the error message ("fatal: unrecognized argument: --prretty")
    being sent to the pager.
    This happens for pretty much all git commands that use USE_PAGER, and then
    check arguments separately. But "git diff" does it too early too (even
    though it does an explicit setup_pager() call)
    This only fixes it for the trivial "git log" family case.
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Junio C Hamano <>
Commits on Jun 14, 2010
  1. @torvalds

    Make :/ accept a regex rather than a fixed pattern

    torvalds authored committed
    This also makes it trigger anywhere in the commit message, rather than
    just at the beginning. Which tends to be a lot more useful.
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Junio C Hamano <>
Commits on Feb 22, 2010
  1. @torvalds

    Move 'builtin-*' into a 'builtin/' subdirectory

    torvalds authored committed
    This shrinks the top-level directory a bit, and makes it much more
    pleasant to use auto-completion on the thing. Instead of
    	[torvalds@nehalem git]$ em buil<tab>
    	Display all 180 possibilities? (y or n)
    	[torvalds@nehalem git]$ em builtin-sh
    	builtin-shortlog.c     builtin-show-branch.c  builtin-show-ref.c
    	builtin-shortlog.o     builtin-show-branch.o  builtin-show-ref.o
    	[torvalds@nehalem git]$ em builtin-shor<tab>
    	builtin-shortlog.c  builtin-shortlog.o
    	[torvalds@nehalem git]$ em builtin-shortlog.c
    you get
    	[torvalds@nehalem git]$ em buil<tab>		[type]
    	builtin/   builtin.h
    	[torvalds@nehalem git]$ em builtin		[auto-completes to]
    	[torvalds@nehalem git]$ em builtin/sh<tab>	[type]
    	shortlog.c     shortlog.o     show-branch.c  show-branch.o  show-ref.c     show-ref.o
    	[torvalds@nehalem git]$ em builtin/sho		[auto-completes to]
    	[torvalds@nehalem git]$ em builtin/shor<tab>	[type]
    	shortlog.c  shortlog.o
    	[torvalds@nehalem git]$ em builtin/shortlog.c
    which doesn't seem all that different, but not having that annoying
    break in "Display all 180 possibilities?" is quite a relief.
    NOTE! If you do this in a clean tree (no object files etc), or using an
    editor that has auto-completion rules that ignores '*.o' files, you
    won't see that annoying 'Display all 180 possibilities?' message - it
    will just show the choices instead.  I think bash has some cut-off
    around 100 choices or something.
    So the reason I see this is that I'm using an odd editory, and thus
    don't have the rules to cut down on auto-completion.  But you can
    simulate that by using 'ls' instead, or something similar.
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Junio C Hamano <>
Commits on Jan 22, 2010
  1. @torvalds

    make "index-pack" a built-in

    torvalds authored committed
    This required some fairly trivial packfile function 'const' cleanup,
    since the builtin commands get a const char *argv[] array.
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Junio C Hamano <>
  2. @torvalds

    make "git pack-redundant" a built-in

    torvalds authored committed
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Junio C Hamano <>
  3. @torvalds

    make "git unpack-file" a built-in

    torvalds authored committed
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Junio C Hamano <>
  4. @torvalds

    make "mktag" a built-in

    torvalds authored committed
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Junio C Hamano <>
  5. @torvalds

    make "merge-index" a built-in

    torvalds authored committed
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Junio C Hamano <>
  6. @torvalds

    make "git patch-id" a built-in

    torvalds authored committed
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Junio C Hamano <>
  7. @torvalds

    make "git var" a built-in

    torvalds authored committed
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Junio C Hamano <>
  8. @torvalds

    make "git hash-object" a built-in

    torvalds authored committed
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Junio C Hamano <>
  9. @torvalds

    make "git merge-tree" a built-in

    torvalds authored committed
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Junio C Hamano <>
  10. @torvalds

    slim down "git show-index"

    torvalds authored committed
    As the documentation says, this is primarily for debugging, and
    in the longer term we should rename it to test-show-index or something.
    In the meantime, just avoid xmalloc (which slurps in the rest of git), and
    separating out the trivial hex functions into "hex.o".
    This results in
      [torvalds@nehalem git]$ size git-show-index
           text    data     bss     dec     hex filename
         222818    2276  112688  337782   52776 git-show-index (before)
           5696     624    1264    7584    1da0 git-show-index (after)
    which is a whole lot better.
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Junio C Hamano <>
  11. @torvalds

    Remove diff machinery dependency from read-cache

    torvalds authored committed
    Exal Sibeaz pointed out that some git files are way too big, and that
    add_files_to_cache() brings in all the diff machinery to any git binary
    that needs the basic git SHA1 object operations from read-cache.c. Which
    is pretty much all of them.
    It's doubly silly, since add_files_to_cache() is only used by builtin
    programs (add, checkout and commit), so it's fairly easily fixed by just
    moving the thing to builtin-add.c, and avoiding the dependency entirely.
    I initially argued to Exal that it would probably be best to try to depend
    on smart compilers and linkers, but after spending some time trying to
    make -ffunction-sections work and giving up, I think Exal was right, and
    the fix is to just do some trivial cleanups like this.
    This trivial cleanup results in pretty stunning file size differences.
    The diff machinery really is mostly used by just the builtin programs, and
    you have things like these trivial before-and-after numbers:
      -rwxr-xr-x 1 torvalds torvalds 1727420 2010-01-21 10:53 git-hash-object
      -rwxrwxr-x 1 torvalds torvalds  940265 2010-01-21 11:16 git-hash-object
    Now, I'm not saying that 940kB is good either, but that's mostly all the
    debug information - you can see the real code with 'size':
       text	   data	    bss	    dec	    hex	filename
     418675	   3920	 127408	 550003	  86473	git-hash-object (before)
     230650	   2288	 111728	 344666	  5425a	git-hash-object (after)
    ie we have a nice 24% size reduction from this trivial cleanup.
    It's not just that one file either. I get:
    	[torvalds@nehalem git]$ du -s /home/torvalds/libexec/git-core
    	45640	/home/torvalds/libexec/git-core (before)
    	33508	/home/torvalds/libexec/git-core (after)
    so we're talking 12MB of diskspace here.
    (Of course, stripping all the binaries brings the 33MB down to 9MB, so the
    whole debug information thing is still the bulk of it all, but that's a
    separate issue entirely)
    Now, I'm sure there are other things we should do, and changing our
    compiler flags from -O2 to -Os would bring the text size down by an
    additional almost 20%, but this thing Exal pointed out seems to be some
    good low-hanging fruit.
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Junio C Hamano <>
Commits on Dec 5, 2009
  1. @torvalds

    Fix diff -B/--dirstat miscounting of newly added contents

    torvalds authored committed
    What used to happen is that diffcore_count_changes() simply ignored any
    hashes in the destination that didn't match hashes in the source. EXCEPT
    if the source hash didn't exist at all, in which case it would count _one_
    destination hash that happened to have the "next" hash value.  As a
    consequence, newly added material was often undercounted, making output
    from --dirstat and "complete rewrite" detection used by -B unrelialble.
    This changes it so that:
     - whenever it bypasses a destination hash (because it doesn't match a
       source), it counts the bytes associated with that as "literal added"
     - at the end (once we have used up all the source hashes), we do the same
       thing with the remaining destination hashes.
     - when hashes do match, and we use the difference in counts as a value,
       we also use up that destination hash entry (the 'd++').
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Junio C Hamano <>
Commits on Oct 28, 2009
  1. @torvalds

    Add '--bisect' revision machinery argument

    torvalds authored committed
    I personally use "git bisect visualize" all the time when I bisect, but it
    turns out that that is not a very flexible model. Sometimes I want to do
    bisection based on all commits (no pathname limiting), but then visualize
    the current bisection tree with just a few pathnames because I _suspect_
    those pathnames are involved in the problem but am not totally sure about
    And at other times, I want to use other revision parsing logic, none of
    which is available with "git bisect visualize".
    So this adds "--bisect" as a revision parsing argument, and as a result it
    just works with all the normal logging tools. So now I can just do
    	gitk --bisect --simplify-by-decoration filename-here
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Junio C Hamano <>
Commits on Aug 23, 2009
  1. @torvalds

    Further 'approxidate' improvements

    torvalds authored committed
    The previous patch to improve approxidate got us to the point that a lot
    of the remaining annoyances were due to the 'strict' date handling running
    first, and deciding that it got a good enough date that the approximate
    date routines were never even invoked.
    For example, using a date string like
    	6AM, June 7, 2009
    the strict date logic would be perfectly happy with the "June 7, 2009"
    part, and ignore the 6AM part that it didn't understand - resulting in the
    information getting dropped on the floor:
    	6AM, June 7, 2009 -> Sat Jun 6 00:00:00 2009
    and the date being calculated as if it was midnight, and the '6AM' having
    confused the date routines into thinking about '6 June' rather than 'June
    7' at 6AM (ie notice how the _day_ was wrong due to this, not just the
    So this makes the strict date routines a bit stricter, and requires that
    not just the date, but also the time, has actually been parsed. With that
    fix, and trivial extension of the approxidate routines, git now properly
    parses the date as
    	6AM, June 7, 2009 -> Sun Jun  7 06:00:00 2009
    without dropping the fuzzy time ("6AM" or "noon" or any of the other
    non-strict time formats) on the floor.
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Junio C Hamano <>
  2. @torvalds

    Improve on 'approxidate'

    torvalds authored committed
    This is not a new failure mode - approxidate has always been kind of
    random in the input it accepts, but some of the randomness is more
    irritating than others.
    For example:
    	Jun 6, 5AM -> Mon Jun 22 05:00:00 2009
    	5AM Jun 6 -> Sat Jun  6 05:00:00 2009
    Whaa? The reason for the above is that approxidate squirrells away the '6'
    from "Jun 6" to see if it's going to be a relative number, and then
    forgets about it when it sees a new number (the '5' in '5AM'). So the odd
    "June 22" date is because today is July 22nd, and if it doesn't have
    another day of the month, it will just pick todays mday - having ignored
    the '6' entirely due to getting all excited about seeing a new number (5).
    There are other oddnesses. This does not fix them all, but I think it
    makes for fewer _really_ perplexing cases. At least now we have
    	Jun 6, 5AM -> Sat Jun  6 05:00:00 2009
    	5AM, Jun 6 -> Sat Jun  6 05:00:00 2009
    which makes me happier. I can still point to cases that don't work as
    well, but those are separate issues.
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Junio C Hamano <>
Commits on Aug 11, 2009
  1. @torvalds

    block-sha1: improve code on large-register-set machines

    torvalds authored committed
    For x86 performance (especially in 32-bit mode) I added that hack to write
    the SHA1 internal temporary hash using a volatile pointer, in order to get
    gcc to not try to cache the array contents. Because gcc will do all the
    wrong things, and then spill things in insane random ways.
    But on architectures like PPC, where you have 32 registers, it's actually
    perfectly reasonable to put the whole temporary array[] into the register
    set, and gcc can do so.
    So make the 'volatile unsigned int *' cast be dependent on a
    SMALL_REGISTER_SET preprocessor symbol, and enable it (currently) on just
    x86 and x86-64.  With that, the routine is fairly reasonable even when
    compared to the hand-scheduled PPC version. Ben Herrenschmidt reports on
    a G5:
     * Paulus asm version:       about 3.67s
     * Yours with no change:     about 5.74s
     * Yours without "volatile": about 3.78s
    so with this the C version is within about 3% of the asm one.
    And add a lot of commentary on what the heck is going on.
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Junio C Hamano <>
Commits on Aug 8, 2009
  1. @torvalds

    block-sha1: improved SHA1 hashing

    torvalds authored committed
    I think I have found a way to avoid the gcc crazyness.
    Lookie here:
    	#             TIME[s] SPEED[MB/s]
    	rfc3174         5.094       119.8
    	rfc3174         5.098       119.7
    	linus           1.462       417.5
    	linusas         2.008         304
    	linusas2        1.878         325
    	mozilla         5.566       109.6
    	mozillaas       5.866       104.1
    	openssl         1.609       379.3
    	spelvin         1.675       364.5
    	spelvina        1.601       381.3
    	nettle          1.591       383.6
    notice? I outperform all the hand-tuned asm on 32-bit too. By quite a
    margin, in fact.
    Now, I didn't try a P4, and it's possible that it won't do that there, but
    the 32-bit code generation sure looks impressive on my Nehalem box. The
    magic? I force the stores to the 512-bit hash bucket to be done in order.
    That seems to help a lot.
    The diff is trivial (on top of the "rename registers with cpp" patch), as
    appended. And it does seem to fix the P4 issues too, although I can
    obviously (once again) only test Prescott, and only in 64-bit mode:
    	#             TIME[s] SPEED[MB/s]
    	rfc3174         1.662       36.73
    	rfc3174          1.64       37.22
    	linus          0.2523       241.9
    	linusas        0.4367       139.8
    	linusas2       0.4487         136
    	mozilla        0.9704        62.9
    	mozillaas      0.9399       64.94
    that's some really impressive improvement. All from just saying "do the
    stores in the order I told you to, dammit!" to the compiler.
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Junio C Hamano <>
  2. @torvalds

    block-sha1: perform register rotation using cpp

    torvalds authored committed
    Instead of letting the compiler to figure out the optimal way to rotate
    register usage, explicitly rotate the register names with cpp.
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Junio C Hamano <>
Something went wrong with that request. Please try again.