¿Debería un mantenedor de github reescribir el autor en las solicitudes de extracción?

No soy programador de profesión, pero codifico y he usado github. Me he encontrado con una situación sorprendente. Estoy muy familiarizado con git.

Hay un proyecto en el que encontré un error (pequeño) que me estaba afectando. Pasé una tarde buscándolo y arreglándolo. Bifurqué el repositorio, cometí el cambio y emití una solicitud de extracción. Después de ver que estaba cerrado como "Fusionada en la rama de desarrollo", pensé que todo estaba bien.

Hoy estaba navegando por el repositorio preparándome para eliminar mi rama, y ​​no puedo encontrar dónde se fusionó el commit en el repositorio del mantenedor. Después de un tiempo, me doy cuenta de que se ha agregado como una confirmación, pero el autor ya no soy yo.

Por lo que puedo decir, la única forma de hacerlo sería usar específicamente una nueva versión, una modificación u otra reescritura de la historia para eliminar al autor original.

Esto me parece muy mal. En el mejor de los casos es confuso, en el peor de los casos, el autor de este repositorio se está dando crédito por los compromisos de todos y luego se pierde la historia del contribuyente original. De nuevo, es un pequeño error, no lo uso para mi currículum profesional, simplemente parece deshonesto.

¿Esto es normal? ¿Debo decir algo al respecto?

Editar: La sensación general parece ser que debo ir a preguntar, así que lo haré esta mañana.

Según la solicitud a continuación. Lo revisé y mi código existe y se aplicó exactamente como lo escribí (incluido el comentario). Verifiqué que tanto el confirmador como el autor han cambiado. Hubo un cambio adicional también agregado al mismo tiempo que mis cambios. Es una sola línea, lo que afectaría al parche, así como a otro código anterior. Es decir, la adición de una línea no está relacionada con el error que estaba arreglando.

Actualización Parece que la respuesta fue que el autor mantiene una rama de desarrollo y no quiere fusionarse con su rama maestra. Es autor de mi compromiso para evitar una fusión. No estaba preocupado con la rama original b / c git es lo suficientemente poderosa para seleccionar, rebase y fusionar los compromisos según sea necesario.

¿Es esto típico en github?
¿Debería comunicarme con el responsable del mantenimiento de un proyecto para preguntar a qué rama aplicar parches?

No, no deberían, si es evitable. Es un problema que, en mi experiencia, sucede con demasiada frecuencia. Sin embargo, creo que tiene más que ver con la ignorancia de cómo usar git correctamente que con alguien que quiere robar crédito.

• Si desean modificar su cambio antes de aplicarlo a su rama principal, pueden crear fácilmente una rama para su cambio. Luego pueden agregar su propia confirmación después de la suya y luego fusionar la rama.
• Si su solicitud de extracción no se basa en la última versión de su rama principal, pueden emitir un git rebase master. Si hay conflictos, pueden elegir solucionar los conflictos ellos mismos (sin cambiar de autor) o darle la oportunidad de solucionarlo.

Creo que Github podría y debería buscar este tipo de robo de crédito accidental y educar a los mantenedores sobre las mejores prácticas cuando sea apropiado.

Has omitido algunos detalles clave aquí.

• Si la forma en que "solucionó" el error no fue del agrado de los mantenedores, o incluso incorrecto en el sentido de que introdujo sus propios errores, entonces el responsable podría haber tenido que editar su trabajo antes de comprometerse. En cuyo caso es comprensible cambiar de autor.

• Como otros han mencionado el autor es bastante diferente de la confirmador . Como ya sabrán, el autor es quien realmente creó el commit, mientras que el committer sería el que lo aplicaría.

Debería echar un vistazo de cerca al commit y actualizar su pregunta con sus hallazgos.

Parece que la respuesta fue que el autor mantiene una rama de desarrollo y no quiere fusionarse con su rama maestra. Es autor de mi compromiso para evitar una fusión.

Para responder a su pregunta actualizada:

Es difícil decir qué es típico en github, más allá de decir que, por lo general, cada proyecto es diferente y cada uno tiene su propio flujo de trabajo preferido. En general, el mejor enfoque antes de enviar una solicitud de extracción es preguntar cuál es su flujo de trabajo o tratar de ver si puede distinguirlo basándose en solicitudes de extracción cerradas anteriores.

Mi experiencia personal ha sido si no lo solicita, en general, en el mejor de los casos, cerrarán la solicitud de extracción sin comentarios (en el peor de los casos), o en el mejor de los casos, dejarán un comentario explicando el procedimiento que le solicita que actualice su solicitud de extracción. Diré que parece extraño la forma en que el mantenedor en su caso lo manejó, pero puede haber sido el camino de menor resistencia para ellos. Sin embargo, dudo que haya sido intencionalmente para robar crédito.

Le sugiero que solicite al responsable de mantenimiento que agregue documentación que explique cómo le gustaría recibir solicitudes de extracción y en qué rama evitar la confusión y la falta de crédito en el futuro. Deseo que más proyectos proporcionen esta documentación, ya que creo que haría que las personas estén más inclinadas a participar en el proyecto.