[Xcb] nice git-repos generated ( was: Re: xinput:QueryDeviceState: git-repo with patches of this thread )

[Christian Linhart]

Hi Ran,

I have made the repos with branches for each patch-set, 
and with Reviewed-by and Signed-off-by as you requested.
I have also posted messages with the Branch-names for each Email-Thread with patches.

Repo-Urls: 
	http://infra-srv1.demorecorder.com/git/free-sw/xcb/proto
	http://infra-srv1.demorecorder.com/git/free-sw/xcb/libxcb

***

Since this is generated by a script from the posted messages, it also contains some
more tags which may be helpful for navigation between git and your Email program
and for staying organized:

    Message-ID: <1409845851-38950-4-git-send-email-chris at demorecorder.com>
    Patch-Thread-Subject: [Xcb] support popcount of a list and associated xml changes
    Patch-Set: PopcountList
    Patch-Number: libxcb 4/4
    Patch-Version: V1
    Signed-off-by: Christian Linhart <chris at DemoRecorder.com>


Message-ID is the email message id of the patch message. 
You can use that to locate the Message in your Mail reader.

Patch-Thread-Subject is the subject of the initial thread-message which contains patches.

Patch-Set is a name for a set of patches in the same email-thread, 
and is also used as a branch-name in git.

Patch-Number is the patch number used in the subject line inside the [PATCH ] brackets.

Patch-Version is the Version of that patch from the [PATCH ] brackets 
     in the Subject line of the email-message.
     V1 is used when it has no version in the [PATCH ] brackets.

***

The HEAD of the repos is set to the most current branch.

When something changes in a branch, a new branch with a version
is created from that position onwards.

All subsequent branches are then also newly generated with a new version.

When the repos will have too many branches, please tell me,
and I'll regenerate them from scratch with the script.
(instead of just updating them with the script)

***

I update these repos a while after posting patches.
(Usually I'll do it after I have worked through all reviews.)

So there will be delay from posting a patch and its appearance in its repo.

If in doubt, and if you want to pull for pushing to the official repo,
please send me an email, and I'll update the repo and 
then I send you an ack that the repo is up-to-date.

Alternatively I could send messages when I update the repos.
But that'll be too many messages, I guess.

***

Reviewed-by is automatically generated when a Reviewed-by: Line
is contained in a direct or indirect reply to a patch-message 
(with no other patch in between.)

Please send Reviewed-By messages for V2 etc of patches, as it is not
clear whether a Reviewed-By for V1 also applies to V2.

***

"gitk --all" is quite useful for displaying all branches visually.

***

I hope we have good procedures for working now,
and that we can concentrate on the XCB things now.

If you have any questions please tell me.

Chris

P.S.: The repo-update-script is now heavily modified 
compared to the previous version which
I have attached to a previous post.

On 09/05/14 15:10, Ran Benita wrote:
> On Wed, Aug 27, 2014 at 12:56:46PM +0200, Christian Linhart wrote:
>> Hi,
> 
> Hi Christian
> 
> I have some more "procedural" requests (for the future), sorry :)
> 
> You have a few repos there with dates, it's a bit hard to follow. May I
> suggest using just a single repo, one for proto and one for xcb, and use
> appropriately-named feature branches for different sets of patches? Then
> it is easier to see the latest versions of the patches, what depends on
> what and in what order we should review (and if you put the repo url +
> branch name in a patchset's cover letter that would be great). The
> libxcb/proto split makes it a bit more difficult but you can give
> matching branches the same name.
> 
> (Although if you make changes maybe it's better to create a
> <branch-name>-v2 branch, see here:
> http://git-scm.com/book/ch3-6.html#The-Perils-of-Rebasing)
> 
> Also, if you create a pull request or V2 for a set of patches, consider
> amending them with the R-b tags you got (unless there were substantial
> changes which require re-reviewing). This again helps with further
> review and saves the committer some work.
> 
> Finally, since you make significant contributions you should probably
> add a Signed-off-by tag to your patches. See towards the end here for
> what this means:
> http://wiki.x.org/wiki/Development/Documentation/SubmittingPatches/
> 
> If all of this is confusing let us know :)
> 
> And thanks for your continued work! With an MIT license people sometimes
> choose to keep such work hidden...
> 
> Ran
> 
>> Chris
>>
>> P.S.: I am aware that the discussion for this patchset is not yet finished.
>> I will recreate these repos when there'll be further changes.
>> _______________________________________________
>> Xcb mailing list
>> Xcb at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/xcb
>