Um mantenedor do github deve reescrever os pedidos de pull do autor?

43

Eu não sou um programador de profissão, mas faço algumas codificações e usei o github algumas. Eu corri através do que eu acho ser uma situação surpreendente. Estou muito familiarizado com o git.

Existe um projeto no qual encontrei um (pequeno) bug que estava me afetando. Passei uma tarde procurando e consertando. Eu bifurquei o repositório, confirmei a mudança e emiti uma solicitação de recebimento. Depois de ver que ele foi fechado como "Fundido no ramo de desenvolvimento", percebi que tudo estava bem.

Eu estava navegando no repositório hoje me preparando para remover minha filial e não consigo encontrar onde o commit foi mesclado no repositório do mantenedor. Depois de algum tempo, percebo que foi adicionado como um commit, mas o autor não é mais eu.

Tanto quanto eu posso dizer, a única maneira de fazer isso seria usar especificamente um rebase, alteração ou outra reescrita do histórico para remover o autor original.

Isso parece muito errado para mim. Na melhor das hipóteses, é confuso, na pior das hipóteses, o autor deste repo está recebendo crédito pelos commits de todos e, em seguida, a história do contribuinte original é perdida. Novamente, é um pequeno bug, eu não uso isso para o meu currículo profissional, só parece desonesto.

Isso é normal? Devo dizer algo sobre isso?

Edit: O sentimento geral parece ser que eu deveria perguntar, então farei exatamente isso esta manhã.

De acordo com a solicitação abaixo. Eu verifiquei e meu código existe e foi aplicado exatamente como eu o escrevi (incluindo o comentário). Verifiquei que tanto o committer quanto o autor foram alterados. Houve uma mudança adicional também adicionada ao mesmo tempo que minhas alterações. É uma linha única, o que afetaria o patch, bem como outro código antes dele. Ou seja, a adição de uma linha não está relacionada ao bug que eu estava corrigindo.

Atualizar Parece que a resposta foi que o autor mantém um ramo de desenvolvimento e não quer se fundir de seu ramo mestre nele. Ele re-escreveu meu commit para evitar uma fusão. Eu não estava preocupado com o branch original b / c git, muito poderoso para escolher, rebase e mesclar os commits, conforme necessário.

Isso é típico no github?
Devo entrar em contato com o mantenedor de um projeto para perguntar a qual filial aplicar os patches?

    
por user1585512 08.08.2012 / 19:55
fonte

4 respostas

3

Parece que a resposta foi que o autor mantém um ramo de desenvolvimento e não quer se fundir de seu ramo mestre nele. Ele foi novamente autor de meu commit para evitar uma fusão.

    
por 10.08.2012 / 15:22
fonte
19

Não, eles não deveriam, se evitáveis. É um problema que na minha experiência acontece com demasiada frequência. No entanto, acredito que tenha mais a ver com a ignorância de como usar o git corretamente do que alguém que queira roubar o crédito.

  • Se eles quiserem modificar sua alteração antes de aplicá-la em sua ramificação principal, ela poderá criar facilmente uma ramificação para sua alteração. Eles podem então adicionar seu próprio commit após o seu e depois mesclar o branch.
  • Se sua solicitação de recebimento não for baseada na versão mais recente de sua ramificação principal, ela poderá emitir git rebase master . Se houver conflitos, eles podem optar por corrigir os próprios conflitos (sem alterar o autor) ou dar a você a chance de corrigi-lo.

Eu acho que o Github poderia e deveria procurar por esse tipo de crédito acidental, roubando e educando os mantenedores sobre as melhores práticas, quando apropriado.

    
por 26.01.2013 / 18:13
fonte
6

Você deixou de fora alguns detalhes importantes aqui.

  • Se o jeito que você "consertou" o bug não foi para os mantenedores gostarem, ou até mesmo incorreto na medida em que introduziu seus próprios erros, então o mantenedor pode ter teve que editar seu trabalho antes de cometer. Nesse caso, é compreensível mude o autor.

  • Como outros já mencionaram, o autor é bem diferente do committer . Como você já deve saber, o autor é quem realmente criou o commit, enquanto o committer seria o único a aplicá-lo.

Você deve dar uma olhada no commit e atualizar sua pergunta com suas descobertas.

    
por 08.08.2012 / 21:17
fonte
3

Para responder à sua pergunta atualizada:

É difícil dizer o que é típico no github, além de dizer que normalmente cada projeto é diferente e cada um tem seu próprio fluxo de trabalho preferido. Geralmente, a melhor abordagem antes de enviar uma solicitação pull é perguntar qual é o fluxo de trabalho ou tentar ver se você pode informar com base nas solicitações anteriores de recepção fechada.

Minha experiência pessoal tem sido se você não perguntar, geralmente eles vão, na melhor das hipóteses, fechar o pedido de puxar sem comentar (pior caso), ou melhor deixar um comentário explicando o procedimento pedindo-lhe para atualizar o seu pedido puxar. Eu vou dizer que parece estranho o modo como o mantenedor no seu caso lidou com isso, mas pode ter sido apenas o caminho de menor resistência para eles. Duvido que isso tenha sido intencionalmente destinado a roubar crédito.

Eu sugiro que você peça ao mantenedor para adicionar documentação explicando como eles gostariam de receber pedidos de pull e contra qual branch para evitar a confusão e a falta de crédito no futuro. Desejo que mais projetos forneçam esta documentação, pois acho que isso tornaria as pessoas mais propensas a participar do projeto.

    
por 10.08.2012 / 17:18
fonte

Tags