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
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
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
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
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
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
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
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
> > \|
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
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<-
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
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
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
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.
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"
15 matches
Mail list logo