Re: [Q] Branch aliases (synonyms)?

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

 



On Tuesday 03-July-2012 10:49:39 Hallvard Breien Furuseth wrote:
>[ ... ]
>  Yes, a symref in the master repo only seems tidy enough.
>  I should have realized that's what he meant.

 My apologies.  I just re-read my original Question,
 and realize I failed to make that clear.  YES, the
 only place there would be a symref is in the master
 repo (we call it the “main” repo).

>  I can think of one irritant to warn developers of:
> 
>    git fetch           # Fetches both A and B
>    git checkout A      # Lemme see how this looks for A users...
>    ...
>    git checkout B      # My scripts are still using B though...
>    ...commit something...
>    git push            # Pushes B, doesn't know remote A is forwarded
>    git push            # Rejected, non-fast-forward of your old A
> 
>  "WTF, why does that keep happening all the time?"
> 
>    git branch -d A     # Fixes the above (if A is not checked out:)

 No developer can push to “main” (we use Gerrit as
 a front-end / staging-area),  Approved Patches go
 from Gerrit → “main” (both internal) and then on
 to the externally-accessible mirrors.  The clients
 pull/fetch from the mirrors, and cannot push to any
 of the Gerrit, “main”, or the mirrors.
 
 Any feedback from the clients  — which is Very Rare
 (not sure if that's Good or Bad?) —  is currently
 done via e-mail, which is put into Gerrit as per
 the usual process.

 Nonetheless, your point is quite valid.  We would
 have to warn developers (and the clients) about
 switch-ing back and forth between A and B.  This
 is one reason I myself am less-than-keen on the
 idea, along with not liking the merge plan anyways.

>  And if you haven't already, it may be best to do
> 
>    git config --bool receive.denyNonFastForwards  true
>    git config --bool receive.denyDeletes          true

 Ah!  That seems like a Good Idea, regardless of whether
 we do this symref'ing or not.  Many Thanks for the tip!

 We do have some access controls, both a front-end and
 hook(s?), on the mirrors which are supposed to prevent
 those sort of things (and other abuses), but I have no
 objection to yet another barrier / protective measure.

cheers!
	-blf-

-- 
Brian Foster
Principal MTS, Software        |  La Ciotat, France
Office:  +33 (0)4 42 98 15 35  |  Fax:  +33 (0)4 42 08 33 19
Maxim Integrated Products      |  Web:  http://www.maxim-ic.com/

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