[OpenAFS-devel] Git/gerrit basics (Windows)

[Jeffrey Altman]

Mickey Lane wrote:
> Understood. If my update gets lost it's not that big a deal. Learning the
> process is the thing here.

If you are looking to fix something real that affects the production
code, please submit to the master branch and not the kdfs branch.

> I'll do
> 
> 	Git checkout origin/master
> 	git pull (since I have not modified anything yet)
> 	git checkout -b my-name-for-fix-1 origin/openafs-windows-kdfs-ifs-branch
> 	Edit 3 or 4 files

you will need a "git add <files>" here

> 	git commit <something TBD wrt the message>
> 	review
> 	git push
> 
> and wait for the outcome of change #1 before doing anything with #2.

There is no need to wait if you use separate branches for each change.
Doing so means they have no dependency on one another.

> General questions wrt "each change in its own branch"
> 
> Suppose the goal is to fix 20 groups of compile warnings in diverse
> parts of the code. Would you create 20 branches? Do these branches
> have a finite lifespan?

Then create 20 branches.  One for each independent change.

Once the change has been accepted for submission by the gatekeepers you
can delete the branch.

> Suppose I create 20 branches, submit the changes and the changes are
> adopted without issue. How does this get cleaned up?

git branch -d <branch>

> If 10 of these groups were say 'signed/unsigned mismatch', could you
> put them under one change even if they were in widely different
> parts of the code?

You can if they are that simple.  Although we prefer one patch per
module (aka directory)

>>> #2
>>>
>>> The phrase "must not end with a full stop" is confusing to Windows
>>> users. (This one anyway)
>> a "full stop" is a period.
> 
> Heh. Sometimes we forget to think of the obvious. I must admit though
> that its been a while since I've seen a period used to end what amounts
> to several paragraphs.

The first line of a git commit is a title.  It should not be a
paragraph.  It should not have a period at the end.  That is the
convention.

>>> If I make a text file (a.txt) with the above as a guide (on Windows,
>>> it'll have <carriage return><line feed>) and supply it to my commit
>>> command (in the bash window from msysGit):
>>>
>>>                 git commit -F a.txt
>> I cannot promise that git will strip the CRs.  If you do not specify
>> -F git.exe will start the default editor with a template file which
>> will be LF only.
> 
> For Windows-only people, using vi (or whatever) is pretty painful.

My default editor is rimstar.  That is what I get prompted with.

> If I make the file using Notepad and the commit becomes corrupted
> as a result of the <carriage return><line feed> situation, is there a
> clean way to fix the mess?

Do not use Notepad.  It can't handle LF only files.  Get a different
editor that you are comfortable with.

> I haven't tried any of this yet. Anyone know what msysGit thinks
> should be the editor? Is there a way to change it to something simple?

I believe it is just what you have configured as the default text
editor in the registry.  It just works for me.  I haven't looked
hard at how it does.  You can always monitor the process with
SysInternals Process Monitor to find out.

> I figured that out. My comment was an attempt to suggest that this is
> not clear to people doing this the 1st time and that some different
> wording might help avoid the confusion.

Propose alternate text and send it to openafs-bugs.  Simon wants to
maintain those documents for a while.

> A footnote or maybe a separate page for Windows users would be a big
> help here. The "~/.." notation is foreign to Windows and there is no
> ~/.ssh directory after a msysGit install & build.

Feel free to contribute one.  I used the instructions that ship with
msysGit.  It was quite clear.

> If, like me, you already have SSH keys, it's not at all clear what
> you're supposed to do with them. Using msysGen, I generated another set
> and discovered where msysGen wants them (it's C:\Documents and
> Settings\<username>\.ssh). It would also be useful to note the use of
> the -C switch to set the user name in the keys since the default
> is login-name@machine-name on a Windows box which almost never equates
> to anything useful.

Again, follow the directions that come with the tools you are using.
It is not our intention to publish a guide to using Git.

> I'm very impressed with the GitDevelopers wiki page. It does a good job
> of giving just the right amount of information. My only complaint, and I
> realize I probably represent 1 percent of the readers, is that it doesn't
> do much for Windows users who have no *nix background. I'm not sure what,
> if anything, could be done about that but I'll think about it for a while.

Simon wrote the text.  I agree he did an excellent job with it.  It is
just the tip of the iceberg.  You need to read the git docs to really
begin to understand how the system works.  It is extremely powerful and
provides much rope to hang yourself.

Jeffrey Altman