{"thread":{"id":"23722","subject":"git branch documentation improvements","startedAt":"2010-05-06T22:24:40Z","lastAt":"2010-05-11T18:27:04Z","messageCount":9,"participants":["Andreas Hartmetz","Jon Seymour","Johannes Sixt"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"141092","messageId":"201005070024.41172.ahartmetz@gmail.com","threadId":"23722","inReplyTo":null,"subject":"git branch documentation improvements","fromName":"Andreas Hartmetz","fromEmail":"ahartmetz@gmail.com","sentAt":"2010-05-06T22:24:40Z","receivedAt":"2010-05-06T22:24:40Z","isPatch":false,"sender":{"key":"ahartmetz@gmail.com","avatar":null},"body":"Hello all,\n\nToday I read the git branch documentation and noticed a few things, mostly \nstyle and consistency related, that could easily be improved, so I did just \nthat.\nPlease consider merging the attached patch if it looks good, or tell me what \nyou don't like about it.\nThe most significant change is renaming <start-point> (or is it \n<startpoint>...) to <branch-head> because even I as a relative beginner know \nthat a branch is defined by its (movable) head, and <start-point> *does* \nactually specify the new branch head if I'm not mistaken.\n\nCheers,\nAndreas Hartmetz\n\n\ndiff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt\nindex 1940256..872bb3e 100644\n--- a/Documentation/git-branch.txt\n+++ b/Documentation/git-branch.txt\n@@ -11,51 +11,50 @@ SYNOPSIS\n 'git branch' [--color[=<when>] | --no-color] [-r | -a]\n \t[-v [--abbrev=<length> | --no-abbrev]]\n \t[(--merged | --no-merged | --contains) [<commit>]]\n-'git branch' [--set-upstream | --track | --no-track] [-l] [-f] <branchname> [<start-point>]\n+'git branch' [--set-upstream | --track | --no-track] [-l] [-f] <branchname> [<branch-head>]\n 'git branch' (-m | -M) [<oldbranch>] <newbranch>\n 'git branch' (-d | -D) [-r] <branchname>...\n \n DESCRIPTION\n -----------\n \n-With no arguments, existing branches are listed and the current branch will\n-be highlighted with an asterisk.  Option `-r` causes the remote-tracking\n-branches to be listed, and option `-a` shows both.\n+With no arguments, local branches are listed and the current branch is\n+highlighted with an asterisk.  Option `-r` lists remote-tracking\n+branches, and option `-a` lists both.\n \n-With `--contains`, shows only the branches that contain the named commit\n+With `--contains`, show only the branches that contain the named commit\n (in other words, the branches whose tip commits are descendants of the\n named commit).  With `--merged`, only branches merged into the named\n commit (i.e. the branches whose tip commits are reachable from the named\n-commit) will be listed.  With `--no-merged` only branches not merged into\n-the named commit will be listed.  If the <commit> argument is missing it\n-defaults to 'HEAD' (i.e. the tip of the current branch).\n+commit) are listed.  With `--no-merged` only branches not merged into\n+the named commit are listed.  If the <commit> argument is missing it\n+defaults to 'HEAD', the tip of the current branch.\n \n-The command's second form creates a new branch head named <branchname>\n-which points to the current 'HEAD', or <start-point> if given.\n-\n-Note that this will create the new branch, but it will not switch the\n+The second form of the command creates a new branch head named <branchname>\n+which points to the current 'HEAD', or <branch-head> if given.\n+Note that this creates the new branch, but does not switch the\n working tree to it; use \"git checkout <newbranch>\" to switch to the\n new branch.\n \n When a local branch is started off a remote branch, git sets up the\n branch so that 'git pull' will appropriately merge from\n the remote branch. This behavior may be changed via the global\n-`branch.autosetupmerge` configuration flag. That setting can be\n-overridden by using the `--track` and `--no-track` options.\n+`branch.autosetupmerge` configuration flag. You can override the\n+flag using the `--track` and `--no-track` options.\n \n-With a '-m' or '-M' option, <oldbranch> will be renamed to <newbranch>.\n+With the '-m' or '-M' command, <oldbranch> is renamed to <newbranch>.\n If <oldbranch> had a corresponding reflog, it is renamed to match\n <newbranch>, and a reflog entry is created to remember the branch\n-renaming. If <newbranch> exists, -M must be used to force the rename\n-to happen.\n+renaming. If <newbranch> exists, -M can be used to forwe overwriting\n+it.\n \n-With a `-d` or `-D` option, `<branchname>` will be deleted.  You may\n-specify more than one branch for deletion.  If the branch currently\n-has a reflog then the reflog will also be deleted.\n+With the `-d` or `-D` command, `<branchname>` is deleted.  You may\n+specify more than one branch to delete.  If the branch currently\n+has a reflog, the reflog is also be deleted.\n \n-Use -r together with -d to delete remote-tracking branches. Note, that it\n+Use -r together with -d to delete remote-tracking branches. Note that it\n only makes sense to delete remote-tracking branches if they no longer exist\n-in the remote repository or if 'git fetch' was configured not to fetch\n+in the remote repository, or if 'git fetch' was configured not to fetch\n them again. See also the 'prune' subcommand of linkgit:git-remote[1] for a\n way to clean up all obsolete remote-tracking branches.\n \n@@ -79,7 +78,7 @@ OPTIONS\n \n -f::\n --force::\n-\tReset <branchname> to <startpoint> if <branchname> exists\n+\tReset <branchname> to <branch-head> if <branchname> exists\n \talready. Without `-f` 'git branch' refuses to change an existing branch.\n \n -m::\n@@ -119,8 +118,8 @@ OPTIONS\n -t::\n --track::\n \tWhen creating a new branch, set up configuration to mark the\n-\tstart-point branch as \"upstream\" from the new branch. This\n-\tconfiguration will tell git to show the relationship between the\n+\t<branch-head> branch as \"upstream\" from the new branch. This\n+\tconfiguration tells git to show the relationship between the\n \ttwo branches in `git status` and `git branch -v`. Furthermore,\n \tit directs `git pull` without arguments to pull from the\n \tupstream when the new branch is checked out.\n@@ -133,13 +132,13 @@ start-point is either a local or remote branch.\n \n --no-track::\n \tDo not set up \"upstream\" configuration, even if the\n-\tbranch.autosetupmerge configuration variable is true.\n+\tbranch.autosetupmerge configuration flag is true.\n \n --set-upstream::\n \tIf specified branch does not exist yet or if '--force' has been\n \tgiven, acts exactly like '--track'. Otherwise sets up configuration\n \tlike '--track' would when creating the branch, except that where\n-\tbranch points to is not changed.\n+\t<branchname> points to is not changed.\n \n --contains <commit>::\n \tOnly list branches which contain the specified commit.\n@@ -158,7 +157,7 @@ start-point is either a local or remote branch.\n \tlinkgit:git-check-ref-format[1].  Some of these checks\n \tmay restrict the characters allowed in a branch name.\n \n-<start-point>::\n+<branch-head>::\n \tThe new branch head will point to this commit.  It may be\n \tgiven as a branch name, a commit-id, or a tag.  If this\n \toption is omitted, the current HEAD will be used instead.\n"},{"id":"141100","messageId":"r2l2cfc40321005061559p9d3a5392rdc2b30f63a34ab9b@mail.gmail.com","threadId":"23722","inReplyTo":"201005070024.41172.ahartmetz@gmail.com","subject":"Re: git branch documentation improvements","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2010-05-06T22:59:22Z","receivedAt":"2010-05-06T22:59:22Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"This patch would be easier to review, and thus more likely to be\naccepted, if the guidelines in SubmittingPatches had been followed,\nw.r.t. not using attachments to submit patches.\n\n\nOn Fri, May 7, 2010 at 8:24 AM, Andreas Hartmetz <ahartmetz@gmail.com> wrote:\n> Hello all,\n>\n> Today I read the git branch documentation and noticed a few things, mostly\n> style and consistency related, that could easily be improved, so I did just\n> that.\n> Please consider merging the attached patch if it looks good, or tell me what\n> you don't like about it.\n> The most significant change is renaming <start-point> (or is it\n> <startpoint>...) to <branch-head> because even I as a relative beginner know\n> that a branch is defined by its (movable) head, and <start-point> *does*\n> actually specify the new branch head if I'm not mistaken.\n>\n\nWhile I agree with you start start-point is probably the wrong name\nfor this parameter, I wonder whether branch-head might be too\nsuggestive that the value of that parameter must itself be an existing\nbranch head.\n\nI think the term \"head-commit\" would be a more accurate way to\ndescribe the possible values of this parameter. That is, it is the\ncommit that will become the head of the new branch.\n\njon.\n"},{"id":"141105","messageId":"201005070304.18141.ahartmetz@gmail.com","threadId":"23722","inReplyTo":"r2l2cfc40321005061559p9d3a5392rdc2b30f63a34ab9b@mail.gmail.com","subject":"Re: git branch documentation improvements","fromName":"Andreas Hartmetz","fromEmail":"ahartmetz@gmail.com","sentAt":"2010-05-07T01:04:17Z","receivedAt":"2010-05-07T01:04:17Z","isPatch":false,"sender":{"key":"ahartmetz@gmail.com","avatar":null},"body":"On Friday 07 May 2010 00:59:22 Jon Seymour wrote:\n> This patch would be easier to review, and thus more likely to be\n> accepted, if the guidelines in SubmittingPatches had been followed,\n> w.r.t. not using attachments to submit patches.\n> \nOops, sorry. I didn't see that file. Patch follows at the end.\n\n> On Fri, May 7, 2010 at 8:24 AM, Andreas Hartmetz <ahartmetz@gmail.com> wrote:\n> > Hello all,\n> > \n> > Today I read the git branch documentation and noticed a few things,\n> > mostly style and consistency related, that could easily be improved, so\n> > I did just that.\n> > Please consider merging the attached patch if it looks good, or tell me\n> > what you don't like about it.\n> > The most significant change is renaming <start-point> (or is it\n> > <startpoint>...) to <branch-head> because even I as a relative beginner\n> > know that a branch is defined by its (movable) head, and <start-point>\n> > *does* actually specify the new branch head if I'm not mistaken.\n> \n> While I agree with you start start-point is probably the wrong name\n> for this parameter, I wonder whether branch-head might be too\n> suggestive that the value of that parameter must itself be an existing\n> branch head.\n> \n> I think the term \"head-commit\" would be a more accurate way to\n> describe the possible values of this parameter. That is, it is the\n> commit that will become the head of the new branch.\n> \nYes, why not.\n\nI noticed a problem in the second paragraph of the description of --track\nwhere neither <start-point> nor <branch-head> nor <head-commit> works well.\nMaybe I butchered the first sentence because it used to say \"start point\".\nEither way, that first sentence looks fishy to me.\nAny suggestions?\n\n>From 3fa7cb87068cfba00c55f494b30f3773f4ce9c69 Mon Sep 17 00:00:00 2001\nFrom: Andreas Hartmetz <ahartmetz@gmail.com>\nDate: Fri, 7 May 2010 02:44:41 +0200\nSubject: [PATCH] git-branch documentation improvements:\n - Use only present tense where possible\n - Use similar wording for similar things\n - Miscellaneous style improvements\n - Replace \"<start-point>\" with \"<head-commit>\" which is more in line with the\n   how git actually works, and applies to all situations\n\nSigned-off-by: Andreas Hartmetz <ahartmetz@gmail.com>\n---\n Documentation/git-branch.txt |   61 ++++++++++++++++++++---------------------\n 1 files changed, 30 insertions(+), 31 deletions(-)\n\ndiff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt\nindex 1940256..7878534 100644\n--- a/Documentation/git-branch.txt\n+++ b/Documentation/git-branch.txt\n@@ -11,51 +11,50 @@ SYNOPSIS\n 'git branch' [--color[=<when>] | --no-color] [-r | -a]\n \t[-v [--abbrev=<length> | --no-abbrev]]\n \t[(--merged | --no-merged | --contains) [<commit>]]\n-'git branch' [--set-upstream | --track | --no-track] [-l] [-f] <branchname> [<start-point>]\n+'git branch' [--set-upstream | --track | --no-track] [-l] [-f] <branchname> [<head-commit>]\n 'git branch' (-m | -M) [<oldbranch>] <newbranch>\n 'git branch' (-d | -D) [-r] <branchname>...\n\n DESCRIPTION\n -----------\n\n-With no arguments, existing branches are listed and the current branch will\n-be highlighted with an asterisk.  Option `-r` causes the remote-tracking\n-branches to be listed, and option `-a` shows both.\n+With no arguments, local branches are listed and the current branch is\n+highlighted with an asterisk.  Option `-r` lists remote-tracking\n+branches, and option `-a` lists both.\n\n-With `--contains`, shows only the branches that contain the named commit\n+With `--contains`, show only the branches that contain the named commit\n (in other words, the branches whose tip commits are descendants of the\n named commit).  With `--merged`, only branches merged into the named\n commit (i.e. the branches whose tip commits are reachable from the named\n-commit) will be listed.  With `--no-merged` only branches not merged into\n-the named commit will be listed.  If the <commit> argument is missing it\n-defaults to 'HEAD' (i.e. the tip of the current branch).\n+commit) are listed.  With `--no-merged` only branches not merged into\n+the named commit are listed.  If the <commit> argument is missing it\n+defaults to 'HEAD', the tip of the current branch.\n\n-The command's second form creates a new branch head named <branchname>\n-which points to the current 'HEAD', or <start-point> if given.\n-\n-Note that this will create the new branch, but it will not switch the\n+The second form of the command creates a new branch head named <branchname>\n+which points to the current 'HEAD', or <head-commit> if given.\n+Note that this creates the new branch, but does not switch the\n working tree to it; use \"git checkout <newbranch>\" to switch to the\n new branch.\n\n When a local branch is started off a remote branch, git sets up the\n branch so that 'git pull' will appropriately merge from\n the remote branch. This behavior may be changed via the global\n-`branch.autosetupmerge` configuration flag. That setting can be\n-overridden by using the `--track` and `--no-track` options.\n+`branch.autosetupmerge` configuration flag. You can override the\n+flag using the `--track` and `--no-track` options.\n\n-With a '-m' or '-M' option, <oldbranch> will be renamed to <newbranch>.\n+With the '-m' or '-M' command, <oldbranch> is renamed to <newbranch>.\n If <oldbranch> had a corresponding reflog, it is renamed to match\n <newbranch>, and a reflog entry is created to remember the branch\n-renaming. If <newbranch> exists, -M must be used to force the rename\n-to happen.\n+renaming. If <newbranch> exists, -M can be used to forwe overwriting\n+it.\n\n-With a `-d` or `-D` option, `<branchname>` will be deleted.  You may\n-specify more than one branch for deletion.  If the branch currently\n-has a reflog then the reflog will also be deleted.\n+With the `-d` or `-D` command, `<branchname>` is deleted.  You may\n+specify more than one branch to delete.  If the branch currently\n+has a reflog, the reflog is also be deleted.\n\n-Use -r together with -d to delete remote-tracking branches. Note, that it\n+Use -r together with -d to delete remote-tracking branches. Note that it\n only makes sense to delete remote-tracking branches if they no longer exist\n-in the remote repository or if 'git fetch' was configured not to fetch\n+in the remote repository, or if 'git fetch' was configured not to fetch\n them again. See also the 'prune' subcommand of linkgit:git-remote[1] for a\n way to clean up all obsolete remote-tracking branches.\n\n@@ -79,7 +78,7 @@ OPTIONS\n\n -f::\n --force::\n-\tReset <branchname> to <startpoint> if <branchname> exists\n+\tReset <branchname> to <head-commit> if <branchname> exists\n \talready. Without `-f` 'git branch' refuses to change an existing branch.\n\n -m::\n@@ -119,27 +118,27 @@ OPTIONS\n -t::\n --track::\n \tWhen creating a new branch, set up configuration to mark the\n-\tstart-point branch as \"upstream\" from the new branch. This\n-\tconfiguration will tell git to show the relationship between the\n+\t<head-commit> branch as \"upstream\" from the new branch. This\n+\tconfiguration tells git to show the relationship between the\n \ttwo branches in `git status` and `git branch -v`. Furthermore,\n \tit directs `git pull` without arguments to pull from the\n \tupstream when the new branch is checked out.\n +\n-This behavior is the default when the start point is a remote branch.\n-Set the branch.autosetupmerge configuration variable to `false` if you\n+This behavior is the default when the <head-commit> is a remote branch.\n+Set the branch.autosetupmerge configuration flag to `false` if you\n want `git checkout` and `git branch` to always behave as if '--no-track'\n were given. Set it to `always` if you want this behavior when the\n-start-point is either a local or remote branch.\n+<head-commit> is either a local or remote branch.\n\n --no-track::\n \tDo not set up \"upstream\" configuration, even if the\n-\tbranch.autosetupmerge configuration variable is true.\n+\tbranch.autosetupmerge configuration flag is true.\n\n --set-upstream::\n \tIf specified branch does not exist yet or if '--force' has been\n \tgiven, acts exactly like '--track'. Otherwise sets up configuration\n \tlike '--track' would when creating the branch, except that where\n-\tbranch points to is not changed.\n+\t<branchname> points to is not changed.\n\n --contains <commit>::\n \tOnly list branches which contain the specified commit.\n@@ -158,7 +157,7 @@ start-point is either a local or remote branch.\n \tlinkgit:git-check-ref-format[1].  Some of these checks\n \tmay restrict the characters allowed in a branch name.\n\n-<start-point>::\n+<head-commit>::\n \tThe new branch head will point to this commit.  It may be\n \tgiven as a branch name, a commit-id, or a tag.  If this\n \toption is omitted, the current HEAD will be used instead.\n--\n1.7.0.4\n"},{"id":"141107","messageId":"201005070428.16827.ahartmetz@gmail.com","threadId":"23722","inReplyTo":"r2l2cfc40321005061559p9d3a5392rdc2b30f63a34ab9b@mail.gmail.com","subject":"Re: git branch documentation improvements","fromName":"Andreas Hartmetz","fromEmail":"ahartmetz@gmail.com","sentAt":"2010-05-07T02:28:16Z","receivedAt":"2010-05-07T02:28:16Z","isPatch":false,"sender":{"key":"ahartmetz@gmail.com","avatar":null},"body":"On Friday 07 May 2010 00:59:22 Jon Seymour wrote:\n> On Fri, May 7, 2010 at 8:24 AM, Andreas Hartmetz <ahartmetz@gmail.com> \nwrote:\n> > Today I read the git branch documentation and noticed a few things,\n> > mostly style and consistency related, that could easily be improved, so\n> > I did just that.\n> > Please consider merging the attached patch if it looks good, or tell me\n> > what you don't like about it.\n> > The most significant change is renaming <start-point> (or is it\n> > <startpoint>...) to <branch-head> because even I as a relative beginner\n> > know that a branch is defined by its (movable) head, and <start-point>\n> > *does* actually specify the new branch head if I'm not mistaken.\n> \n> While I agree with you start start-point is probably the wrong name\n> for this parameter, I wonder whether branch-head might be too\n> suggestive that the value of that parameter must itself be an existing\n> branch head.\n> \n> I think the term \"head-commit\" would be a more accurate way to\n> describe the possible values of this parameter. That is, it is the\n> commit that will become the head of the new branch.\n> \nAnother suggestion I came up with much earlier that I recalled just now:\n<new-head>\n"},{"id":"141117","messageId":"4BE3BF2F.8050903@viscovery.net","threadId":"23722","inReplyTo":"201005070024.41172.ahartmetz@gmail.com","subject":"Re: git branch documentation improvements","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2010-05-07T07:20:15Z","receivedAt":"2010-05-07T07:20:15Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 5/7/2010 0:24, schrieb Andreas Hartmetz:\n> The most significant change is renaming <start-point> (or is it \n> <startpoint>...) to <branch-head> because even I as a relative beginner know \n> that a branch is defined by its (movable) head, and <start-point> *does* \n> actually specify the new branch head if I'm not mistaken.\n\nBut what is wrong with \"start-point\"? It precisely conveys the meaning of\nthe parameter.\n\n-- Hannes\n"},{"id":"141118","messageId":"m2t2cfc40321005070140m85d51db7id75b5b897f2acc00@mail.gmail.com","threadId":"23722","inReplyTo":"4BE3BF2F.8050903@viscovery.net","subject":"Re: git branch documentation improvements","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2010-05-07T08:40:06Z","receivedAt":"2010-05-07T08:40:06Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"My minor quibble with start-point is that the naive user may assume\nthat, like CVS or SVN, git has some persistent notion of a \"start\npoint\".\n\nIn reality, git only tracks heads. A term like \"head-commit\" is, IMO,\nmore precise than \"start-point\" and does not potentially convey the\nfalse notion that git knows or cares about the point at which a branch\nwas \"started\".\n\njon.\n\nOn Fri, May 7, 2010 at 5:20 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:\n> Am 5/7/2010 0:24, schrieb Andreas Hartmetz:\n>> The most significant change is renaming <start-point> (or is it\n>> <startpoint>...) to <branch-head> because even I as a relative beginner know\n>> that a branch is defined by its (movable) head, and <start-point> *does*\n>> actually specify the new branch head if I'm not mistaken.\n>\n> But what is wrong with \"start-point\"? It precisely conveys the meaning of\n> the parameter.\n>\n> -- Hannes\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n>\n"},{"id":"141252","messageId":"201005081839.37790.ahartmetz@gmail.com","threadId":"23722","inReplyTo":"4BE3BF2F.8050903@viscovery.net","subject":"Re: git branch documentation improvements","fromName":"Andreas Hartmetz","fromEmail":"ahartmetz@gmail.com","sentAt":"2010-05-08T16:39:37Z","receivedAt":"2010-05-08T16:39:37Z","isPatch":false,"sender":{"key":"ahartmetz@gmail.com","avatar":null},"body":"On Friday 07 May 2010 09:20:15 Johannes Sixt wrote:\n> Am 5/7/2010 0:24, schrieb Andreas Hartmetz:\n> > The most significant change is renaming <start-point> (or is it\n> > <startpoint>...) to <branch-head> because even I as a relative beginner\n> > know that a branch is defined by its (movable) head, and <start-point>\n> > *does* actually specify the new branch head if I'm not mistaken.\n> \n> But what is wrong with \"start-point\"? It precisely conveys the meaning of\n> the parameter.\n> \nLook at -f: as far as I understand it moves the branch *head*, so start-point \nis plain wrong. The \"root\" of the branch is not moved, or only moved \nindirectly (not sure if the latter is allowed).\n"},{"id":"141348","messageId":"4BE7A629.7050709@viscovery.net","threadId":"23722","inReplyTo":"201005081839.37790.ahartmetz@gmail.com","subject":"Re: git branch documentation improvements","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2010-05-10T06:22:33Z","receivedAt":"2010-05-10T06:22:33Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 5/8/2010 18:39, schrieb Andreas Hartmetz:\n> On Friday 07 May 2010 09:20:15 Johannes Sixt wrote:\n>> But what is wrong with \"start-point\"? It precisely conveys the meaning of\n>> the parameter.\n>>\n> Look at -f: as far as I understand it moves the branch *head*, so start-point \n> is plain wrong. The \"root\" of the branch is not moved, or only moved \n> indirectly (not sure if the latter is allowed).\n\nHuh? The purpose of -f is not to *move* a branch head, but to say \"trust\nme, I know what I'm doing\". Why would \"start-point\" not be suitable in\nthis case?\n\n-- Hannes\n"},{"id":"141488","messageId":"201005112027.05818.ahartmetz@gmail.com","threadId":"23722","inReplyTo":"4BE7A629.7050709@viscovery.net","subject":"Re: git branch documentation improvements","fromName":"Andreas Hartmetz","fromEmail":"ahartmetz@gmail.com","sentAt":"2010-05-11T18:27:04Z","receivedAt":"2010-05-11T18:27:04Z","isPatch":false,"sender":{"key":"ahartmetz@gmail.com","avatar":null},"body":"On Monday 10 May 2010 08:22:33 Johannes Sixt wrote:\n> Am 5/8/2010 18:39, schrieb Andreas Hartmetz:\n> > On Friday 07 May 2010 09:20:15 Johannes Sixt wrote:\n> >> But what is wrong with \"start-point\"? It precisely conveys the meaning\n> >> of the parameter.\n> > \n> > Look at -f: as far as I understand it moves the branch *head*, so\n> > start-point is plain wrong. The \"root\" of the branch is not moved, or\n> > only moved indirectly (not sure if the latter is allowed).\n> \n> Huh? The purpose of -f is not to *move* a branch head, but to say \"trust\n> me, I know what I'm doing\". Why would \"start-point\" not be suitable in\n> this case?\n> \nBecause a branch doesn't start at the head.\n"}]}