Browse Repository (Chapter 3)

[rthorp]

I am starting to update this chapter.

Any questions I have will be posted here.

[rthorp]

My first question:

While looking in the code repo, directory GitUI/Resources/Icons for the Refresh icon, I noticed there was an icon called arrow_refresh_dirty.png. I have never seen the 'dirty' icon. Under what conditions is this icon displayed instead of the normal Refresh icon? Do you have to do command line Git operations that affect the commit history (ie outside of the GitExt GUI)?

[jbialobr]

Do you have checked setting: Git Extensions -> Use FileSystemWatcher to check if index is changed? You can run another GitExtensions instance and do some actions that affects repository (commit, stash), then go back to the first instance and you should see dirty icon.

[rthorp]

No I didn't have that setting checked, but when I do, it behaves as you said. Thanks.

[rthorp]

Can you please give me more detail about the following button on the toolbar?

As the doc repo doesnt have submodules, I can't really see what happens when you click this button. What does this button do (the tooltip says Go to superproject)? What does that mean?

[jbialobr]

Clone main code repo. There are two submoduls: doc and tests. When you are on submodule project then you can click on this button and it will take you to the superproject.

[rthorp]

Questions about the Pull etc buttons on the toolbar.

1. if doing a merge or a rebase, you must first have the local branch checked out and this local branch must have a remote tracking branch. Is this correct?

2. on my local repo, I have two remotes defined (Origin and Upstream). If I do a Fetch All, it fetches from both remotes (as expected). If I just do a Fetch though, it only fetches from Origin ie git command issued is

    "C:\Program Files\Git\bin\git.exe" fetch --progress "origin" 

   What rules are followed by Git Extensions to determine I want to fetch from Origin? How would I set up the default to be Upstream (if it is possible)? I tried opening the Pull dialog, selecting Upstream and doing a fetch, then clicking Fetch from the toolbar again but it still used Origin (I thought it might default to Upstream since that was the last repo I did a fetch from). I notice in the Remotes/Manage Remote repositories dialog that Origin is listed first in my list - is this how the repo for the fetch is determined?

[jbialobr]

1. You have to have the local branch checked out, but it doesn't have to have remote tracking branch - you can choose remote branch on Pull dialog. It is good to have remote tracking branch configured as git uses it as default when remote branch is not explicitly given.
2. The rules are: i) fetch from remote specified for a current branch (git config --get branch..remote). If it is null then ii) fetch from origin if exists, if not then: iii) fetch from remote listed as the second (the first is artificial [All] entry) .

[rthorp]

Maybe I confused you with my question in point 1 above. I know you can choose the branch on the Pull dialog. My question was about clicking the Merge or Rebase item on the dropdown menu next to the toolbar button.

E.g. consider the following:

If I am on my local branch fix/Chapter3 which does not have a remote branch on origin (and therefore is not a tracking branch) and I select Merge from the dropdown menu on the toolbar, I get the following message:

"C:\Program Files\Git\bin\git.exe" pull --progress "origin" 
You asked to pull from the remote 'origin', but did not specify
a branch. Because this is not the default configured remote
for your current branch, you must specify a branch on the command line.
Done

The Pull dialog does not open. Can you confirm this is the correct behaviour ie that if you select Merge or Rebase from the dropdown you must be on a branch that is a local tracking branch for a remote?

[jbialobr]

Can you confirm this is the correct behaviour ie that if you select Merge or Rebase from the dropdown you must be on a branch that is a local tracking branch for a remote?

Yes. This dropdown buttons are only shorthands for common actions:

• Merge - is shorthand for open pull dialog, choose merge option and click ok.
• Rebase - is shorthand for open pull dialog, choose rebase option and click ok.
• and so on. Assuming, if you use one of these shorthands you can not provide additional arguments - defaults are used. For non default actions you have to open Pull dialog and input extra arguments.

[rthorp]

Ok. I understand. Thanks.

[rthorp]

Can you have a quick look at the Toolbar section in the Browse Repository chapter of the doc? I have just uploaded my latest version to RTD at https://testgitext.readthedocs.org/en/latest/browse_repository.html (everything after the Toolbar section is still a work in progress).

This is the level of detail I will be putting in all the chapters I update. It takes me a while since I am not familiar with the code and I haven't used GitExt before (and that is why I ask all the questions :) I have to try everything out to understand how it works.

I put this level of detail in because when I look at a manual I expect things to be explained, so I don't have to guess what a button or a menu item does. Some people are happy to click things and just see what happens; me, I like to know what is going to happen before I do something.

A closer review will also need to be done on the content I add; I may miss certain behaviours for buttons, menu items, dialogs etc because a situation that is coded for does not occur in my test repo (eg the Submodule stuff above).

I appreciate any corrections you have and if you have a better way than just putting corrections in this Issue (eg. me putting my fix/Chapter3 branch on GitHub so you can commit corrections yourself) then let me know.

[jbialobr]

This is the level of detail I will be putting in all the chapters I update. It takes me a while since I am not familiar with the code and I haven't used GitExt before (and that is why I ask all the questions :) I have to try everything out to understand how it works.

Feel free to ask any question, the better you will know GitExt the better doco you will write.

I put this level of detail in because when I look at a manual I expect things to be explained, so I don't have to guess what a button or a menu item does. Some people are happy to click things and just see what happens; me, I like to know what is going to happen before I do something.

Very good.

I appreciate any corrections you have and if you have a better way than just putting corrections in this Issue (eg. me putting my fix/Chapter3 branch on GitHub so you can commit corrections yourself) then let me know.

I created PR - it allows to do comments to changes you commit. I think it will the best way to discuss. If one has chnages ready to commit, then he can push them and create a PR targeted to your repo, that you could review them.

[rthorp]

I understand what you are saying, but I don't ever want my TestDocBuild branch to be merged into latest - it is there purely for testing the build on RTD - it could contain anything! It also gives you (or anybody else) a chance to see what the doco looks like formatted to HTML (it saves you the effort of pulling my changes to a local repo and then running the build_html command if you want to see what it looks like). Reading the source .rst files give you the content, but not the layout of how it looks.

My 'real' branch for Chap3 changes is called fix/Chapter3 and that is on my local repo only. Maybe my understanding of Git branching/merging/pushing etc is not quite right, so maybe you could explain how to resolve the following:

At the moment, on my fix/Chapter3 branch I can do rebases on latest whenever latest is changed, I can also do lots of commits and then do interactive rebases to 'squash' all the commits into one (when I am happy with the current state). I always end up with just one commit branching off latest. When it is ready to merge to latest, I can then push to GitHub and there is only one commit in latest ie history is kept clean.

If I publish this branch to my local GitHub fork, then my understanding is that I can't do rebases any more because the next time I push it wont let me (because I would have changed my local history). So other people could do pushes to my GitHub branch, and I could be pushing numerous 'in-progress' commits. When I finally finish the chapter, this branch would now contain lots of commits instead of just one - merging to latest would now put all of them in the history.

How do you keep the history clean in latest? Is there a way to do a rebase -i when when merging a PR with lots of commits into another branch on GitHub?

[jbialobr]

I see, so the workflow should be as folow:

1. Create branch fix/Chapter3, push it to upstream/origin whichever you prefer to.
2. Create a PR base:latest, head:fix/Chapter3 (to allow discussion)
3. Do as much commits as you need. Do pushes frequently (i.e. daily) - to backup your work
4. Merge latest into fix/Chapter3 to be up to date with latest.
5. When you are finished: 5a) If you want to keep history clean you can click right on latest branch, then choose reset to this revision with soft option and do a single commit then you can push it forced and merge or push it directly to latest. 5b) If you don't want to keep history clean, then just merge it to latest branch. There is no need to keep history clean. All your changes will be showed in a merge commit (when you merge fix/Chapter3 into latest). Browsing history by the most left parents allows you to skip all 'unclean' history.

[jbialobr]

If I publish this branch to my local GitHub fork, then my understanding is that I can't do rebases any more because the next time I push it wont let me (because I would have changed my local history). So other people could do pushes to my GitHub branch, and I could be pushing numerous 'in-progress' commits.

As long as it is only your private fork (you didn't grant direct write access to it) you can rebase pushed branches and push them forced.

[jbialobr]

I would also like to clarify what clean history should mean. For me it is to keep commits atomic with clean message (any unrelated changes should be commited separately). When I will go in the future to blame window to see why one did a given change, then it will be the easier to know the reason the more verbose commits are. Defined as that, it is very difficult to keep the history clean.

[rthorp]

I see what you mean. I was thinking along the lines of just having one commit for a 'feature' so the history is not cluttered with 'in progress' type commits, but I see that having multiple commits for a 'feature' is useful as long as each commit implements a 'unit of work'.

I have seen that 'force' checkbox in GitExt, but have ignored it for now - I will read up on it and see exactly what it does.

(I am coming from a 30+ year old SCM that only allows one person to work on a pgm at a time - you make all your changes and then migrate to Acceptance Test/Prod etc - the only thing the SCM does is move a file from one place to another! You can't imagine the pain we go through when the same programs are changed in different projects - trying to co-ordinate all the changes!).

This is all a great learning experience for me: both Git and GitExtensions and I appreciate your patience.

[jbialobr]

I would be carefull with push forced and rebase, they are destructive actions (the second is less destructive but still). Merge is the safiest action.

(I am coming from a 30+ year old SCM...

Fortunatelly (for you and for us) you found Git.

[jbialobr]

Configuring this dropdown menu will present you with the following configuration options:

This dialog let you to configure repository dropdown list: This list can be divided into most recent and less recent lists (see divider pointed by arrow). In your description you refer to comboboxes shown on dialog form - they are only shown for a preview.

Fixed width set to 120, maximum most recent entries set to 8, shortening strategy set to middle dots:

[rthorp]

Thanks. Have updated this section as per your comments. I was getting confused with the terminology - when I was saying combobox I meant the boxes on the dialog which I think are listboxes, not comboboxes (?) - I don't write Windows software so I am not that familiar with all the controls. I have made it clear the changes are previewed in the listboxes, and then reflected on the toolbar and dropdown menu.

Also, I think the 'Combobox minimum width' setting should say 'maximum width'? If you enter a value of say 100, then regardless of the length of the repository path, the button on the toolbar is 100 (pixels?) wide.

[jbialobr]

Also, I think the 'Combobox minimum width' setting should say 'maximum width'? If you enter a value of say 100, then regardless of the length of the repository path, the button on the toolbar is 100 (pixels?) wide.

It is a bug, I remember that there was no MinimumWidth property for this component and I used Width property and forgot to fix it.

[rthorp]

Raised issue gitextensions/gitextensions/issues/1952 in code repo.

[rthorp]

In the file tree tab in the main Commit log window, the display of the file changes depending on the filetype e.g. a .cmd file shows yellow text on black b/ground, image files (png/gif etc) show the image, JavaScript shows individual highlighting.

Can you tell me what filetypes cause a different display i.e. not just a 'plain text' display? Is it a feature of Git Extensions or of the underlying VS control used to display the file contents?

[jbialobr]

Syntax highlighting is done by ICSharpCode.TextEditor (available only on windows). Supported file formats can be get from here (files with .xshd file extension) https://github.com/KindDragon/ICSharpCode.TextEditor/blob/master/Project/Resources/SyntaxModes.xml

[rthorp]

In the context menu (ie via right mouse click) when displaying a file from the File tree tab or the Diff tab there is a menu option called 'copy patch'. Can you explain what this does? As far as I can tell, it just copies the whole contents of the displayed file to the clipboard. How does this differ from highlighting the whole contents and selecting Copy (or Ctrl-C) from the context menu?

[rthorp]

On the Diff tab, where it says Diff (A: parent --> B: selection), can you tell me which is the 'parent' commit when the selected commit has two parents (e.g. if the selected commit is a merge commit)? Example

Author:     xxxxxxxxxxxxxxxxxxxxxxxxx
Date:       2 weeks ago (Mon Jul 08 13:35:32 2013)
Commit hash:    155823b12e76f360debcb465479055303b8b7f30
Children:   e14e90057e
Parent(s):  37e2e43da8 c57ace33fa

Is the parent commit simply the first one listed or is there some other method of determining it?

[jbialobr]

In the context menu (ie via right mouse click) when displaying a file from the File tree tab or the Diff tab there is a menu option called 'copy patch'. Can you explain what this does? As far as I can tell, it just copies the whole contents of the displayed file to the clipboard. How does this differ from highlighting the whole contents and selecting Copy (or Ctrl-C) from the context menu?

It differes when you select some part of diplayed file that doesn't contain diff header (line starting with @@), then ctrl-c copies selected text without leading speciall git characters ('+','-') but 'copy patch' copies selected text with these speciall characters.

[jbialobr]

Is the parent commit simply the first one listed or is there some other method of determining it?

Yes, it is the first one.

[rthorp]

Thanks @jbialobr (yes I am still working on this chapter!).

[jbialobr]

Great! I am glad I can help you.

[gerhardol]

closing old issue