path: root/read-tree.c
AgeCommit message (Collapse)Author
2006-05-23Builtin git-read-tree.Peter Eriksen
Signed-off-by: Peter Eriksen <> Signed-off-by: Junio C Hamano <>
2006-05-17read-tree -m -u: do not overwrite or remove untracked working tree files.Junio C Hamano
When a merge results in a creation of a path that did not exist in HEAD, and if you already have that path on the working tree, because the index has not been told about the working tree file, read-tree happily removes it. The issue was brought up by Santi Béjar on the list. Signed-off-by: Junio C Hamano <>
2006-05-15read-tree --reset -u fix.Linus Torvalds
The previous commit makes -u to mean "I do want to remove the local changes, just update it from the read tree" only for one-way merge. It makes sense to have it depend on the "--reset" flag instead. Signed-off-by: Linus Torvalds <> Signed-off-by: Junio C Hamano <>
2006-05-15read-tree -u one-way merge fix to check out locally modified paths.Junio C Hamano
The "-u" flag means "update the working tree files", but to other types of merges, it also implies "I want to keep my local changes" -- because they prevent local changes from getting lost by using verify_uptodate. The one-way merge is different from other merges in that its purpose is opposite of doing something else while keeping unrelated local changes. The point of one-way merge is to nuke local changes. So while it feels somewhat wrong that this actively loses local changes, it is the right thing to do. Signed-off-by: Junio C Hamano <>
2006-05-14Allow one-way tree merge to remove old filesLinus Torvalds
For some random reason (probably just because nobody noticed), the one-way merge strategy didn't mark deleted files as deleted, so if you used git-read-tree -m -u <newtree> it would update the files that got changed in the index, but it would not delete the files that got deleted. This should fix it, and I can't imagine that anybody depends on the old strange "update only existing files" behaviour. Signed-off-by: Linus Torvalds <> Signed-off-by: Junio C Hamano <>
2006-05-08Separate object name errors from usage errorsDmitry V. Levin
Separate object name errors from usage errors. Signed-off-by: Dmitry V. Levin <> Signed-off-by: Junio C Hamano <>
2006-04-04Merge branch 'pe/cleanup' into nextJunio C Hamano
* pe/cleanup: Replace xmalloc+memset(0) with xcalloc. Use blob_, commit_, tag_, and tree_type throughout.
2006-04-04Replace xmalloc+memset(0) with xcalloc.Peter Eriksen
Signed-off-by: Peter Eriksen <> Signed-off-by: Junio C Hamano <>
2006-04-04Merge branch 'lt/fix-sol-pack' into nextJunio C Hamano
* lt/fix-sol-pack: Use sigaction and SA_RESTART in read-tree.c; add option in Makefile. safe_fgets() - even more anal fgets()
2006-04-04Use sigaction and SA_RESTART in read-tree.c; add option in Makefile.v1.2.5Jason Riedy
Might as well ape the sigaction change in read-tree.c to avoid the same potential problems. The fprintf status output will be overwritten in a second, so don't bother guarding it. Do move the fputc after disabling SIGALRM to ensure we go to the next line, though. Also add a NO_SA_RESTART option in the Makefile in case someone doesn't have SA_RESTART but does restart (maybe older HP/UX?). We want the builder to chose this specifically in case the system both lacks SA_RESTART and does not restart stdio calls; a compat #define in git-compat-utils.h would silently allow broken systems. Signed-off-by: Jason Riedy <> Signed-off-by: Junio C Hamano <>
2006-03-24sha1_name: warning ambiguous refs.Junio C Hamano
This makes sure that many commands that take refs on the command line to honor core.warnambiguousrefs configuration. Earlier, the commands affected by this patch did not read the configuration file. Signed-off-by: Junio C Hamano <>
2006-03-05Add --temp and --stage=all options to checkout-index.Shawn Pearce
Sometimes it is convient for a Porcelain to be able to checkout all unmerged files in all stages so that an external merge tool can be executed by the Porcelain or the end-user. Using git-unpack-file on each stage individually incurs a rather high penalty due to the need to fork for each file version obtained. git-checkout-index -a --stage=all will now do the same thing, but faster. Signed-off-by: Shawn O. Pearce <> Signed-off-by: Junio C Hamano <>
2006-03-02Documentation: read-tree --aggressiveJunio C Hamano
Signed-off-by: Junio C Hamano <>
2006-03-02Merge branch 'maint'Junio C Hamano
* maint: read-tree --aggressive: remove deleted entry from the working tree.
2006-03-02read-tree --aggressive: remove deleted entry from the working tree.Junio C Hamano
When both heads deleted, or our side deleted while the other side did not touch, we did not have to update the working tree. However, we forgot to remove existing working tree file when we did not touch and the other side did. Signed-off-by: Junio C Hamano <>
2006-02-24Merge fixes early for next maint series.Junio C Hamano
2006-02-24Merge branches 'jc/fix-co-candy', 'jc/fix-rename-leak' and 'ar/fix-win' into ↵Junio C Hamano
maint * jc/fix-co-candy: checkout - eye candy. * jc/fix-rename-leak: diffcore-rename: plug memory leak. * ar/fix-win: fix on windows
2006-02-23Give no terminating LF to error() function.Junio C Hamano
Signed-off-by: Junio C Hamano <>
2006-02-23checkout - eye candy.Junio C Hamano
This implements "eye candy" similar to the pack-object/unpack-object to entertain users while a large tree is being checked out after a clone or a pull. Signed-off-by: Junio C Hamano <>
2006-02-09"Assume unchanged" gitJunio C Hamano
This adds "assume unchanged" logic, started by this message in the list discussion recently: <> This is a workaround for filesystems that do not have lstat() that is quick enough for the index mechanism to take advantage of. On the paths marked as "assumed to be unchanged", the user needs to explicitly use update-index to register the object name to be in the next commit. You can use two new options to update-index to set and reset the CE_VALID bit: git-update-index --assume-unchanged path... git-update-index --no-assume-unchanged path... These forms manipulate only the CE_VALID bit; it does not change the object name recorded in the index file. Nor they add a new entry to the index. When the configuration variable "core.ignorestat = true" is set, the index entries are marked with CE_VALID bit automatically after: - update-index to explicitly register the current object name to the index file. - when update-index --refresh finds the path to be up-to-date. - when tools like read-tree -u and apply --index update the working tree file and register the current object name to the index file. The flag is dropped upon read-tree that does not check out the index entry. This happens regardless of the core.ignorestat settings. Index entries marked with CE_VALID bit are assumed to be unchanged most of the time. However, there are cases that CE_VALID bit is ignored for the sake of safety and usability: - while "git-read-tree -m" or git-apply need to make sure that the paths involved in the merge do not have local modifications. This sacrifices performance for safety. - when git-checkout-index -f -q -u -a tries to see if it needs to checkout the paths. Otherwise you can never check anything out ;-). - when git-update-index --really-refresh (a new flag) tries to see if the index entry is up to date. You can start with everything marked as CE_VALID and run this once to drop CE_VALID bit for paths that are modified. Most notably, "update-index --refresh" honours CE_VALID and does not actively stat, so after you modified a file in the working tree, update-index --refresh would not notice until you tell the index about it with "git-update-index path" or "git-update-index --no-assume-unchanged path". This version is not expected to be perfect. I think diff between index and/or tree and working files may need some adjustment, and there probably needs other cases we should automatically unmark paths that are marked to be CE_VALID. But the basics seem to work, and ready to be tested by people who asked for this feature. Signed-off-by: Junio C Hamano <>
2006-02-07read-tree --aggressiveJunio C Hamano
A new flag --aggressive resolves what we traditionally resolved with external git-merge-one-file inside index while read-tree 3-way merge works. git-merge-octopus and git-merge-resolve use this flag before running git-merge-index with git-merge-one-file. Signed-off-by: Junio C Hamano <>
2005-12-27avoid asking ?alloc() for zero bytes.Junio C Hamano
Avoid asking for zero bytes when that change simplifies overall logic. Later we would change the wrapper to ask for 1 byte on platforms that return NULL for zero byte request. Signed-off-by: Junio C Hamano <>
2005-11-29Make the rest of commands work from a subdirectory.Junio C Hamano
These commands are converted to run from a subdirectory. commit-tree convert-objects merge-base merge-index mktag pack-objects pack-redundant prune-packed read-tree tar-tree unpack-file unpack-objects update-server-info write-tree Signed-off-by: Junio C Hamano <>
2005-11-08ls-files and read-tree need core.filemodeAlex Riesen
ls-files.c and read-tree.c miss the default configuration, in particular the filemode=false part. The recent +x bit flip made me notice that, because git-merge refused to merge anything saying that is not up to date. Signed-off-by: Junio C Hamano <>
2005-10-11Remove empty directories after read-tree -u.Junio C Hamano
This fixes everybody's favorite gripe that switching branche with 'git checkout' leaves empty directories. Signed-off-by: Junio C Hamano <>
2005-10-02read-tree: --trivialLinus Torvalds
This adds an option --trivial to restrict 3-way 'read-tree -m -u' to happen only if there is no file-level merging required. Signed-off-by: Linus Torvalds <> Signed-off-by: Junio C Hamano <>
2005-10-02read-tree: remove --head option.Junio C Hamano
Initially it was to allow specifying more than one remote to allow creation of an Octopus, but it is not being used. Signed-off-by: Junio C Hamano <>
2005-09-20Document -i flag to git-read-treeJunio C Hamano
Somehow I missed it when we updated read-tree to support the recursive merge strategy. Also -i should require -m as well, which the command did not check. Signed-off-by: Junio C Hamano <>
2005-09-14read-tree: fix bogus debugging statement.Junio C Hamano
We wanted to detect case #16 which should be rare, but botched the case when some paths are missing, causing a segfault. My fault. Signed-off-by: Junio C Hamano <>
2005-09-11Add a new merge strategy by Fredrik Kuivinen.Junio C Hamano
I really wanted to try this out, instead of asking for an adjustment to the 'git merge' driver and waiting. For now the new strategy is called 'fredrik' and not in the list of default strategies to be tried. The script wants Python 2.4 so this commit also adjusts Debian and RPM build procecure files. Signed-off-by: Junio C Hamano <>
2005-09-11Plug leak in Daniel's read-tree.Junio C Hamano
... and it is ready to be pushed out in the "master" branch. Signed-off-by: Junio C Hamano <>
2005-09-11[PATCH] Add debugging help for case #16 to read-tree.cJunio C Hamano
This will help us detect if real-world example merges have multiple merge-base candidates and one of them matches one head while another matches the other head. Signed-off-by: Junio C Hamano <>
2005-09-11[PATCH] Disable debugging from read-tree.Junio C Hamano
Signed-off-by: Junio C Hamano <>
2005-09-11[PATCH] Rewrite read-treeDaniel Barkalow
Adds support for multiple ancestors, removes --emu23, much simplification. Signed-off-by: Daniel Barkalow <> Signed-off-by: Junio C Hamano <>
2005-07-30[PATCH] Unify usage strings declarationPetr Baudis
All usage strings are now declared as static const char []. This is carried over from my old git-pb branch. Signed-off-by: Petr Baudis <> Signed-off-by: Junio C Hamano <>
2005-07-14Start adding interfaces to read in partial treesLinus Torvalds
The same way "git-diff-tree" can limit its output to just a set of matches, we can read in just a partial tree for comparison purposes.
2005-06-15git-read-tree: fix "--reset" handlingLinus Torvalds
2005-06-13[PATCH] read-tree: loosen too strict index requirementsJunio C Hamano
This patch teaches read-tree 3-way merge that, when only "the other tree" changed a path, and if the index file already has the same change, we are not in a situation that would clobber the index and the work tree, and lets the merge succeed; this is case #14ALT in t1000 test. It does not change the result of the merge, but prevents it from failing when it does not have to. Signed-off-by: Junio C Hamano <> Signed-off-by: Linus Torvalds <>
2005-06-13[PATCH] Finish making --emu23 equivalent to pure 2-way merge.Junio C Hamano
This adds #3ALT rule (and #2ALT rule for symmetry) to the read-tree 3-way merge logic that collapses paths that are added only in one branch and not in the other internally. This makes --emu23 to succeed in the last remaining case where the pure 2-way merge succeeded and earlier one failed. Running diff between t1001 and t1005 test scripts shows that the only difference between the two is that --emu23 can leave the states into separate stages so that the user can use usual 3-way merge resolution techniques to carry forward the local changes when pure 2-way merge would have refused to run. Signed-off-by: Junio C Hamano <> Signed-off-by: Linus Torvalds <>
2005-06-13[PATCH] read-tree: fix too strong index requirement #5ALTJunio C Hamano
This fixes too strong index requirement 3-way merge enforces in one case: the same file is added in both branches. In this case, the original code insisted that if the index file has that path, it must match our branch and be up-to-date. However in this particular case, it only has to match it, and can be dirty. We just need to make sure that we keep the work-tree copy instead of checking out the merge result. The resolution of such a path, however, cannot be left to outside script, because we will not keep the original stage0 entries for unmerged paths when read-tree finishes, and at that point, the knowledge of "if we resolve it to match the new file added in both branches, the merge succeeds and the work tree would not lose information, but we should _not_ update the work tree from the resulting index file" is lost. For this reason, the now code needs to resolve this case (#5ALT) internally. This affects some existing tests in the test suite, but all in positive ways. In t1000 (3-way test), this #5ALT case now gets one stage0 entry, instead of an identical stage2 and stage3 entry pair, for such a path, and one test that checked for merge failure (because the test assumed the "stricter-than-necessary" behaviour) does not have to fail anymore. In t1005 (emu23 test), two tests that involves a case where the work tree already had a change introduced in the upstream (aka "merged head"), the merge succeeds instead of failing. Signed-off-by: Junio C Hamano <> Signed-off-by: Linus Torvalds <>
2005-06-13[PATCH] read-tree --emu23.Junio C Hamano
This new flag causes two-way fast forward to internally use the three-way merge mechanism. This behaviour is intended to offer a better fast forward semantics when used in a dirty work tree. The new test t1005 is parallel to the existing t1001 "pure 2-way" tests, but some parts that are commented out would fail. These failures are due to three-way merge enforcing too strict index requirements for cases that could succeed. This problem will be addressed by later patches. Without even changing three-way mechanism, the --emu23 two-way fast forward already gives the user an easier-to-handle merge result when a file that "merged head" updates has local modifications. This is demonstrated as "case 16" test in t1005. Signed-off-by: Junio C Hamano <> Signed-off-by: Linus Torvalds <>
2005-06-09git-read-tree: remove deleted files in the working directoryLinus Torvalds
Only when "-u" is used of course.
2005-06-09git-read-tree: add "--reset" flagLinus Torvalds
This is the same as "-m", but it will silently ignore any unmerged entries, which makes it useful for efficiently forcing a new position regardless of the state of the current index file. IOW, to reset to a previous HEAD (in case you have had a failed merge, for example), you'd just do git-read-tree -u --reset HEAD which will also update your working tree to the right state. NOTE! The "update" will not remove files that may have been added by the merge. Yet.
2005-06-07git-read-tree: -u without -m is meaningless. Don't allow it.Linus Torvalds
Also, documetn the "-u" in the usage string.
2005-06-07git-read-tree: make one-way merge also honor the "update" flagLinus Torvalds
It didn't set CE_UPDATE before, so "-u" was a no-op.
2005-06-07[PATCH] read-tree: save more user hassles during fast-forward.Junio C Hamano
This implements the "never lose the current cache information or the work tree state, but favor a successful merge over merge failure" principle in the fast-forward two-tree merge operation. It comes with a set of tests to cover all the cases described in the case matrix found in the new documentation. Signed-off-by: Junio C Hamano <> Signed-off-by: Linus Torvalds <>
2005-06-06git-read-tree: some "final" cleanupsLinus Torvalds
Looking good, but hey, it's not like I even have a real testcase for any of this. But unlike the mess that this was yerstday, today read-cache is pretty readable and understandable. Which is always a good sign.
2005-06-06git-read-tree: simplify merge loops enormouslyLinus Torvalds
Stop trying to haev this stateful thing that keeps track of what it has seen, and use a much simpler "gather all the different stages with the same name together and just merge them in one go" approach. Makes it a lot more understandable, and allows the different merge algorithms to share the basic merge loop.
2005-06-06[PATCH] index locking like everybody elseJunio C Hamano
This patch teaches read-tree how to use the index file locking helpers the same way "checkout-cache -u" and "update-cache" do. Signed-off-by: Junio C Hamano <> Signed-off-by: Linus Torvalds <>
2005-06-06Fix off-by-one in new three-way-merge updatesLinus Torvalds
That's the final one ("Yeah, sure, we believe you"). Anyway, at least the tests pass, which is not saying a lot, since they don't end up testing all the new the things that the new merge world order tries to do. But hopefully we're now at least not any worse off than we were before the rewrite.