[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: A simple git workflow for the rest of us
From: |
Sergey Organov |
Subject: |
Re: A simple git workflow for the rest of us |
Date: |
Mon, 24 Nov 2014 18:25:56 +0300 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) |
Bill Wohler <address@hidden> writes:
> Steinar Bang <address@hidden> writes:
>
>>>>>>> Bill Wohler <address@hidden>:
>>
>>> I'd second setting it globally to ensure that it happens universally
>>> to avoid the spurious merge commits that otherwise ensue.
>>
>> (I've never understood why "spurious merge commits" bother people so
>> much. Personally I'm much more concerned with what might happen to my
>> individual commits if I'm hitting a conflict during rebase: the commit's
>> diff may no longer be the clear and meaningful diff I indented it to be)
>
> Like many things, it depends.
>
> If a merge in either direction doesn't add any information, it's
> spurious. If it's useful, it's not spurious. For me, a merge commit from
> a pull breaks up the flow of my unpushed commits and usually doesn't add
> anything. I can imagine that folks used to Subversion would prefer
> pull --rebase as well as that mimics svn update. Sort of.
>
> If it's vital to capture that merge in the middle of your own commits,
> then the pull should be merged. I've just never encountered this
> situation. In the situation you presented, could you use git rebase
> --abort and then run git merge origin/master to recover?
>
> In any event, there is no right or wrong answer. It all depends.
AFAIK, one can pull with merge, then finally, before pushing, call "git
rebase" by hand, and Git will get rid of all those intermediate merges
while rebasing. This doesn't play nicely with intended local merges. The
latter is unlikely to make any difference for simple workflows though.
One probably needs to enable "rerere" to avoid repeating the same merge
resolution.
--
Sergey.
- Re: A simple git workflow for the rest of us, (continued)
- Re: A simple git workflow for the rest of us, Andreas Schwab, 2014/11/15
- Re: A simple git workflow for the rest of us, Kelvin White, 2014/11/15
- Re: A simple git workflow for the rest of us, Bill Wohler, 2014/11/16
- Re: A simple git workflow for the rest of us, Eli Zaretskii, 2014/11/16
- Re: A simple git workflow for the rest of us, Steinar Bang, 2014/11/22
- Re: A simple git workflow for the rest of us, Bill Wohler, 2014/11/23
- Re: A simple git workflow for the rest of us,
Sergey Organov <=
Re: A simple git workflow for the rest of us, Lars Magne Ingebrigtsen, 2014/11/15
- Re: A simple git workflow for the rest of us, Andreas Schwab, 2014/11/15
- Re: A simple git workflow for the rest of us, Lars Magne Ingebrigtsen, 2014/11/16
- Re: A simple git workflow for the rest of us, David Engster, 2014/11/16
- Re: A simple git workflow for the rest of us, Lars Magne Ingebrigtsen, 2014/11/16
- Re: A simple git workflow for the rest of us, David Engster, 2014/11/16
- Re: A simple git workflow for the rest of us, Lars Magne Ingebrigtsen, 2014/11/16
- Re: A simple git workflow for the rest of us, David Kastrup, 2014/11/16
Re: A simple git workflow for the rest of us, Achim Gratz, 2014/11/16
Re: A simple git workflow for the rest of us, Glenn Morris, 2014/11/15