Skip to content

G
git

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

从无法访问的项目Fork

通知 2
Star 1
Fork 0
G
git

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

切换分支/标签
  1. 20 9月, 2008 2 次提交
  3. 19 9月, 2008 15 次提交
  5. 16 9月, 2008 4 次提交
  7. 13 9月, 2008 3 次提交
  9. 12 9月, 2008 1 次提交
  11. 11 9月, 2008 6 次提交
  13. 10 9月, 2008 6 次提交
    • J
      Merge branch 'jc/maint-log-grep' into maint · a14f6ca2
      由 Junio C Hamano 提交于 
      * jc/maint-log-grep:
  log --author/--committer: really match only with name part
      a14f6ca2
    • J
      Merge branch 'jc/maint-hide-cr-in-diff-from-less' into maint · 26c10c7a
      由 Junio C Hamano 提交于 
      * jc/maint-hide-cr-in-diff-from-less:
  diff: Help "less" hide ^M from the output
      26c10c7a
    • J
      Merge branch 'jc/maint-checkout-fix' into maint · 94c27881
      由 Junio C Hamano 提交于 
      * jc/maint-checkout-fix:
  checkout: do not check out unmerged higher stages randomly
      94c27881
    • J
      Merge branch 'np/maint-safer-pack' into maint · 9f35e5fd
      由 Junio C Hamano 提交于 
      * np/maint-safer-pack:
  fixup_pack_header_footer(): use nicely aligned buffer sizes
  index-pack: use fixup_pack_header_footer()'s validation mode
  pack-objects: use fixup_pack_header_footer()'s validation mode
  improve reliability of fixup_pack_header_footer()
  pack-objects: improve returned information from write_one()
      9f35e5fd
    • J
      checkout: do not lose staged removal · 55218834
      由 Junio C Hamano 提交于 
      The logic to checkout a different commit implements the safety to never
lose user's local changes.  For example, switching from a commit to
another commit, when you have changed a path that is different between
them, need to merge your changes to the version from the switched-to
commit, which you may not necessarily be able to resolve easily.  By
default, "git checkout" refused to switch branches, to give you a chance
to stash your local changes (or use "-m" to merge, accepting the risks of
getting conflicts).

This safety, however, had one deliberate hole since early June 2005.  When
your local change was to remove a path (and optionally to stage that
removal), the command checked out the path from the switched-to commit
nevertheless.

This was to allow an initial checkout to happen smoothly (e.g. an initial
checkout is done by starting with an empty index and switching from the
commit at the HEAD to the same commit).  We can tighten the rule slightly
to allow this special case to pass, without losing sight of removal
explicitly done by the user, by noticing if the index is truly empty when
the operation begins.

For historical background, see:

    http://thread.gmane.org/gmane.comp.version-control.git/4641/focus=4646

This case is marked as *0* in the message, which both Linus and I said "it
feels somewhat wrong but otherwise we cannot start from an empty index".
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      55218834
    • J
      Fix permission bits on sources checked out with an overtight umask · d8bdc492
      由 Junio C Hamano 提交于 
      Two patches 99077215 (templates/Makefile: don't depend on local umask
setting, 2008-02-28) and 96cda0b1 (templates/Makefile: install is
unnecessary, just use mkdir -p, 2008-08-21) tried to prevent an overtight
umask the builder/installer might have from screwing over the installation
procedure, but we forgot there was another source of trouble.  If the
person who checked out the source tree had an overtight umask, it will
leak out to the built products, which is propagated to the installation
destination.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      d8bdc492
  15. 09 9月, 2008 3 次提交
    • D
      git-rebase--interactive: auto amend only edited commit · c14c3c82
      由 Dmitry Potapov 提交于 
      "git rebase --continue" issued after git rebase being stop by "edit"
command is trying to amend the last commit using stage changes. However,
if the last commit is not the commit that was marked as "edit" then it
can produce unexpected results.

For instance, after being stop by "edit", I have made some changes to
commit message using "git commit --amend". After that I realized that
I forgot to add some changes to some file. So, I said "git add file"
and the "git rebase --continue". Unfortunately, it caused that the new
commit message was lost.

Another problem is that after being stopped at "edit", the user adds new
commits. In this case, automatic amend behavior of git rebase triggered
by some stage changes causes that not only that the log message of the
last commit is lost but that it will contain also wrong Author and Date
information.

Therefore, this patch restrict automatic amend only to the situation
where HEAD is the commit at which git rebase stop by "edit" command.
Signed-off-by: NDmitry Potapov <dpotapov@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      c14c3c82
    • H
      Start conforming code to "git subcmd" style part 2 · 05207a28
      由 Heikki Orsila 提交于 
      User notifications are presented as 'git cmd', and code comments
are presented as '"cmd"' or 'git's cmd', rather than 'git-cmd'.
Signed-off-by: NHeikki Orsila <heikki.orsila@iki.fi>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      05207a28
    • D
      git-rebase-interactive: do not squash commits on abort · 8beb1f33
      由 Dmitry Potapov 提交于 
      If git rebase interactive is stopped by "edit" command and then the user
said "git rebase --continue" while having some stage changes, git rebase
interactive is trying to amend the last commit by doing:
  git --soft reset && git commit

However, the user can abort commit for some reason by providing an empty
log message, and that would leave the last commit undone, while the user
being completely unaware about what happened. Now if the user tries to
continue, by issuing "git rebase --continue" that squashes two previous
commits.
Signed-off-by: NDmitry Potapov <dpotapov@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      8beb1f33