Чи повинен технік, що підтримує github, переписати авторські запити на запити на тягу?


44

Я за професією не програміст, але я займаюся кодуванням, а деякі використовую github. Я наткнувся на те, що мені здається дивною ситуацією. Я дуже добре знайомий з git.

Є проект, в якому я виявив (маленьку) помилку, яка вплинула на мене. Я провів післяобідній пошук і виправляв це. Я відправив у сховище, здійснив зміну та надіслав запит на тягнення. Побачивши, що він закритий як "Об'єднаний у галузь розвитку", я зрозумів, що все добре.

Сьогодні я переглядав репо, готуючись видалити свою гілку, і я не можу знайти, де комісія була об'єднана в репо-службу респондента. Через деякий час я усвідомлюю, що це було додано як зобов’язання, але автором це вже не я.

Наскільки я можу сказати, єдиний спосіб зробити це - спеціально використовувати ребауз, поправки чи інші переписування історії, щоб видалити оригінального автора.

Це здається мені дуже неправильним. У кращому випадку це заплутано, в гіршому випадку автор цього репо приймає кредит за всі зобов’язання, і тоді історія первинного дописувача втрачається. Знову це невелика помилка, я не використовую це для свого професійного резюме, це просто здається нечесним.

Це нормально? Чи варто щось про це сказати?

Редагувати: Здається, загальне відчуття, що я мушу піти запитати, тому я зроблю саме це сьогодні вранці.

Відповідно до запиту нижче. Я перевірив, і мій код існує, і його застосовували акуратно під час написання (включаючи коментар). Я переконався, що і виконавці, і автор були змінені. Була додана ще одна зміна одночасно з моїми змінами. Це один рядок, який впливатиме на патч, а також на інший код перед ним. IE, додавання одного рядка не пов'язане з помилкою, яку я виправляв.

Оновлення Здається, що відповідь полягала в тому, що автор підтримує галузь розвитку і не хоче зливатися зі своєї головної гілки в неї. Він повторно написав моє зобов'язання, щоб уникнути злиття. Я не переймався тим, що в оригінальній гілці b / c git є достатньо потужним для вибору, перестановки та об'єднання комісій, якщо це потрібно.

Це типово для github?
Чи слід звертатися до технічного керівника проекту, щоб запитати, до якої гілки застосувати патчі?


7
+1 для підняття етичного питання щодо кодування :) Зацікавлене в тому, щоб дізнатись, чи це поведінка за замовчуванням, здається, трохи додаткових робіт, щоб цей оператор це зробив. Або це станеться, якщо обслуговуючий персонал трохи змінив ваше зобов’язання після прийняття вашого запиту на витяг?
Суніл Д.

Це гарне запитання. Я недостатньо знайомий з github, щоб відповісти, що нормально . Однак, я думаю, що можна вибирати вишню за допомогою параметра -n, вносити зміни та виконувати. Ефективно змінює автора.

4
Можливо, технічний супровід застосував вашу зміну вручну, а не об'єднувати її. Пропоную попросити технічного керівника про це (не звинувачуючи його в нечесності).
Кіт Томпсон

6
Просто, щоб було зрозуміло, це "автор", який змінився, правда? Чи не "комітер"? Я запитую лише тому, що відмінність надзвичайно важлива, коли мова йде про етику кодового плагизму.
Крістофер

2
Ви не кажете, наскільки велике виправлення (рядки коду) або як ліцензований код, але, можливо, це також може бути порушенням вашого авторського права.
Джейді

Відповіді:


20

Ні, вони не повинні, якщо це можна уникнути. Це проблема, яка, на мій досвід, трапляється занадто часто. Однак я вважаю, що це більше стосується незнання того, як правильно використовувати git, ніж того, хто хоче вкрасти кредит.

  • Якщо вони хочуть змінити вашу зміну, перш ніж застосувати її до своєї основної гілки, вони можуть легко створити гілку для вашої зміни. Потім вони можуть додати свої власні зобов’язання після вашого, а потім об'єднати гілку в.
  • Якщо ваш запит на виклик не базується на останній версії їхнього головного відділення, вони можуть видати git rebase master. Якщо є конфлікти, вони можуть або вирішити самі конфлікти (не змінюючи автора), або надати вам можливість виправити це.

Я думаю, що Github міг би і повинен шукати подібний випадок випадкового викрадення кредитів та навчати обслуговуючого персоналу про найкращі практики, коли це доречно.


6

Тут ви залишили деякі ключові деталі.

  • Якщо спосіб "виправити" помилку не сподобався обслуговуючим особам або навіть був неправильним у тому, що він представив власні помилки, то, можливо, довелося б редагувати вашу роботу перед тим, як здійснити. У такому випадку змінити автора зрозуміло.

  • Як згадували інші, автор сильно відрізняється від комітента . Як ви, можливо, вже знаєте, автором є той, хто фактично створив зобов’язання, тоді як виконавцем буде той, хто його застосував.

Слід уважно ознайомитись із зобов'язаннями та оновити своє запитання своїми висновками.


1
Я просто пішов перевірити це. Зміни в моєму патчі не змінюються. Раніше була зміна 1 рядка і не була пов'язана з моїм патчем, який було додано одночасно.
користувач1585512

3

Здається, відповідь полягала в тому, що автор підтримує галузь розвитку і не хоче зливатися зі своєї головної гілки в неї. Він повторно написав моє зобов’язання, щоб уникнути злиття.


12
Тоді вони повинні були використати git cherry-pick.
svick

3

Щоб відповісти на оновлене запитання:

Важко сказати, що є типовим для github, за винятком того, що зазвичай кожен проект є різним і кожен має свій уподобаний робочий процес. Як правило, найкращий підхід до надсилання запиту на виклик - це запитати, що таке їх робочий процес, або спробувати перевірити, чи можете ви дізнатись, виходячи з попередніх закритих запитів на тягу.

Мій особистий досвід був, якщо ви не запитуєте, як правило, вони в кращому випадку закриють запит на витяг без коментарів (в гіршому випадку), або в кращому випадку вони залишать коментар, в якому пояснюється, яка процедура вимагає оновити ваш запит на отримання. Я скажу, що це видається дивним, як обслуговуючий персонал у вашому випадку впорався з цим, але, можливо, це був лише шлях найменшого опору для них. Я сумніваюся, що це було навмисно призначене для крадіжки кредиту.

Я б запропонував вам попросити обслуговуючого персоналу додати документацію, в якій пояснюється, як вони хочуть отримувати запити на тягнення та проти того, в яку галузь, щоб уникнути плутанини та браку кредиту в майбутньому. Я хотів би, щоб більше проектів надали цю документацію, оскільки я думаю, що це зробить людей більш схильними брати участь у проекті.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.