Re: Bug Report
- From
Eric N. Vander Weele <ericvw@gmail.com>
- Date
- Apr 3, 2016, 02:20 UTC
- Message-ID
- <CAGhVqYthSWCqXW2=3dSUweZ2hqTRSHJiHGNWsmQxUxtmAbnzYw@mail.gmail.com>
- In-Reply-To
- <04bf01d18d3f$4ce38410$e6aa8c30$@u.northwestern.edu>
On Sat, Apr 2, 2016 at 8:25 PM, Benjamin Sandeen <benjaminsandeen2016@u.northwestern.edu> wrote:
> Today, I managed to create a duplicate branch in a git repository. While > this may not be a bug per se, I do think that it is confusing and some way > of preventing such issues in the future may be helpful.
This can be confusing. I'll hopefully try to help and explain below.
Show 7 quoted lines
> I first cloned the repository: > > $ git clone https://github.com/CodeForChicago/superclass.git > > Then, I created a new branch (or so I thought): > > $ git checkout -b lesson_page
At this point, you created a *local* branch called 'lesson_page' which points to the current HEAD and then switched to that branch . This local branch is independent of the remote branch called 'origin/lesson_page'.
Show 17 quoted lines
> However, this branch has already existed for about 4 weeks, without my > knowledge. I proceeded to do some work on the files it contained, and when > it came time to commit and push, and when I pushed, I got the following > message: > > To https://github.com/CodeForChicago/superclass.git > ! [rejected] lesson_page -> lesson_page (non-fast-forward) > error: failed to push some refs to ' > https://github.com/CodeForChicago/superclass.git' > hint: Updates were rejected because the tip of your current branch is behind > hint: its remote counterpart. Integrate the remote changes (e.g. > hint: 'git pull ...') before pushing again. > hint: See the 'Note about fast-forwards' in 'git push --help' for details. > > Given that I had believed that I had created the branch just a few hours > prior and was the first to attempt to push to it, this error was > consternating.
The non-fast-forward push is preventing history being rewritten- this is a good thing :).
Show 10 quoted lines
> I may be wrong (I am aware that my understanding of git is limited), but I > believe that the git checkout -b command is simply supposed to create a new > branch and then switch to it (I'm not aware of any subtle behavior that goes > on behind the scenes if the "new" branch that the user is attempting to > create already exists). This is why I said it "may not be a bug per se". > However, I expect most people who use git to expect this command to create a > new branch and then switch to it (this is what most sources online will tell > users to do to create a new branch), and as such, it would be extremely > beneficial if git were to, at the very least, alert the user to the conflict > in some way or another.
The `git checkout -b` command is working as expected. `git checkout -b <name>` is equivalent to `git branch <name> && git checkout <name>`. If you were to execute `git checkout lesson_page`, you would get the desired behavior you were expecting because in the presence of one remote, git will actually execute `git checkout -b lesson_page --track origin/lesson_page` - more details can be found in `git help checkout`. Effectively, it checkouts 'origin/lesson_page' as a new local branch named 'lesson_page'.
However, you indicated that you did not know there was a remote branch already named 'lesson_page'. After cloning the repository, you can use `git branch -a` to see all remotes to determine which form of `git checkout` to use.
Show 17 quoted lines
> Thanks, > Ben > > Lead Consultant, Northwestern University Information Technology > Research Assistant, Center for Interdisciplinary Exploration and Research in > Astrophysics at Northwestern University > Phsyics, Weinberg College of Arts and Sciences > Computer Science, Weinberg College of Arts and Sciences > Classics, Weinberg College of Arts and Sciences > > > > > -- > To unsubscribe from this list: send the line "unsubscribe git" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html