Tuesday, September 22, 2015

Finding a branch point with Git? - Stack Overflow

I have a repository with branches master and A and lots of merge activity between the two. How can I find the commit in my repository when branch A was created based on master?
My repository basically looks like this:
-- X -- A -- B -- C -- D -- F  (master) 
          \     /   \     /
           \   /     \   /
             G -- H -- I -- J  (branch A)
I'm looking for revision A, which is not what git merge-base (--all) finds.
shareimprove this question
up vote229down voteaccepted
I was looking for the same thing, and I found this question. Thank you for asking it!
However, I found that the answers I see here don't seem to quite give the answer you asked for (or that I was looking for) -- they seem to give the G commit, instead of the A commit.
So, I've created the following tree (letters assigned in chronological order), so I could test things out:
A - B - D - F - G   <- "master" branch (at G)
     \   \     /
      C - E --'     <- "topic" branch (still at E)
This looks a little different than yours, because I wanted to make sure that I got (referring to this graph, not yours) B, but not A (and not D or E). Here are the letters attached to SHA prefixes and commit messages (my repo can be cloned from here, if that's interesting to anyone):
G: a9546a2 merge from topic back to master
F: e7c863d commit on master after master was merged to topic
E: 648ca35 merging master onto topic
D: 37ad159 post-branch commit on master
C: 132ee2a first commit on topic branch
B: 6aafd7f second commit on master before branching
A: 4112403 initial commit on master
So, the goal: find B. Here are three ways that I found, after a bit of tinkering:

1. visually, with gitk:

You should visually see a tree like this (as viewed from master):
gitk screen capture from master
or here (as viewed from topic):
gitk screen capture from topic
in both cases, I've selected the commit that is B in my graph. Once you click on it, its full SHA is presented in a text input field just below the graph.

2. visually, but from the terminal:

git log --graph --oneline --all
which shows (assuming git config --global color.ui auto):
output of git log --graph --oneline --all
Or, in straight text:
*   a9546a2 merge from topic back to master
|\  
| *   648ca35 merging master onto topic
| |\  
| * | 132ee2a first commit on topic branch
* | | e7c863d commit on master after master was merged to topic
| |/  
|/|   
* | 37ad159 post-branch commit on master
|/  
* 6aafd7f second commit on master before branching
* 4112403 initial commit on master
in either case, we see the 6aafd7f commit as the lowest common point, i.e. B in my graph, or Ain yours.

3. With shell magic:

You don't specify in your question whether you wanted something like the above, or a single command that'll just get you the one revision, and nothing else. Well, here's the latter:
diff -u <(git rev-list --first-parent topic) \
             <(git rev-list --first-parent master) | \
     sed -ne 's/^ //p' | head -1
6aafd7ff98017c816033df18395c5c1e7829960d
Which you can also put into your ~/.gitconfig as (note: trailing dash is important; thanks Brian for bringing attention to that):
[alias]
    oldest-ancestor = !zsh -c 'diff -u <(git rev-list --first-parent "${1:-master}") <(git rev-list --first-parent "${2:-HEAD}") | sed -ne \"s/^ //p\" | head -1' -
Which could be done via the following (convoluted with quoting) command-line:
git config --global alias.oldest-ancestor '!zsh -c '\''diff -u <(git rev-list --first-parent "${1:-master}") <(git rev-list --first-parent "${2:-HEAD}") | sed -ne "s/^ //p" | head -1'\'' -'
Note: zsh could just as easily have been bash, but sh will not work -- the <() syntax doesn't exist in vanilla sh. (Thank you again, @conny, for making me aware of it in a comment on another answer on this page!)

Note: Alternate version of the above:

Thanks to liori for pointing out that the above could fall down when comparing identical branches, and coming up with an alternate diff form which removes the sed form from the mix, and makes this "safer" (i.e. it returns a result (namely, the most recent commit) even when you compare master to master):
As a .git-config line:
[alias]
    oldest-ancestor = !zsh -c 'diff --old-line-format='' --new-line-format='' <(git rev-list --first-parent "${1:-master}") <(git rev-list --first-parent "${2:-HEAD}") | head -1' -
From the shell:
git config --global alias.oldest-ancestor '!zsh -c '\''diff --old-line-format='' --new-line-format='' <(git rev-list --first-parent "${1:-master}") <(git rev-list --first-parent "${2:-HEAD}") | head -1'\'' -'
So, in my test tree (which was unavailable for a while, sorry; it's back), that now works on both master and topic (giving commits G and B, respectively). Thanks again, liori, for the alternate form.

So, that's what I [and liori] came up with. It seems to work for me. It also allows an additional couple of aliases that might prove handy:
git config --global alias.branchdiff '!sh -c "git diff `git oldest-ancestor`.."'
git config --global alias.branchlog '!sh -c "git log `git oldest-ancestor`.."'
Happy git-ing!
shareimprove this answer
3 
Thanks lindes, the shell option is great for situations where you want to find the branch point of a long running maintenance branch. When you are looking for a revision that might be a thousand commits in the past, the visual options really isn't going to cut it. *8') –  Mark Booth Apr 2 '12 at 15:47
3 
In your third method you depend on that the context will show the first unchanged line. This won't happen in certain edge cases or if you happen to have slightly different requirements (e.g. I need only the one of the histories be --first-parent, and I am using this method in a script that might sometimes use the same branches on both sides). I found it safer to use diff's if-then-else mode and erase changed/deleted lines from its output instead of counting on having big enough context., by: diff --old-line-format='' --new-line-format='' <(git rev-list …) <(git rev-list …)|head -1. –  liori Oct 5 '12 at 14:17
16 
Nowadays there is git merge-base --fork-point ... –  Jakub Narębski Dec 8 '13 at 14:08
2 
diff -U1 <(git rev-list --first-parent topic) <(git rev-list --first-parent master) | tail -1 . By forcing diff context to have only one line, you don't need to grep/sed through it. – Alexander Bird Dec 12 '14 at 22:13
2 
@JakubNarębski @lindes --fork-point is based on the reflog, so it will only work if you made the changes locally. Even then, the reflog entries could have expired. It's useful but not reliable at all. –  DanielJun 19 at 23:49
You may be looking for git merge-base:
git merge-base finds best common ancestor(s) between two commits to use in a three-way merge. One common ancestor is better than another common ancestor if the latter is an ancestor of the former. A common ancestor that does not have any better common ancestor is a best common ancestor, i.e. a merge base. Note that there can be more than one merge base for a pair of commits.
shareimprove this answer
6 
Note also the --all option to "git merge-base" –  Jakub Narębski Oct 6 '09 at 21:49
6 
This doesn't answer the original question, but most people asking the much simpler question for which this is the answer :) –  FelipeC Apr 23 '12 at 23:19
2 
he said he didn't wan't the result of git merge-base –  Tom Tanner Mar 20 '13 at 17:31
5 
@TomTanner: I just looked at the question history and the original question was edited to include that note about git merge-base five hours after my answer was posted (probably in response to my answer). Nevertheless, I will leave this answer as is because it may still be useful for somebody else who finds this question via search. –  Greg Hewgill Mar 20 '13 at 18:24
6 
Nowadays there is git merge-base --fork-point ... –  Jakub Narębski Dec 8 '13 at 14:07
I've used git rev-list for this sort of thing. For example,
$ git rev-list --boundary branch-a...master | grep ^- | cut -c2-
will spit out the branch point. Now, it's not perfect; since you've merged master into branch A a couple of times, that'll split out a couple possible branch points (basically, the original branch point and then each point at which you merged master into branch A). However, it should at least narrow down the possibilities.
I've added that command to my aliases in ~/.gitconfig as:
[alias]
    diverges = !sh -c 'git rev-list --boundary $1...$2 | grep ^- | cut -c2-'
so I can call it as:
$ git diverges branch-a master

Thursday, September 17, 2015

SMPP TON and NPI Reference | Aerialink

SMPP TON and NPI Reference | Aerialink: SMPP TON and NPI Reference

Table of Contents
1.
TON (Type of Number)
2.
NPI (Numbering Plan Identification)
3.
TON and NPI Defaults
4.
SMPP Official Specification
5.
Troubleshooting
6.
Support
API Interface: SMPP API Version 3.4
TON (Type of Number)
The Type of Number (TON) setting is used to tell both your EMSE the format of the addressing (bind addressing) that will be processed for inbound messages as well as tell the Aerialink network (source and destination addressing) how it should be processed for submits. There are three separate pairs of TON and NPI values; receiving addressing, source addressing, and destination addressing. These definitions are derived from the ETSI GSM 03.40 specification, which defines the SMS protocol. The SMPP specification defines the following TON values:

If you wish to specific a special value for the TON, the available options are:

0: Unknown
1: International
2: National
3: Network Specific
4: Subscriber Number
5: Alphanumeric
6: Abbreviated
Aerialink does not generally require specific TON values from your bind to our network. We store specific values as defaults for your routes, connections, and communication assets (Short Code, Long Code, Alphanumeric Code). See TON and NPI defaults below.

NPI (Numbering Plan Identification)
The Numbering Plan Identification setting is used to tell both your EMSE the numbering plan associated with your messaging. The SMPP specification defines the following TON values:

If you wish to specific a special value for the NPI, the available options are:

Unknown = 0
ISDN/telephone numbering plan (E163/E164) = 1
Data numbering plan (X.121) = 3
Telex numbering plan (F.69) = 4
Land Mobile (E.212) =6
National numbering plan = 8
Private numbering plan = 9
ERMES numbering plan (ETSI DE/PS 3 01-3) = 10
Internet (IP) = 13
WAP Client Id (to be defined by WAP Forum) = 18
TON and NPI Defaults
Aerialink will generally default both your TON and NPI to the values they should be to insure your messages are delivered properly. If you have special reasons for controlling these settings on your side, please contact the Aerialink Support Team. The default values used by Aerialink are as follows:

Short Code (3 digits to 8 digits in length)
If the source code/address is a Short Code

TON = 3
NPI = 0
Long Code (10 digits to 15 digits in length, excludes the plus sign)
If the source code/address is a Long Code the recommended settings and default settings that Aerialink will use are:

TON = 1
NPI = 1
Alphanumeric
If the source code/address is Alphanumeric (contains both letters and numbers or only letters)

TON = 5
NPI = 0
SMPP Official Specification
For details on the SMPP Specification, see SMPP 3.4 Official Specification.

Troubleshooting
If you are having trouble authenticating with the Aerialink API confirm that you have white listed your IP address and that your API credentials are correct. You can view the API Authentication Error Log under Reports in the APi section of the Platform portal. This will confirm whether your authentication requests are being rejected or not.

Support
If you require any additional assistance, please use one of these methods to contact the Aerialink Support Team.

This page was last updated 1430774692620