summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2012-02-10Merge branch 'jc/parse-date-raw'Libravatar Junio C Hamano1-0/+23
* jc/parse-date-raw: parse_date(): '@' prefix forces git-timestamp parse_date(): allow ancient git-timestamp
2012-02-10Merge branch 'jc/merge-ff-only-stronger-than-signed-merge'Libravatar Junio C Hamano1-0/+13
* jc/merge-ff-only-stronger-than-signed-merge: merge: do not create a signed tag merge under --ff-only option
2012-02-10Merge branch 'jc/branch-desc-typoavoidance'Libravatar Junio C Hamano1-4/+37
* jc/branch-desc-typoavoidance: branch --edit-description: protect against mistyped branch name
2012-02-10Merge branch 'jk/tests-write-script'Libravatar Junio C Hamano2-6/+11
* jk/tests-write-script: t0300: use write_script helper tests: add write_script helper function
2012-02-07Merge branch 'jc/maint-request-pull-for-tag'Libravatar Junio C Hamano1-5/+1
* jc/maint-request-pull-for-tag: request-pull: explicitly ask tags/$name to be pulled
2012-02-07Merge branch 'jn/svn-fe'Libravatar Junio C Hamano3-174/+556
* jn/svn-fe: (36 commits) vcs-svn: suppress a -Wtype-limits warning vcs-svn: allow import of > 4GiB files vcs-svn: rename check_overflow arguments for clarity vcs-svn/svndiff.c: squelch false "unused" warning from gcc vcs-svn: reset first_commit_done in fast_export_init vcs-svn: do not initialize report_buffer twice vcs-svn: avoid hangs from corrupt deltas vcs-svn: guard against overflow when computing preimage length vcs-svn: cap number of bytes read from sliding view test-svn-fe: split off "test-svn-fe -d" into a separate function vcs-svn: implement text-delta handling vcs-svn: let deltas use data from preimage vcs-svn: let deltas use data from postimage vcs-svn: verify that deltas consume all inline data vcs-svn: implement copyfrom_data delta instruction vcs-svn: read instructions from deltas vcs-svn: read inline data from deltas vcs-svn: read the preimage when applying deltas vcs-svn: parse svndiff0 window header vcs-svn: skeleton of an svn delta parser ...
2012-02-05branch --edit-description: protect against mistyped branch nameLibravatar Junio C Hamano1-4/+37
It is very easy to mistype the branch name when editing its description, e.g. $ git checkout -b my-topic master : work work work : now we are at a good point to switch working something else $ git checkout master : ah, let's write it down before we forget what we were doing $ git branch --edit-description my-tpoic The command does not notice that branch 'my-tpoic' does not exist. It is not lost (it becomes description of an unborn my-tpoic branch), but is not very useful. So detect such a case and error out to reduce the grief factor from this common mistake. This incidentally also errors out --edit-description when the HEAD points at an unborn branch (immediately after "init", or "checkout --orphan"), because at that point, you do not even have any commit that is part of your history and there is no point in describing how this particular branch is different from the branch it forked off of, which is the useful bit of information the branch description is designed to capture. We may want to special case the unborn case later, but that is outside the scope of this patch to prevent more common mistakes before 1.7.9 series gains too much widespread use. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-05merge: do not create a signed tag merge under --ff-only optionLibravatar Junio C Hamano1-0/+13
Starting at release v1.7.9, if you ask to merge a signed tag, "git merge" always creates a merge commit, even when the tag points at a commit that happens to be a descendant of your current commit. Unfortunately, this interacts rather badly for people who use --ff-only to make sure that their branch is free of local developments. It used to be possible to say: $ git checkout -b frotz v1.7.9~30 $ git merge --ff-only v1.7.9 and expect that the resulting tip of frotz branch matches v1.7.9^0 (aka the commit tagged as v1.7.9), but this fails with the updated Git with: fatal: Not possible to fast-forward, aborting. because a merge that merges v1.7.9 tag to v1.7.9~30 cannot be created by fast forwarding. We could teach users that now they have to do $ git merge --ff-only v1.7.9^0 but it is far more pleasant for users if we DWIMmed this ourselves. When an integrator pulls in a topic from a lieutenant via a signed tag, even when the work done by the lieutenant happens to fast-forward, the integrator wants to have a merge record, so the integrator will not be asking for --ff-only when running "git pull" in such a case. Therefore, this change should not regress the support for the use case v1.7.9 wanted to add. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-03parse_date(): '@' prefix forces git-timestampLibravatar Junio C Hamano1-0/+23
The only place that the issue this series addresses was observed where we read "cat-file commit" output and put it in GIT_AUTHOR_DATE in order to replay a commit with an ancient timestamp. With the previous patch alone, "git commit --date='20100917 +0900'" can be misinterpreted to mean an ancient timestamp, not September in year 2010. Guard this codepath by requring an extra '@' in front of the raw git timestamp on the parsing side. This of course needs to be compensated by updating get_author_ident_from_commit and the code for "git commit --amend" to prepend '@' to the string read from the existing commit in the GIT_AUTHOR_DATE environment variable. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-03t0300: use write_script helperLibravatar Jeff King1-6/+2
t0300 creates some helper shell scripts, and marks them with "!/bin/sh". Even though the scripts are fairly simple, they can fail on broken shells (specifically, Solaris /bin/sh will persist a temporary assignment to IFS in a "read" command). Rather than work around the problem for Solaris /bin/sh, using write_script will make sure we point to a known-good shell that the user has given us. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-03tests: add write_script helper functionLibravatar Junio C Hamano1-0/+9
Many of the scripts in the test suite write small helper shell scripts to disk. It's best if these shell scripts start with "#!$SHELL_PATH" rather than "#!/bin/sh", because /bin/sh on some platforms is too buggy to be used. However, it can be cumbersome to expand $SHELL_PATH, because the usual recipe for writing a script is: cat >foo.sh <<-\EOF #!/bin/sh echo my arguments are "$@" EOF To expand $SHELL_PATH, you have to either interpolate the here-doc (which would require quoting "\$@"), or split the creation into two commands (interpolating the $SHELL_PATH line, but not the rest of the script). Let's provide a helper function that makes that less syntactically painful. While we're at it, this helper can also take care of the "chmod +x" that typically comes after the creation of such a script, saving the caller a line. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-31Merge branch 'jc/pull-signed-tag'Libravatar Junio C Hamano1-1/+2
* jc/pull-signed-tag: merge: use editor by default in interactive sessions Conflicts: Documentation/merge-options.txt
2012-01-31Merge branch 'nd/clone-detached'Libravatar Junio C Hamano3-17/+53
* nd/clone-detached: clone: fix up delay cloning conditions push: do not let configured foreign-vcs permanently clobbered clone: print advice on checking out detached HEAD clone: allow --branch to take a tag clone: refuse to clone if --branch points to bogus ref clone: --branch=<branch> always means refs/heads/<branch> clone: delay cloning until after remote HEAD checking clone: factor out remote ref writing clone: factor out HEAD update code clone: factor out checkout code clone: write detached HEAD in bare repositories t5601: add missing && cascade
2012-01-31Merge branch 'da/maint-mergetool-twoway'Libravatar Junio C Hamano1-1/+27
* da/maint-mergetool-twoway: mergetool: Provide an empty file when needed
2012-01-31Merge branch 'va/git-p4-branch'Libravatar Junio C Hamano1-7/+87
* va/git-p4-branch: t9801: do not overuse test_must_fail git-p4: Change p4 command invocation git-p4: Add test case for complex branch import git-p4: Search for parent commit on branch creation
2012-01-31Merge branch 'jl/submodule-re-add'Libravatar Junio C Hamano1-0/+8
* jl/submodule-re-add: submodule add: fix breakage when re-adding a deep submodule
2012-01-31Merge branch 'tr/grep-l-with-decoration'Libravatar Junio C Hamano1-0/+22
* tr/grep-l-with-decoration: grep: fix -l/-L interaction with decoration lines
2012-01-31Merge branch 'ks/sort-wildcard-in-makefile'Libravatar Junio C Hamano1-3/+3
* ks/sort-wildcard-in-makefile: t/Makefile: Use $(sort ...) explicitly where needed
2012-01-31Merge branch 'ld/git-p4-branches-and-labels'Libravatar Junio C Hamano2-0/+161
* ld/git-p4-branches-and-labels: git-p4: label import fails with multiple labels at the same changelist git-p4: add test for p4 labels git-p4: importing labels should cope with missing owner git-p4: cope with labels with empty descriptions git-p4: handle p4 branches and labels containing shell chars
2012-01-31request-pull: explicitly ask tags/$name to be pulledLibravatar Junio C Hamano1-5/+1
When asking for a tag to be pulled, disambiguate by leaving tags/ prefix in front of the name of the tag. E.g. ... in the git repository at: git://example.com/git/git.git/ tags/v1.2.3 for you to fetch changes up to 123456... This way, older versions of "git pull" can be used to respond to such a request more easily, as "git pull $URL v1.2.3" did not DWIM to fetch v1.2.3 tag in older versions. Also this makes it clearer for humans that the pull request is made for a tag and he should anticipate a signed one. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-29Merge branch 'rs/diff-postimage-in-context'Libravatar Junio C Hamano1-7/+7
* rs/diff-postimage-in-context: xdiff: print post-image for common records instead of pre-image
2012-01-29Merge branch 'sp/smart-http-failure-to-push'Libravatar Junio C Hamano1-0/+28
* sp/smart-http-failure-to-push: remote-curl: Fix push status report when all branches fail
2012-01-29Merge branch 'jc/maint-log-first-parent-pathspec'Libravatar Junio C Hamano1-0/+1
* jc/maint-log-first-parent-pathspec: Making pathspec limited log play nicer with --first-parent
2012-01-29Merge branch 'jl/test-pause'Libravatar Junio C Hamano2-0/+26
* jl/test-pause: test-lib: add the test_pause convenience function
2012-01-29Merge branch 'tr/maint-mailinfo'Libravatar Junio C Hamano1-2/+12
* tr/maint-mailinfo: mailinfo: with -b, keep space after [foo] am: learn passing -b to mailinfo Conflicts: git-am.sh
2012-01-29Merge branch 'pw/p4-view-updates'Libravatar Junio C Hamano2-3/+396
* pw/p4-view-updates: git-p4: add tests demonstrating spec overlay ambiguities git-p4: adjust test to adhere to stricter useClientSpec git-p4: clarify comment git-p4: fix verbose comment typo git-p4: only a single ... wildcard is supported
2012-01-29Merge branch 'jn/gitweb-unspecified-action'Libravatar Junio C Hamano1-0/+8
* jn/gitweb-unspecified-action: gitweb: Fix actionless dispatch for non-existent objects
2012-01-29Merge branch 'cb/push-quiet'Libravatar Junio C Hamano2-0/+15
* cb/push-quiet: t5541: avoid TAP test miscounting fix push --quiet: add 'quiet' capability to receive-pack server_supports(): parse feature list more carefully
2012-01-29Merge branch 'nd/clone-single-branch'Libravatar Junio C Hamano1-1/+71
* nd/clone-single-branch: clone: add --single-branch to fetch only one branch
2012-01-29Merge branch 'cb/git-daemon-tests'Libravatar Junio C Hamano2-0/+217
* cb/git-daemon-tests: git-daemon tests: wait until daemon is ready git-daemon: produce output when ready git-daemon: add tests
2012-01-27Merge branch 'svn-fe' of git://repo.or.cz/git/jrn into jn/svn-feLibravatar Junio C Hamano3-174/+556
This simplifies svn-fe a great deal and fulfills a longstanding wish: support for dumps with deltas in them, and incremental imports. The cost is that commandline usage of the svn-fe tool becomes a little more complicated since it no longer keeps state itself but instead reads blobs back from fast-import in order to copy them between revisions and apply deltas to them. Also removes a couple of custom data structures and replaces them with strbufs like other parts of Git. * 'svn-fe' of git://repo.or.cz/git/jrn: (32 commits) vcs-svn: reset first_commit_done in fast_export_init vcs-svn: do not initialize report_buffer twice vcs-svn: avoid hangs from corrupt deltas vcs-svn: guard against overflow when computing preimage length vcs-svn: cap number of bytes read from sliding view test-svn-fe: split off "test-svn-fe -d" into a separate function vcs-svn: implement text-delta handling vcs-svn: let deltas use data from preimage vcs-svn: let deltas use data from postimage vcs-svn: verify that deltas consume all inline data vcs-svn: implement copyfrom_data delta instruction vcs-svn: read instructions from deltas vcs-svn: read inline data from deltas vcs-svn: read the preimage when applying deltas vcs-svn: parse svndiff0 window header vcs-svn: skeleton of an svn delta parser vcs-svn: make buffer_read_binary API more convenient vcs-svn: learn to maintain a sliding view of a file Makefile: list one vcs-svn/xdiff object or header per line vcs-svn: avoid using ls command twice ... Conflicts: Makefile contrib/svn-fe/svn-fe.txt
2012-01-26t9801: do not overuse test_must_failLibravatar Junio C Hamano1-4/+4
test_must_fail is to make sure a program we can potentially break during the course of updating git itself exits with a non-zero status in a clean and controlled way. When we expect a non-zero exit status from the commands we use from the underlying platform in tests, e.g. making sure a string "error: " does not appear in the output by running "grep 'error: '", just use "! grep" for readability. It is not like we will try to update Git and suddenly 'grep' we use from the system starts segfaulting. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-26git-p4: Add test case for complex branch importLibravatar Vitor Antunes1-7/+87
Check if branches created from old changelists are correctly imported. Also included some updates to simple branch test so that both are coherent in respect to each other. Signed-off-by: Vitor Antunes <vitor.hda@gmail.com> Acked-by: Pete Wyckoff <pw@padd.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-24submodule add: fix breakage when re-adding a deep submoduleLibravatar Jens Lehmann1-0/+8
Since recently a submodule with name <name> has its git directory in the .git/modules/<name> directory of the superproject while the work tree contains a gitfile pointing there. When the same submodule is added on a branch where it wasn't present so far (it is not found in the .gitmodules file), the name is not initialized from the path as it should. This leads to a wrong path entered in the gitfile when the .git/modules/<name> directory is found, as this happily uses the - now empty - name. It then always points only a single directory up, even if we have a path deeper in the directory hierarchy. Fix that by initializing the name of the submodule early in module_clone() if module_name() returned an empty name and add a test to catch that bug. Reported-by: Jehan Bing <jehan@orb.com> Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-23merge: use editor by default in interactive sessionsLibravatar Junio C Hamano1-1/+2
Traditionally, a cleanly resolved merge was committed by "git merge" using the auto-generated merge commit log message without invoking the editor. After 5 years of use in the field, it turns out that people perform too many unjustified merges of the upstream history into their topic branches. These merges are not just useless, but they are often not explained well, and making the end result unreadable when it gets time for merging their history back to their upstream. Earlier we added the "--edit" option to the command, so that people can edit the log message to explain and justify their merge commits. Let's take it one step further and spawn the editor by default when we are in an interactive session (i.e. the standard input and the standard output are pointing at the same tty device). There may be existing scripts that leave the standard input and the standard output of the "git merge" connected to whatever environment the scripts were started, and such invocation might trigger the above "interactive session" heuristics. GIT_MERGE_AUTOEDIT environment variable can be set to "no" at the beginning of such scripts to use the historical behaviour while the script runs. Note that this backward compatibility is meant only for scripts, and we deliberately do *not* support "merge.edit = yes/no/auto" configuration option to allow people to keep the historical behaviour. Suggested-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-23mergetool: Provide an empty file when neededLibravatar David Aguilar1-1/+27
Some merge tools cannot cope when $LOCAL, $BASE, or $REMOTE are missing. $BASE can be missing when two branches independently add the same filename. Provide an empty file to make these tools happy. When a delete/modify conflict occurs, $LOCAL and $REMOTE can also be missing. We have special case code to handle such case so this change may not affect that codepath, but try to be consistent and create an empty file for them anyway. Reported-by: Jason Wenger <jcwenger@gmail.com> Signed-off-by: David Aguilar <davvid@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-23grep: fix -l/-L interaction with decoration linesLibravatar Albert Yale1-0/+22
In threaded mode, git-grep emits file breaks (enabled with context, -W and --break) into the accumulation buffers even if they are not required. The output collection thread then uses skip_first_line to skip the first such line in the output, which would otherwise be at the very top. This is wrong when the user also specified -l/-L/-c, in which case every line is relevant. While arguably giving these options together doesn't make any sense, git-grep has always quietly accepted it. So do not skip anything in these cases. Signed-off-by: Albert Yale <surfingalbert@gmail.com> Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-22t/Makefile: Use $(sort ...) explicitly where neededLibravatar Kirill Smelkov1-3/+3
Starting from GNU Make 3.82 $(wildcard ...) no longer sorts the result (from NEWS): * WARNING: Backward-incompatibility! Wildcards were not documented as returning sorted values, but the results have been sorted up until this release.. If your makefiles require sorted results from wildcard expansions, use the $(sort ...) function to request it explicitly. http://repo.or.cz/w/make.git/commitdiff/2a59dc32aaf0681dec569f32a9d7ab88a379d34f I usually watch test progress visually, and if tests are sorted, even with make -j4 they go more or less incrementally by their t number. On the other side, without sorting, tests are executed in seemingly random order even for -j1. Let's please maintain sane tests order for perceived prettyness. Another note is that in GNU Make sort also works as uniq, so after sort being removed, we might expect e.g. $(wildcard *.sh a.*) to produce duplicates for e.g. "a.sh". From this point of view, adding sort could be seen as hardening t/Makefile from accidentally introduced dups. It turned out that prevous releases of GNU Make did not perform full sort in $(wildcard), only sorting results for each pattern, that's why explicit sort-as-uniq is relevant even for older makes. Signed-off-by: Kirill Smelkov <kirr@navytux.spb.ru> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-20git-p4: label import fails with multiple labels at the same changelistLibravatar Luke Diamand1-0/+41
git-p4 has an array of changelists with one label per changelist. But you can have multiple labels on a single changelist and so this code fails. Add a test case demonstrating the problem. Signed-off-by: Luke Diamand <luke@diamand.org> Acked-by: Pete Wyckoff <pw@padd.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-20git-p4: add test for p4 labelsLibravatar Luke Diamand1-0/+72
Add basic test of p4 label import. Checks label import and import with shell metachars; labels with different length descriptions. Signed-off-by: Luke Diamand <luke@diamand.org> Acked-by: Pete Wyckoff <pw@padd.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-20git-p4: handle p4 branches and labels containing shell charsLibravatar Luke Diamand1-0/+48
Don't use shell expansion when detecting branches, as it will fail if the branch name contains a shell metachar. Similarly for labels. Add additional test for branches with shell metachars. Signed-off-by: Luke Diamand <luke@diamand.org> Acked-by: Pete Wyckoff <pw@padd.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-20remote-curl: Fix push status report when all branches failLibravatar Shawn O. Pearce1-0/+28
The protocol between transport-helper.c and remote-curl requires remote-curl to always print a blank line after the push command has run. If the blank line is ommitted, transport-helper kills its container process (the git push the user started) with exit(128) and no message indicating a problem, assuming the helper already printed reasonable error text to the console. However if the remote rejects all branches with "ng" commands in the report-status reply, send-pack terminates with non-zero status, and in turn remote-curl exited with non-zero status before outputting the blank line after the helper status printed by send-pack. No error messages reach the user. This caused users to see the following from git push over HTTP when the remote side's update hook rejected the branch: $ git push http://... master Counting objects: 4, done. Delta compression using up to 6 threads. Compressing objects: 100% (2/2), done. Writing objects: 100% (3/3), 301 bytes, done. Total 3 (delta 0), reused 0 (delta 0) $ Always print a blank line after the send-pack process terminates, ensuring the helper status report (if it was output) will be correctly parsed by the calling transport-helper.c. This ensures the helper doesn't abort before the status report can be shown to the user. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-19Making pathspec limited log play nicer with --first-parentLibravatar Junio C Hamano1-0/+1
In a topic branch workflow, you often want to find the latest commit that merged a side branch that touched a particular area of the system, so that a new topic branch to work on that area can be forked from that commit. For example, I wanted to find an appropriate fork-point to queue Luke's changes related to git-p4 in contrib/fast-import/. "git log --first-parent" traverses the first-parent chain, and "-m --stat" shows the list of paths touched by commits including merge commits. We could ask the question this way: # What is the latest commit that touched that path? $ git log --first-parent --oneline -m --stat master | sed -e '/^ contrib\/fast-import\/git-p4 /q' | tail The above finds that 8cbfc11 (Merge branch 'pw/p4-view-updates', 2012-01-06) was such a commit. But a more natural way to spell this question is this: $ git log --first-parent --oneline -m --stat -1 master -- \ contrib/fast-import/git-p4 Unfortunately, this does not work. It finds ecb7cf9 (git-p4: rewrite view handling, 2012-01-02). This commit is a part of the merged topic branch and is _not_ on the first-parent path from the 'master': $ git show-branch 8cbfc11 ecb7cf9 ! [8cbfc11] Merge branch 'pw/p4-view-updates' ! [ecb7cf9] git-p4: rewrite view handling -- - [8cbfc11] Merge branch 'pw/p4-view-updates' + [8cbfc11^2] git-p4: view spec documentation ++ [ecb7cf9] git-p4: rewrite view handling The problem is caused by the merge simplification logic when it inspects the merge commit 8cbfc11. In this case, the history leading to the tip of 'master' did not touch git-p4 since 'pw/p4-view-updates' topic forked, and the result of the merge is simply a copy from the tip of the topic branch in the view limited by the given pathspec. The merge simplification logic discards the history on the mainline side of the merge, and pretends as if the sole parent of the merge is its second parent, i.e. the tip of the topic. While this simplification is correct in the general case, it is at least surprising if not outright wrong when the user explicitly asked to show the first-parent history. Here is an attempt to fix this issue, by not allowing us to compare the merge result with anything but the first parent when --first-parent is in effect, to avoid the history traversal veering off to the side branch. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-18Merge branch 'nd/pathspec-recursion-cleanup'Libravatar Junio C Hamano1-0/+8
* nd/pathspec-recursion-cleanup: diff-index: enable recursive pathspec matching in unpack_trees Document limited recursion pathspec matching with wildcards
2012-01-18Merge branch 'tr/maint-word-diff-incomplete-line'Libravatar Junio C Hamano1-0/+14
* tr/maint-word-diff-incomplete-line: word-diff: ignore '\ No newline at eof' marker
2012-01-17test-lib: add the test_pause convenience functionLibravatar Jens Lehmann2-0/+26
Since 781f76b15 (test-lib: redirect stdin of tests) you can't simply put a "bash &&" into a test for debugging purposes anymore. Instead you'll have to use "bash <&6 >&3 2>&4". As that invocation is not that easy to remember add the test_pause convenience function. It invokes "$SHELL_PATH" to provide a sane shell for the user. This function also checks if the -v flag is given and will error out if that is not the case instead of letting the test hang until ^D is pressed. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-16clone: allow --branch to take a tagLibravatar Nguyễn Thái Ngọc Duy2-0/+24
Because a tag ref cannot be put to HEAD, HEAD will become detached. This is consistent with "git checkout <tag>". This is mostly useful in shallow clone, where it allows you to clone a tag in addtion to branches. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-16clone: refuse to clone if --branch points to bogus refLibravatar Nguyễn Thái Ngọc Duy2-13/+2
It's possible that users make a typo in the branch name. Stop and let users recheck. Falling back to remote's HEAD is not documented any way. Except when using remote helper, the pack has not been transferred at this stage yet so we don't waste much bandwidth. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-16clone: write detached HEAD in bare repositoriesLibravatar Nguyễn Thái Ngọc Duy1-1/+24
If we don't write, HEAD is still at refs/heads/master as initialized by init-db, which may or may not match remote's HEAD. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-16t5601: add missing && cascadeLibravatar Nguyễn Thái Ngọc Duy1-3/+3
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>