The pattern ' origin/*' makes sure we are selecting the remote branches of the right remote repo. The format transforms a remotes/origin/aBranchName into aBranchName. No need to grep origin, sed or sort (unless a branch.sort config had been set): use a pattern and a format: git branch -r -list 'origin/*' -format="%(refname:lstrip=3)" no need to sort git tag: they are already sorted by default by refname, unless a tag.sort config had been set.īut to be on the safe side, use at least git tag -sort="refname" (no | sort needed).(Merged by Junio C Hamano - gitster - in commit d89db6f, ) See commit 560ae1c () by Samuel Maftoul (``). Instead of using | sort, both git tag and git branch have a -sort= option, with based on git for-each-ref field names and using a pattern.īy default, the default sort order, both for branches and tags, is already by refname.Īnd since Git 2.19 (Q3 2018), git branch supports a config branch.sort, like git tag already had a config tag.sort. Since tags don't normally move, their reflogs, if any, tend to be pretty dull: "this tag has always had value 0f39ca43." Branches, however, do move, as we noted above, and their reflogs are full of "where this branch pointed yesterday" and such.Saeedgnu's answer is on the right track, but uses many additional shell commands. The reflog for a branch (or any reference, really) contains all the previous values that reference had, for the last 30 to 90 days or so (the numbers are a little complicated and can be tuned if you like). The command will fail (and return a nonzero status, and normally print a message but you can suppress this) if the name does not exist, and will print out the hash ID if the name does exist.īeware: when you delete a branch name, you also delete its reflog. To find out whether one exists, and if so get its value, use the plumbing command git rev-parse and spell out the full name of the reference. So you can write a script that checks for the existence of refs/heads/ whatever and/or refs/tags/ whatever, and creates or deletes the "other one". The plumbing command to create, delete, or update a reference- reference is the fancy long word for "branch, tag, or other such name"-is git update-ref, and it requires that you spell out refs/heads/X or refs/tags/X every time. These commands are meant to be used from scripts, and hence have very predictable and repeatable behavior, but they tend to require a lot of typing (which is OK, it's the computer doing the typing). To work harder, use Git's so-called plumbing commands. Your choices are to ignore the warning, or work harder to avoid it. Git has very precise-albeit rather convoluted-rules that always pick just one. not because Git will get confused, but because you will. It's generally unwise to have two things whose short form is just X. (There are some exceptions but this is the usual rule.) When it tells you about a tag name, it strips off the leading refs/tags/. When Git tells you about a branch name, it strips off the leading refs/heads/. The parent commit refers to its own parent, and so on and this is the history of the branch. That commit then refers back to its parent commit, which probably used to be the tip of the branch. In fact, that's precisely how Git knows which commits are on the branch: the branch name X, which is really refs/heads/X, identifies the specific commit that is the tip of the branch. as a rule, a tag name should never change which hash ID it names, but a branch name normally does change over time, in a well-defined way: it always points to the latest commit added to the branch.the full name of branch X is refs/heads/X.There's really very little difference between a branch name like X and a tag name like X. A branch or tag name is in part just a short, human-readable name for one of those big ugly Git hash IDs you have seen.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |