Re: [SCRIPT/RFC 0/3] git-commit --onto-parent (three-way merge, no working tree file changes)

Hi Alexei, On 09/12/2017 03:18, Alexei Lozovsky wrote: > > > Chris reported in this very topic[1] that sometimes, due to > > conflicts with later commits, "checkout > commit > [checkout >] > > rebase --onto" is "much easier to do", where "commit --fixup > > > rebase -i" "breaks" (does not apply

Re: [SCRIPT/RFC 0/3] git-commit --onto-parent (three-way merge, no working tree file changes)

On Dec 9, 2017, at 01:54, Igor Djordjevic wrote: > On 08/12/2017 17:24, Junio C Hamano wrote: >> I'd rather do a quick fix-up on top (which ensures that at least the >> fix-up works in the context of the tip), and then "rebase -i" to >> move it a more appropriate place in the history (during which

Re: [SCRIPT/RFC 0/3] git-commit --onto-parent (three-way merge, no working tree file changes)

On 08/12/2017 17:24, Junio C Hamano wrote: > > > To get back on track, and regarding what`s already been said, > > would having something like this(1) feel useful? > > > > (1) git commit --onto > > Are you asking me if _I_ find it useful? It is not a very useful > question to ask, as I've

Re: [SCRIPT/RFC 0/3] git-commit --onto-parent (three-way merge, no working tree file changes)

Igor Djordjevic writes: > To get back on track, and regarding what`s already been said, would > having something like this(1) feel useful? > > (1) git commit --onto Are you asking me if _I_ find it useful? It is not a very useful question to ask, as I've taken

Re: [SCRIPT/RFC 0/3] git-commit --onto-parent (three-way merge, no working tree file changes)

On 06/12/2017 19:34, Johannes Sixt wrote: > > I am sorry for not responding in detail. I think we've reached a > mutual understanding of our workflows. No problem, thanks for your time so far. There might be one more thing I should address, possibly left unclear from my previous message, but

Re: [SCRIPT/RFC 0/3] git-commit --onto-parent (three-way merge, no working tree file changes)

On Wed, Dec 6, 2017 at 10:34 AM, Johannes Sixt wrote: > I am sorry for not responding in detail. I think we've reached a mutual > understanding of our workflows. > > Though, from the ideas you tossed around most recently, you seem to want to > make git-commit into a kitchen-sink

Re: [SCRIPT/RFC 0/3] git-commit --onto-parent (three-way merge, no working tree file changes)

I am sorry for not responding in detail. I think we've reached a mutual understanding of our workflows. Though, from the ideas you tossed around most recently, you seem to want to make git-commit into a kitchen-sink for everything. I have my doubts that this will be a welcome change. Just

Re: [SCRIPT/RFC 0/3] git-commit --onto-parent (three-way merge, no working tree file changes)

Hi Hannes, On 01/12/2017 18:23, Johannes Sixt wrote: > > > To work with `--onto-parent` and be able to commit on top of any of > > the topic branches, you would need a situation like this instead: > > > > (1) ...C <- topic C > > | > > ...A | <- topic A > > \|

Re: [SCRIPT/RFC 0/3] git-commit --onto-parent (three-way merge, no working tree file changes)

Hi Chris, On 30/11/2017 23:40, Chris Nerwert wrote: > > I'm actually doing the described workflow quite often with git rebase > when working on a topic. Given the following structure: > > ---o (master) > \ >o---A---B---C (topic) > > When I want to make changes to

Re: [SCRIPT/RFC 0/3] git-commit --onto-parent (three-way merge, no working tree file changes)

Am 30.11.2017 um 00:10 schrieb Igor Djordjevic: On 29/11/2017 20:11, Johannes Sixt wrote: With git-post, I make a fixup commit commit on the integration branch, then `git post B && git merge B`: ...A...C <- topics A, C \ \ ---o---o---o---o---f---F<-

Re: [SCRIPT/RFC 0/3] git-commit --onto-parent (three-way merge, no working tree file changes)

On Nov 27, 2017, at 00:35, Igor Djordjevic wrote: > Approach discussed here could have a few more useful applications, > but one seems to be standing out the most - in case where multiple > topic branches are temporarily merged for integration testing, it > could

Re: [SCRIPT/RFC 0/3] git-commit --onto-parent (three-way merge, no working tree file changes)

Hi Hannes, On 29/11/2017 20:11, Johannes Sixt wrote: > > Ok, then please explain, how this process should work in my workflow > and with the `commit --onto-parent` feature that you have in mind. I > have an integration branch (which is a throw-away type, so you can > mangle it in any way you

Re: [SCRIPT/RFC 0/3] git-commit --onto-parent (three-way merge, no working tree file changes)

Am 28.11.2017 um 02:15 schrieb Igor Djordjevic: On 27/11/2017 22:54, Johannes Sixt wrote: I my opinion, putting the focus on integration merge commits and the desire to automate the re-merge step brings in a LOT of complexity in the implementation for a very specific use-case that does not

Re: [SCRIPT/RFC 0/3] git-commit --onto-parent (three-way merge, no working tree file changes)

Hi Johannes, On 27/11/2017 22:54, Johannes Sixt wrote: > > I my opinion, putting the focus on integration merge commits and the > desire to automate the re-merge step brings in a LOT of complexity in > the implementation for a very specific use-case that does not > necessarily help other cases.

Re: [SCRIPT/RFC 0/3] git-commit --onto-parent (three-way merge, no working tree file changes)

Am 26.11.2017 um 23:35 schrieb Igor Djordjevic: Approach discussed here could have a few more useful applications, but one seems to be standing out the most - in case where multiple topic branches are temporarily merged for integration testing, it could be very useful to be able to post "hotfix"

[SCRIPT/RFC 0/3] git-commit --onto-parent (three-way merge, no working tree file changes)

Hi to all, Here`s my humble attempt on (once more) scratching a use case which seems to be desired occasionally through the years, obviously not enough to be actually implemented yet, but might be worth some more attention... :) For the reference, some past mentions of (more or less) similar