Welcome to Software Development on Codidact!
Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.
Post History
This isn't specific to git merge. The standard Git behaviour is that any content- or history-changing command operates on the current branch. For example, you cannot git commit to a branch other th...
Answer
#3: Post edited
This isn't specific to `git merge`. The standard Git behaviour is that **any** command which makes changes to content operates on the current branch. For example, you cannot `git commit` to a branch other than the current one. It is possible to delete a non-checked-out branch using `git branch -d`, but deleting a branch doesn't actually make changes to content, it is just removing the reference to the branch HEAD so that a subsequent garbage collection can clean up the unreferenced commits.- A Git developer would be needed to confirm the canonical reason for this design, but I can think of a couple of likely reasons:
- 1. Having a consistent, well-understood interface is generally a good thing. Every developer understands that when they edit a source file, they are making changes to the current working copy, not to some other copy on a different branch. It is therefore easy to understand that VCS commands also write their changes into the current branch or working copy.
- 1. Many (perhaps all) changes to content involve using a local staging area called the [Git Index](https://www.geeksforgeeks.org/git-index/), and there is only a single index which reflects changes to the current checked out branch. There is no concept of "the index for branch X".
- 2. Many commands (especially `merge`) can fail, and require the user to resolve conflicts by editing text and committing it. This requires the checked out files to reflect what is about to be committed so that the user can make the necessary edits. It's not clear how editing before commit would work if the destination of the merge wasn't actually checked out to begin with; perhaps the merge would have to simply fail with an error.
None of these issues would be dealbreakers if there was a genuine need for a "merge to" feature, but if the only benefit of such a feature is saving a couple of command-line branch switch operations, it's probably not worth the development time.
- This isn't specific to `git merge`. The standard Git behaviour is that **any** content- or history-changing command operates on the current branch. For example, you cannot `git commit` to a branch other than the current one.[^1]
- A Git developer would be needed to confirm the canonical reason for this design, but I can think of a couple of likely reasons:
- 1. Having a consistent, well-understood interface is generally a good thing. Every developer understands that when they edit a source file, they are making changes to the current working copy, not to some other copy on a different branch. It is therefore easy to understand that VCS commands also write their changes into the current branch or working copy.
- 1. Many (perhaps all) changes to content involve using a local staging area called the [Git Index](https://www.geeksforgeeks.org/git-index/), and there is only a single index which reflects changes to the current checked out branch. There is no concept of "the index for branch X".
- 2. Many commands (especially `merge`) can fail, and require the user to resolve conflicts by editing text and committing it. This requires the checked out files to reflect what is about to be committed so that the user can make the necessary edits. It's not clear how editing before commit would work if the destination of the merge wasn't actually checked out to begin with; perhaps the merge would have to simply fail with an error.
- None of these issues would be dealbreakers if there was a genuine need for a "merge to" feature, but if the only benefit of such a feature is saving a couple of command-line branch switch operations, it's probably not worth the development time.
- [^1]: It is possible to **delete** a non-checked-out branch using `git branch -d`, but deleting a branch doesn't actually delete any commits, it just removes the reference to the branch HEAD so that a subsequent garbage collection can clean up the unreferenced commits. Besides, deleting the checked-out branch would probably leave the working copy in a weird state, so this has to operate on a different branch.
#2: Post edited
- This isn't specific to `git merge`. The standard Git behaviour is that **any** command which makes changes to content operates on the current branch. For example, you cannot `git commit` to a branch other than the current one. It is possible to delete a non-checked-out branch using `git branch -d`, but deleting a branch doesn't actually make changes to content, it is just removing the reference to the branch HEAD so that a subsequent garbage collection can clean up the unreferenced commits.
- A Git developer would be needed to confirm the canonical reason for this design, but I can think of a couple of likely reasons:
1. Having a consistent, well-understood interface is generally a good thing.- 1. Many (perhaps all) changes to content involve using a local staging area called the [Git Index](https://www.geeksforgeeks.org/git-index/), and there is only a single index which reflects changes to the current checked out branch. There is no concept of "the index for branch X".
- 2. Many commands (especially `merge`) can fail, and require the user to resolve conflicts by editing text and committing it. This requires the checked out files to reflect what is about to be committed so that the user can make the necessary edits. It's not clear how editing before commit would work if the destination of the merge wasn't actually checked out to begin with; perhaps the merge would have to simply fail with an error.
- None of these issues would be dealbreakers if there was a genuine need for a "merge to" feature, but if the only benefit of such a feature is saving a couple of command-line branch switch operations, it's probably not worth the development time.
- This isn't specific to `git merge`. The standard Git behaviour is that **any** command which makes changes to content operates on the current branch. For example, you cannot `git commit` to a branch other than the current one. It is possible to delete a non-checked-out branch using `git branch -d`, but deleting a branch doesn't actually make changes to content, it is just removing the reference to the branch HEAD so that a subsequent garbage collection can clean up the unreferenced commits.
- A Git developer would be needed to confirm the canonical reason for this design, but I can think of a couple of likely reasons:
- 1. Having a consistent, well-understood interface is generally a good thing. Every developer understands that when they edit a source file, they are making changes to the current working copy, not to some other copy on a different branch. It is therefore easy to understand that VCS commands also write their changes into the current branch or working copy.
- 1. Many (perhaps all) changes to content involve using a local staging area called the [Git Index](https://www.geeksforgeeks.org/git-index/), and there is only a single index which reflects changes to the current checked out branch. There is no concept of "the index for branch X".
- 2. Many commands (especially `merge`) can fail, and require the user to resolve conflicts by editing text and committing it. This requires the checked out files to reflect what is about to be committed so that the user can make the necessary edits. It's not clear how editing before commit would work if the destination of the merge wasn't actually checked out to begin with; perhaps the merge would have to simply fail with an error.
- None of these issues would be dealbreakers if there was a genuine need for a "merge to" feature, but if the only benefit of such a feature is saving a couple of command-line branch switch operations, it's probably not worth the development time.
#1: Initial revision
This isn't specific to `git merge`. The standard Git behaviour is that **any** command which makes changes to content operates on the current branch. For example, you cannot `git commit` to a branch other than the current one. It is possible to delete a non-checked-out branch using `git branch -d`, but deleting a branch doesn't actually make changes to content, it is just removing the reference to the branch HEAD so that a subsequent garbage collection can clean up the unreferenced commits. A Git developer would be needed to confirm the canonical reason for this design, but I can think of a couple of likely reasons: 1. Having a consistent, well-understood interface is generally a good thing. 1. Many (perhaps all) changes to content involve using a local staging area called the [Git Index](https://www.geeksforgeeks.org/git-index/), and there is only a single index which reflects changes to the current checked out branch. There is no concept of "the index for branch X". 2. Many commands (especially `merge`) can fail, and require the user to resolve conflicts by editing text and committing it. This requires the checked out files to reflect what is about to be committed so that the user can make the necessary edits. It's not clear how editing before commit would work if the destination of the merge wasn't actually checked out to begin with; perhaps the merge would have to simply fail with an error. None of these issues would be dealbreakers if there was a genuine need for a "merge to" feature, but if the only benefit of such a feature is saving a couple of command-line branch switch operations, it's probably not worth the development time.