Thanks a lot ! It is kind of two step dance. Is it possible to implement it in more simple fashion ? Click branch icon, dialog displays: first line SHA1 of commit(default to selected with ability to select different, not current HEAD which is not even changebale, second line name of the new branch (you can type there) ? At the end it is just one line in git:
git branch <name> <SHA1>
In practice though, it's still a 2-step process on the command line too:
git branch <name> <SHA> git checkout <name>
The only time it isn't is if you want to create a branch on a SHA and not check it out, but does anyone do that? As opposed to creating a tag where it's common.
I thought the whole point of UI is USABILITY and USER FRIENDLINESS. Everyone has different wotkflows and at the end of the day command line is still an option. But even in your last reply the sequence of events is DIFFERENT from what you need to do in Sourcetree.
sourcetree: checkout commit (and deal with detached HEAD and get presented with dialog box), create branch
git: create branch, possibly checkout
> but does anyone do that?
1. Have staged, modified files which are not ready to get commited (stashing is not an option)
2. Need to create several branches as project maintenance exercise
Also, what the point to have a first line (if you can not change it) in Branch dialog box displaying checked out branch, if I can see it in a views (as bold in list and in a sidebar with checked mark) ???
It's all about usability. Anyway, thanks for your reply.
Sure - my point was simply to illustrate that it's currently no more steps than git command line in the typical case, since that's what you'd compared it to. I was genuinely interested whether people actually create a branch like this without checking it out - I know I never do, since the only point of creating a new branch is to start commiting to it (otherwise it's really just a tag). I suppose you could create it with the intention of committing to it another time, but then why bother doing it now? These are genuine questions that I ask not to dismiss the need to support it, but to understand precisely why it's needed and in what use cases - that's the best way to deliver the right solution in my experience.
I've added a feature request anyway: https://jira.atlassian.com/browse/SRCTREE-1020
Appreciate it !
But my point is, if it will be in like you say sequence: 1. Create Branch and 2. Check it out (even in one transaction) -- then it will be more LOGICAL and INTUITIVE. Currently you MUST check it out first which does not imply you are doing it just in order to create a new branch. You can do check out for any other reason (rebasing as an example).
When I'm working on a project, sometimes I plan ahead and create several branches at the time on which I will work in near future, helps me to see a big picture.
Agreed, this is not a big issue, but a nice user friendly addition. Especially for people new to a git. It is not currently obvious how to do it, that is why I asked this question at the first place :)
I guess 'intuitive' depends on your previous experiences; for whatever reason I've always thought of it from a point of view of check out then branch - maybe because I'd usually encounter this scenario when doing a hotfix or similar from a previous release point, and I'd reproduce the problem case first by checking it out, then branching when I realised there was something to fix. I've used lots of systems back to old CVS and this was always my habit, maybe that's just my grey hair talking ;)
Anyhow, it's on the list for those who think of it the other way around :)
Last week Megan Cook, Head of Jira Software and Mahreen Khan, PhD, Organizational Psychology hosted an “ask me anything” session focused on the psychology of agile teams. We received 22 questions, 16...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events