Un maintainer di github dovrebbe riscrivere le richieste pull dell'autore?

Naviga le tue risposte
43

Non sono un programmatore di professione, ma faccio un po 'di programmazione e ho usato alcuni GitHub. Ho attraversato quello che trovo per essere una situazione sorprendente. Sono molto familiare con git.

C'è un progetto in cui ho trovato un (piccolo) bug che mi stava interessando. Ho passato un pomeriggio a trovarlo e sistemarlo. Ho biforcuto il repository, ho commesso la modifica e ho emesso una richiesta di pull. Dopo aver visto che è stato chiuso come "Fuso nel ramo di sviluppo", ho pensato che tutto andava bene.

Stavo sfogliando il repository oggi preparandomi a rimuovere il mio ramo, e non riesco a trovare dove il commit è stato fuso nel repository del maintainer. Dopo un po 'mi rendo conto che è stato aggiunto come commit, ma l'autore non è più me.

Per quanto ne so, l'unico modo per farlo sarebbe quello di utilizzare specificamente un rebase, un emendamento o un'altra riscrittura della cronologia per rimuovere l'autore originale.

Questo mi sembra molto sbagliato. Nel migliore dei casi è confusionario, nel peggiore dei casi l'autore di questo repo si sta prendendo credito per i commit di tutti e quindi la storia del contributore originale è andata persa. Di nuovo è un piccolo bug, non lo uso per il mio curriculum professionale, sembra solo disonesto.

È normale? Dovrei dire qualcosa a riguardo?

Modifica: Il sentimento generale sembra essere che dovrei andare a chiedere, quindi lo farò stamattina.

Come da richiesta qui sotto. Ho controllato e il mio codice esiste ed è stato applicato esattamente come l'ho scritto (compreso il commento). Ho verificato che sia il committer che l'autore sono stati modificati. C'era anche una modifica aggiuntiva aggiunta allo stesso tempo delle mie modifiche. È una singola riga, che interesserebbe la patch e altri codici prima di essa. IE l'aggiunta di una riga non è correlata al bug che stavo correggendo.

Aggiorna Sembra che la risposta sia stata che l'autore mantiene un ramo di sviluppo e non vuole unirsi al suo ramo principale. È stato ri-autore del mio impegno per evitare un'unione. Non ero interessato al ramo originale b / c git è molto potente per selezionare, rebase e unire commit in base alle necessità.

Questo è tipico di github?
Devo contattare il manutentore di un progetto per chiedere a quale filiale applicare le patch?

    
posta user1585512 08.08.2012 - 19:55
fonte

4 risposte

3

Sembra che la risposta sia stata che l'autore mantiene un ramo di sviluppo e non vuole unirsi al suo ramo principale. È stato ri-autore del mio commit per evitare l'unione.

    
risposta data 10.08.2012 - 15:22
fonte
19

No, non dovrebbero, se evitabili. È un problema che nella mia esperienza accade troppo spesso. Comunque credo che sia più a che fare con l'ignoranza su come usare git correttamente rispetto a qualcuno che vuole rubare credito.

  • Se vogliono modificare la tua modifica prima di applicarla al loro ramo principale, possono facilmente creare un ramo per la tua modifica. Possono quindi aggiungere il proprio commit dopo il tuo e quindi unire il ramo in.
  • Se la tua richiesta di pull non è basata sull'ultima versione del loro ramo principale, allora possono emettere un git rebase master . Se ci sono conflitti, possono scegliere di correggere i conflitti da soli (senza cambiare autore), o darti la possibilità di risolverli.

Penso che Github potrebbe e dovrebbe cercare questo tipo di furto accidentale del credito ed educare i manutentori sulle migliori pratiche quando appropriato.

    
risposta data 26.01.2013 - 18:13
fonte
6

Hai omesso alcuni dettagli chiave qui.

  • Se il modo in cui hai "corretto" il bug non era per i manutentori, o anche per i manutentori errato in quanto ha introdotto i propri bug, quindi il manutentore potrebbe avere dovevo modificare il tuo lavoro prima di impegnarti. In tal caso è comprensibile a cambia l'autore.

  • Come altri hanno menzionato, l' autore è molto diverso dal committer . Come forse già sai, l'autore è colui che in realtà creato il commit, mentre il committer sarebbe quello che lo applicherà.

Dovresti dare un'occhiata al commit e aggiornare la tua domanda con i risultati.

    
risposta data 08.08.2012 - 21:17
fonte
3

Per rispondere alla tua domanda aggiornata:

È difficile dire cosa sia tipico di github, oltre a dire che in genere ogni progetto è diverso e ognuno ha il proprio flusso di lavoro preferito. In genere, l'approccio migliore prima di inviare una richiesta di pull è chiedersi quale sia il loro flusso di lavoro o cercare di capire se si è in grado di distinguere le precedenti richieste di pull chiuso.

La mia esperienza personale è stata che se non lo chiedi, generalmente chiuderanno al meglio la richiesta di pull senza commento (caso peggiore), o il caso migliore lasciano un commento che spiega quale procedura ti chiede di aggiornare la tua richiesta di pull. Dirò che sembra strano il modo in cui il manutentore nel tuo caso lo ha gestito, ma potrebbe essere stato solo il percorso di minor resistenza per loro. Dubito che fosse intenzionalmente destinato a rubare il credito però.

Suggerirei di chiedere al manutentore di aggiungere una documentazione che spieghi come vorrebbero ricevere le richieste pull e contro quale ramo evitare la confusione e la mancanza di credito in futuro. Vorrei che più progetti fornissero questa documentazione, poiché penso che renderebbe le persone più inclini a partecipare al progetto.

    
risposta data 10.08.2012 - 17:18
fonte

Leggi altre domande sui tag

Digitare le variabili di casting in PHP, qual è il motivo pratico per farlo? Manutenzione del codice: mantenere uno schema errato quando si estende un nuovo codice per essere coerenti o no?