Skip to content

G
git

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

从无法访问的项目Fork

通知 2
Star 1
Fork 0
G
git

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

切换分支/标签
  1. 14 6月, 2014 2 次提交
    • J
      use get_commit_buffer everywhere · bc6b8fc1
      由 Jeff King 提交于 
      Each of these sites assumes that commit->buffer is valid.
Since they would segfault if this was not the case, they are
likely to be correct in practice. However, we can
future-proof them by using get_commit_buffer.

And as a side effect, we abstract away the final bare uses
of commit->buffer.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      bc6b8fc1
    • J
      convert logmsg_reencode to get_commit_buffer · b66103c3
      由 Jeff King 提交于 
      Like the callsites in the previous commit, logmsg_reencode
already falls back to read_sha1_file when necessary.
However, I split its conversion out into its own commit
because it's a bit more complex.

We return either:

  1. The original commit->buffer

  2. A newly allocated buffer from read_sha1_file

  3. A reencoded buffer (based on either 1 or 2 above).

while trying to do as few extra reads/allocations as
possible. Callers currently free the result with
logmsg_free, but we can simplify this by pointing them
straight to unuse_commit_buffer. This is a slight layering
violation, in that we may be passing a buffer from (3).
However, since the end result is to free() anything except
(1), which is unlikely to change, and because this makes the
interface much simpler, it's a reasonable bending of the
rules.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      b66103c3
  3. 13 6月, 2014 1 次提交
    • J
      sequencer: use logmsg_reencode in get_message · d74a4e57
      由 Jeff King 提交于 
      This simplifies the code, as logmsg_reencode handles the
reencoding for us in a single call. It also means we learn
logmsg_reencode's trick of pulling the buffer from disk when
commit->buffer is NULL (we currently just silently return!).
It is doubtful this matters in practice, though, as
sequencer operations would not generally turn off
save_commit_buffer.

Note that we may be fixing a bug here. The existing code
does:

  if (same_encoding(to, from))
	  reencode_string(buf, to, from);

That probably should have been "!same_encoding".
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      d74a4e57
  5. 28 1月, 2014 1 次提交
  7. 06 12月, 2013 1 次提交
    • C
      replace {pre,suf}fixcmp() with {starts,ends}_with() · 59556548
      由 Christian Couder 提交于 
      Leaving only the function definitions and declarations so that any
new topic in flight can still make use of the old functions, replace
existing uses of the prefixcmp() and suffixcmp() with new API
functions.

The change can be recreated by mechanically applying this:

    $ git grep -l -e prefixcmp -e suffixcmp -- \*.c |
      grep -v strbuf\\.c |
      xargs perl -pi -e '
        s|!prefixcmp\(|starts_with\(|g;
        s|prefixcmp\(|!starts_with\(|g;
        s|!suffixcmp\(|ends_with\(|g;
        s|suffixcmp\(|!ends_with\(|g;
      '

on the result of preparatory changes in this series.
Signed-off-by: NChristian Couder <chriscool@tuxfamily.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      59556548
  9. 31 8月, 2013 1 次提交
  11. 10 7月, 2013 1 次提交
    • N
      Convert "struct cache_entry *" to "const ..." wherever possible · 9c5e6c80
      由 Nguyễn Thái Ngọc Duy 提交于 
      I attempted to make index_state->cache[] a "const struct cache_entry **"
to find out how existing entries in index are modified and where. The
question I have is what do we do if we really need to keep track of on-disk
changes in the index. The result is

 - diff-lib.c: setting CE_UPTODATE

 - name-hash.c: setting CE_HASHED

 - preload-index.c, read-cache.c, unpack-trees.c and
   builtin/update-index: obvious

 - entry.c: write_entry() may refresh the checked out entry via
   fill_stat_cache_info(). This causes "non-const struct cache_entry
   *" in builtin/apply.c, builtin/checkout-index.c and
   builtin/checkout.c

 - builtin/ls-files.c: --with-tree changes stagemask and may set
   CE_UPDATE

Of these, write_entry() and its call sites are probably most
interesting because it modifies on-disk info. But this is stat info
and can be retrieved via refresh, at least for porcelain
commands. Other just uses ce_flags for local purposes.

So, keeping track of "dirty" entries is just a matter of setting a
flag in index modification functions exposed by read-cache.c. Except
unpack-trees, the rest of the code base does not do anything funny
behind read-cache's back.

The actual patch is less valueable than the summary above. But if
anyone wants to re-identify the above sites. Applying this patch, then
this:

    diff --git a/cache.h b/cache.h
    index 430d021..1692891 100644
    --- a/cache.h
    +++ b/cache.h
    @@ -267,7 +267,7 @@ static inline unsigned int canon_mode(unsigned int mode)
     #define cache_entry_size(len) (offsetof(struct cache_entry,name) + (len) + 1)

     struct index_state {
    -	struct cache_entry **cache;
    +	const struct cache_entry **cache;
     	unsigned int version;
     	unsigned int cache_nr, cache_alloc, cache_changed;
     	struct string_list *resolve_undo;

will help quickly identify them without bogus warnings.
Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      9c5e6c80
  13. 20 6月, 2013 1 次提交
  15. 07 6月, 2013 1 次提交
  17. 04 6月, 2013 1 次提交
  19. 10 5月, 2013 1 次提交
  21. 13 4月, 2013 1 次提交
  23. 12 4月, 2013 1 次提交
    • M
      cherry-pick: make sure all input objects are commits · 21246dbb
      由 Miklos Vajna 提交于 
      When a single argument was a non-commit, the error message used to be:

	fatal: BUG: expected exactly one commit from walk

For multiple arguments, when none of the arguments was a commit, the error was:

	fatal: empty commit set passed

Finally, when some of the arguments were non-commits, we ignored those
arguments.  Fix this bug and make sure all arguments are commits, and
for the first non-commit, error out with:

	fatal: <name>: Can't cherry-pick a <type>
Signed-off-by: NMiklos Vajna <vmiklos@suse.cz>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      21246dbb
  25. 23 2月, 2013 1 次提交
  27. 13 2月, 2013 7 次提交
  29. 24 12月, 2012 1 次提交
  31. 04 11月, 2012 1 次提交
    • J
      reencode_string(): introduce and use same_encoding() · 0e18bcd5
      由 Junio C Hamano 提交于 
      Callers of reencode_string() that re-encodes a string from one
encoding to another all used ad-hoc way to bypass the case where the
input and the output encodings are the same.  Some did strcmp(),
some did strcasecmp(), yet some others when converting to UTF-8 used
is_encoding_utf8().

Introduce same_encoding() helper function to make these callers use
the same logic.  Notably, is_encoding_utf8() has a work-around for
common misconfiguration to use "utf8" to name UTF-8 encoding, which
does not match "UTF-8" hence strcasecmp() would not consider the
same.  Make use of it in this helper function.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      0e18bcd5
  33. 29 10月, 2012 1 次提交
  35. 16 9月, 2012 1 次提交
  37. 15 9月, 2012 1 次提交
    • M
      cherry-pick: don't forget -s on failure · 5ed75e2a
      由 Miklos Vajna 提交于 
      In case 'git cherry-pick -s <commit>' failed, the user had to use 'git
commit -s' (i.e. state the -s option again), which is easy to forget
about.  Instead, write the signed-off-by line early, so plain 'git
commit' will have the same result.

Also update 'git commit -s', so that in case there is already a relevant
Signed-off-by line before the Conflicts: line, it won't add one more at
the end of the message. If there is no such line, then add it before the
the Conflicts: line.
Signed-off-by: NMiklos Vajna <vmiklos@suse.cz>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      5ed75e2a
  39. 31 8月, 2012 1 次提交
    • M
      cherry-pick/revert: respect order of revisions to pick · a73e22e9
      由 Martin von Zweigbergk 提交于 
      When giving multiple individual revisions to cherry-pick or revert, as
in 'git cherry-pick A B' or 'git revert B A', one would expect them to
be picked/reverted in the order given on the command line. They are
instead ordered by their commit timestamp -- in chronological order
for "cherry-pick" and in reverse chronological order for
"revert". This matches the order in which one would usually give them
on the command line, making this bug somewhat hard to notice. Still,
it has been reported at least once before [1].

It seems like the chronological sorting happened by accident because
the revision walker has traditionally always sorted commits in reverse
chronological order when rev_info.no_walk was enabled. In the case of
'git revert B A' where B is newer than A, this sorting is a no-op. For
'git cherry-pick A B', the sorting would reverse the arguments, but
because the sequencer also flips the rev_info.reverse flag when
picking (as opposed to reverting), the end result is a chronological
order. The rev_info.reverse flag was probably flipped so that the
revision walker emits B before C in 'git cherry-pick A..C'; that it
happened to effectively undo the unexpected sorting done when not
walking, was probably a coincidence that allowed this bug to happen at
all.

Fix the bug by telling the revision walker not to sort the commits
when not walking. The only case we want to reverse the order is now
when cherry-picking and walking revisions (rev_info.no_walk = 0).

 [1] http://thread.gmane.org/gmane.comp.version-control.git/164794Signed-off-by: NMartin von Zweigbergk <martinvonz@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      a73e22e9
  41. 07 8月, 2012 1 次提交
  43. 30 5月, 2012 1 次提交
    • J
      cherry-pick: regression fix for empty commits · ac2b0e8f
      由 Junio C Hamano 提交于 
      The earlier "--keep-redundant-commit" series broke "cherry-pick"
that is given a commit whose change is already in the current
history. Such a cherry-pick would result in an empty change, and
should stop with an error, telling the user that conflict resolution
may have made the result empty (which is exactly what is happening),
but we silently dropped the change on the floor without any message
nor non-zero exit code.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      ac2b0e8f
  45. 04 5月, 2012 1 次提交
  47. 26 4月, 2012 1 次提交
  49. 25 4月, 2012 1 次提交
    • N
      git-cherry-pick: Add keep-redundant-commits option · b27cfb0d
      由 Neil Horman 提交于 
      The git-cherry-pick --allow-empty command by default only preserves empty
commits that were originally empty, i.e only those commits for which
<commit>^{tree} and <commit>^^{tree} are equal.  By default commits which are
non-empty, but were made empty by the inclusion of a prior commit on the current
history are filtered out.  This option allows us to override that behavior and
include redundant commits as empty commits in the change history.

Note that this patch changes the default behavior of git cherry-pick slightly.
Prior to this patch all commits in a cherry-pick sequence were applied and git
commit was run.  The implication here was that, if a commit was redundant, and
the commit did not trigger the fast forward logic, the git commit operation, and
therefore the git cherry-pick operation would fail, displaying the cherry pick
advice (i.e. run git commit --allow-empty).  With this patch however, such
redundant commits are automatically skipped without stopping, unless
--keep-redundant-commits is specified, in which case, they are automatically
applied as empty commits.
Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      b27cfb0d
  51. 20 4月, 2012 1 次提交
  53. 12 4月, 2012 1 次提交
    • N
      git-cherry-pick: add allow-empty option · df478b74
      由 Neil Horman 提交于 
      git cherry-pick fails when picking a non-ff commit that is empty.  The advice
given with the failure is that a git-commit --allow-empty should be issued to
explicitly add the empty commit during the cherry pick.  This option allows a
user to specify before hand that they want to keep the empty commit.  This
eliminates the need to issue both a cherry pick and a commit operation.
Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      df478b74
  55. 24 3月, 2012 1 次提交
  57. 23 2月, 2012 1 次提交
    • P
      cherry-pick: No advice to commit if --no-commit · ed727b19
      由 Phil Hord 提交于 
      When cherry-pick fails it offers a helpful hint about how to
proceed.  The hint tells the user how to do the cleanup
needed by the conflicted cherry-pick and finish the job after
conflict resolution.  In case of cherry-pick --no-commit, the
hint goes too far. It tells the user to finish up with
'git commit'.  That is not what this git-cherry-pick was
trying to do in the first place.

Restrict the hint in case of --no-commit to avoid giving this
extra advice.

Also, add a test verifying the reduced hint for the --no-commit
version of cherry-pick.
Signed-off-by: NPhil Hord <hordp@cisco.com>
Acked-by: NJonathan Nieder <jrnieder@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      ed727b19
  59. 12 1月, 2012 1 次提交
    • R
      sequencer: factor code out of revert builtin · 043a4492
      由 Ramkumar Ramachandra 提交于 
      Expose the cherry-picking machinery through a public
sequencer_pick_revisions() (renamed from pick_revisions() in
builtin/revert.c), so that cherry-picking and reverting are special
cases of a general sequencer operation.  The cherry-pick builtin is
now a thin wrapper that does command-line argument parsing before
calling into sequencer_pick_revisions().  In the future, we can write
a new "foo" builtin that calls into the sequencer like:

  memset(&opts, 0, sizeof(opts));
  opts.action = REPLAY_FOO;
  opts.revisions = xmalloc(sizeof(*opts.revs));
  parse_args_populate_opts(argc, argv, &opts);
  init_revisions(opts.revs);
  sequencer_pick_revisions(&opts);

This patch does not intend to make any functional changes.  Check
with:

  $ git blame -s -C HEAD^..HEAD -- sequencer.c | grep -C3 '^[^^]'
Signed-off-by: NRamkumar Ramachandra <artagnon@gmail.com>
Reviewed-by: NJonathan Nieder <jrnieder@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      043a4492
  61. 13 12月, 2011 1 次提交
  63. 05 8月, 2011 1 次提交