summaryrefslogtreecommitdiff
path: root/branch.c
AgeCommit message (Collapse)AuthorFilesLines
2009-03-22strbuf_check_branch_ref(): a helper to check a refname for a branchLibravatar Junio C Hamano1-4/+1
This allows a common calling sequence strbuf_branchname(&ref, name); strbuf_splice(&ref, 0, 0, "refs/heads/", 11); if (check_ref_format(ref.buf)) die(...); to be refactored into if (strbuf_check_branch_ref(&ref, name)) die(...); Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-22strbuf_branchname(): a wrapper for branch name shorthandsLibravatar Junio C Hamano1-6/+1
The function takes a user-supplied string that is supposed to be a branch name, and puts it in a strbuf after expanding possible shorthand notation. A handful of open coded sequence to do this in the existing code have been changed to use this helper function. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-22Rename interpret/substitute nth_last_branch functionsLibravatar Junio C Hamano1-1/+1
These allow you to say "git checkout @{-2}" to switch to the branch two "branch switching" ago by pretending as if you typed the name of that branch. As it is likely that we will be introducing more short-hands to write the name of a branch without writing it explicitly, rename the functions from "nth_last_branch" to more generic "branch_name", to prepare for different semantics. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-10Improve "git branch --tracking" outputLibravatar Junio C Hamano1-6/+17
An earlier patch always spelled the full name of the ref that we track (e.g. "refs/heads/frotz" instead of just "frotz" when we mean the branch whose name is "frotz"). Worse yet, because we now use the true name of the ref at the original repository when talk about a tracking branch that copies from a remote, such a full name alone still does not give enough information. This reorganizes the verbose codepath to: - differentiate "refs/heads/something" and everything else; we say that the branch tracks "branch <something>" if it begins with "refs/heads/", and otherwise the branch tracks "ref refs/<someother>/<something>"; - report the name of the remote when we talk about a tracking branch, by saying "branch frotz from origin"; - not say "by merging" at the end; it is the default and is not worth reporting. Signed-off-by: Junio C Hamano <junio@pobox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-03Make git-clone respect branch.autosetuprebaseLibravatar Junio C Hamano1-16/+33
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: Junio C Hamano <gitster@pobox.com>
2009-02-13Teach the "@{-1} syntax to "git branch"Libravatar Junio C Hamano1-5/+14
This teaches the new "@{-1} syntax to refer to the previous branch to "git branch". After looking at somebody's faulty patch series on a topic branch too long, if you decide it is not worth merging, you can just say: $ git checkout master $ git branch -D @{-1} to get rid of it without having to type the name of the topic you now hate so much for wasting a lot of your time. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-10-21Merge branch 'jc/maint-co-track'Libravatar Junio C Hamano1-1/+3
* jc/maint-co-track: Enhance hold_lock_file_for_{update,append}() API demonstrate breakage of detached checkout with symbolic link HEAD Fix "checkout --track -b newbranch" on detached HEAD Conflicts: builtin-commit.c
2008-10-17Fix "checkout --track -b newbranch" on detached HEADLibravatar Junio C Hamano1-1/+3
The test to make sure that checkout fails when --track was asked for and we cannot set up tracking information in t7201 was wrong, and it turns out that the implementation for that feature itself was buggy. This fixes it. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-10-03builtin-commit: use reduce_heads() only when appropriateLibravatar Miklos Vajna1-0/+1
Since commit 6bb6b034 (builtin-commit: use commit_tree(), 2008-09-10), builtin-commit performs a reduce_heads() unconditionally. However, it's not always needed, and in some cases even harmful. reduce_heads() is not needed for the initial commit or for an "ordinary" commit, because they don't have any or have only one parent, respectively. reduce_heads() must be avoided when 'git commit' is run after a 'git merge --no-ff --no-commit', otherwise it will turn the non-fast-forward merge into fast-forward. For the same reason, reduce_heads() must be avoided when amending such a merge commit. To resolve this issue, 'git merge' will write info about whether fast-forward is allowed or not to $GIT_DIR/MERGE_MODE. Based on this info, 'git commit' will only perform reduce_heads() when it's committing a merge and fast-forward is enabled. Also add test cases to ensure that non-fast-forward merges are committed and amended properly. Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2008-07-13Move MERGE_RR from .git/rr-cache/ into .git/Libravatar Johannes Schindelin1-1/+1
If you want to reuse the rerere cache in another repository, and set a symbolic link to it, you do not want to have the two repositories interfer with each other by accessing the _same_ MERGE_RR. For example, if you use contrib/git-new-workdir to set up a second working directory, and you have a conflict in one working directory, but commit in the other working directory first, the wrong "resolution" will be recorded. The easy solution is to move MERGE_RR out of the rr-cache/ directory, which also corresponds with the notion that rr-cache/ contains cached resolutions, not some intermediate temporary states. Noticed by Kalle Olavi Niemitalo. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-11Allow tracking branches to set up rebase by default.Libravatar Dustin Sallings1-1/+21
Change cd67e4d4 introduced a new configuration parameter that told pull to automatically perform a rebase instead of a merge. This change provides a configuration option to enable this feature automatically when creating a new branch. If the variable branch.autosetuprebase applies for a branch that's being created, that branch will have branch.<name>.rebase set to true. Signed-off-by: Dustin Sallings <dustin@spy.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-19branch: optionally setup branch.*.merge from upstream local branchesLibravatar Jay Soffian1-20/+24
"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: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-09Move code to clean up after a branch change to branch.cLibravatar Daniel Barkalow1-0/+8
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
2008-02-09Move create_branch into a library fileLibravatar Daniel Barkalow1-0/+140
You can also create branches, in exactly the same way, with checkout -b. This introduces branch.{c,h} library files for doing porcelain-level operations on branches (such as creating them with their appropriate default configuration). Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>