Re: Pair Programming Workflow Suggestions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Sep 15, 2009 at 2:14 PM, Sean Estabrooks <seanlkml@xxxxxxxxxxxx> wrote:
> On Tue, 15 Sep 2009 13:43:17 -0400
> Tim Visher <tim.visher@xxxxxxxxx> wrote:
>
> [...]
>> It would be nicer to
>> have an arbitrary number of authors that can all exist separately, but
>> I'm fairly certain that git does not support that.
>
> Tim,
>
> If you're just looking for a way to quickly switch the author information
> quickly between individual commits.  You could create a shell alias for
> each of the programmers that does:
>
>   export GIT_AUTHOR_NAME="some name" GIT_AUTHOR_EMAIL="name@xxxxxxxxx"
>
> This will override the global and per repo configured author information
> for all subsequent commits.

That is an interesting idea.  My point is really that having a
committer and an author is something that makes sense in terms of
non-pairing.  Especially in the OS world where developers may never
even get to meet, let alone code together, one developer writes a
feature somewhere and then submits it to the maintainer and the
maintainer puts it in.  Pairing, on the other hand, is much more
tightly integrated than that.  Just like in Brian's post, it's really
a situation of Dev1 _&_ Dev2 wrote this feature, but one of them
happened to be typing and doing most of the nitty-gritty developing.
Changing the authors between committs almost seems to introduce an
arbitrary level of distinction where it's no longer _both_ but _one
then the other_.  Does that make my question any clearer?

-- 

In Christ,

Timmy V.

http://burningones.com/
http://five.sentenc.es/ - Spend less time on e-mail
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]