Community
Participate
Working Groups
I will add these actions and do some re-wording of the branch/remote related stuff in RC2.
Created attachment 197797 [details] Mockup with some wording changes My point on the call yesterday was to make using Git easier for people who are not familiar with it. So "Git Status" action would be replaced with something obvious for all developers "Manage Your Changes" or just "Change Management". It would take you to our Git Status page where we could "Stage Changes", but perhaps we should add a message on the page saying "This is a Git managed project, before you share your changes you need to stage and create local commit". Then we have "Share Commits Now" which would share our changes immediately. But you could also go to the Full Log and see details etc. Then on the Full Log page you could share changes too. Since we agreed to leave the Git wording on our pages, i would use "Push Commits Now" instead of "Share Commits Now". And it should be clear on the Git Status page what is the order of actions there i.e. stage -> commit -> share/push
Since I was the one yesterday who pushed back, I should probably comment: (In reply to comment #2) > My point on the call yesterday was to make using Git easier for people who are > not familiar with it. I don't think you are helping users who are not familiar with Git by using names that don't map to anything in the existing Git documentation, books, or online tutorials. > So "Git Status" action would be replaced with something > obvious for all developers "Manage Your Changes" or just "Change Management". But as a user, it is important to know which version control system is being used. I would rather see "Git" or "Team Concert" in the menu so that I can know what to expect when clicking on the link. > It would take you to our Git Status page where we could "Stage Changes", but > perhaps we should add a message on the page saying "This is a Git managed > project, before you share your changes you need to stage and create local > commit". Adding commentary like this is probably a good idea. Maybe there is also something visual that can be done to show that local changes have to be staged before you can commit them, etc. >Then we have "Share Commits Now" which would share our changes > immediately. But you could also go to the Full Log and see details etc. Then on > the Full Log page you could share changes too. Like I said above, it is important that actions map directly to terms used in Git so that you can ask a Git expert for help instead of having to ask someone who knows Orion and Git. But the idea of having a button on the git status page that covers the easy cases, with potentially more options available on the page that shows the complete log, makes sense to me. This is exactly what I am asking for. > Since we agreed to leave the Git wording on our pages, i would use "Push > Commits Now" instead of "Share Commits Now". Yes (although I think just "Push" would be sufficient). > And it should be clear on the Git Status page what is the order of actions > there i.e. stage -> commit -> share/push Yes, I agree, that would be good.
(In reply to comment #3) > >Then we have "Share Commits Now" which would share our changes > > immediately. But you could also go to the Full Log and see details etc. Then on > > the Full Log page you could share changes too. > > Like I said above, it is important that actions map directly to terms used in > Git so that you can ask a Git expert for help instead of having to ask someone > who knows Orion and Git. But the idea of having a button on the git status page > that covers the easy cases, with potentially more options available on the page > that shows the complete log, makes sense to me. This is exactly what I am > asking for. I tried to copy the git Fetch Command and paste it in git-status-table.js. I did a small change (mostly refactor) and made it my local command. I added that command in status page , worked like a charm. As I already have all the branch and remote info , seems that the change will not be big. Seems very doable to me and I will talk to Szymon on Monday to surface the fetch , merge and push commands.
Given that the git commands are not really shared perfectly (e.g. open compare editor ) , I think for 0.2 maybe I can just add these 3 commands locally to git status page(I am afraid changing too much code will affect existing log page , but Szymon knows it better). We can consolidate the git command area post 0.2 . Any objections?
(In reply to comment #5) > Given that the git commands are not really shared perfectly (e.g. open compare > editor ) , I think for 0.2 maybe I can just add these 3 commands locally to git > status page(I am afraid changing too much code will affect existing log page , > but Szymon knows it better). > We can consolidate the git command area post 0.2 . > Any objections? Add your commands to gitCommands.js and I'll find time to look how to merge them with the existing ones.
Having fetch, merge, and push would be enough.
+1 to the current set of changes but that duplication of commands has to be fixed asap.
The initial draft of the code was checked in. You can now fetch , merge and push. I am still working on on polishing it but in order to avoid huge check in I've had Simon review my code . His comments was that the copying of those 3 commands is brutal and we should change that. I will open a new bug for Szymon to customize the existing commands.
(In reply to comment #6) > (In reply to comment #5) > > Given that the git commands are not really shared perfectly (e.g. open compare > > editor ) , I think for 0.2 maybe I can just add these 3 commands locally to git > > status page(I am afraid changing too much code will affect existing log page , > > but Szymon knows it better). > > We can consolidate the git command area post 0.2 . > > Any objections? > > Add your commands to gitCommands.js and I'll find time to look how to merge > them with the existing ones. Szymon , I opened bug 349231 for the merge. Please refer to function exports.createStatusCommands , which is the only function I added in gitCommands.js. I havn't touched anything else in this file.
working on refreshing both mini logs after merge and push action
(In reply to comment #11) > working on refreshing both mini logs after merge and push action I am passing a git status refresh call back to the exports.createStatusCommands function in gitCommands.js. After merge and push is done this call back will refresh the status page. E.g. : 1. if you merge and there are conflicts you will see the conflciting files right away 2.If you merge successfully , you will see both mini logs are updated. 3. If you push successfully , you will see both mini logs are updated.
Had John review the code I mentioned in comment 12. Committed changes at 7e2ac7c56ef1c9a42dfc4c49e3119d9c081d6db4 Szymon , please go ahead for the merging in the gitCommands.js. I will close this bug after your merge.
bug 349231 was targeted to 0.3. Closing this bug now.
