Граф коммитов

27 Коммитов

Автор SHA1 Сообщение Дата
Junio C Hamano be02b3c53e Merge branch 'ar/chmod-series'
* ar/chmod-series:
  make update-index --chmod work with multiple files and --stdin
2006-04-24 02:08:35 -07:00
Alex Riesen 227bdb186f make update-index --chmod work with multiple files and --stdin
The patch makes "--chmod=-x" and "--chmod=+x" act like "--add"
and "--remove" to affect the behaviour of the command for the
rest of the path parameters, not just the following one.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-23 00:47:03 -07:00
Junio C Hamano 2bd452d3b9 git-update-index --unresolve
Retire git-unresolve and make it into "git-update-index --unresolve".
It processes all paths that follow.

During a merge, you would mark a path that is dealt with with:

	$ git update-index hello

and you would "undo" it with:

	$ git update-index --unresolve hello

Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-19 23:52:05 -07:00
Peter Eriksen 90321c106c Replace xmalloc+memset(0) with xcalloc.
Signed-off-by: Peter Eriksen <s022018@student.dtu.dk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-04 00:11:19 -07:00
Shawn Pearce a41c175d6f Prevent --index-info from ignoring -z.
If git-update-index --index-info -z is used only the first
record given to the process will actually be updated as
the -z option is ignored until after all index records
have been read and processed.  This meant that multiple
null terminated records were seen as a single record which
was lacking a trailing LF, however since the first record
ended in a null the C string handling functions ignored the
trailing garbage.  So --index-info should be required to be
the last command line option, much as --stdin is required
to be the last command line option.  Because --index-info
implies --stdin this isn't an issue as the user shouldn't
be passing --stdin when also passing --index-info.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-02 23:07:42 -08:00
Junio C Hamano b92b2ce94e "Assume unchanged" git: --really-refresh fix.
The earlier round failed to make --really-refresh to mark
up-to-date index entry to valid again due to a trivial thinko.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-09 00:55:17 -08:00
Junio C Hamano 8b9b0f3af7 "Assume unchanged" git: do not set CE_VALID with --refresh
When working with automatic assume-unchanged mode using
core.ignorestat, setting CE_VALID after --refresh makes things
more cumbersome to use.  Consider this scenario:

 (1) the working tree is on a filesystem with slow lstat(2).
     The user sets core.ignorestat = true.

 (2) "git checkout" to switch to a different branch (or initial
     checkout) updates all paths and the index starts out with
     "all clean".

 (3) The user knows she wants to edit certain paths.  She uses
     update-index --no-assume-unchanged (we could call it --edit;
     the name is inmaterial) to mark these paths and starts
     editing.

 (4) After editing half of the paths marked to be edited, she
     runs "git status".  This runs "update-index --refresh" to
     reduce the false hits from diff-files.

 (5) Now the other half of the paths, since she has not changed
     them, are found to match the index, and CE_VALID is set on
     them again.

For this reason, this commit makes update-index --refresh not to
set CE_VALID even after the path without CE_VALID are verified
to be up to date.  The user still can run --really-refresh to
force lstat() to match the index entries to the reality.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-08 21:54:48 -08:00
Junio C Hamano 5f73076c1a "Assume unchanged" git
This adds "assume unchanged" logic, started by this message in the list
discussion recently:

	<Pine.LNX.4.64.0601311807470.7301@g5.osdl.org>

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
after:

 - 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: Junio C Hamano <junkio@cox.net>
2006-02-08 21:54:42 -08:00
Junio C Hamano 2d49711512 update-index --index-info: allow stage 0 entries.
Somehow we did not allow stuffing the index with stage 0 entries
through --index-info interface.  I do not think of a reason to
forbid it offhand.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-01 19:45:55 -08:00
Junio C Hamano a94d9948da update-index: work with c-quoted name
update-index --stdin did not work with c-style quoted names even though
update-index --index-info did.  This fixes the inconsistency.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-01-11 13:36:45 -08:00
Junio C Hamano d23748a6af update-index: allow --index-info to add higher stages.
The new merge world order tells the merge strategies to leave
the cache unmerged and store the automerge result in the working
tree if automerge is not clean.  This was done for the resolve
strategy and recursive strategy when no rename is involved, but
recording a conflicting merge in the rename case could not
easily be done by the recursive strategy.

This commit adds a new input format, in addition to the exsting
two, to "update-index --index-info".

    (1) mode         SP sha1          TAB path
    The first format is what "git-apply --index-info"
    reports, and used to reconstruct a partial tree
    that is used for phony merge base tree when falling
    back on 3-way merge.

    (2) mode SP type SP sha1          TAB path
    The second format is to stuff git-ls-tree output
    into the index file.

    (3) mode         SP sha1 SP stage TAB path
    This format is to put higher order stages into the
    index file and matches git-ls-files --stage output.

To place a higher stage entry to the index, the path should
first be removed by feeding a mode=0 entry for the path, and
then feeding necessary input lines in the (3) format.

For example, starting with this index:

$ git ls-files -s
100644 8a1218a1024a212bb3db30becd860315f9f3ac52 0       frotz

$ git update-index --index-info ;# interactive session -- input follows...

0 0000000000000000000000000000000000000000	frotz
100644 8a1218a1024a212bb3db30becd860315f9f3ac52 1	frotz
100755 8a1218a1024a212bb3db30becd860315f9f3ac52 2	frotz

The first line of the input feeds 0 as the mode to remove the
path; the SHA1 does not matter as long as it is well formatted.
Then the second and third line feeds stage 1 and stage 2 entries
for that path.  After the above, we would end up with this:

$ git ls-files -s
100644 8a1218a1024a212bb3db30becd860315f9f3ac52 1	frotz
100755 8a1218a1024a212bb3db30becd860315f9f3ac52 2	frotz

This completes the groundwork for the new merge world order.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-07 01:53:50 -08:00
Junio C Hamano 9c20a47067 Teach update-index to read from ls-tree.
git-update-index --index-info can almost be usable to read from ls-tree
output to update the index (and not the working tree file) to HEAD commit,
but not quite.  It was designed to read from git-apply --index-info
output, and does not want " blob " in ls-tree output.  Accept that as well.

This lets us update "git-checkout <ent> <path>" that used to filter the
extra " blob " string out.  Noted by Luben.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-23 22:25:55 -08:00
Chris Shoemaker 14470c0de3 Add to documentation of git-update-index arguments and usage.
Removed unknown [--version] option.

Signed-off-by: Chris Shoemaker <c.shoemaker@cox.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-30 17:28:01 -08:00
Petr Baudis f6ab5bb265 Add usage string to git-update-index
This patch adds usage string to git-update-index, can be printed by the -h
or --help parameter.

Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-25 22:51:18 -07:00
Junio C Hamano 973d6a2015 update-index --index-info: adjust for funny-path quoting.
Although the sole current user uses -z to read this, we should be
prepared for somebody to feed non-z format to the command.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-17 17:41:57 -07:00
Junio C Hamano caf4f582b2 Improve "git add" again.
This makes it possible to add paths that have funny characters (TAB
and LF) in them, and makes adding many paths more efficient in
general.

New flag "--stdin" to update-index was initially added for different
purpose, but it turns out to be a perfect match for feeding "ls-files
--others -z" output to improve "git add".

It also adds "--verbose" flag to update-index for use with "git add"
command.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-17 17:41:55 -07:00
Junio C Hamano 3e09cdfd11 Use core.filemode.
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
   off.

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: Junio C Hamano <junkio@cox.net>
2005-10-11 18:45:33 -07:00
Junio C Hamano d4dbf36df0 update-index: read --show-index-info output from standard input.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-07 03:42:00 -07:00
Junio C Hamano ec1fcc16af Show original and resulting blob object info in diff output.
This adds more cruft to diff --git header to record the blob SHA1 and
the mode the patch/diff is intended to be applied against, to help the
receiving end fall back on a three-way merge.  The new header looks
like this:

    diff --git a/apply.c b/apply.c
    index 7be5041..8366082 100644
    --- a/apply.c
    +++ b/apply.c
    @@ -14,6 +14,7 @@
     //    files that are being modified, but doesn't apply the patch
     //  --stat does just a diffstat, and doesn't actually apply
    +//  --show-index-info shows the old and new index info for...
    ...

Upon receiving such a patch, if the patch did not apply cleanly to the
target tree, the recipient can try to find the matching old objects in
her object database and create a temporary tree, apply the patch to
that temporary tree, and attempt a 3-way merge between the patched
temporary tree and the target tree using the original temporary tree
as the common ancestor.

The patch lifts the code to compute the hash for an on-filesystem
object from update-index.c and makes it available to the diff output
routine.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-07 03:42:00 -07:00
Linus Torvalds 5cd5ace72b [PATCH] Re-instate index file write optimization
This makes "git-update-index" avoid the new index file write if it didn't
make any changes to the index.

It still doesn't make things like "git status" be read-only operations in
general, but if the index file doesn't need refreshing, it now will at
least avoid making unnecessary changes.

Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-01 23:56:16 -07:00
Linus Torvalds 5d1a5c02e8 [PATCH] Better error reporting for "git status"
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: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-01 23:55:47 -07:00
Junio C Hamano ee1bec3d10 update-index: --stdin and -z
The new option --stdin reads list of paths to be updated from the
standard input.  As usual, -z means the paths are terminated with NUL
characters, as opposed to LF without that option.

This is useful to use git-diff-files -z and git-ls-files -z when the
platform xargs does not support -0 option, and obviously saves one
process even when xargs can take -0.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-27 16:59:44 -07:00
Junio C Hamano 6b5ee137e5 Diff clean-up.
This is a long overdue clean-up to the code for parsing and passing
diff options.  It also tightens some constness issues.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-24 23:50:43 -07:00
Junio C Hamano b0391890d2 Show modified files in git-ls-files
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: Junio C Hamano <junkio@cox.net>
2005-09-20 15:07:53 -07:00
Junio C Hamano 1991b223c0 Fast-path 'update-index --refresh' a bit.
If the length in the stat information does not match what is recorded
in the index, there is no point rehashing the contents to see if the
index entry can be refreshed.

We need to be a bit careful.  Immediately after read-tree or
checkout-index without -u, ce_size is set to zero and does not match
the length of the blob that is recorded, and we need to actually look
at the contents to see if it has been changed.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-20 15:07:53 -07:00
Petr Baudis 34143b2639 [PATCH] Improve git-update-index error reporting
This makes git-update-index error reporting much less confusing. The
user will know what went wrong with better precision, and will be given
a hopefully less confusing advice.

Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-18 14:18:57 -07:00
Junio C Hamano 215a7ad1ef Big tool rename.
As promised, this is the "big tool rename" patch.  The primary differences
since 0.99.6 are:

  (1) git-*-script are no more.  The commands installed do not
      have any such suffix so users do not have to remember if
      something is implemented as a shell script or not.

  (2) Many command names with 'cache' in them are renamed with
      'index' if that is what they mean.

There are backward compatibility symblic links so that you and
Porcelains can keep using the old names, but the backward
compatibility support  is expected to be removed in the near
future.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-07 17:45:20 -07:00