Mickey,

> 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?

You could choose to do that, though I would not.

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

your changes move onto the master; you can junk your branches and
adopt the master, or you could merge (I think; I am not an expert
either)

> 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?

yes!


>> Changes are not submitted to gerrit by using a web browser.  They are
>> pushed to gerrit using the "git push" command which in turn uses the
>> ssh client you configured to communicate securely with gerrit's clone
>> of the repository.
>
> 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.

Send revised wording to Simon; he's coordinating changes to the wiki
page, since he wrote it.

>
> 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.

Same as above!

>> The submit is now in gerrit where it can be reviewed.  Comments can be
>> applied.  Verification can be specified.  If it all looks good, it will
>> be submitted.  If it needs work, you will need to update the commit and
>> resubmit it to the same gerrit issue.  This is hopefully explained well
>> enough in the GitDevelopers wiki page.
>>
>
> 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.

Well, it's not perfect. But we're trying to make sure it stays as you describe!
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel

Reply via email to