summaryrefslogtreecommitdiff
path: root/git-filter-branch.sh
AgeCommit message (Collapse)Author
2007-07-06filter-branch: fail gracefully when a filter failsJohannes Schindelin
A common mistake is to provide a filter which fails unwantedly. For example, this will stop in the middle: git filter-branch --env-filter ' test $GIT_COMMITTER_EMAIL = xyz && export GIT_COMMITTER_EMAIL = abc' rewritten When $GIT_COMMITTER_EMAIL is not "xyz", the test fails, and consequently the whole filter has a non-zero exit status. However, as demonstrated in this example, filter-branch would just stop, and the user would be none the wiser. Also, a failing msg-filter would not have been caught, as was the case with one of the tests. This patch fixes both issues, by paying attention to the exit status of msg-filter, and by saying what failed before exiting. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-04filter-branch: added missing warn functionSteffen Prohaska
--tag-name-filter may have failed before because warn is used for reporting but was not available. Signed-off-by: Steffen Prohaska <prohaska@zib.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-04filter-branch: make output nicerJohannes Schindelin
Instead of filling the screen with progress lines, use \r so that the progress can be seen, but warning messages are more visible. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-04filter-branch: Avoid an error message in the map function.Johannes Sixt
When the map function didn't find the rewritten commit of the passed in original id, it printed the original id, but it still fell through to the 'cat', which failed with an error message. Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-04Document git-filter-branchJohannes Schindelin
This moves the documentation in git-filter-branch.sh to its own man page, with a few touch ups (incorporating comments by Frank Lichtenheld). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-03Rewrite "git-frotz" to "git frotz"Junio C Hamano
This uses the remove-dashes target to replace "git-frotz" to "git frotz". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-03Start deprecating "git-command" in favor of "git command"Linus Torvalds
I realize that a lot of people use the "git-xyzzy" format, and we have various historical reasons for it, but I also think that most people have long since started thinking of the git command as a single command with various subcommands, and we've long had the documentation talk about it that way. Slowly migrating away from the git-xyzzy format would allow us to eventually no longer install hundreds of binaries (even if most of them are symlinks or hardlinks) in users $PATH, and the _original_ reasons for it (implementation issues and bash completion) are really long long gone. Using "git xyzzy" also has some fundamental advantages, like the ability to specify things like paging ("git -p xyzzy") and making the whole notion of aliases act like other git commands (which they already do, but they do *not* have a "git-xyzzy" form!) Anyway, while actually removing the "git-xyzzy" things is not practical right now, we can certainly start slowly to deprecate it internally inside git itself - in the shell scripts we use, and the test vectors. This patch adds a "remove-dashes" makefile target, which does that. It isn't particularly efficient or smart, but it *does* successfully rewrite a lot of our shell scripts to use the "git xyzzy" form for all built-in commands. (For non-builtins, the "git xyzzy" format implies an extra execve(), so this script leaves those alone). So apply this patch, and then run make remove-dashes make test git commit -a to generate a much larger patch that actually starts this transformation. (The only half-way subtle thing about this is that it also fixes up git-filter-branch.sh for the new world order by adding quoting around the use of "git-commit-tree" as an argument. It doesn't need it in that format, but when changed into "git commit-tree" it is no longer a single word, and the quoting maintains the old behaviour). NOTE! This does not yet mean that you can actually stop installing the "git-xyzzy" binaries for the builtins. There are some remaining places that want to use the old form, this just removes the most obvious ones that can easily be done automatically. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-01Merge branch 'ei/worktree+filter'Junio C Hamano
* ei/worktree+filter: filter-branch: always export GIT_DIR if it is set setup_git_directory: fix segfault if repository is found in cwd test GIT_WORK_TREE extend rev-parse test for --is-inside-work-tree Use new semantics of is_bare/inside_git_dir/inside_work_tree introduce GIT_WORK_TREE to specify the work tree test git rev-parse rev-parse: introduce --is-bare-repository rev-parse: document --is-inside-git-dir
2007-06-23filter-branch: add example to move everything into a subdirectoryJohannes Schindelin
This is based on Jeff King's example in 20070621130137.GB4487@coredump.intra.peff.net Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-09filter-branch: subdirectory filter needs --full-historyJohannes Sixt
When two branches are merged that modify a subdirectory (possibly in different intermediate steps) such that both end up identical, then rev-list chooses only one branch. But when we filter history, we want to keep both branches. Therefore, we must use --full-history. Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-09filter-branch: Simplify parent computation.Johannes Sixt
We can use git rev-list --parents when we list the commits to rewrite. It is not necessary to run git rev-list --parents for each commit in the loop. Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-09Teach filter-branch about subdirectory filteringJohannes Schindelin
With git-filter-branch --subdirectory-filter <subdirectory> you can get at the history, as seen by a certain subdirectory. The history of the rewritten branch will only contain commits that touched that subdirectory, and the subdirectory will be rewritten to be the new project root. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-06filter-branch: always export GIT_DIR if it is setMatthias Lederhofer
Currently filter-branch exports GIT_DIR only if it is an relative path but git-sh-setup might also set GIT_DIR to an absolute path that is not exported yet. Additionally export GIT_WORK_TREE with GIT_DIR to ensure that cwd is used as working tree even for bare repositories. Signed-off-by: Matthias Lederhofer <matled@gmx.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-06filter-branch: also don't fail in map() if a commit cannot be mappedJohannes Sixt
The map() function can be used by filters to map a commit id to its rewritten id. Such a mapping may not exist, in which case the identity mapping is used (the commit is returned unchanged). In the rewrite loop, this mapping is also needed, but was done explicitly in the same way. Use the map() function instead. Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-06filter-branch: Use rev-list arguments to specify revision ranges.Johannes Sixt
A subset of commits in a branch used to be specified by options (-k, -r) as well as the branch tip itself (-s). It is more natural (for git users) to specify revision ranges like 'master..next' instead. This makes it so. If no range is specified it defaults to 'HEAD'. As a consequence, the new name of the filtered branch must be the first non-option argument. All remaining arguments are passed to 'git rev-list' unmodified. The tip of the branch that gets filtered is implied: It is the first commit that git rev-list would print for the specified range. Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-06filter-branch: fix behaviour of '-k'Johannes Schindelin
The option '-k' says that the given commit and _all_ of its ancestors are kept as-is. However, if a to-be-rewritten commit branched from an ancestor of an ancestor of a commit given with '-k', filter-branch would fail. Example: A - B \ C If filter-branch was called with '-k B -s C', it would actually keep B (and A as its parent), but would rewrite C, and its parent. Noticed by Johannes Sixt. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-06filter-branch: use $(($i+1)) instead of $((i+1))Johannes Schindelin
The expression $((i+1)) is not portable at all: even some bash versions do not grok it. So do not use it. Noticed by Jonas Fonseca. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-06chmod +x git-filter-branch.shMatthias Lederhofer
Signed-off-by: Matthias Lederhofer <matled@gmx.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-06filter-branch: prevent filters from reading from stdinMatthias Lederhofer
stdin is the list of commits when the env, tree and index filter are executed. The filters are not supposed to read anything from stdin so the best is to give them /dev/null for reading. Signed-off-by: Matthias Lederhofer <matled@gmx.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-03Add git-filter-branchJohannes Schindelin
This script is derived from Pasky's cg-admin-rewritehist. In fact, it _is_ the same script, minimally adapted to work without cogito. It _should_ be able to perform the same tasks, even if only relying on core-git programs. All the work is Pasky's, just the adaption is mine. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Hopefully-signed-off-by: Petr "cogito master" Baudis <pasky@suse.cz> Signed-off-by: Junio C Hamano <junkio@cox.net>