Un manutentore di github dovrebbe riscrivere l'autore nelle richieste pull?

Non sono un programmatore di professione, ma faccio un po 'di codice e ne ho usato un po'. Ho incontrato quella che trovo una situazione sorprendente. Conosco molto bene Git.

C'è un progetto in cui ho trovato un (piccolo) bug che mi stava colpendo. Ho trascorso un pomeriggio a trovarlo e risolverlo. Ho modificato il repository, eseguito il commit della modifica ed emesso una richiesta pull. Dopo aver visto che è stato chiuso come "Immerso nel ramo di sviluppo" ho pensato che tutto andasse bene.

Oggi stavo sfogliando il repository per prepararmi a rimuovere il mio ramo e non riesco a trovare dove il commit è stato unito al repository del manutentore. Dopo qualche tempo mi rendo conto che è stato aggiunto come commit, ma l'autore non è più io.

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

Questo mi sembra molto sbagliato. Nella migliore delle ipotesi è confuso, nella peggiore delle ipotesi l'autore di questo repository si sta prendendo il merito degli impegni di tutti e quindi la storia del contributore originale viene persa. Ancora una volta è un piccolo bug, non lo uso per il mio curriculum professionale, sembra solo disonesto.

È normale? Dovrei dire qualcosa al riguardo?

Modifica: la sensazione generale sembra essere che dovrei chiedere, quindi lo farò stamattina.

Secondo la richiesta di seguito. Ho controllato e il mio codice esiste ed è stato applicato esattamente come l'ho scritto (incluso il commento). Ho verificato che sia il committer che l'autore sono stati modificati. È stata aggiunta una modifica aggiuntiva contemporaneamente alle mie modifiche. È una riga singola, che influirebbe sulla patch e su altri codici prima di essa. Vale a dire l'aggiunta di una riga non è correlata al bug che stavo correggendo.

Aggiornamento Sembra che la risposta sia stata che l'autore mantiene un ramo di sviluppo e non vuole unirsi dal suo ramo principale in esso. Ha scritto nuovamente il mio impegno per evitare l'unione. Non mi preoccupavo del ramo originale b / c di Git, che è molto potente da selezionare, ribassare e unire in base alle esigenze.

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

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

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

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

Hai lasciato fuori alcuni dettagli chiave qui.

• Se il modo in cui "correvi" il bug non era di gradimento per i manutentori, o addirittura errato in quanto presentava i propri bug, allora il manutentore avrebbe dovuto modificare il tuo lavoro prima di impegnarsi. Nel qual caso è comprensibile cambiare l'autore.

• Come altri hanno già detto, l' autore è molto diverso dal committer . Come forse già sapete, l'autore è colui che ha effettivamente creato il commit, mentre il committer sarebbe quello che lo applica.

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

Sembra che la risposta sia che l'autore mantiene un ramo di sviluppo e non vuole fondersi dal suo ramo principale in esso. Ha scritto nuovamente il mio impegno per evitare l'unione.

Per rispondere alla tua domanda aggiornata:

È difficile dire ciò che è tipico su github, oltre a dire che in genere ogni progetto è diverso e ognuno ha il proprio flusso di lavoro preferito. Generalmente, l'approccio migliore prima di inviare una richiesta pull è quello di chiedere qual è il loro flusso di lavoro o provare a vedere se è possibile distinguere in base alle precedenti richieste pull chiuse.

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

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