- 29 9月, 2005 4 次提交
-
-
由 Tom Prince 提交于
Signed-off-by: NTom Prince <tom.prince@ualberta.net> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
The merge strategy would check this itself and typically does it by using git-read-tree -m -u 3-way merge. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
The refspecs specified in the .git/remotes/<remote> on the "Pull: " lines are for fetching multiple heads in one go, but most of the time making an Octopus out of them is not what is wanted. Make git-fetch leave the marker in .git/FETCH_HEAD file so that later stages can tell which heads are for merging and which are not. Tom Prince made me realize how stupid the original behaviour was. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
It still talked about "the proposed alternative semantics" but we have used those alternative semantics for quite some time. Update them to avoid confusion. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 28 9月, 2005 6 次提交
-
-
由 Junio C Hamano 提交于
-
由 Junio C Hamano 提交于
Now update-index supports '-z --stdin', we do not have to rely on platform xargs to support -0 option. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
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: NJunio C Hamano <junkio@cox.net>
-
由 H. Peter Anvin 提交于
-
由 H. Peter Anvin 提交于
-
- 27 9月, 2005 16 次提交
-
-
-
由 H. Peter Anvin 提交于
-
由 Nick Hengeveld 提交于
Return CURL error message when object transfer fails [jc: added similar curl_errorstr errors to places where we use curl_easy_perform() to run fetch that _must_ succeed.] Signed-off-by: NNick Hengeveld <nickh@reactrix.com> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Daniel Barkalow 提交于
With the --recover option, we verify that we have absolutely everything reachable from the target, not assuming that things reachable from refs will be complete. Signed-off-by: NDaniel Barkalow <barkalow@iabervon.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Sven Verdoolaege 提交于
Signed-off-by: NSven Verdoolaege <skimo@kotnet.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Peter Eriksen 提交于
This is from Peter Eriksen, but further fixed. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
**BLUSH** Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 H. Peter Anvin 提交于
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
-
由 Junio C Hamano 提交于
Only the "Fetching ... using http" was leaking to stdout. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
My stupidity deserved to be yelled at by Linus ... there is no reason to require the working tree to be clean when merging -- the only requirements are index to match HEAD commit and the paths involved in merge are up to date in the working tree. Revert and cherry-pick are just specialized forms of merge, and the requirements should be the same. Remove the 'general purpose routine to make sure tree is clean' from git-sh-setup, to prevent me from getting tempted again. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
Being able to try multiple strategies and automatically picking one that seems to give less conflicting result may or may not much sense in practice. At least that should not force normal use case to additionally require the working tree to be fully clean. As Linus shouted, local changes do not matter unless they interfere with the merge. This commit changes git-merge not to require a clean working tree. Only when we will iterate through more than one merge strategies, local changes are stashed away before trying the first merge, and restored before second and later merges are attempted. The index file must be in sync with HEAD in any case -- otherwise the merge result would contain changes since HEAD that was done locally and registered in the index. This check is already enforced by three-way read-tree existing merge strategies use, but is done here as a safeguard as well. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
And with -n flag you can tell it not to. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Paul Mackerras 提交于
-
- 26 9月, 2005 5 次提交
-
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Paul Mackerras 提交于
Checking in the change from wish to wish8.4 was a mistake; I had changed it for a test but forgot to change it back before checking in a patch.
-
由 Linus Torvalds 提交于
This is a careful version of the script stuff that currently just blindly writes HEAD with a new value. You can use git-update-ref HEAD <newhead> or git-update-ref HEAD <newhead> <oldhead> where the latter version verifies that the old value of HEAD matches oldhead. It basically allows a "ref" file to be a symbolic pointer to another ref file by starting with the four-byte header sequence of "ref:". More importantly, it allows the update of a ref file to follow these symbolic pointers, whether they are symlinks or these "regular file symbolic refs". NOTE! It follows _real_ symlinks only if they start with "refs/": otherwise it will just try to read them and update them as a regular file (ie it will allow the filesystem to follow them, but will overwrite such a symlink to somewhere else with a regular filename). In general, using git-update-ref HEAD "$head" should be a _lot_ safer than doing echo "$head" > "$GIT_DIR/HEAD" both from a symlink following standpoint _and_ an error checking standpoint. The "refs/" rule for symlinks means that symlinks that point to "outside" the tree are safe: they'll be followed for reading but not for writing (so we'll never write through a ref symlink to some other tree, if you have copied a whole archive by creating a symlink tree). Signed-off-by: NLinus Torvalds <torvalds@osdl.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Fredrik Kuivinen 提交于
The merge strategies can give more descriptive error messages for conflict cases if they are given the actual branch names instead of the SHA1s. Signed-off-by: NFredrik Kuivinen <freku045@student.liu.se> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Fredrik Kuivinen 提交于
If the working tree is dirty read-tree will fail, and we don't want an ugly stack trace in that case. Also make sure we don't print stack traces when we use 'die'. Signed-off-by: NFredrik Kuivinen <freku045@student.liu.se> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 25 9月, 2005 9 次提交
-
-
由 Junio C Hamano 提交于
The new output format shows only the status letter and paths. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
When many paths are modified, rename detection takes a lot of time. The new option -l<num> can be used to disable rename detection when more than <num> paths are possibly created as renames. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
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: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
-
由 Junio C Hamano 提交于
Now we conditionally compile things in compat/, so we should remove object files there. Python execution can leave *.pyc and *.pyo, which need to be cleaned as well. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
Also cmd-renames.sh can now be used to remove the backward compatible symlinks -- this is not used by default in any way. As discussed on the list with Pasky, git-ssh-push and git-ssh-pull will keep calling each other for a while longer. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
It was ignoring the generation number of the commit when naming 2nd and later parents, showing "(linus^n)^2" for any <n> incorrectly as "linus^2". Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Daniel Barkalow 提交于
Fix missing symbol explanations, a few incorrect cases, and add two-way merge rules. Signed-off-by: NDaniel Barkalow <barkalow@iabervon.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
People typically say 'grep -e $pattern' because $pattern has a leading dash which would be mistaken as a grep flag. Make sure we pass -e in front of $pattern when we invoke grep. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-