kernel/git - git - PowerEL Git System

10805 Commits

6 Branches

36 Tags

131 MiB

Tree: 55feb1200f

Commit Graph

Author SHA1 Message Date

Author	SHA1	Message	Date
Shawn O. Pearce	183d79724f	Keep untracked files not involved in a merge. My earlier fix (`8371234e`) to delete renamed tracked files from the working directory also caused merge-recursive to delete untracked files that were in the working directory. The problem here is merge-recursive is deleting the working directory file without regard for which branch it was associated with. What we really want to do during a merge is to only delete files that were renamed by the branch we are merging into the current branch, and that are still tracked by the current branch. These files definitely don't belong in the working directory anymore. Anything else is either a merge conflict (already handled in other parts of the code) or a file that is untracked by the current branch and thus is not even participating in the merge. Its this latter class that must be left alone. For this fix to work we are now assuming that the first non-base argument passed to git-merge-recursive always corresponds to the working directory. This is already true for all in-tree callers of merge-recursive. This assumption is also supported by the long time usage message of "<base> ... -- <head> <remote>", where "<head>" is implied to be HEAD, which is generally assumed to be the current tree-ish. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>	18 years ago
Shawn Pearce	8371234eca	Remove uncontested renamed files during merge. Prior to `65ac6e9c3f` we deleted a file from the working directory during a merge if the file existed before the merge started but was renamed by the branch being merged in. This broke in 65ac6e as git-merge-recursive did not actually update the working directory on an uncontested rename. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>	18 years ago

Shawn O. Pearce

183d79724f

Keep untracked files not involved in a merge.

My earlier fix (8371234e) to delete renamed tracked files from the
working directory also caused merge-recursive to delete untracked
files that were in the working directory.

The problem here is merge-recursive is deleting the working directory
file without regard for which branch it was associated with.  What we
really want to do during a merge is to only delete files that were
renamed by the branch we are merging into the current branch,
and that are still tracked by the current branch.  These files
definitely don't belong in the working directory anymore.

Anything else is either a merge conflict (already handled in other
parts of the code) or a file that is untracked by the current branch
and thus is not even participating in the merge.  Its this latter
class that must be left alone.

For this fix to work we are now assuming that the first non-base
argument passed to git-merge-recursive always corresponds to the
working directory.  This is already true for all in-tree callers
of merge-recursive.  This assumption is also supported by the
long time usage message of "<base> ... -- <head> <remote>", where
"<head>" is implied to be HEAD, which is generally assumed to be
the current tree-ish.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

18 years ago

Shawn Pearce

8371234eca

Remove uncontested renamed files during merge.

Prior to 65ac6e9c3f we deleted a file
from the working directory during a merge if the file existed before
the merge started but was renamed by the branch being merged in.
This broke in 65ac6e as git-merge-recursive did not actually update
the working directory on an uncontested rename.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

18 years ago

2 Commits (55feb1200f0e1a7f6cb8670de0dee97f09d8cb9f)