1. 15 Aug, 2006 2 commits
    • Junio C Hamano's avatar
      avoid nanosleep(2) · 789a09b4
      Junio C Hamano authored
      On Solaris nanosleep(2) is not available in libc; you need to
      link with -lrt to get it.
      The purpose of the loop is to wait until the next filesystem
      timestamp granularity, and the code uses subsecond sleep in the
      hope that it can shorten the delay to 0.5 seconds on average
      instead of a full second.  It is probably not worth depending on
      an extra library for this.
      We might want to yank out the whole "racy-git avoidance is
      costly later at runtime, so let's delay writing the index out"
      codepath later, but that is a separate issue and needs some
      testing on large trees to figure it out.  After playing with the
      kernel tree, I have a feeling that the whole thing may not be
      worth it.
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
    • David Rientjes's avatar
      read-cache.c cleanup · 968a1d65
      David Rientjes authored
      Removes conditional returns.
      Signed-off-by: default avatarDavid Rientjes <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
  2. 09 Aug, 2006 1 commit
    • Junio C Hamano's avatar
      read-cache: tweak racy-git delay logic · 6015c28b
      Junio C Hamano authored
      Instead of looping over the entries and writing out, use a
      separate loop after all entries have been written out to check
      how many entries are racily clean.  Make sure that the newly
      created index file gets the right timestamp when we check by
      flushing the buffered data by ce_write().
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
  3. 07 Aug, 2006 1 commit
    • Junio C Hamano's avatar
      Racy git: avoid having to be always too careful · b7e58b17
      Junio C Hamano authored
      Immediately after a bulk checkout, most of the paths in the
      working tree would have the same timestamp as the index file,
      and this would force ce_match_stat() to take slow path for all
      of them.  When writing an index file out, if many of the paths
      have very new (read: the same timestamp as the index file being
      written out) timestamp, we are better off delaying the return
      from the command, to make sure that later command to touch the
      working tree files will leave newer timestamps than recorded in
      the index, thereby avoiding to take the slow path.
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
  4. 31 Jul, 2006 1 commit
  5. 26 Jul, 2006 2 commits
  6. 10 Jul, 2006 1 commit
  7. 20 Jun, 2006 1 commit
  8. 28 May, 2006 1 commit
  9. 19 May, 2006 1 commit
    • Linus Torvalds's avatar
      Libify the index refresh logic · 405e5b2f
      Linus Torvalds authored
      This cleans up and libifies the "git update-index --[really-]refresh"
      functionality. This will be eventually required for eventually doing the
      "commit" and "status" commands as built-ins.
      It really just moves "refresh_index()" from update-index.c to
      read-cache.c, but it also has to change the calling convention so that the
      function uses a "unsigned int flags" argument instead of various static
      flags variables for passing down the information about whether to be quiet
      or not, and allow unmerged entries etc.
      That actually cleans up update-index.c too, since it turns out that all
      those flags were really specific to that one function of the index update,
      so they shouldn't have had file-scope visibility even before.
      Signed-off-by: default avatarLinus Torvalds <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
  10. 18 May, 2006 1 commit
  11. 09 May, 2006 1 commit
  12. 25 Apr, 2006 1 commit
  13. 23 Apr, 2006 1 commit
  14. 13 Feb, 2006 1 commit
  15. 09 Feb, 2006 1 commit
    • Junio C Hamano's avatar
      "Assume unchanged" git · 5f73076c
      Junio C Hamano authored
      This adds "assume unchanged" logic, started by this message in the list
      discussion recently:
      	<[email protected]>
      This is a workaround for filesystems that do not have lstat()
      that is quick enough for the index mechanism to take advantage
      of.  On the paths marked as "assumed to be unchanged", the user
      needs to explicitly use update-index to register the object name
      to be in the next commit.
      You can use two new options to update-index to set and reset the
      CE_VALID bit:
      	git-update-index --assume-unchanged path...
      	git-update-index --no-assume-unchanged path...
      These forms manipulate only the CE_VALID bit; it does not change
      the object name recorded in the index file.  Nor they add a new
      entry to the index.
      When the configuration variable "core.ignorestat = true" is set,
      the index entries are marked with CE_VALID bit automatically
       - update-index to explicitly register the current object name to the
         index file.
       - when update-index --refresh finds the path to be up-to-date.
       - when tools like read-tree -u and apply --index update the working
         tree file and register the current object name to the index file.
      The flag is dropped upon read-tree that does not check out the index
      entry.  This happens regardless of the core.ignorestat settings.
      Index entries marked with CE_VALID bit are assumed to be
      unchanged most of the time.  However, there are cases that
      CE_VALID bit is ignored for the sake of safety and usability:
       - while "git-read-tree -m" or git-apply need to make sure
         that the paths involved in the merge do not have local
         modifications.  This sacrifices performance for safety.
       - when git-checkout-index -f -q -u -a tries to see if it needs
         to checkout the paths.  Otherwise you can never check
         anything out ;-).
       - when git-update-index --really-refresh (a new flag) tries to
         see if the index entry is up to date.  You can start with
         everything marked as CE_VALID and run this once to drop
         CE_VALID bit for paths that are modified.
      Most notably, "update-index --refresh" honours CE_VALID and does
      not actively stat, so after you modified a file in the working
      tree, update-index --refresh would not notice until you tell the
      index about it with "git-update-index path" or "git-update-index
      --no-assume-unchanged path".
      This version is not expected to be perfect.  I think diff
      between index and/or tree and working files may need some
      adjustment, and there probably needs other cases we should
      automatically unmark paths that are marked to be CE_VALID.
      But the basics seem to work, and ready to be tested by people
      who asked for this feature.
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
  16. 20 Dec, 2005 3 commits
    • Junio C Hamano's avatar
      ce_smudge_racily_clean_entry: explain why it works. · 4b3511b0
      Junio C Hamano authored
      This is a tricky code and warrants extra commenting.  I wasted
      30 minutes trying to break it until I realized why it works.
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
    • Junio C Hamano's avatar
      Racy GIT (part #2) · 407c8eb0
      Junio C Hamano authored
      The previous round caught the most trivial case well, but broke
      down once index file is updated again.  Smudge problematic
      entries (they should be very few if any under normal interactive
      workflow) before writing a new index file out.
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
    • Junio C Hamano's avatar
      Racy GIT · 29e4d363
      Junio C Hamano authored
      This fixes the longstanding "Racy GIT" problem, which was pretty
      much there from the beginning of time, but was first
      demonstrated by Pasky in this message on October 24, 2005:
      If you run the following sequence of commands:
      	echo frotz >infocom
              git update-index --add infocom
              echo xyzzy >infocom
      so that the second update to file "infocom" does not change
      st_mtime, what is recorded as the stat information for the cache
      entry "infocom" exactly matches what is on the filesystem
      (owner, group, inum, mtime, ctime, mode, length).  After this
      sequence, we incorrectly think "infocom" file still has string
      "frotz" in it, and get really confused.  E.g. git-diff-files
      would say there is no change, git-update-index --refresh would
      not even look at the filesystem to correct the situation.
      Some ways of working around this issue were already suggested by
      Linus in the same thread on the same day, including waiting
      until the next second before returning from update-index if a
      cache entry written out has the current timestamp, but that
      means we can make at most one commit per second, and given that
      the e-mail patch workflow used by Linus needs to process at
      least 5 commits per second, it is not an acceptable solution.
      Linus notes that git-apply is primarily used to update the index
      while processing e-mailed patches, which is true, and
      git-apply's up-to-date check is fooled by the same problem but
      luckily in the other direction, so it is not really a big issue,
      but still it is disturbing.
      The function ce_match_stat() is called to bypass the comparison
      against filesystem data when the stat data recorded in the cache
      entry matches what stat() returns from the filesystem.  This
      patch tackles the problem by changing it to actually go to the
      filesystem data for cache entries that have the same mtime as
      the index file itself.  This works as long as the index file and
      working tree files are on the filesystems that share the same
      monotonic clock.  Files on network mounted filesystems sometimes
      get skewed timestamps compared to "date" output, but as long as
      working tree files' timestamps are skewed the same way as the
      index file's, this approach still works.  The only problematic
      files are the ones that have the same timestamp as the index
      file's, because two file updates that sandwitch the index file
      update must happen within the same second to trigger the
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
  17. 12 Oct, 2005 2 commits
    • Linus Torvalds's avatar
      Use git config file for committer name and email info · e1b10391
      Linus Torvalds authored
      This starts using the "user.name" and "user.email" config variables if
      they exist as the default name and email when committing.  This means
      that you don't have to use the GIT_COMMITTER_EMAIL environment variable
      to override your email - you can just edit the config file instead.
      The patch looks bigger than it is because it makes the default name and
      email information non-static and renames it appropriately.  And it moves
      the common git environment variables into a new library file, so that
      you can link against libgit.a and get the git environment without having
      to link in zlib and libcrypt.
      In short, most of it is renaming and moving, the real change core is
      just a few new lines in "git_default_config()" that copies the user
      config values to the new base.
      It also changes "git-var -l" to list the config variables.
      Signed-off-by: default avatarLinus Torvalds <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
    • Junio C Hamano's avatar
      Use core.filemode. · 3e09cdfd
      Junio C Hamano authored
      With "[core] filemode = false", you can tell git to ignore
      differences in the working tree file only in executable bit.
       * "git-update-index --refresh" does not say "needs update" if index
         entry and working tree file differs only in executable bit.
       * "git-update-index" on an existing path takes executable bit
         from the existing index entry, if the path and index entry are
         both regular files.
       * "git-diff-files" and "git-diff-index" without --cached flag
         pretend the path on the filesystem has the same executable
         bit as the existing index entry, if the path and index entry
         are both regular files.
      If you are on a filesystem with unreliable mode bits, you may need to
      force the executable bit after registering the path in the index.
       * "git-update-index --chmod=+x foo" flips the executable bit of the
         index file entry for path "foo" on.  Use "--chmod=-x" to flip it
      Note that --chmod only works in index file and does not look at nor
      update the working tree.
      So if you are on a filesystem and do not have working executable bit,
      you would do:
       1. set the appropriate .git/config option;
       2. "git-update-index --add new-file.c"
       3. "git-ls-files --stage new-file.c" to see if it has the desired
         mode bits.  If not, e.g. to drop executable bit picked up from the
         filesystem, say "git-update-index --chmod=-x new-file.c".
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
  18. 10 Oct, 2005 1 commit
    • Linus Torvalds's avatar
      Add ".git/config" file parser · 17712991
      Linus Torvalds authored
      This is a first cut at a very simple parser for a git config file.
      The format of the file is a simple ini-file like thing, with simple
      variable/value pairs. You can (and should) make the variables have a
      simple single-level scope, ie a valid file looks something like this:
      	# This is the config file, and
      	# a '#' or ';' character indicates
      	# a comment
      	; core variables
      		; Don't trust file modes
      		filemode = false
      	; Our diff algorithm
      		external = "/usr/local/bin/gnu-diff -u"
      		renames = true
      which parses into three variables: "core.filemode" is associated with the
      string "false", and "diff.external" gets the appropriate quoted value.
      Right now we only react to one variable: "core.filemode" is a boolean that
      decides if we should care about the 0100 (user-execute) bit of the stat
      information. Even that is just a parsing demonstration - this doesn't
      actually implement that st_mode compare logic itself.
      Different programs can react to different config options, although they
      should always fall back to calling "git_default_config()" on any config
      option name that they don't recognize.
      Signed-off-by: default avatarLinus Torvalds <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
  19. 02 Oct, 2005 1 commit
    • Linus Torvalds's avatar
      [PATCH] Better error reporting for "git status" · 5d1a5c02
      Linus Torvalds authored
      Instead of "git status" ignoring (and hiding) potential errors from the
      "git-update-index" call, make it exit if it fails, and show the error.
      In order to do this, use the "-q" flag (to ignore not-up-to-date files)
      and add a new "--unmerged" flag that allows unmerged entries in the index
      without any errors.
      This also avoids marking the index "changed" if an entry isn't actually
      modified, and makes sure that we exit with an understandable error message
      if the index is corrupt or unreadable. "read_cache()" no longer returns an
      error for the caller to check.
      Finally, make die() and usage() exit with recognizable error codes, if we
      ever want to check the failure reason in scripts.
      Signed-off-by: default avatarLinus Torvalds <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
  20. 25 Sep, 2005 1 commit
  21. 20 Sep, 2005 1 commit
    • Junio C Hamano's avatar
      Show modified files in git-ls-files · b0391890
      Junio C Hamano authored
      Add -m/--modified to show files that have been modified wrt. the index.
      [jc: The original came from Brian Gerst on Sep 1st but it only checked
      if the paths were cache dirty without actually checking the files were
      modified.  I also added the usage string and a new test.]
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
  22. 11 Sep, 2005 1 commit
  23. 17 Aug, 2005 1 commit
  24. 30 Jul, 2005 1 commit
    • Pavel Roskin's avatar
      [PATCH] mmap error handling · e35f9824
      Pavel Roskin authored
      I have reviewed all occurrences of mmap() in git and fixed three types
      of errors/defects:
      1) The result is not checked.
      2) The file descriptor is closed if mmap() succeeds, but not when it
      3) Various casts applied to -1 are used instead of MAP_FAILED, which is
      specifically defined to check mmap() return value.
      [jc: This is a second round of Pavel's patch.  He fixed up the problem
      that close() potentially clobbering the errno from mmap, which
      the first round had.]
      Signed-off-by: Pavel Roskin's avatarPavel Roskin <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
  25. 14 Jul, 2005 1 commit
  26. 25 Jun, 2005 1 commit
    • Junio C Hamano's avatar
      [PATCH] Fix oversimplified optimization for add_cache_entry(). · b155725d
      Junio C Hamano authored
      An earlier change to optimize directory-file conflict check
      broke what "read-tree --emu23" expects.  This is fixed by this
      (1) Introduces an explicit flag to tell add_cache_entry() not to
          check for conflicts and use it when reading an existing tree
          into an empty stage --- by definition this case can never
          introduce such conflicts.
      (2) Makes read-cache.c:has_file_name() and read-cache.c:has_dir_name()
          aware of the cache stages, and flag conflict only with paths
          in the same stage.
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      Signed-off-by: default avatarLinus Torvalds <[email protected]>
  27. 19 Jun, 2005 2 commits
    • Linus Torvalds's avatar
      read-cache.c: remove stray debugging printf · 2160a025
      Linus Torvalds authored
      Pointed out by Junio, part of my debugging of the rewrite of the
      file/dir conflict handling.
    • Linus Torvalds's avatar
      Re-implement "check_file_directory_conflict()" · 12676608
      Linus Torvalds authored
      This is (imho) more readable, and is also a lot faster.  The expense of
      looking up sub-directory beginnings was killing us on things like
      "git-diff-cache", even though that one didn't even care at all about the
      file vs directory conflicts.
      We really only care when somebody tries to add a conflicting name to
      stage 0.
      We should go through the conflict rules more carefully some day.
  28. 10 Jun, 2005 1 commit
  29. 09 Jun, 2005 1 commit
  30. 07 Jun, 2005 1 commit
  31. 27 May, 2005 1 commit
    • David Meybohm's avatar
      [PATCH] check_file_directory_conflict path fix · 8310c2c0
      David Meybohm authored
      check_file_directory_conflict can give the wrong answers. This is
      because the wrong length is passed to cache_name_pos. The length
      passed should be the length of the whole path from the root, not
      the length of each path subcomponent.
      	$ git-init-db
      	defaulting to local storage area
      	$ mkdir path && touch path/file
      	$ git-update-cache --add path/file
      	$ rm path/file
      	$ mkdir path/file && touch path/file/f
      	$ git-update-cache --add path/file/f  <-- Conflict ignored
      Signed-off-by: default avatarDavid Meybohm <[email protected]>
      Signed-off-by: default avatarLinus Torvalds <[email protected]>
  32. 22 May, 2005 2 commits
    • Linus Torvalds's avatar
      Don't care about st_dev in the index file · 2cb45e95
      Linus Torvalds authored
      Thomas Glanzmann points out that it doesn't work well with different
      clients accessing the repository over NFS - they have different views
      on what the "device" for the filesystem is.
      Of course, other filesystems may not even have stable inode numbers.
      But we don't care. At least for now.
    • Linus Torvalds's avatar
      Include file cleanups.. · 6b0c3121
      Linus Torvalds authored
      Add <limits.h> to the include files handled by "cache.h", and remove
      extraneous #include directives from various .c files. The rule is that
      "cache.h" gets all the basic stuff, so that we'll have as few system
      dependencies as possible.
  33. 20 May, 2005 1 commit