1. 07 Dec, 2017 2 commits
  2. 13 Oct, 2017 1 commit
    • Junio C Hamano's avatar
      branch: split validate_new_branchname() into two · bc1c9c0e
      Junio C Hamano authored
      Checking if a proposed name is appropriate for a branch is strictly
      a subset of checking if we want to allow creating or updating a
      branch with such a name.  The mysterious sounding 'attr_only'
      parameter to validate_new_branchname() is used to switch the
      function between these two roles.
      Instead, split the function into two, and adjust the callers.  A new
      helper validate_branchname() only checks the name and reports if the
      branch already exists.
      This loses one NEEDSWORK from the branch API.
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  3. 21 Feb, 2017 1 commit
    • Kyle Meyer's avatar
      branch: record creation of renamed branch in HEAD's log · 39ee4c6c
      Kyle Meyer authored
      Renaming the current branch adds an event to the current branch's log
      and to HEAD's log.  However, the logged entries differ.  The entry in
      the branch's log represents the entire renaming operation (the old and
      new hash are identical), whereas the entry in HEAD's log represents
      the deletion only (the new sha1 is null).
      Extend replace_each_worktree_head_symref(), whose only caller is
      branch_rename(), to take a reflog message argument.  This allows the
      creation of the new ref to be recorded in HEAD's log.  As a result,
      the renaming event is represented by two entries (a deletion and a
      creation entry) in HEAD's log.
      It's a bit unfortunate that the branch's log and HEAD's log now
      represent the renaming event in different ways.  Given that the
      renaming operation is not atomic, the two-entry form is a more
      accurate representation of the operation and is more useful for
      debugging purposes if a failure occurs between the deletion and
      creation events.  It would make sense to move the branch's log to the
      two-entry form, but this would involve changes to how the rename is
      carried out and to how the update flags and reflogs are processed for
      deletions, so it may not be worth the effort.
      Based-on-patch-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: Kyle Meyer's avatarKyle Meyer <kyle@kyleam.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  4. 09 Nov, 2016 1 commit
    • Jeff King's avatar
      create_branch: drop unused "head" parameter · 4bd488ea
      Jeff King authored
      This function used to have the caller pass in the current
      value of HEAD, in order to make sure we didn't clobber HEAD.
      In 55c4a673, that logic moved to validate_new_branchname(),
      which just resolves HEAD itself. The parameter to
      create_branch is now unused.
      Since we have to update and re-wrap the docstring describing
      the parameters anyway, let's take this opportunity to break
      it out into a list, which makes it easier to find the
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  5. 22 Apr, 2016 1 commit
    • Duy Nguyen's avatar
      worktree.c: check whether branch is rebased in another worktree · 8d9fdd70
      Duy Nguyen authored
      This function find_shared_symref() is used in a couple places:
      1) in builtin/branch.c: it's used to detect if a branch is checked out
         elsewhere and refuse to delete the branch.
      2) in builtin/notes.c: it's used to detect if a note is being merged in
         another worktree
      3) in branch.c, the function die_if_checked_out() is actually used by
         "git checkout" and "git worktree add" to see if a branch is already
         checked out elsewhere and refuse the operation.
      In cases 1 and 3, if a rebase is ongoing, "HEAD" will be in detached
      mode, find_shared_symref() fails to detect it and declares "no branch is
      checked out here", which is not really what we want.
      This patch tightens the test. If the given symref is "HEAD", we try to
      detect if rebase is ongoing. If so return the branch being rebased. This
      makes checkout and branch delete operations safer because you can't
      checkout a branch being rebased in another place, or delete it.
      Special case for checkout. If the current branch is being rebased,
      git-rebase.sh may use "git checkout" to abort and return back to the
      original branch. The updated test in find_shared_symref() will prevent
      that and "git rebase --abort" will fail as a result.
      find_shared_symref() and die_if_checked_out() have to learn a new
      option ignore_current_worktree to loosen the test a bit.
      Signed-off-by: Duy Nguyen's avatarNguyễn Thái Ngọc Duy <pclouds@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  6. 04 Apr, 2016 1 commit
    • Kazuki Yamaguchi's avatar
      branch -m: update all per-worktree HEADs · 70999e9c
      Kazuki Yamaguchi authored
      When renaming a branch, currently only the HEAD of current working tree
      is updated, but it must update HEADs of all working trees which point at
      the old branch.
      This is the current behavior, /path/to/wt's HEAD is not updated:
        % git worktree list
        /path/to     2c3c5f2 [master]
        /path/to/wt  2c3c5f2 [oldname]
        % git branch -m master master2
        % git worktree list
        /path/to     2c3c5f2 [master2]
        /path/to/wt  2c3c5f2 [oldname]
        % git branch -m oldname newname
        % git worktree list
        /path/to     2c3c5f2 [master2]
        /path/to/wt  0000000 [oldname]
      This patch fixes this issue by updating all relevant worktree HEADs
      when renaming a branch.
      Signed-off-by: Kazuki Yamaguchi's avatarKazuki Yamaguchi <k@rhe.jp>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  7. 22 Feb, 2016 1 commit
    • Patrick Steinhardt's avatar
      branch: report errors in tracking branch setup · 27852b2c
      Patrick Steinhardt authored
      When setting up a new tracking branch fails due to issues with
      the configuration file we do not report any errors to the user
      and pretend setting the tracking branch succeeded.
      Setting up the tracking branch is handled by the
      `install_branch_config` function. We do not want to simply die
      there as the function is not only invoked when explicitly setting
      upstream information with `git branch --set-upstream-to=`, but
      also by `git push --set-upstream` and `git clone`. While it is
      reasonable to die in the explict first case, we would lose
      information in the latter two cases, so we only print the error
      message but continue the program as usual.
      Signed-off-by: default avatarPatrick Steinhardt <ps@pks.im>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  8. 02 Oct, 2015 1 commit
  9. 11 Aug, 2015 1 commit
  10. 20 Jul, 2015 1 commit
    • Eric Sunshine's avatar
      branch: publish die_if_checked_out() · ed89f84b
      Eric Sunshine authored
      git-worktree currently conflates new branch creation, setting of HEAD in
      the new wortkree, and worktree population into a single sub-invocation
      of git-checkout. However, these operations will eventually be separated,
      and git-worktree itself will need to be able to detect if the branch is
      already checked out elsewhere, rather than relying upon git-branch to
      make this determination, so publish die_if_checked_out().
      Signed-off-by: Eric Sunshine's avatarEric Sunshine <sunshine@sunshineco.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  11. 27 Mar, 2012 1 commit
  12. 28 Nov, 2011 1 commit
  13. 05 Oct, 2011 1 commit
  14. 17 Sep, 2011 1 commit
    • Junio C Hamano's avatar
      branch --set-upstream: regression fix · fa799376
      Junio C Hamano authored
      The "git branch" command, while not in listing mode, calls create_branch()
      even when the target branch already exists, and it does so even when it is
      not interested in updating the value of the branch (i.e. the name of the
      commit object that sits at the tip of the existing branch). This happens
      when the command is run with "--set-upstream" option.
      The earlier safety-measure to prevent "git branch -f $branch $commit" from
      updating the currently checked out branch did not take it into account,
      and we no longer can update the tracking information of the current branch.
      Minimally fix this regression by telling the validation code if it is
      called to really update the value of a potentially existing branch, or if
      the caller merely is interested in updating auxiliary aspects of a branch.
      Reported-and-Tested-by: Jay Soffian
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  15. 22 Aug, 2011 1 commit
    • Conrad Irwin's avatar
      Prevent force-updating of the current branch · 55c4a673
      Conrad Irwin authored
      "git branch -M <foo> <current-branch>" allows updating the current branch
      which HEAD points, without the necessary house-keeping that git reset
      normally does to make this operation sensible. It also leaves the reflog
      in a confusing state (you would be warned when trying to read it).
      "git checkout -B <current branch> <foo>" is also partly vulnerable to this
      bug; due to inconsistent pre-flight checks it would perform half of its
      task and then abort just before rewriting the branch. Again this
      manifested itself as the index file getting out-of-sync with HEAD.
      "git branch -f" already guarded against this problem, and aborts with
      a fatal error.
      Update "git branch -M", "git checkout -B" and "git branch -f" to share the
      same check before allowing a branch to be created. These prevent you from
      updating the current branch.
      We considered suggesting the use of "git reset" in the failure message
      but concluded that it was not possible to discern what the user was
      actually trying to do.
      Signed-off-by: Conrad Irwin's avatarConrad Irwin <conrad.irwin@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  16. 03 Nov, 2010 1 commit
  17. 04 Mar, 2009 1 commit
    • Junio C Hamano's avatar
      Make git-clone respect branch.autosetuprebase · a9f2c136
      Junio C Hamano authored
      When git-clone creates an initial branch it was not checking the
      branch.autosetuprebase configuration option (which may exist in
      ~/.gitconfig).  Refactor the code used by "git branch" to create
      a new branch, and use it instead of the insufficiently duplicated code
      in builtin-clone.
      Changes are partly, and the test is mostly, based on the previous work by
      Pat Notz.
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  18. 20 Feb, 2008 1 commit
    • Jay Soffian's avatar
      branch: optionally setup branch.*.merge from upstream local branches · 9ed36cfa
      Jay Soffian authored
      "git branch" and "git checkout -b" now honor --track option even when
      the upstream branch is local.  Previously --track was silently ignored
      when forking from a local branch.  Also the command did not error out
      when --track was explicitly asked for but the forked point specified
      was not an existing branch (i.e. when there is no way to set up the
      tracking configuration), but now it correctly does.
      The configuration setting branch.autosetupmerge can now be set to
      "always", which is equivalent to using --track from the command line.
      Setting branch.autosetupmerge to "true" will retain the former behavior
      of only setting up branch.*.merge for remote upstream branches.
      Includes test cases for the new functionality.
      Signed-off-by: default avatarJay Soffian <jaysoffian@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  19. 10 Feb, 2008 2 commits