summaryrefslogtreecommitdiff
path: root/contrib/subtree/git-subtree.sh
AgeCommit message (Collapse)Author
2021-06-15subtree: fix assumption about the directory separatorJohannes Schindelin
On Windows, both forward and backslash are valid separators. In 22d550749361 (subtree: don't fuss with PATH, 2021-04-27), however, we added code that assumes that it can only be the forward slash. Let's fix that. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-06-15subtree: fix the GIT_EXEC_PATH sanity check to work on WindowsJohannes Schindelin
In 22d550749361 (subtree: don't fuss with PATH, 2021-04-27), `git subtree` was broken thoroughly on Windows. The reason is that it assumes Unix semantics, where `PATH` is colon-separated, and it assumes that `$GIT_EXEC_PATH:` is a verbatim prefix of `$PATH`. Neither are true, the latter in particular because `GIT_EXEC_PATH` is a Windows-style path, while `PATH` is a Unix-style path list. Let's make extra certain that `$GIT_EXEC_PATH` and the first component of `$PATH` refer to different entities before erroring out. We do that by using the `test <path1> -ef <path2>` command that verifies that the inode of `<path1>` and of `<path2>` is the same. Sadly, this construct is non-portable, according to https://pubs.opengroup.org/onlinepubs/009695399/utilities/test.html. However, it does not matter in practice because we still first look whether `$GIT_EXEC_PREFIX` is string-identical to the first component of `$PATH`. This will give us the expected result everywhere but in Git for Windows, and Git for Windows' own Bash _does_ handle the `-ef` operator. Just in case that we _do_ need to show the error message _and_ are running in a shell that lacks support for `-ef`, we simply suppress the error output for that part. This fixes https://github.com/git-for-windows/git/issues/3260 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-04-28subtree: be stricter about validating flagsLuke Shumaker
Don't silently ignore a flag that's invalid for a given subcommand. The user expected it to do something; we should tell the user that they are mistaken, instead of surprising the user. It could be argued that this change might break existing users. I'd argue that those existing users are already broken, and they just don't know it. Let them know that they're broken. Signed-off-by: Luke Shumaker <lukeshu@datawire.io> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-04-28subtree: push: allow specifying a local rev other than HEADLuke Shumaker
'git subtree split' lets you specify a rev other than HEAD. 'git push' lets you specify a mapping between a local thing and a remot ref. So smash those together, and have 'git subtree push' let you specify which local thing to run split on and push the result of that split to the remote ref. Signed-off-by: Luke Shumaker <lukeshu@datawire.io> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-04-28subtree: allow 'split' flags to be passed to 'push'Luke Shumaker
'push' does a 'split' internally, but it doesn't pass flags through to the 'split'. This is silly, if you need to pass flags to 'split', then it means that you can't use 'push'! So, have 'push' accept 'split' flags, and pass them through to 'split'. Add tests for this by copying split's tests with minimal modification. Signed-off-by: Luke Shumaker <lukeshu@datawire.io> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-04-28subtree: allow --squash to be used with --rejoinLuke Shumaker
Besides being a genuinely useful thing to do, this also just makes sense and harmonizes which flags may be used when. `git subtree split --rejoin` amounts to "automatically go ahead and do a `git subtree merge` after doing the main `git subtree split`", so it's weird and arbitrary that you can't pass `--squash` to `git subtree split --rejoin` like you can `git subtree merge`. It's weird that `git subtree split --rejoin` inherits `git subtree merge`'s `--message` but not `--squash`. Reconcile the situation by just having `split --rejoin` actually just call `merge` internally (or call `add` instead, as appropriate), so it can get access to the full `merge` behavior, including `--squash`. Signed-off-by: Luke Shumaker <lukeshu@datawire.io> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-04-28subtree: give the docs a once-overLuke Shumaker
Just went through the docs looking for anything inaccurate or that can be improved. In the '-h' text, in the man page synopsis, and in the man page description: Normalize the ordering of the list of sub-commands: 'add', 'merge', 'split', 'pull', 'push'. This allows us to kinda separate the lower-level add/merge/split from the higher-level pull/push. '-h' text: - correction: Indicate that split's arg is optional. - clarity: Emphasize that 'pull' takes the 'add'/'merge' flags. man page: - correction: State that all subcommands take options (it seemed to indicate that only 'split' takes any options other than '-P'). - correction: 'split' only guarantees that the results are identical if the flags are identical. - correction: The flag is named '--ignore-joins', not '--ignore-join'. - completeness: Clarify that 'push' always operates on HEAD, and that 'split' operates on HEAD if no local commit is given. - clarity: In the description, when listing commands, repeat what their arguments are. This way the reader doesn't need to flip back and forth between the command description and the synopsis and the full description to understand what's being said. - clarity: In the <variables> used to give command arguments, give slightly longer, descriptive names. Like <local-commit> instead of just <commit>. - clarity: Emphasize that 'pull' takes the 'add'/'merge' flags. - style: In the synopsis, list options before the subcommand. This makes things line up and be much more readable when shown non-monospace (such as in `make html`), and also more closely matches other man pages (like `git-submodule.txt`). - style: Use the correct syntax for indicating the options ([<options>] instead of [OPTIONS]). - style: In the synopsis, separate 'pull' and 'push' from the other lower-level commands. I think this helps readability. - style: Code-quote things in prose that seem like they should be code-quoted, like '.gitmodules', flags, or full commands. - style: Minor wording improvements, like more consistent mood (many of the command descriptions start in the imperative mood and switch to the indicative mode by the end). That sort of thing. - style: Capitalize "ID". - style: Remove the "This option is only valid for XXX command" remarks from each option, and instead rely on the section headings. - style: Since that line is getting edited anyway, switch "behaviour" to American "behavior". - style: Trim trailing whitespace. `todo`: - style: Trim trailing whitespace. Signed-off-by: Luke Shumaker <lukeshu@datawire.io> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-04-28subtree: have $indent actually affect indentationLuke Shumaker
Currently, the $indent variable is just used to track how deeply we're nested, and the debug log is indented by things like debug " foo" That is: The indentation-level is hard-coded. It used to be that the code couldn't recurse, so the indentation level could be known statically, so it made sense to just hard-code it in the output. However, since 315a84f9aa ("subtree: use commits before rejoins for splits", 2018-09-28), it can now recurse, and the debug log is misleading. So fix that. Indent according to $indent. Signed-off-by: Luke Shumaker <lukeshu@datawire.io> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-04-28subtree: don't let debug and progress output clashLuke Shumaker
Currently, debug output (triggered by passing '-d') and progress output stomp on each other. The debug output is just streamed as lines to stderr, and the progress output is sent to stderr as '%s\r'. When writing to a file, it is awkward to read and difficult to distinguish between the debug output and a progress line. When writing to a terminal the debug lines hide progress lines. So, when '-d' has been passed, spit out progress as 'progress: %s\n', instead of as '%s\r', so that it can be detected, and so that the debug lines don't overwrite the progress when written to a terminal. Signed-off-by: Luke Shumaker <lukeshu@datawire.io> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-04-28subtree: add comments and sanity checksLuke Shumaker
For each function in subtree, add a usage comment saying what the arguments are, and add an `assert` checking the number of arguments. In figuring out each thing's arguments in order to write those comments and assertions, it turns out that find_existing_splits is written as if it takes multiple 'revs', but it is in fact only ever passed a single 'rev': unrevs="$(find_existing_splits "$dir" "$rev")" || exit $? So go ahead and codify that by documenting and asserting that it takes exactly two arguments, one dir and one rev. Signed-off-by: Luke Shumaker <lukeshu@datawire.io> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-04-28subtree: remove duplicate checkLuke Shumaker
`cmd_add` starts with a check that the directory doesn't yet exist. However, the `main` function performs the exact same check before calling `cmd_add`. So remove the check from `cmd_add`. Signed-off-by: Luke Shumaker <lukeshu@datawire.io> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-04-28subtree: parse revs in individual cmd_ functionsLuke Shumaker
The main argument parser goes ahead and tries to parse revs to make things simpler for the sub-command implementations. But, it includes enough special cases for different sub-commands. And it's difficult having having to think about "is this info coming from an argument, or a global variable?". So the main argument parser's effort to make things "simpler" ends up just making it more confusing and complicated. Begone with the 'revs' global variable; parse 'rev=$(...)' as needed in individual 'cmd_*' functions. Begone with the 'default' global variable. Its would-be value is knowable just from which function we're in. Begone with the 'ensure_single_rev' function. Its functionality can be achieved by passing '--verify' to 'git rev-parse'. Signed-off-by: Luke Shumaker <lukeshu@datawire.io> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-04-28subtree: use "^{commit}" instead of "^0"Luke Shumaker
They are synonyms. Both are used in the file. ^{commit} is clearer, so "standardize" on that. Signed-off-by: Luke Shumaker <lukeshu@datawire.io> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-04-28subtree: don't fuss with PATHLuke Shumaker
Scripts needing to fuss with with adding $(git --exec-prefix) PATH before loading git-sh-setup is a thing of the past. As far as I can tell, it's been a thing of the past since since Git v1.2.0 (2006-02-12), or more specifically, since 77cb17e940 (Exec git programs without using PATH, 2006-01-10). However, it stuck around in contrib scripts and in third-party scripts for long enough that it wasn't unusual to see. Originally `git subtree` didn't fuss with PATH, but when people (including the original subtree author) had problems, because it was a common thing to see, it seemed that having subtree fuss with PATH was a reasonable solution. Here is an abridged history of fussing with PATH in subtree: 2987e6add3 (Add explicit path of git installation by 'git --exec-path', Gianluca Pacchiella, 2009-08-20) As pointed out by documentation, the correct use of 'git-sh-setup' is using $(git --exec-path) to avoid problems with not standard installations. -. git-sh-setup +. $(git --exec-path)/git-sh-setup 33aaa697a2 (Improve patch to use git --exec-path: add to PATH instead, Avery Pennarun, 2009-08-26) If you (like me) are using a modified git straight out of its source directory (ie. without installing), then --exec-path isn't actually correct. Add it to the PATH instead, so if it is correct, it'll work, but if it's not, we fall back to the previous behaviour. -. $(git --exec-path)/git-sh-setup +PATH=$(git --exec-path):$PATH +. git-sh-setup 9c632ea29c ((Hopefully) fix PATH setting for msysgit, Avery Pennarun, 2010-06-24) Reported by Evan Shaw. The problem is that $(git --exec-path) includes a 'git' binary which is incompatible with the one in /usr/bin; if you run it, it gives you an error about libiconv2.dll. +OPATH=$PATH PATH=$(git --exec-path):$PATH . git-sh-setup +PATH=$OPATH # apparently needed for some versions of msysgit df2302d774 (Another fix for PATH and msysgit, Avery Pennarun, 2010-06-24) Evan Shaw tells me the previous fix didn't work. Let's use this one instead, which he says does work. This fix is kind of wrong because it will run the "correct" git-sh-setup *after* the one in /usr/bin, if there is one, which could be weird if you have multiple versions of git installed. But it works on my Linux and his msysgit, so it's obviously better than what we had before. -OPATH=$PATH -PATH=$(git --exec-path):$PATH +PATH=$PATH:$(git --exec-path) . git-sh-setup -PATH=$OPATH # apparently needed for some versions of msysgit First of all, I disagree with Gianluca's reading of the documentation: - I haven't gone back to read what the documentation said in 2009, but in my reading of the 2021 documentation is that it includes "$(git --exec-path)/" in the synopsis for illustrative purposes, not to say it's the proper way. - After being executed by `git`, the git exec path should be the very first entry in PATH, so it shouldn't matter. - None of the scripts that are part of git do it that way. But secondly, the root reason for fussing with PATH seems to be that Avery didn't know that he needs to set GIT_EXEC_PATH if he's going to use git from the source directory without installing. And finally, Evan's issue is clearly just a bug in msysgit. I assume that msysgit has since fixed the issue, and also msysgit has been deprecated for 6 years now, so let's drop the workaround for it. So, remove the line fussing with PATH. However, since subtree *is* in 'contrib/' and it might get installed in funny ways by users after-the-fact, add a sanity check to the top of the script, checking that it is installed correctly. Signed-off-by: Luke Shumaker <lukeshu@datawire.io> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-04-28subtree: use "$*" instead of "$@" as appropriateLuke Shumaker
"$*" is for when you want to concatenate the args together, whitespace-separated; and "$@" is for when you want them to be separate strings. There are several places in subtree that erroneously use $@ when concatenating args together into an error message. For instance, if the args are argv[1]="dead" and argv[2]="beef", then the line die "You must provide exactly one revision. Got: '$@'" surely intends to call 'die' with the argument argv[1]="You must provide exactly one revision. Got: 'dead beef'" however, because the line used $@ instead of $*, it will actually call 'die' with the arguments argv[1]="You must provide exactly one revision. Got: 'dead" argv[2]="beef'" This isn't a big deal, because 'die' concatenates its arguments together anyway (using "$*"). But that doesn't change the fact that it was a mistake to use $@ instead of $*, even though in the end $@ still ended up doing the right thing. Signed-off-by: Luke Shumaker <lukeshu@datawire.io> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-04-28subtree: use more explicit variable names for cmdline argsLuke Shumaker
Make it painfully obvious when reading the code which variables are direct parsings of command line arguments. Signed-off-by: Luke Shumaker <lukeshu@datawire.io> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-04-28subtree: use git-sh-setup's `say`Luke Shumaker
subtree currently defines its own `say` implementation, rather than using git-sh-setups's implementation. Change that, don't re-invent the wheel. Signed-off-by: Luke Shumaker <lukeshu@datawire.io> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-04-28subtree: use `git merge-base --is-ancestor`Luke Shumaker
Instead of writing a slow `rev_is_descendant_of_branch $a $b` function in shell, just use the fast `git merge-base --is-ancestor $b $a`. Signed-off-by: Luke Shumaker <lukeshu@datawire.io> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-04-28subtree: drop support for git < 1.7Luke Shumaker
Suport for Git versions older than 1.7.0 (older than February 2010) was nice to have when git-subtree lived out-of-tree. But now that it lives in git.git, it's not necessary to keep around. While it's technically in contrib, with the standard 'git' packages for common systems (including Arch Linux and macOS) including git-subtree, it seems vanishingly likely to me that people are separately installing git-subtree from git.git alongside an older 'git' install (although it also seems vanishingly likely that people are still using >11 year old git installs). Not that there's much reason to remove it either, it's not much code, and none of my changes depend on a newer git (to my knowledge, anyway; I'm not actually testing against older git). I just figure it's an easy piece of fat to trim, in the journey to making the whole thing easier to hack on. "Ignore space change" is probably helpful when viewing this diff. Signed-off-by: Luke Shumaker <lukeshu@datawire.io> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-04-28subtree: more consistent error propagationLuke Shumaker
Ensure that every $(subshell) that calls a function (as opposed to an external executable) is followed by `|| exit $?`. Similarly, ensure that every `cmd | while read; do ... done` loop is followed by `|| exit $?`. Both of those constructs mean that it can miss `die` calls, and keep running when it shouldn't. Signed-off-by: Luke Shumaker <lukeshu@datawire.io> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-04-28subtree: don't have loose code outside of a functionLuke Shumaker
Shove all of the loose code inside of a main() function. This comes down to personal preference more than anything else. A preference that I've developed over years of maintaining large Bash scripts, but still a mere personal preference. In this specific case, it's also moving the `set -- -h`, the `git rev-parse --parseopt`, and the `. git-sh-setup` to be closer to all the rest of the argument parsing, which is a readability win on its own, IMO. "Ignore space change" is probably helpful when viewing this diff. Signed-off-by: Luke Shumaker <lukeshu@datawire.io> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-03-12contrib/subtree: ensure only one rev is providedDenton Liu
While looking at the inline help for git-subtree.sh, I noticed that git subtree split --prefix=<prefix> <commit...> was given as an option. However, it only really makes sense to provide one revision because of the way the commits are forwarded to rev-parse so change "<commit...>" to "<commit>" to reflect this. In addition, check the arguments to ensure that only one rev is provided for all subcommands that accept a commit. Signed-off-by: Denton Liu <liu.denton@gmail.com> Acked-by: Avery Pennarun <apenwarr@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-12subtree: performance improvement for finding unexpected parent commitsRoger Strain
After testing a previous patch at larger scale, a performance issue was detected when using git show to locate parent revisions, with a single run of the git show command taking 2 seconds or longer in a complex repo. When the command is required tens or hundreds of times in a run of the script, the additional wait time is unaccepatable. Replacing the command with git rev-parse resulted in significantly increased performance, with the command in question returning instantly. Signed-off-by: Roger Strain <rstrain@swri.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-06subtree: improve decision on merges kept in splitStrain, Roger L
When multiple identical parents are detected for a commit being considered for copying, explicitly check whether one is the common merge base between the commits. If so, the other commit can be used as the identical parent; if not, a merge must be performed to maintain history. In some situations two parents of a merge commit may appear to both have identical subtree content with each other and the current commit. However, those parents can potentially come from different commit graphs. Previous behavior would simply select one of the identical parents to serve as the replacement for this commit, based on the order in which they were processed. New behavior compares the merge base between the commits to determine if a new merge commit is necessary to maintain history despite the identical content. Signed-off-by: Strain, Roger L <roger.strain@swri.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-06subtree: use commits before rejoins for splitsStrain, Roger L
Adds recursive evaluation of parent commits which were not part of the initial commit list when performing a split. Split expects all relevant commits to be reachable from the target commit but not reachable from any previous rejoins. However, a branch could be based on a commit prior to a rejoin, then later merged back into the current code. In this case, a parent to the commit will not be present in the initial list of commits, trigging an "incorrect order" warning. Previous behavior was to consider that commit to have no parent, creating an original commit containing all subtree content. This commit is not present in an existing subtree commit graph, changing commit hashes and making pushing to a subtree repo impossible. New behavior will recursively check these unexpected parent commits to track them back to either an earlier rejoin, or a true original commit. The generated synthetic commits will properly match previously-generated commits, allowing successful pushing to a prior subtree repo. Signed-off-by: Strain, Roger L <roger.strain@swri.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-06subtree: make --ignore-joins pay attention to addsStrain, Roger L
Changes the behavior of --ignore-joins to always consider a subtree add commit, and ignore only splits and squashes. The --ignore-joins option is documented to ignore prior --rejoin commits. However, it additionally ignored subtree add commits generated when a subtree was initially added to a repo. Due to the logic which determines whether a commit is a mainline commit or a subtree commit (namely, the presence or absence of content in the subtree prefix) this causes commits before the initial add to appear to be part of the subtree. An --ignore-joins split would therefore consider those commits part of the subtree history and include them at the beginning of the synthetic history, causing the resulting hashes to be incorrect for all later commits. Signed-off-by: Strain, Roger L <roger.strain@swri.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-06subtree: refactor split of a commit into standalone methodStrain, Roger L
In a particularly complex repo, subtree split was not creating compatible splits for pushing back to a separate repo. Addressing one of the issues requires recursive handling of parent commits that were not initially considered by the algorithm. This commit makes no functional changes, but relocates the code to be called recursively into a new method to simply comparisons of later commits. Signed-off-by: Strain, Roger L <roger.strain@swri.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-02-23subtree: fix add and pull for GPG-signed commitsStephen R Guglielmo
If log.showsignature is true (or --show-signature is passed) while performing a `subtree add` or `subtree pull`, the command fails. toptree_for_commit() calls `log` and passes the output to `commit-tree`. If this output shows the GPG signature data, `commit-tree` throws a fatal error. This commit fixes the issue by adding --no-show-signature to `log` calls in a few places, as well as using the more appropriate `rev-parse` instead where possible. Signed-off-by: Stephen R Guglielmo <srg@guglielmo.us> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-28subtree: adjust function definitions to match CodingGuidelinesDavid Aguilar
We prefer a space between the function name and the parentheses, and no space inside the parentheses. The opening "{" should also be on the same line. Suggested-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: David Aguilar <davvid@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-28subtree: adjust style to match CodingGuidelinesDavid Aguilar
Prefer "test" over "[ ... ]", use double-quotes around variables, break long lines, and properly indent "case" statements. Helped-by: Johannes Sixt <j6t@kdbg.org> Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: David Aguilar <davvid@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-26subtree: fix "git subtree split --rejoin"David Aguilar
"git merge" in v2.9 prevents merging unrelated histories. "git subtree split --rejoin" creates unrelated histories when creating a split repo from a raw sub-directory that did not originate from an invocation of "git subtree add". Restore the original behavior by passing --allow-unrelated-histories when merging subtrees. This ensures that the synthetic history created by "git subtree split" can be merged. Add a test to ensure that this feature works as advertised. Reported-by: Brett Cundal <brett.cundal@iugome.com> Helped-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: David Aguilar <davvid@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-03Merge branch 'dw/subtree-split-do-not-drop-merge'Junio C Hamano
The "split" subcommand of "git subtree" (in contrib/) incorrectly skipped merges when it shouldn't, which was corrected. * dw/subtree-split-do-not-drop-merge: contrib/subtree: fix "subtree split" skipped-merge bug
2016-01-22Merge branch 'rm/subtree-unwrap-tags'Junio C Hamano
"git subtree" (in contrib/) records the tag object name in the commit log message when a subtree is added using a tag, without peeling it down to the underlying commit. The tag needs to be peeled when "git subtree split" wants to work on the commit, but the command forgot to do so. * rm/subtree-unwrap-tags: contrib/subtree: unwrap tag refs
2016-01-20contrib/subtree: fix "subtree split" skipped-merge bugDave Ware
'git subtree split' can incorrectly skip a merge even when both parents act on the subtree, provided the merge results in a tree identical to one of the parents. Fix by copying the merge if at least one parent is non-identical, and the non-identical parent is not an ancestor of the identical parent. Also, add a test case which checks that a descendant remains a descendent on the subtree in this case. Signed-off-by: Dave Ware <davidw@realtimegenomics.com> Reviewed-by: David A. Greene <greened@obbligato.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-11-24contrib/subtree: unwrap tag refsRob Mayoff
If a subtree was added using a tag ref, the tag ref is stored in the subtree commit message instead of the underlying commit's ref. To split or push subsequent changes to the subtree, the subtree command needs to unwrap the tag ref. This patch makes it do so. The problem was described in a message to the mailing list from Junio C Hamano dated 29 Apr 2014, with the subject "Re: git subtree issue in more recent versions". The archived message can be found at <http://comments.gmane.org/gmane.comp.version-control.git/247503>. Signed-off-by: Rob Mayoff <mayoff@dqd.com> Signed-off-by: Jeff King <peff@peff.net>
2015-11-13contrib/subtree: Handle '--prefix' argument with a slash appendedTechlive Zheng
'git subtree merge' will fail if the argument of '--prefix' has a slash appended. Signed-off-by: Techlive Zheng <techlivezheng@gmail.com> Signed-off-by: David A. Greene <greened@obbligato.org> Signed-off-by: Jeff King <peff@peff.net>
2015-09-08contrib/subtree: respect spaces in a repository pathAlexey Shumkin
Remote repository may have spaces in its path, so take it into account. Also, as far as there are no tests for the `push` command, add them. Signed-off-by: Alexey Shumkin <Alex.Crezoff@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-08t7900-subtree: test the "space in a subdirectory name" caseAlexey Shumkin
In common case there can be spaces in a subdirectory name. Change tests accorgingly to this statement. Also, as far as a call to the `rejoin_msg` function (in `cmd_split`) does not take into account such a case this patch fixes commit message when `--rejoin` option is set . Besides, as `fixnl` and `multiline` functions did not take into account the "new" tested "space in a subdirectory name" case they become unused and redundant, so they are removed. Signed-off-by: Alexey Shumkin <Alex.Crezoff@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-03Merge branch 'da/subtree-date-confusion'Junio C Hamano
"git subtree" (in contrib/) depended on "git log" output to be stable, which was a no-no. Apply a workaround to force a particular date format. * da/subtree-date-confusion: contrib/subtree: ignore log.date configuration
2015-07-23contrib/subtree: ignore log.date configurationDavid Aguilar
git-subtree's log format string uses "%ad" and "%cd", which respect the user's configured log.date value. This is problematic for git-subtree because it needs to use real dates so that copied commits come through unchanged. Add a test and tweak the format strings to use %aD and %cD so that the default date format is used instead. Reported-by: Bryan Jacobs <b@q3q.us> Signed-off-by: David Aguilar <davvid@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-22Merge branch 'dl/subtree-avoid-tricky-echo'Junio C Hamano
"git subtree" script (in contrib/) used "echo -n" to produce progress messages in a non-portable way. * dl/subtree-avoid-tricky-echo: contrib/subtree: portability fix for string printing
2015-05-08contrib/subtree: portability fix for string printingDanny Lin
'echo -n' is not portable, but this script used it as a way to give a string followed by a carriage return for progress messages. Introduce a new helper shell function "progress" and use printf as a more portable way to do this. As a side effect, this makes it unnecessary to have a raw CR in our source, which can be munged in some shells. For example, MsysGit trims CR before executing a shell script file in order to make it work right on Windows even if it uses CRLF as linefeeds. While at it, replace "echo" using printf in debug() and say() to eliminate the temptation of reintroducing the same bug. Signed-off-by: Danny Lin <danny0838@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-07contrib/subtree: there's no push --squashDanny Lin
The documentation says that --squash is for 'add', 'merge', 'pull' and 'push', while --squash actually doesn't change the behavior of 'push'. Correct the documentation. Signed-off-by: Danny Lin <danny0838@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-13contrib/subtree: allow adding an annotated tagJames Denholm
cmd_add_commit() is passed FETCH_HEAD by cmd_add_repository, which is then rev-parsed into an object name. However, if the user is fetching a tag rather than a branch HEAD, such as by executing: $ git subtree add -P oldGit https://github.com/git/git.git tags/v1.8.0 the object name refers to a tag and is never peeled, and the git commit-tree call (line 561) slaps us in the face because it doesn't peel tags to commits. Because peeling a committish doesn't do anything if it's already a commit, fix by peeling the object name before assigning it to $rev using peel_committish() from git:git-sh-setup.sh, a pre-existing dependency of git-subtree. Reported-by: Kevin Cagle <kcagle@micron.com> Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: James Denholm <nod.helm@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-17subtree: initialize "prefix" variableJeff King
We parse the "--prefix" command-line option into the "$prefix" shell variable. However, if we do not see such an option, the variable is left with whatever value it had in the environment. We should initialize it to a known value, like we do for other variables. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-13subtree: fix argument validation in add/pull/pushAnthony Baire
When working with a remote repository add/pull/push do not accept a <refspec> as parameter but just a <ref>. They should accept any well-formatted ref name. This patch: - relaxes the check the <ref> argument in "git subtree add <repo>" (previous code would not accept a ref name that does not exist locally too, new code only ensures that the ref is well formatted) - add the same check in "git subtree pull/push" + check the number of parameters - update the doc to use <ref> instead of <refspec> Signed-off-by: Anthony Baire <Anthony.Baire@irisa.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-01Merge branch 'lf/echo-n-is-not-portable'Junio C Hamano
* lf/echo-n-is-not-portable: Avoid using `echo -n` anywhere
2013-07-29Avoid using `echo -n` anywhereLukas Fleischer
`echo -n` is non-portable. The POSIX specification says: Conforming applications that wish to do prompting without <newline> characters or that could possibly be expecting to echo a -n, should use the printf utility derived from the Ninth Edition system. Since all of the affected shell scripts use a POSIX shell shebang, replace `echo -n` invocations with printf. Signed-off-by: Lukas Fleischer <git@cryptocrack.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-05Merge branch 'dm/unbash-subtree'Junio C Hamano
It turns out that git-subtree script does not have to be run with bash. * dm/unbash-subtree: contrib/git-subtree: Use /bin/sh interpreter instead of /bin/bash
2013-05-21contrib/git-subtree: Use /bin/sh interpreter instead of /bin/bashDmitry Marakasov
Use /bin/sh interpreter instead of /bin/bash for contrib/git-subtree: it's required for systems which don't use bash by default (for example, FreeBSD), while there seem to be no bashisms in the script (confirmed by looking through the source and tesing subtree functionality with FreeBSD's /bin/sh) to require specifically bash and not the generic posix shell. Signed-off-by: Dmitry Marakasov <amdmi3@amdmi3.ru> Signed-off-by: Junio C Hamano <gitster@pobox.com>