¿Cómo enviar dos requestes de extracción en el mismo repository sin rehacer todas las confirmaciones?

Hice esta request de extracción para Smart Listing. Fue aceptado y continué mi desarrollo. Ahora estoy intentando enviar nuevos cambios, y todos los cambios de mi primera request de extracción aparecen nuevamente en la nueva request de extracción, como puede ver aquí .

Intenté sacar el repo original, searchlo o volver a clasificarlo y no sirvió. Seguí la sugerencia dada en esta pregunta .

Marca "Esta twig tiene 27 compromisos por delante de Sology: maestro". Pero hice solo 4 commits desde que se aceptaron mis primeros cambios.

¿Que puedo hacer?

Esto se debe a que el mantenedor del repository ascendente aplastó su primera request de extracción en una nueva confirmación, mientras usted continuaba el desarrollo en la "twig no bloqueada". Abra su historial de repos (por ejemplo, con gitk) y siga leyendo.

La situación inicial fue así:

* 970f363 (your repo) Add spec for #smart_listing <-- last commit in your first pull request * 098fcfe Add specs for #smart_listing_create (more of your commits) * 721817f Ignore some files * 89e24b6 (upstream repo) Add missing update_list event <-- tip of origin/master back then * a084fb9 Fix handling unlimited per page (...) 

ljachymczyk aplastó todas tus confirmaciones en una nueva confirmación antes de agregarla al repository de subida:

 * 61cad2d (upstream repo) Feature spec <-- your work squashed into single commit | * 970f363 (your repo) Add spec for #smart_listing <-- last commit in your first pull request | * 098fcfe Add specs for #smart_listing_create | (...) | * 721817f Ignore some files |/ * 89e24b6 Add missing update_list event * a084fb9 Fix handling unlimited per page (...) 

Ahora, debe comprender que Git no ve ninguna connection entre la única nueva confirmación ( 61cad2d ) y su twig completa ( 721817f..970f363 ). Incluso si esa confirmación única presenta los mismos cambios que las anteriores 20+ confirmaciones, para Git estos son cambios no relacionados. (Y por buenas razones)

Luego continuó trabajando en su repository, agregando nuevos commits a esa antigua twig:

 * 61cad2d (upstream repo) Feature spec | * 0b14747 (your repo) Refactor #smart_listing_create <-- your new stuff | * e49c522 Use the controller name by default | * a1c1a92 Remove the spec directory in dummy app | * 4128104 Remove gems from Gemfile and add it in gemspec | * 970f363 Add spec for #smart_listing <-- your old stuff | * 098fcfe Add specs for #smart_listing_create | (...) | * 721817f Ignore some files |/ * 89e24b6 Add missing update_list event * a084fb9 Fix handling unlimited per page (...) 

Como puede ver, todos estos compromisos antiguos todavía no están presentes en el repository de subida, es por eso que aparecen en la request de extracción. Ni la fusión, ni el rebasamiento "normal" cambiarán eso.

Sus nuevas confirmaciones deberían haberse creado encima de 61cad2d (la confirmación aplastada), no en la parte superior de la twig anterior. Por lo tanto, ahora necesitas trasplantarlos allí. Esto es fácil asumiendo que la confirmación única aplastada (61cad2d) es exactamente equivalente a su twig anterior (es decir, git diff 970f363 61cad2d no muestra ningún cambio). En ese caso, simplemente hazlo

 git branch newstuff 0b14747 git rebase --onto 61cad2d 970f363 newstuff 

y deberías get una twig newstuff con cuatro nuevos commits basados ​​en la parte superior de la confirmación aplastada.

Tenga en count que si 970f363 y 61cad2d no son equivalentes, puede que tenga que resolver conflictos de combinación. Esto sería una ilustración de cómo las correcciones publicadas y aplastadas generan problemas.