Skip to content

G
git

李少辉-开发者 / git
与 Fork 源项目一致

从无法访问的项目Fork

通知 2
Star 1
Fork 0
G
git

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 02 3月, 2018 1 次提交
    • M
      write_locked_index(): add flag to avoid writing unchanged index · 61000814
      由 Martin Ågren 提交于 
      We have several callers like

	if (active_cache_changed && write_locked_index(...))
		handle_error();
	rollback_lock_file(...);

where the final rollback is needed because "!active_cache_changed"
shortcuts the if-expression. There are also a few variants of this,
including some if-else constructs that make it more clear when the
explicit rollback is really needed.

Teach `write_locked_index()` to take a new flag SKIP_IF_UNCHANGED and
simplify the callers. Leave the most complicated of the callers (in
builtin/update-index.c) unchanged. Rewriting it to use this new flag
would end up duplicating logic.

We could have made the new flag behave the other way round
("FORCE_WRITE"), but that could break existing users behind their backs.
Let's take the more conservative approach. We can still migrate existing
callers to use our new flag. Later we might even be able to flip the
default, possibly without entirely ignoring the risk to in-flight or
out-of-tree topics.
Suggested-by: NJeff King <peff@peff.net>
Signed-off-by: NMartin Ågren <martin.agren@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      61000814
  3. 13 12月, 2017 1 次提交
  5. 04 8月, 2017 1 次提交
  7. 03 8月, 2017 1 次提交
  9. 16 6月, 2017 1 次提交
  11. 09 1月, 2017 1 次提交
    • B
      mv: remove use of deprecated 'get_pathspec()' · 2ec87741
      由 Brandon Williams 提交于 
      Convert the 'internal_copy_pathspec()' function to 'prefix_path()'
instead of using the deprecated 'get_pathspec()' interface.  Also,
rename 'internal_copy_pathspec()' to 'internal_prefix_pathspec()' to be
more descriptive of what the funciton is actually doing.

In addition to this, fix a memory leak caused by only duplicating some
of the pathspec elements.  Instead always duplicate all of the the
pathspec elements as an intermediate step (with modificationed based on
the passed in flags).  This way the intermediate strings can then be
freed after getting the result from 'prefix_path()'.
Signed-off-by: NBrandon Williams <bmwill@google.com>
Reviewed-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      2ec87741
  13. 08 12月, 2016 1 次提交
    • J
      hold_locked_index(): align error handling with hold_lockfile_for_update() · b3e83cc7
      由 Junio C Hamano 提交于 
      Callers of the hold_locked_index() function pass 0 when they want to
prepare to write a new version of the index file without wishing to
die or emit an error message when the request fails (e.g. somebody
else already held the lock), and pass 1 when they want the call to
die upon failure.

This option is called LOCK_DIE_ON_ERROR by the underlying lockfile
API, and the hold_locked_index() function translates the paramter to
LOCK_DIE_ON_ERROR when calling the hold_lock_file_for_update().

Replace these hardcoded '1' with LOCK_DIE_ON_ERROR and stop
translating.  Callers other than the ones that are replaced with
this change pass '0' to the function; no behaviour change is
intended with this patch.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
---

Among the callers of hold_locked_index() that passes 0:

 - diff.c::refresh_index_quietly() at the end of "git diff" is an
   opportunistic update; it leaks the lockfile structure but it is
   just before the program exits and nobody should care.

 - builtin/describe.c::cmd_describe(),
   builtin/commit.c::cmd_status(),
   sequencer.c::read_and_refresh_cache() are all opportunistic
   updates and they are OK.

 - builtin/update-index.c::cmd_update_index() takes a lock upfront
   but we may end up not needing to update the index (i.e. the
   entries may be fully up-to-date), in which case we do not need to
   issue an error upon failure to acquire the lock.  We do diagnose
   and die if we indeed need to update, so it is OK.

 - wt-status.c::require_clean_work_tree() IS BUGGY.  It asks
   silence, does not check the returned value.  Compare with
   callsites like cmd_describe() and cmd_status() to notice that it
   is wrong to call update_index_if_able() unconditionally.
      b3e83cc7
  15. 26 9月, 2016 1 次提交
    • R
      use COPY_ARRAY · 45ccef87
      由 René Scharfe 提交于 
      Add a semantic patch for converting certain calls of memcpy(3) to
COPY_ARRAY() and apply that transformation to the code base.  The result
is
 shorter and safer code.  For now only consider calls where source and
destination have the same type, or in other words: easy cases.
Signed-off-by: NRene Scharfe <l.s.r@web.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      45ccef87
  17. 09 8月, 2016 1 次提交
  19. 20 4月, 2016 1 次提交
    • S
      mv: allow moving nested submodules · a127331c
      由 Stefan Beller 提交于 
      When directories are moved using `git mv` all files in the directory
have been just moved, but no further action was taken on them. This
was done by assigning the mode = WORKING_DIRECTORY to the files
inside a moved directory.

submodules however need to update their link to the git directory as
well as updates to the .gitmodules file. By removing the condition of
`mode != INDEX` (the remaining modes are BOTH and WORKING_DIRECTORY) for
the required submodule actions, we perform these for submodules in a
moved directory.
Signed-off-by: NStefan Beller <sbeller@google.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      a127331c
  21. 23 2月, 2016 2 次提交
  23. 15 1月, 2015 1 次提交
  25. 02 10月, 2014 1 次提交
  27. 19 9月, 2014 1 次提交
  29. 04 9月, 2014 6 次提交
  31. 12 8月, 2014 2 次提交
  33. 14 6月, 2014 1 次提交
  35. 09 5月, 2014 1 次提交
  37. 18 3月, 2014 1 次提交
  39. 12 3月, 2014 1 次提交
    • J
      builtin/mv: fix out of bounds write · 89ccc1b0
      由 John Keeping 提交于 
      When commit a88c915d (mv: move submodules using a gitfile, 2013-07-30)
added the submodule_gitfile array, it was not added to the block that
enlarges the arrays when we are moving a directory so that we do not
have to worry about it being a directory when we perform the actual
move.  After this, the loop continues over the enlarged set of sources.

Since we assume that submodule_gitfile has size argc, if any of the
items in the source directory are submodules we are guaranteed to write
beyond the end of submodule_gitfile.

Fix this by realloc'ing submodule_gitfile at the same time as the other
arrays.
Reported-by: NGuillaume Gelin <contact@ramnes.eu>
Signed-off-by: NJohn Keeping <john@keeping.me.uk>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      89ccc1b0
  41. 19 2月, 2014 1 次提交
    • J
      builtin/mv: don't use memory after free · d954828d
      由 John Keeping 提交于 
      If 'src' already ends with a slash, then add_slash() will just return
it, meaning that 'free(src_with_slash)' is actually 'free(src)'.  Since
we use 'src' later, this will result in use-after-free.

In fact, this cannot happen because 'src' comes from
internal_copy_pathspec() without the KEEP_TRAILING_SLASH flag, so any
trailing '/' will have been stripped; but static analysis tools are not
clever enough to realise this and so warn that 'src' could be used after
having been free'd.  Fix this by checking that 'src_w_slash' is indeed
newly allocated memory.
Signed-off-by: NJohn Keeping <john@keeping.me.uk>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      d954828d
  43. 11 1月, 2014 1 次提交
    • J
      mv: let 'git mv file no-such-dir/' error out on Windows, too · a8933469
      由 Johannes Sixt 提交于 
      The previous commit c57f6281 (mv: let 'git mv file no-such-dir/' error out)
relies on that rename("file", "no-such-dir/") fails if the directory does not
exist (note the trailing slash).  This does not work as expected on Windows:
This rename() call does not fail, but renames "file" to "no-such-dir" (not to
"no-such-dir/file"). Insert an explicit check for this case to force an error.

This changes the error message from

   $ git mv file no-such-dir/
   fatal: renaming 'file' failed: Not a directory

to

   $ git mv file no-such-dir/
   fatal: destination directory does not exist, source=file, destination=no-such-dir/
Signed-off-by: NJohannes Sixt <j6t@kdbg.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      a8933469
  45. 05 12月, 2013 1 次提交
  47. 14 10月, 2013 1 次提交
    • J
      mv: Fix spurious warning when moving a file in presence of submodules · 04c1ee57
      由 Jens Lehmann 提交于 
      In commit 0656781f "git mv" learned to update the submodule path in the
.gitmodules file when moving a submodule in the work tree. But since that
commit update_path_in_gitmodules() gets called no matter if we moved a
submodule or a regular file, which is wrong and leads to a bogus warning
when moving a regular file in a repo containing a .gitmodules file:

    warning: Could not find section in .gitmodules where path=<filename>

Fix that by only calling update_path_in_gitmodules() when moving a
submodule. To achieve that, we introduce the special SUBMODULE_WITH_GITDIR
define to distinguish the cases where we also have to connect work tree
and git directory from those where we only need to update the .gitmodules
setting.

A test for submodules using a .git directory together with a .gitmodules
file has been added to t7001. Even though newer git versions will always
use a gitfile when cloning submodules, repositories cloned with older git
versions will still use this layout.
Reported-by: NMatthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Signed-off-by: NJens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
      04c1ee57
  49. 07 8月, 2013 1 次提交
    • J
      mv: update the path entry in .gitmodules for moved submodules · 0656781f
      由 Jens Lehmann 提交于 
      Currently using "git mv" on a submodule moves the submodule's work tree in
that of the superproject. But the submodule's path setting in .gitmodules
is left untouched, which is now inconsistent with the work tree and makes
git commands that rely on the proper path -> name mapping (like status and
diff) behave strangely.

Let "git mv" help here by not only moving the submodule's work tree but
also updating the "submodule.<submodule name>.path" setting from the
.gitmodules file and stage both. This doesn't happen when no .gitmodules
file is found and only issues a warning when it doesn't have a section for
this submodule. This is because the user might just use plain gitlinks
without the .gitmodules file or has already updated the path setting by
hand before issuing the "git mv" command (in which case the warning
reminds him that mv would have done that for him). Only when .gitmodules
is found and contains merge conflicts the mv command will fail and tell
the user to resolve the conflict before trying again.

Also extend the man page to inform the user about this new feature.
Signed-off-by: NJens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      0656781f
  51. 06 8月, 2013 1 次提交
  53. 31 7月, 2013 2 次提交
    • J
      mv: move submodules using a gitfile · a88c915d
      由 Jens Lehmann 提交于 
      When moving a submodule which uses a gitfile to point to the git directory
stored in .git/modules/<name> of the superproject two changes must be made
to make the submodule work: the .git file and the core.worktree setting
must be adjusted to point from work tree to git directory and back.

Achieve that by remembering which submodule uses a gitfile by storing the
result of read_gitfile() of each submodule. If that is not NULL the new
function connect_work_tree_and_git_dir() is called after renaming the
submodule's work tree which updates the two settings to the new values.

Extend the man page to inform the user about that feature (and while at it
change the description to not talk about a script anymore, as mv is a
builtin for quite some time now).
Signed-off-by: NJens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      a88c915d
    • J
      mv: move submodules together with their work trees · 11502468
      由 Jens Lehmann 提交于 
      Currently the attempt to use "git mv" on a submodule errors out with:

  fatal: source directory is empty, source=<src>, destination=<dest>

The reason is that mv searches for the submodule with a trailing slash in
the index, which it doesn't find (because it is stored without a trailing
slash). As it doesn't find any index entries inside the submodule it
claims the directory would be empty even though it isn't.

Fix that by searching for the name without a trailing slash and continue
if it is a submodule. Then rename() will move the submodule work tree just
like it moves a file.
Signed-off-by: NJens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      11502468
  55. 16 7月, 2013 1 次提交
  57. 21 8月, 2012 1 次提交
  59. 13 12月, 2011 3 次提交
    • J
      mv: be quiet about overwriting · 534376ca
      由 Jeff King 提交于 
      When a user asks us to force a mv and overwrite the
destination, we print a warning. However, since a typical
use would be:

  $ git mv one two
  fatal: destination exists, source=one, destination=two
  $ git mv -f one two
  warning: overwriting 'two'

this warning is just noise. We already know we're
overwriting; that's why we gave -f!

This patch silences the warning unless "--verbose" is given.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      534376ca
    • J
      mv: improve overwrite warning · cd40b05d
      由 Jeff King 提交于 
      When we try to "git mv" over an existing file, the error
message is fairly informative:

  $ git mv one two
  fatal: destination exists, source=one, destination=two

When the user forces the overwrite, we give a warning:

  $ git mv -f one two
  warning: destination exists; will overwrite!

This is less informative, but still sufficient in the simple
rename case, as there is only one rename happening.

But when moving files from one directory to another, it
becomes useless:

  $ mkdir three
  $ touch one two three/one
  $ git add .
  $ git mv one two three
  fatal: destination exists, source=one, destination=three/one
  $ git mv -f one two three
  warning: destination exists; will overwrite!

The first message is helpful, but the second one gives us no
clue about what was overwritten. Let's mention the name of
the destination file:

  $ git mv -f one two three
  warning: overwriting 'three/one'
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      cd40b05d
    • J
      mv: make non-directory destination error more clear · 77471646
      由 Jeff King 提交于 
      If you try to "git mv" multiple files onto another
non-directory file, you confusingly get the "usage" message:

  $ touch one two three
  $ git add .
  $ git mv one two three
  usage: git mv [options] <source>... <destination>
  [...]

From the user's perspective, that makes no sense. They just
gave parameters that exactly match that usage!

This behavior dates back to the original C version of "git
mv", which had a usage message like:

  usage: git mv (<source> <destination> | <source>...  <destination>)

This was slightly less confusing, because it at least
mentions that there are two ways to invoke (but it still
isn't clear why what the user provided doesn't work).

Instead, let's show an error message like:

  $ git mv one two three
  fatal: destination 'three' is not a directory

We could leave the usage message in place, too, but it
doesn't actually help here. It contains no hints that there
are two forms, nor that multi-file form requires that the
endpoint be a directory. So it just becomes useless noise
that distracts from the real error.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      77471646