Software Development

#5: Post edited by

hkotsubo‭ · 2023-08-09T14:50:04Z (9 months ago)

Copy Link

Raw

Markdown

I can't speak for the people who designed it, but I guess it was made this way because you can merge multiple branches all at once.
Let's say I've created multiple branches:
```none
C---D => b1
/
/ E---F => b2
| /
A--B--G--H => master
\
I---J => b3
```
And I want to merge branches b1, b2 and b3 onto master. All I need to do is:
```bash
git checkout master
git merge b1 b2 b3
```
As long as there are no conflicts, all will be merged.
Of course I could merge one by one (first `git merge b1`, then `git merge b2` etc), but in this case, each merge will create another commit. If I merge all in one single command, only one commit will be created. Something like this:
```none
C-------D
/ |
/ E---F |
| / \ |
A--B--G--H---K => master
\ |
I--------J
```
> In this case, commit K will have four parent commits: D, F, H and J.
If the command was designed the opposite way, there would be no way to merge all at once. Well, maybe they could add a command line option to include more sources, but that would be confusing IMO. I think the current way is more clear and straightforward: you provide a list of source branches, and they'll all be merged onto the current branch.
I admit, though, this is not a common case, at least in my experience. I myself rarely needed to merge two or more source branches at the same time. But the functionality exists, and is a good reason to keep the command this way, IMO.
But as I said, I can't tell for sure (only guess) if this was the reason to design the command this way. Maybe it was the other way around: first they decided that the current branch is the destination, and then realized that the command could be improved to merge multiple branches. Who knows?

I can't speak for the people who designed it, but I guess it was made this way because you can merge multiple branches all at once.
Let's say I've created multiple branches:
```none
C---D => b1
/
/ E---F => b2
| /
A--B--G--H => master
\
I---J => b3
```
And I want to merge branches b1, b2 and b3 onto master. All I need to do is:
```bash
git checkout master
git merge b1 b2 b3
```
As long as there are no conflicts, all will be merged.
Of course I could merge one by one (first `git merge b1`, then `git merge b2` etc), but in this case, each merge will create another commit. If I merge all in one single command, only one commit will be created. Something like this:
```none
C-------D
/ |
/ E---F |
| / \ |
A--B--G--H---K => master
\ |
I--------J
```
> In this case, commit K will have four parent commits: D, F, H and J.
If the command was designed the opposite way, there would be no way to merge all at once. Well, maybe they could add a command line option to include more sources, but that would be confusing IMO. I think the current way is more clear and straightforward: you provide a list of source branches, and they'll all be merged onto the current branch.
I admit, though, this is not a common case, at least in my experience. I myself rarely needed to merge two or more source branches at the same time. But the functionality exists, and is a good reason to keep the command this way, IMO.
But as I said, I can't tell for sure (only guess) if this was the reason to design the command this way. Maybe it was the other way around: first they decided that the current branch is the destination (because [that would follow a general design principle](/posts/289289/289308#answer-289308)), and then realized that the command could be improved to merge multiple branches. Who knows?

#4: Post edited by

hkotsubo‭ · 2023-08-08T18:54:36Z (9 months ago)

Copy Link

Raw

Markdown

I can't speak for the people who designed it, but I guess it was made this way because you can merge multiple branches all at once.
Let's say I've created multiple branches:
```none
C---D => b1
/
/ E---F => b2
| /
A--B--G--H => master
\
I---J => b3
```
And I want to merge branches b1, b2 and b3 onto master. All I need to do is:
```bash
git checkout master
git merge b1 b2 b3
```
As long as there are no conflicts, all will be merged.
Of course I could merge one by one (first `git merge b1`, then `git merge b2` etc), but in this case, each merge will create another commit. If I merge all in one single command, only one commit will be created. Something like this:
```none
C-------D
/ |
/ E---F |
| / \ |
A--B--G--H---K => master
\ |
I--------J
```
> In this case, commit K will have four parent commits: D, F, H and J.
If the command was designed the opposite way, there would be no way to merge all at once. Well, maybe they could add a command line option to include more sources, but that would be confusing IMO. I think the current way is more clear and straightforward.
But as I said, I can't tell for sure (only guess) if this was the reason to design the command this way. Maybe it was the other way around: first they decided that the current branch is the destination, and then realized that the command could be improved to merge multiple branches. Who knows?

I can't speak for the people who designed it, but I guess it was made this way because you can merge multiple branches all at once.
Let's say I've created multiple branches:
```none
C---D => b1
/
/ E---F => b2
| /
A--B--G--H => master
\
I---J => b3
```
And I want to merge branches b1, b2 and b3 onto master. All I need to do is:
```bash
git checkout master
git merge b1 b2 b3
```
As long as there are no conflicts, all will be merged.
Of course I could merge one by one (first `git merge b1`, then `git merge b2` etc), but in this case, each merge will create another commit. If I merge all in one single command, only one commit will be created. Something like this:
```none
C-------D
/ |
/ E---F |
| / \ |
A--B--G--H---K => master
\ |
I--------J
```
> In this case, commit K will have four parent commits: D, F, H and J.
If the command was designed the opposite way, there would be no way to merge all at once. Well, maybe they could add a command line option to include more sources, but that would be confusing IMO. I think the current way is more clear and straightforward: you provide a list of source branches, and they'll all be merged onto the current branch.
I admit, though, this is not a common case, at least in my experience. I myself rarely needed to merge two or more source branches at the same time. But the functionality exists, and is a good reason to keep the command this way, IMO.
But as I said, I can't tell for sure (only guess) if this was the reason to design the command this way. Maybe it was the other way around: first they decided that the current branch is the destination, and then realized that the command could be improved to merge multiple branches. Who knows?

#3: Post edited by

hkotsubo‭ · 2023-08-08T18:49:28Z (9 months ago)

Copy Link

Raw

Markdown

I can't speak for the people who designed it, but I guess it was made this way because you can merge multiple branches all at once.
Let's say I've created multiple branches:
```none
C---D => b1
/
/ E---F => b2
| /
A--B--G--H => master
\
I---J => b3
```
And I want to merge branches b1, b2 and b3 onto master. All I need to do is:
```bash
git checkout master
git merge b1 b2 b3
```
As long as there are no conflicts, all will be merged.
Of course I could merge one by one (first `git merge b1`, then `git merge b2` etc), but in this case, each merge will create another commit. If I merge all in one single command, only one commit will be created. Something like this:
```none
C-------D
/ |
/ E---F |
| / \ |
A--B--G--H---K => master
\ |
I--------J
```
If the command was designed the opposite way, there would be no way to merge all at once. Well, maybe they could add a command line option to include more sources, but that would be confusing IMO. I think the current way is more clear and straightforward.
But as I said, I can't tell for sure (only guess) if this was the reason to design the command this way. Maybe it was the other way around: first they decided that the current branch is the destination, and then realized that the command could be improved to merge multiple branches. Who knows?

I can't speak for the people who designed it, but I guess it was made this way because you can merge multiple branches all at once.
Let's say I've created multiple branches:
```none
C---D => b1
/
/ E---F => b2
| /
A--B--G--H => master
\
I---J => b3
```
And I want to merge branches b1, b2 and b3 onto master. All I need to do is:
```bash
git checkout master
git merge b1 b2 b3
```
As long as there are no conflicts, all will be merged.
Of course I could merge one by one (first `git merge b1`, then `git merge b2` etc), but in this case, each merge will create another commit. If I merge all in one single command, only one commit will be created. Something like this:
```none
C-------D
/ |
/ E---F |
| / \ |
A--B--G--H---K => master
\ |
I--------J
```
> In this case, commit K will have four parent commits: D, F, H and J.
If the command was designed the opposite way, there would be no way to merge all at once. Well, maybe they could add a command line option to include more sources, but that would be confusing IMO. I think the current way is more clear and straightforward.
But as I said, I can't tell for sure (only guess) if this was the reason to design the command this way. Maybe it was the other way around: first they decided that the current branch is the destination, and then realized that the command could be improved to merge multiple branches. Who knows?

#2: Post edited by

hkotsubo‭ · 2023-08-08T18:46:59Z (9 months ago)

Copy Link

Raw

Markdown

I can't speak for the people who designed it, but I guess it was made this way because you can merge multiple branches all at once.
Let's say I've created multiple branches:
```none
C---D => b1
/
/ E---F => b2
| /
A--B--G--H => master
\
I---J => b3
```
And I want to merge branches b1, b2 and b3 onto master. All I need to do is:
```bash
git checkout master
git merge b1 b2 b3
```
As long as there are no conflicts, all will be merged.
Of course I could merge one by one (first `git merge b1`, then `git merge b2` etc), but in this case, each merge will create another commit. If I merge all in one single command, only one commit will be created. Something like this:
```none
C-------D
/ |
/ E---F |
| / \ |
A--B--G--H---K => master
\ |
I--------J
```
If the command was designed the opposite way, there would be no way to merge all at once. Well, maybe they could add a command line option to include more sources, but that would be confusing IMO. I think the current way is more clear and straightforward.
But as I said, I can't tell for sure (only guess) if this was the reason to design the command this way, or it was the other way around (first they decided that the current branch is the destination, and then realized that it could be improved to merge multiple branches).

I can't speak for the people who designed it, but I guess it was made this way because you can merge multiple branches all at once.
Let's say I've created multiple branches:
```none
C---D => b1
/
/ E---F => b2
| /
A--B--G--H => master
\
I---J => b3
```
And I want to merge branches b1, b2 and b3 onto master. All I need to do is:
```bash
git checkout master
git merge b1 b2 b3
```
As long as there are no conflicts, all will be merged.
Of course I could merge one by one (first `git merge b1`, then `git merge b2` etc), but in this case, each merge will create another commit. If I merge all in one single command, only one commit will be created. Something like this:
```none
C-------D
/ |
/ E---F |
| / \ |
A--B--G--H---K => master
\ |
I--------J
```
If the command was designed the opposite way, there would be no way to merge all at once. Well, maybe they could add a command line option to include more sources, but that would be confusing IMO. I think the current way is more clear and straightforward.
But as I said, I can't tell for sure (only guess) if this was the reason to design the command this way. Maybe it was the other way around: first they decided that the current branch is the destination, and then realized that the command could be improved to merge multiple branches. Who knows?

#1: Initial revision by

hkotsubo‭ · 2023-08-08T18:44:39Z (9 months ago)

Copy Link

Raw

Markdown

I can't speak for the people who designed it, but I guess it was made this way because you can merge multiple branches all at once.

Let's say I've created multiple branches:

```none
       C---D   =>  b1
      /    
     /  E---F  =>  b2
     | /   
  A--B--G--H   =>  master
     \
      I---J    =>  b3
```

And I want to merge branches b1, b2 and b3 onto master. All I need to do is:

```bash
git checkout master
git merge b1 b2 b3
```

As long as there are no conflicts, all will be merged.

Of course I could merge one by one (first `git merge b1`, then `git merge b2` etc), but in this case, each merge will create another commit. If I merge all in one single command, only one commit will be created. Something like this:

```none
       C-------D
      /        |
     /  E---F  |
     | /     \ |
  A--B--G--H---K  =>  master
     \         |
      I--------J
```


If the command was designed the opposite way, there would be no way to merge all at once. Well, maybe they could add a command line option to include more sources, but that would be confusing IMO. I think the current way is more clear and straightforward.

But as I said, I can't tell for sure (only guess) if this was the reason to design the command this way, or it was the other way around (first they decided that the current branch is the destination, and then realized that it could be improved to merge multiple branches).

Communities

Post History