Skip to content

G
git

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

从无法访问的项目Fork

通知 2
Star 1
Fork 0
G
git

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

切换分支/标签
  1. 22 1月, 2006 5 次提交
  3. 21 1月, 2006 1 次提交
  5. 20 1月, 2006 7 次提交
  7. 16 1月, 2006 11 次提交
  9. 15 1月, 2006 8 次提交
  11. 14 1月, 2006 8 次提交
    • J
      git-push: avoid falling back on pushing "matching" refs. · 9e9b2675
      由 Junio C Hamano 提交于 
      The underlying "git send-pack remote.host:path" pushes all the
matching refs that both local and remote have, and "git push"
blindly inherits this property.  Which probably was a mistake.

A typical cloned repository (e.g. a subsystem repository cloned
from Linus repository) has at least two branches, "master" to
keep the subsystem and "origin" that records tip of Linus
"master" when the repository was cloned.  If this is the public
repository for the subsystem, then subsystem developers would
clone it, and then cloned ones have "master" and "origin".  When
developers use this public subsystem repository as a shared
repository, pushing into it via "git push subsys:/path/name"
would try to push the matching refs, "master" and "origin", from
the developers' repositories.  The "origin" in the public shared
repository does not have much relevance, yet pushing into
"origin" would cause "not a fast forward" checks to be
triggered.  Arguably "git push subsys:/path/name master" would
work it around, but having them to say it explicitly to avoid
pushing into "origin" as well is bad.

This commit requires you to give at least one refspec to
git-push.  You could "give" by either:

 (1) Listing the refspec(s) explicitly on the command line.
     E.g. "git push subsys:/path/name master".

 (2) Using --all or --tags on the command line.
     E.g. "git push --tags subsys:/path/name".

 (3) Using a $GIT_DIR/remotes shorthand with 'Push: refspec'
     line in it.

Unlike pull that can happen pretty much promiscuously, people
will push into the same set of a limited number of remote
repositories repeatedly over the life of the project, so it is
reasonable to assume they would want to keep a $GIT_DIR/remotes/
entry for those repositories even only to save typing the URL,
so keeping the default 'Push: refspec' line in such is a
sensible thing to do.

It was suggested to further fall back on pushing the current
branch, but this commit does not implement it.  If developers
adopt topic branch workflow, pushing to public while on a topic
branch by mistake would expose the topic branch to the public
repository.  Not falling back to the current branch prevents
that mistake from happening.
Signed-off-by: NJunio C Hamano <junkio@cox.net>
      9e9b2675
    • J
      checkout: merge local modifications while switching branches. · 1be0659e
      由 Junio C Hamano 提交于 
       * Instead of going interactive, introduce a command line switch
   '-m' to allow merging changes when normal two-way merge by
   read-tree prevents branch switching.

 * Leave the unmerged stages intact if automerge fails, but
   reset index entries of cleanly merged paths to that of the
   new branch, so that "git diff" (not "git diff HEAD") would
   show the local modifications.

 * Swap the order of trees in read-tree three-way merge used in
   the fallback, so that `git diff` to show the conflicts become
   more natural.

 * Describe the new option and give more examples in the documentation.
Signed-off-by: NJunio C Hamano <junkio@cox.net>
      1be0659e
    • J
      checkout: automerge local changes while switching branches. · 19205acf
      由 Junio C Hamano 提交于 
      When switching branches, if the working tree has a local
modification at paths that are different between current and new
branches, we refused the operation saying "cannot merge."  This
attempts to do an automerge for such paths.

This is still experimental.
Signed-off-by: NJunio C Hamano <junkio@cox.net>
      19205acf
    • J
      Merge fixes up to GIT 1.1.2 · 429608fc
      由 Junio C Hamano 提交于
      429608fc
    • J
      Fix the installation location. · b42934d6
      由 Junio C Hamano 提交于 
      The earlier change to separate $(gitexecdir) from $(bindir) had
the installation location of the git wrapper and the rest of the
commands the wrong way (right now, both of them point at the
same location so there is no real harm).

Also gitk needs to be installed in $(bindir).
Signed-off-by: NJunio C Hamano <junkio@cox.net>
      b42934d6
    • M
      Exec git programs without using PATH. · 77cb17e9
      由 Michal Ostrowski 提交于 
      The git suite may not be in PATH (and thus programs such as
git-send-pack could not exec git-rev-list).  Thus there is a need for
logic that will locate these programs.  Modifying PATH is not
desirable as it result in behavior differing from the user's
intentions, as we may end up prepending "/usr/bin" to PATH.

- git C programs will use exec*_git_cmd() APIs to exec sub-commands.
- exec*_git_cmd() will execute a git program by searching for it in
  the following directories:
	1. --exec-path (as used by "git")
	2. The GIT_EXEC_PATH environment variable.
	3. $(gitexecdir) as set in Makefile (default value $(bindir)).
- git wrapper will modify PATH as before to enable shell scripts to
  invoke "git-foo" commands.

Ideally, shell scripts should use the git wrapper to become independent
of PATH, and then modifying PATH will not be necessary.

[jc: with minor updates after a brief review.]
Signed-off-by: NMichal Ostrowski <mostrows@watson.ibm.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>
      77cb17e9
    • J
      GIT 1.1.2 · 59617ebb
      由 Junio C Hamano 提交于
      59617ebb
    • J
      GIT 1.0.10 · e99c2fbd
      由 Junio C Hamano 提交于
      e99c2fbd