sulle pull request (chi sa sa): mi fa molto piacere che cerchiate di contribuire ma bisogna regolarle, altrimenti io non capisco cosa state cercando di fare. e allora:
ci deve essere un solo commit. due già possono creare confusione ma vabbè. tre assolutamente no. in git si possono "compattare" più commit facendo un rebase, ma non so esattamente come funziona. male che vada potete clonare da qualche altra parte, creare un'altra branch, copiarci su il repository precedentemente modificato, committare e mandare la pull request da lì.
- esorciccio a.d.
non mettete più cose insieme. la pull request deve riguardare un solo argomento, non tizio caio e già che c'ero ci ho buttato dentro anche sempronio e pippobaudo.
- esorciccio a.d.
gradle ha già rotto le palle. 'sto coso non fornisce nessuna funzione indispensabile e però, come me lo presentate voi, vorrebbe spostare più di 500 file. se ne ha proprio bisogno gradle non lo mettiamo. se invece, come credo, può funzionare aggiungendo solo qualche file di configurazione allora si.
- esorciccio a.d.
per adesso è tutto. scusatemi ma le PR che ci sono aperte adesso non le voglio prendere così come sono
- esorciccio a.d.
Ok Torvalds, ma poi non ti lamentare se il progetto verrà forkato 😀
- cagnulein
queste cose sono un decimo di quello che ti chiedono in qualsiasi progetto OS. un'altra cosa: tab/spazi e formattazione, impostateli come sono già in uso nel progetto, grazie
- esorciccio a.d.
uh? da quel che ho visto si può aggiungere gradle senza spostare niente e creando solo due file e due cartelle extra. (l'ultima PR di sciack)
- Angelo
Si la cosa di gradle in effetti non l'ho capita neanche io esorciccio. Per i Tab sorry, ho visto dopo il commit
- cagnulein
entrambe le pr che mettevano gradle avevano un commit che spostava tutti i sorgenti, poi si, 36 commit dopo li rimettevano a posto magari
- esorciccio a.d.
guarda che le pull request le puoi mergeare in una branch che ti crei tu a parte
- Craiv
la roba di riunire tutto sotto un solo commit che vantaggi ti da, a parte impedire di commentare le singole modifiche in più di due righe?
- Craiv
sull'unificare più commit: http://gitready.com/advance...
- Francesco Mosca
@Craiv: si capisce prima/meglio cosa fa la patch (chi le accetta non ha tempo infinito per capire cosa intendevi fare e non è interessato a come ci sei arrivato)
- Francesco Mosca
vabbè ma nel pull request c'è un messaggio in cui spieghi cosa hai fatto, poi se fai 1 commit in cui dici "ops" e 1 commit in cui dici "ri-ops" sono d'accordo nel brasarli
- Craiv
spero che nessuno accetti PR fidandosi solo di quello che è scritto nel messaggio :)
- Francesco Mosca
Non hai capito. Nel messaggio riassumi, i commit servono ad atomizzare le modifiche in modo che siano più comprensibili e non devi guardarti km di diff per capire cosa ha fatto
- Craiv
Mi pare che la richiesta sia (ed è così di solito nei progetti OSS) che più modifiche → più PR distinte
- Francesco Mosca
io sto parlando di un caso molto semplice (UI, libreria che dialoga con quel pezzo di UI e documentazione di quel pezzo di codice), vuoi 3 pull request o 3 commit? 1 commit con scritto "oh guarda zì che ho cambiato la libreria e la UI che chiama la libreria e la documentazione che al mercato mio padre comprò fixando #1 #3 #4 #1000", poi vai ad aprire #1000 e nel changeset prima di capire quale delle 400 righe modificate ha risolto #1000 impieghi due ore
- Craiv
sui commit a cazzo sono nazista pure io, ma un commit per pull request è folle
- Craiv
credo che l'equivoco nasca dal fatto che io partivo dal punto di vista "la gente fa PR con commit a cazzo di cane" e che per modifica intendo "feature", non "componenti di una feature". credo sia pacifico che se sono ordinati e distinti in maniera sensata e leggibile sono più utili. Poi se esorciccio ha altri gusti ce lo dirà lui :)
- Francesco Mosca
Giusto per capirci, se io faccio una pull request del branch (esempio) "material_design" coi seguenti commit: "added new action bar", "new theme", " new icons", "fix for older Android versions", "added compat library" non va bene? io pensavo fosse la cosa più sensata, così se il commit #4 manda tutto a puttane si fa il revert solo di quello, no? Dovrei riunire tutto in un commit o fare 5 pull request?
- Osiride
Poi OK, evitare una pull request che include revert che fai in locale, microfix, modifiche non strettamente collegate alla PR tutto chiaro.
- Osiride
il problema dei tanti commit è questo: una aggiunge/cambia una cosa e committa, poi andando avanti (magari anche 3 o 4 commit dopo) la rimette a posto com'era - per questo o quell'altro motivo. e magari qualche "ripensamento" ha la sua revert mentre qualcun altro è infilato in un'altra commit. più se ne fanno più è probabile che succeda. allora tanti richiedono di compattarli (http://eli.thegreenplace.net/2014...)
- esorciccio a.d.
poi oh, a qualcuno può anche sembrare esagerato stabilire delle regole sulle pr. a me no
- esorciccio a.d.
Sei tu il boss
- cagnulein
Una PR in genere si conclude con al massimo tre commit, ma il fatto di volerne uno solo per "policy" non ha senso. L'interfaccia di Github ti fa vedere tutti i file modificati contemporaneamente, per cui... che problema c'è? Se io faccio tre operazioni atomiche, farò tre commit. Su quello non ci piove :)
- Claudio Cicali
Va beh, se uno fa i revert facendo dei commit è malato, è un altro problema. In quel caso si rimbalza la pull request con "torna quando avrai studiato".
- Craiv
No che c'entra, non è esagerato stabilire delle regole, anzi, chiedevo proprio per adeguarmi alle regole. Quindi anche nel mio esempio dovrei riunire tutto in un solo commit. OK.
- Osiride
comunque esorciccio non ho ancora capito la tua posizione in merito al pull request di gradle fatta da sciack. Al di là del numero di commit, la request mi sembra legittima e funziona correttamente. Non capisco perchè non abbracciarla.
- cagnulein