summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* git add: -u/-A now affects the entire working treejn/add-2.0-u-A-sans-pathspecJunio C Hamano2013-04-264-121/+19
| | | | | | | | | | | As promised in 0fa2eb530fb7 (add: warn when -u or -A is used without pathspec, 2013-01-28), in Git 2.0, "git add -u/-A" that is run without pathspec in a subdirectory updates all updated paths in the entire working tree, not just the current directory and its subdirectories. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Git 1.8.3-rc0v1.8.3-rc0Junio C Hamano2013-04-262-19/+9
| | | | Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'rr/shortlog-doc'Junio C Hamano2013-04-265-22/+35
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | Update documentation for "log" and "shortlog". * rr/shortlog-doc: builtin/shortlog.c: make usage string consistent with log builtin/log.c: make usage string consistent with doc git-shortlog.txt: make SYNOPSIS match log, update OPTIONS git-log.txt: rewrite note on why "--" may be required git-log.txt: generalize <since>..<until> git-log.txt: order OPTIONS properly; move <since>..<until> revisions.txt: clarify the .. and ... syntax git-shortlog.txt: remove (-h|--help) from OPTIONS
| * builtin/shortlog.c: make usage string consistent with logRamkumar Ramachandra2013-04-221-3/+1
| | | | | | | | | | | | | | | | | | | | "--" is used to separate pathspecs from the rev specs, and not rev specs from the options, as the shortlog_usage string currently indicates. In correcting this usage string, make it consistent with the log_usage string. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * builtin/log.c: make usage string consistent with docRamkumar Ramachandra2013-04-221-1/+1
| | | | | | | | | | | | | | | | Replace '<since>..<until>' with '<revision range>', in accordance with the documentation. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * git-shortlog.txt: make SYNOPSIS match log, update OPTIONSRamkumar Ramachandra2013-04-211-2/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are broadly two problems with the current SYNOPSIS. First, it completely omits the detail that paths can be specified. Second, it attempts to list all the options: this is futile as, in addition to the options unique to it, it accepts all the options that git-rev-list accepts. In fixing these problems, make the SYNOPSIS consistent with that in git-log.txt. Also add the corresponding sections to OPTIONS. Save adding the options from rev-list-options.txt for a later patch, as it requires some work to pick out the options that are relevant to shortlog. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * git-log.txt: rewrite note on why "--" may be requiredRamkumar Ramachandra2013-04-211-2/+2
| | | | | | | | | | | | | | | | | | | | | | In its current form, the note talks about separating options from "branch names" and "refnames" in the same sentence. This is entirely inaccurate, as <revision range> need not be a set of branch names or ref names. Rewrite it to use the word "revision range", to be consistent with the SYNOPSIS. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * git-log.txt: generalize <since>..<until>Ramkumar Ramachandra2013-04-211-7/+9
| | | | | | | | | | | | | | | | | | | | '<since>..<until>' is misleading, as there are many other forms that 'git log' can accept as an argument. Replace it with <revision range>, referring to the section "Specifying Ranges" in revisions.txt, and rewrite the section appropriately. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * git-log.txt: order OPTIONS properly; move <since>..<until>Ramkumar Ramachandra2013-04-211-7/+7
| | | | | | | | | | | | | | | | | | The OPTIONS section lists <since>..<until> as the first item, but this is inconsistent with the ordering in SYNOPSIS. Move it down until it appears just before [[--] <path>...]. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * revisions.txt: clarify the .. and ... syntaxRamkumar Ramachandra2013-04-211-2/+4
| | | | | | | | | | | | | | | | In <rev1>..<rev2> and <rev1>...<rev2>, if either <rev1> or <rev2> is omitted, it defaults to 'HEAD'. Add this detail to the document. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * git-shortlog.txt: remove (-h|--help) from OPTIONSRamkumar Ramachandra2013-04-211-4/+0
| | | | | | | | | | | | | | | | To be consistent with the documentation of all the other commands, remove (-h|--help) from the OPTIONS section. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'th/bisect-skipped-log'Junio C Hamano2013-04-262-0/+30
|\ \ | | | | | | | | | | | | * th/bisect-skipped-log: bisect: Log possibly bad, skipped commits at bisection end
| * | bisect: Log possibly bad, skipped commits at bisection endTorstein Hegge2013-04-232-0/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | If the bisection completes with only skipped commits left to as possible first bad commit, output the list of possible first bad commits to human readers of the bisection log. Signed-off-by: Torstein Hegge <hegge@resisty.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | Merge branch 'ph/rebase-original'Junio C Hamano2013-04-262-1/+8
|\ \ \ | | | | | | | | | | | | | | | | * ph/rebase-original: rebase: find orig_head unambiguously
| * | | rebase: find orig_head unambiguouslyPhil Hord2013-04-232-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When we 'git rebase $upstream', git uses 'rev-parse --verify $current_branch' to find ORIG_HEAD. But if $current_branch is ambiguous, 'rev-parse --verify' emits a warning and returns a SHA1 anyway. When the wrong ambiguous choice is used, git-rebase fails non-gracefully: it emits a warning about failing to lock $current_branch, an error about being unable to checkout $current_branch again, and it might even decide the rebase is a fast-forward when it is not. In the 'rebase $upstream' case, we already know the unambiguous spelling of $current_branch is "HEAD". Fix git-rebase to find $orig_head unambiguously. Add a test in t3400-rebase.sh which creates an ambiguous branch name and rebases it implicitly with 'git rebase $other'. Signed-off-by: Phil Hord <hordp@cisco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | Merge branch 'jn/glossary-revision'Junio C Hamano2013-04-261-3/+1
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The wording for "revision" in the glossary wanted to say it refers to "commit (noun) as a concept" but it was badly phrased. This may need further updates to hint that in contexts where it is clear, the word may refer to an object name, not necessarily a commit. But the patch as-is is already an improvement. * jn/glossary-revision: glossary: a revision is just a commit
| * | | | glossary: a revision is just a commitJonathan Nieder2013-04-211-3/+1
| | |_|/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current definition of 'revision' sounds like it is saying that a revision is a tree object. In reality it is just a commit. This should be especially useful for people used to other revision control systems trying to see how familiar concepts translate into git terms. Reported-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | Merge branch 'jc/add-ignore-removal'Junio C Hamano2013-04-262-10/+23
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Introduce "--ignore-removal" as a synonym to "--no-all" for "git add", and improve the 2.0 migration warning with it. * jc/add-ignore-removal: git add: rephrase -A/--no-all warning git add: --ignore-removal is a better named --no-all
| * | | | git add: rephrase -A/--no-all warningJunio C Hamano2013-04-221-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now we have a synonym --ignore-removal for --no-all, we can rephrase the Git 2.0 transition warning message in a more natural way. Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | | git add: --ignore-removal is a better named --no-allJunio C Hamano2013-04-222-4/+17
| | |_|/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the historical context of "git add --all ." that pays attention to "all kinds of changes" (implying "without ignoring removals"), the option to countermand it "--no-all" may have made sense, but because we will be making "--all" the default when a pathspec is given, it makes more sense to rename the option to a more explicit "--ignore-removal". The "--all" option naturally becomes its negation, "--no-ignore-removal". Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | remote-bzr: strip extra newlineFelipe Contreras2013-04-261-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | It's added by fast-export, the user didn't type it. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | remote-bzr: tell bazaar to be quietFelipe Contreras2013-04-261-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Otherwise we get notification, progress bars, and what not. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | remote-bzr: store converted URLFelipe Contreras2013-04-261-1/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Bazaar might convert the URL to something more appropriate, like an absolute path. Lets store that instead of the original URL, which won't work from a different working directory if it's relative. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | remote-hg: use hashlib instead of hg sha1 utilFelipe Contreras2013-04-261-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | To be in sync with remote-bzr. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | remote-bzr: add support to push URLsFelipe Contreras2013-04-261-3/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Just like in remote-hg. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | remote-bzr: fix bad state issueFelipe Contreras2013-04-261-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Carried from remote-hg. The problem reportedly happened after doing a push that fails, the abort causes the state of remote-hg to go bad, this happens because remote-hg's marks are not stored, but 'git fast-export' marks are. Ensure that the marks are _always_ stored. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | remote-hg: remove extra checkFelipe Contreras2013-04-261-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Not needed since we use xrange ourselves. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | remote-helpers: trivial cleanupsFelipe Contreras2013-04-262-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | No functional changes. Typos, unused variables, redundant operations, and white-spaces. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | Merge branch 'fc/remote-hg'Junio C Hamano2013-04-263-36/+141
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * fc/remote-hg: remote-hg: strip extra newline remote-hg: use marks instead of inlined files remote-hg: small performance improvement remote-hg: allow refs with spaces remote-hg: don't update bookmarks unnecessarily remote-hg: add support for schemes extension remote-hg: improve email sanitation remote-hg: add custom local tag write code remote-hg: write tags in the appropriate branch remote-hg: custom method to write tags remote-hg: add support for tag objects remote-hg: add branch_tip() helper remote-hg: properly mark branches up-to-date remote-hg: use python urlparse remote-hg: safer bookmark pushing remote-helpers: avoid has_key
| * | | | remote-hg: strip extra newlineFelipe Contreras2013-04-221-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There's no functional change since mercurial commit operation strips that anyway, but that's no excuse for us not to do the right thing. So let's be explicit about it. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | | remote-hg: use marks instead of inlined filesFelipe Contreras2013-04-221-8/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | So that we can find already exported ones. We can never be 100% sure that we already exported such data, due to mercurial design, it at least sometimes we should detect them, and so should give us some performance boost. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | | remote-hg: small performance improvementFelipe Contreras2013-04-221-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Load previous manifest first as Mercurial does; for caching reasons. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | | remote-hg: allow refs with spacesFelipe Contreras2013-04-221-8/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Mercurial supports them, Git doesn't. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | | remote-hg: don't update bookmarks unnecessarilyFelipe Contreras2013-04-221-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | | remote-hg: add support for schemes extensionFelipe Contreras2013-04-221-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | So that we can use shortened URLs, for example 'bb:://felipec/repo' (Bitbucket). Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | | remote-hg: improve email sanitationFelipe Contreras2013-04-222-6/+12
| | | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | | remote-hg: add custom local tag write codeFelipe Contreras2013-04-221-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There's no point in calling the tag method for such simple action. Not that we care much about the hg-git compat mode, it's mostly just for comparison testing purposes. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | | remote-hg: write tags in the appropriate branchFelipe Contreras2013-04-221-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | | remote-hg: custom method to write tagsFelipe Contreras2013-04-221-1/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The one from mercurial is meant for users, on top of the latest tip. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | | remote-hg: add support for tag objectsFelipe Contreras2013-04-221-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | | remote-hg: add branch_tip() helperFelipe Contreras2013-04-221-3/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Idea from gitifyhg, the backwards compatibility is how Mercurial used to do it. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | | remote-hg: properly mark branches up-to-dateFelipe Contreras2013-04-221-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | | remote-hg: use python urlparseFelipe Contreras2013-04-221-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It's simpler, and we don't need to depend on certain Mercurial versions. Also, now we don't update the URL if 'file://' is not present. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | | remote-hg: safer bookmark pushingFelipe Contreras2013-04-221-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It is possible that the remote has changed the bookmarks, so let's fetch them before we make any assumptions, just the way mercurial does. Probably doesn't make a difference, but better be safe than sorry. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | | remote-helpers: avoid has_keyDusty Phillips2013-04-222-2/+2
| |/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It is deprecated. [fc: do the same in remote-bzr] Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | Merge branch 'fc/remote-bzr'Junio C Hamano2013-04-261-5/+5
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | * fc/remote-bzr: remote-bzr: use proper push method
| * | | | remote-bzr: use proper push methodFelipe Contreras2013-04-251-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Do not just randomly synchronize the revisions with no checks at all. I don't have any evidence that there's anything wrong with the current code, which Bazaar seems to use, but for different purposes. Let's use the logic Bazaar UI uses to avoid surprises. Also, add a non-ff check. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | | Merge branch 'jc/warn-pathless-add-finishing-touches'Junio C Hamano2013-04-261-0/+2
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | * jc/warn-pathless-add-finishing-touches: git add: avoid "-u/-A without pathspec" warning on stat-dirty paths
| * | | | | git add: avoid "-u/-A without pathspec" warning on stat-dirty pathsJunio C Hamano2013-04-261-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In preparation for Git 2.0, "git add -u/-A" without pathspec checks all the working tree (not limited to the current directory) and issues a warning when it finds any path that we might add in Git 2.0, because that would mean the users' fingers need to be trained to explicitly say "." if they want to keep the current behaviour. However, the check was incomplete, because "git add" usually does not refresh the index, considers a path that is stat-dirty but has contents that is otherwise up-to-date in the index as "we might add", and relies on that it is a no-op to add the same thing again via the add_file_to_index() API (which also knows not to say "added" in verbose mode when this happens). We do not want to trigger the warning for a path that is outside the current directory is merely stat-dirty, as it won't be added in Git 2.0, either. Signed-off-by: Junio C Hamano <gitster@pobox.com> Acked-by: Jonathan Nieder <jrnieder@gmail.com>
* | | | | | Sync with 1.8.2.2Junio C Hamano2013-04-267-20/+54
|\ \ \ \ \ \