summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* contrib/subtree: remove "push" command from the "todo" filefp/subtree-todo-updateFabio Porcedda2015-11-061-2/+0
| | | | | | | | Because the "push" command is already available, remove it from the "todo" file. Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'as/subtree-with-spaces'Junio C Hamano2015-10-052-74/+124
|\ | | | | | | | | | | | | | | | | | | Update "git subtree" (in contrib/) so that it can take whitespaces in the pathnames, not only in the in-tree pathname but the name of the directory that the repository is in. * as/subtree-with-spaces: contrib/subtree: respect spaces in a repository path t7900-subtree: test the "space in a subdirectory name" case
| * contrib/subtree: respect spaces in a repository pathas/subtree-with-spacesAlexey Shumkin2015-09-082-1/+48
| | | | | | | | | | | | | | | | | | 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>
| * t7900-subtree: test the "space in a subdirectory name" caseAlexey Shumkin2015-09-082-73/+76
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Merge branch 'jk/connect-clear-env'Junio C Hamano2015-10-052-11/+49
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ssh transport, just like any other transport over the network, did not clear GIT_* environment variables, but it is possible to use SendEnv and AcceptEnv to leak them to the remote invocation of Git, which is not a good idea at all. Explicitly clear them just like we do for the local transport. * jk/connect-clear-env: git_connect: clarify conn->use_shell flag git_connect: clear GIT_* environment for ssh
| * | git_connect: clarify conn->use_shell flagjk/connect-clear-envJeff King2015-09-081-9/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When executing user-specified programs, we generally always want to use a shell, for flexibility and consistency. One big exception is executing $GIT_SSH, which for historical reasons must not use a shell. Once upon a time the logic in git_connect looked like: if (protocol == PROTO_SSH) { ... setup ssh ... } else { ... setup local connection ... conn->use_shell = 1; } But over time the PROTO_SSH block has grown, and the "local" block has shrunk so that it contains only conn->use_shell; it's easy to miss at the end of the large block. Moreover, PROTO_SSH now also sometimes sets use_shell, when the new GIT_SSH_COMMAND is used. Let's just set conn->use_shell when we're setting up the "conn" struct, and unset it (with a comment) in the historical GIT_SSH case. This will make the flow easier to follow. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | git_connect: clear GIT_* environment for sshJeff King2015-09-042-2/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When we "switch" to another local repository to run the server side of a fetch or push, we must clear the variables in local_repo_env so that our local $GIT_DIR, etc, do not pollute the upload-pack or receive-pack that is executing in the "remote" repository. We have never done so for ssh connections. For the most part, nobody has noticed because ssh will not pass unknown environment variables by default. However, it is not out of the question for a user to configure ssh to pass along GIT_* variables using SendEnv/AcceptEnv. We can demonstrate the problem by using "git -c" on a local command and seeing its impact on a remote repository. This config ends up in $GIT_CONFIG_PARAMETERS. In the local case, the config has no impact, but in the ssh transport, it does (our test script has a fake ssh that passes through all environment variables; this isn't normal, but does simulate one possible setup). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | Merge branch 'jk/date-local'Junio C Hamano2015-10-0510-114/+166
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "git log --date=local" used to only show the normal (default) format in the local timezone. The command learned to take 'local' as an instruction to use the local timezone with other formats, e.g. "git show --date=rfc-local". * jk/date-local: t6300: add tests for "-local" date formats t6300: make UTC and local dates different date: make "local" orthogonal to date format date: check for "local" before anything else t6300: add test for "raw" date format t6300: introduce test_date() helper fast-import: switch crash-report date to iso8601 Documentation/rev-list: don't list date formats Documentation/git-for-each-ref: don't list date formats Documentation/config: don't list date formats Documentation/blame-options: don't list date formats
| * | | t6300: add tests for "-local" date formatsjk/date-localJohn Keeping2015-09-031-0/+36
| | | | | | | | | | | | | | | | | | | | Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | t6300: make UTC and local dates differentJohn Keeping2015-09-031-35/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | By setting the UTC time to 23:18:43 the date in +0200 is the following day, 2006-07-04. This will ensure that the test for "short-local" to be added in the following patch tests for different output from the "short" format. Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | date: make "local" orthogonal to date formatJeff King2015-09-034-33/+61
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Most of our "--date" modes are about the format of the date: which items we show and in what order. But "--date=local" is a bit of an oddball. It means "show the date in the normal format, but using the local timezone". The timezone we use is orthogonal to the actual format, and there is no reason we could not have "localized iso8601", etc. This patch adds a "local" boolean field to "struct date_mode", and drops the DATE_LOCAL element from the date_mode_type enum (it's now just DATE_NORMAL plus local=1). The new feature is accessible to users by adding "-local" to any date mode (e.g., "iso-local"), and we retain "local" as an alias for "default-local" for backwards compatibility. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | date: check for "local" before anything elseJohn Keeping2015-09-031-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In a following commit we will make "local" orthogonal to the format. Although this will not apply to "relative", which does not use the timezone, it applies to all other formats so move the timezone conversion to the start of the function. Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | t6300: add test for "raw" date formatJohn Keeping2015-09-031-0/+4
| | | | | | | | | | | | | | | | | | | | Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | t6300: introduce test_date() helperJohn Keeping2015-09-031-52/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This moves the setup of the "expected" file inside the test case. The helper function has the advantage that we can use SQ in the file content without needing to escape the quotes. Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | fast-import: switch crash-report date to iso8601Jeff King2015-09-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When fast-import emits a crash report, it does so in the user's local timezone. But because we omit the timezone completely for DATE_LOCAL, a reader of the report does not immediately know which time zone was used. Let's switch this to ISO8601 instead, which includes the time zone. This does mean we will show the time in UTC, but that's not a big deal. A crash report like this will either be looked at immediately (in which case nobody even looks at the timestamp), or it will be passed along to a developer to debug, in which case the original timezone is less likely to be of interest. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | Documentation/rev-list: don't list date formatsJohn Keeping2015-09-032-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We are about to add several new date formats which will make this list too long to display in a single line. Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | Documentation/git-for-each-ref: don't list date formatsJohn Keeping2015-09-031-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We are about to add a new set of supported date formats and do not want to have to maintain the same list in several different bits of documentation. Refer to git-rev-list(1) which contains the full list of supported formats. Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | Documentation/config: don't list date formatsJohn Keeping2015-09-031-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This list is already incomplete (missing "raw") and we're about to add new formats. Since this option sets a default for git-log's --date option, just refer to git-log(1). Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | Documentation/blame-options: don't list date formatsJohn Keeping2015-09-031-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This list is already incomplete (missing "raw") and we're about to add new formats. Remove it and refer to the canonical documentation in git-log(1). Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | Merge branch 'dt/refs-bisection'Junio C Hamano2015-10-056-33/+313
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Move the refs used during a "git bisect" session to per-worktree hierarchy refs/worktree/* so that independent bisect sessions can be done in different worktrees. * dt/refs-bisection: refs: make refs/bisect/* per-worktree path: optimize common dir checking refs: clean up common_list
| * | | | refs: make refs/bisect/* per-worktreedt/refs-bisectionDavid Turner2015-09-016-3/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We need the place we stick refs for bisects in progress to not be shared between worktrees. So we make the refs/bisect/ hierarchy per-worktree. The is_per_worktree_ref function and associated docs learn that refs/bisect/ is per-worktree, as does the git_path code in path.c The ref-packing functions learn that per-worktree refs should not be packed (since packed-refs is common rather than per-worktree). Since refs/bisect is per-worktree, logs/refs/bisect should be too. Signed-off-by: David Turner <dturner@twopensource.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | | path: optimize common dir checkingDavid Turner2015-09-012-14/+214
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of a linear search over common_list to check whether a path is common, use a trie. The trie search operates on path prefixes, and handles excludes. Signed-off-by: David Turner <dturner@twopensource.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | | refs: clean up common_listDavid Turner2015-09-011-21/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of common_list having formatting like ! and /, use a struct to hold common_list data in a structured form. We don't use 'exclude' yet; instead, we keep the old codepath that handles info/sparse-checkout and logs/HEAD. Later, we will use exclude. [jc: with "make common_list[] static" clean-up from Ramsay squashed in] Signed-off-by: David Turner <dturner@twopensource.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | | Merge branch 'nk/stash-show-config'Junio C Hamano2015-10-053-1/+31
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Users who are too busy to type three extra keystrokes to ask for "git stash show -p" can now set stash.showPatch configuration varible to true to always see the actual patch, not just the list of paths affected with feel for the extent of damage via diffstat. * nk/stash-show-config: stash: allow "stash show" diff output configurable
| * | | | | stash: allow "stash show" diff output configurablenk/stash-show-configNamhyung Kim2015-08-313-1/+31
| | |_|/ / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some users might want to see diff (patch) output always rather than diffstat when [s]he runs 'git stash show'. Although this can be done with adding -p option, users are too lazy to type extra three keys. Add two variables that control to show diffstat and patch output respectively. The stash.showStat is for diffstat and default is true. The stat.showPatch is for the patch output and default is false. Signed-off-by: Namhyung Kim <namhyung@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | | Merge branch 'jk/async-pkt-line'Junio C Hamano2015-10-053-2/+23
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The debugging infrastructure for pkt-line based communication has been improved to mark the side-band communication specifically. * jk/async-pkt-line: pkt-line: show packets in async processes as "sideband" run-command: provide in_async query function
| * | | | | pkt-line: show packets in async processes as "sideband"jk/async-pkt-lineJeff King2015-09-011-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If you run "GIT_TRACE_PACKET=1 git push", you may get confusing output like (line prefixes omitted for clarity): packet: push< \1000eunpack ok0019ok refs/heads/master0000 packet: push< unpack ok packet: push< ok refs/heads/master packet: push< 0000 packet: push< 0000 Why do we see the data twice, once apparently wrapped inside another pkt-line, and once unwrapped? Why do we get two flush packets? The answer is that we start an async process to demux the sideband data. The first entry comes from the sideband process reading the data, and the second from push itself. Likewise, the first flush is inside the demuxed packet, and the second is an actual sideband flush. We can make this a bit more clear by marking the sideband demuxer explicitly as "sideband" rather than "push". The most elegant way to do this would be to simply call packet_trace_identity() inside the sideband demuxer. But we can't do that reliably, because it relies on a global variable, which might be shared if pthreads are in use. What we really need is thread-local storage for packet_trace_identity. But the async code does not provide an interface for that, and it would be messy to add it here (we'd have to care about pthreads, initializing our pthread_key_t ahead of time, etc). So instead, let us just assume that any async process is handling sideband data. That's always true now, and is likely to remain so in the future. The output looks like: packet: sideband< \1000eunpack ok0019ok refs/heads/master0000 packet: push< unpack ok packet: push< ok refs/heads/master packet: push< 0000 packet: sideband< 0000 Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | | | run-command: provide in_async query functionJeff King2015-09-012-1/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It's not easy for arbitrary code to find out whether it is running in an async process or not. A top-level function which is fed to start_async() can know (you just pass down an argument saying "you are async"). But that function may call other global functions, and we would not want to have to pass the information all the way through the call stack. Nor can we simply set a global variable, as those may be shared between async threads and the main thread (if the platform supports pthreads). We need pthread tricks _or_ a global variable, depending on how start_async is implemented. The callers don't have enough information to do this right, so let's provide a simple query function that does. Fortunately we can reuse the existing infrastructure to make the pthread case simple (and even simplify die_async() by using our new function). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | | | Merge branch 'jh/quiltimport-explicit-series-file'Junio C Hamano2015-10-052-4/+23
|\ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "quiltimport" allows to specify the series file by honoring the $QUILT_SERIES environment and also --series command line option. * jh/quiltimport-explicit-series-file: git-quiltimport: add commandline option --series <file>
| * | | | | | git-quiltimport: add commandline option --series <file>jh/quiltimport-explicit-series-fileJuerg Haefliger2015-09-012-4/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The quilt series file doesn't have to be located in the same directory with the patches and can be named differently than 'series' as well. This patch adds a commandline option to allow for a non-standard series filename and location. Signed-off-by: Juerg Haefliger <juerg.haefliger@hp.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | | | | Merge branch 'ld/p4-import-labels'Junio C Hamano2015-10-052-8/+62
|\ \ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Correct "git p4 --detect-labels" so that it does not fail to create a tag that points at a commit that is also being imported. * ld/p4-import-labels: git-p4: fix P4 label import for unprocessed commits git-p4: do not terminate creating tag for unknown commit git-p4: failing test for ignoring invalid p4 labels
| * | | | | | | git-p4: fix P4 label import for unprocessed commitsld/p4-import-labelsLuke Diamand2015-08-282-9/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With --detect-labels enabled, git-p4 will try to create tags using git fast-import by writing a "tag" clause to the fast-import stream. If the commit that the tag references has not yet actually been processed by fast-import, then the tag can't be created and git-p4 fails to import the P4 label. Teach git-p4 to use fast-import "marks" when creating tags which reference commits created during the current run of the program. Commits created before the current run are still referenced in the old way using a normal git commit. Signed-off-by: Luke Diamand <luke@diamand.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | | | | | git-p4: do not terminate creating tag for unknown commitLuke Diamand2015-08-281-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If p4 reports a tag for a commit that git-p4 does not know about (e.g. because it references a P4 changelist that was imported prior to the point at which the repo was cloned into git), make sure that the error is correctly caught and handled. rather than just crashing. Signed-off-by: Luke Diamand <luke@diamand.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | | | | | git-p4: failing test for ignoring invalid p4 labelsLuke Diamand2015-08-281-0/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When importing a label which references a commit that git-p4 does not know about, git-p4 should skip it and go on to process other labels that can be imported. Instead it crashes when attempting to find the missing commit in the git history. This test demonstrates the problem. Signed-off-by: Luke Diamand <luke@diamand.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | | | | | Merge branch 'ad/bisect-terms'Junio C Hamano2015-10-054-16/+350
|\ \ \ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The use of 'good/bad' in "git bisect" made it confusing to use when hunting for a state change that is not a regression (e.g. bugfix). The command learned 'old/new' and then allows the end user to say e.g. "bisect start --term-old=fast --term=new=slow" to find a performance regression. Michael's idea to make 'good/bad' more intelligent does have certain attractiveness ($gname/272867), and makes some of the work on this topic a moot point. * ad/bisect-terms: bisect: allow setting any user-specified in 'git bisect start' bisect: add 'git bisect terms' to view the current terms bisect: add the terms old/new bisect: sanity check on terms
| * | | | | | | | bisect: allow setting any user-specified in 'git bisect start'Matthieu Moy2015-08-033-3/+132
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This allows a natural user-interface when looking for any change in the code, not just regression. For example: git bisect start --term-old fast --term-new slow git bisect fast git bisect slow ... There were several proposed user-interfaces for this feature. This patch implements it as options to 'git bisect start' for the following reasons: * By construction, the terms will be valid for one and only one bisection. * Unlike positional arguments, using named options avoid having to remember an order. * We can combine user-defined terms and passing old/new commits as argument to "git bisect start". * The implementation is relatively simple. See previous discussions: http://mid.gmane.org/1435337896-20709-3-git-send-email-Matthieu.Moy@imag.fr Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | | | | | | bisect: add 'git bisect terms' to view the current termsMatthieu Moy2015-08-033-1/+68
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | | | | | | bisect: add the terms old/newAntoine Delaite2015-08-034-14/+119
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When not looking for a regression during a bisect but for a fix or a change in another given property, it can be confusing to use 'good' and 'bad'. This patch introduce `git bisect new` and `git bisect old` as an alternative to 'bad' and good': the commits which have a certain property must be marked as `new` and the ones which do not as `old`. The output will be the first commit after the change in the property. During a new/old bisect session you cannot use bad/good commands and vice-versa. Some commands are still not available for old/new: * git rev-list --bisect does not treat the revs/bisect/new and revs/bisect/old-SHA1 files. Old discussions: - http://thread.gmane.org/gmane.comp.version-control.git/86063 introduced bisect fix unfixed to find fix. - http://thread.gmane.org/gmane.comp.version-control.git/182398 discussion around bisect yes/no or old/new. - http://thread.gmane.org/gmane.comp.version-control.git/199758 last discussion and reviews New discussions: - http://thread.gmane.org/gmane.comp.version-control.git/271320 ( v2 1/7-4/7 ) - http://comments.gmane.org/gmane.comp.version-control.git/271343 ( v2 5/7-7/7 ) Signed-off-by: Antoine Delaite <antoine.delaite@ensimag.grenoble-inp.fr> Signed-off-by: Louis Stuber <stuberl@ensimag.grenoble-inp.fr> Signed-off-by: Valentin Duperray <Valentin.Duperray@ensimag.imag.fr> Signed-off-by: Franck Jonas <Franck.Jonas@ensimag.imag.fr> Signed-off-by: Lucien Kong <Lucien.Kong@ensimag.imag.fr> Signed-off-by: Thomas Nguy <Thomas.Nguy@ensimag.imag.fr> Signed-off-by: Huynh Khoi Nguyen Nguyen <Huynh-Khoi-Nguyen.Nguyen@ensimag.imag.fr> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | | | | | | bisect: sanity check on termsMatthieu Moy2015-08-031-0/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is currently only a defensive check since the only terms are bad/good and new/old, which pass it, but this is a preparation step for accepting user-supplied terms. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | | | | | | Merge branch 'jc/rerere'Junio C Hamano2015-10-053-154/+417
|\ \ \ \ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Code clean-up and minor fixes. * jc/rerere: (21 commits) rerere: un-nest merge() further rerere: use "struct rerere_id" instead of "char *" for conflict ID rerere: call conflict-ids IDs rerere: further clarify do_rerere_one_path() rerere: further de-dent do_plain_rerere() rerere: refactor "replay" part of do_plain_rerere() rerere: explain the remainder rerere: explain "rerere forget" codepath rerere: explain the primary codepath rerere: explain MERGE_RR management helpers rerere: fix benign off-by-one non-bug and clarify code rerere: explain the rerere I/O abstraction rerere: do not leak mmfile[] for a path with multiple stage #1 entries rerere: stop looping unnecessarily rerere: drop want_sp parameter from is_cmarker() rerere: report autoupdated paths only after actually updating them rerere: write out each record of MERGE_RR in one go rerere: lift PATH_MAX limitation rerere: plug conflict ID leaks rerere: handle conflicts with multiple stage #1 entries ...
| * | | | | | | | | rerere: un-nest merge() furtherjc/rerereJunio C Hamano2015-07-241-24/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | By consistently using "upon failure, set 'ret' and jump to out" pattern, flatten the function further. Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | | | | | | | rerere: use "struct rerere_id" instead of "char *" for conflict IDJunio C Hamano2015-07-243-28/+85
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This gives a thin abstraction between the conflict ID that is a hash value obtained by inspecting the conflicts and the name of the directory under $GIT_DIR/rr-cache/, in which the previous resolution is recorded to be replayed. The plan is to make sure that the presence of the directory does not imply the presense of a previous resolution and vice-versa, and later allow us to have more than one pair of <preimage, postimage> for a given conflict ID. Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | | | | | | | rerere: call conflict-ids IDsJunio C Hamano2015-07-243-41/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Most places we call conflict IDs "name" and some others we call them "hex"; update all of them to "id". Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | | | | | | | rerere: further clarify do_rerere_one_path()Junio C Hamano2015-07-241-9/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | | | | | | | rerere: further de-dent do_plain_rerere()Junio C Hamano2015-07-241-32/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It's just easier to follow this way. Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | | | | | | | rerere: refactor "replay" part of do_plain_rerere()Junio C Hamano2015-07-241-35/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Extract the body of a loop that attempts to replay recorded resolution for each conflicted path into a helper function, not because I want to call it from multiple places later, but because the logic has become too deeply nested and hard to read. Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | | | | | | | rerere: explain the remainderJunio C Hamano2015-07-241-0/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Explain the internals of rerere as in-code comments, while sprinkling "NEEDSWORK" comment to highlight iffy bits and questionable assumptions. This covers the codepath that implements "rerere gc" and "rerere clear". Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | | | | | | | rerere: explain "rerere forget" codepathJunio C Hamano2015-07-241-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Explain the internals of rerere as in-code comments, while sprinkling "NEEDSWORK" comment to highlight iffy bits and questionable assumptions. This covers the codepath that implements "rerere forget". Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | | | | | | | rerere: explain the primary codepathJunio C Hamano2015-07-241-13/+82
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Explain the internals of rerere as in-code comments, while sprinkling "NEEDSWORK" comment to highlight iffy bits and questionable assumptions. This one covers the codepath reached from rerere(), the primary interface to the subsystem. Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | | | | | | | rerere: explain MERGE_RR management helpersJunio C Hamano2015-07-241-0/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Explain the internals of rerere as in-code comments, while sprinkling "NEEDSWORK" comment to highlight iffy bits and questionable assumptions. This one covers the "$GIT_DIR/MERGE_RR" file and in-core merge_rr that are used to keep track of the status of "rerere" session in progress. Signed-off-by: Junio C Hamano <gitster@pobox.com>