Re: [PATCH 4/5] sequencer: Expose code that handles files in .git/sequencer
- From
Jonathan Nieder <jrnieder@gmail.com>
- Date
- Aug 11, 2011, 06:22 UTC
- Message-ID
- <20110811062236.GA27394@elie.gateway.2wire.net>
- In-Reply-To
- <CALkWK0kxtyPABBUOrXtKDxPCBKt3CynoP4Fm8f_+C1ymkLTo-w@mail.gmail.com>
Hi Ram,
Ramkumar Ramachandra wrote:
> Are you certain about pick_revisions? I've copied over the function > here for your reference. My issue is that it's too specific > cherry-pick/ revert:
I'm a very pragmatic person: as long as the code and history are readable and behave reasonably well, I'm happy.
So in this particular case, why not expose pick_revisions, with some name like revert_or_cherry_pick? It would be readable and behave reasonably well. :) A theoretical other caller could save a fork by calling revert_or_cherry_pick instead of forking a subprocess to do the same.
[...]
> 2. You mentioned multiple entry points earlier, and that's something > I've been meaning to do: In the long run
Sure, and that still seems like a good idea in the long run.
But as long as we are not closing doors, ideas about the long run should not get in the way of getting work done today.
Hoping that is clearer. Jonathan