"Marco Costalba" [off-list ref] writes:
quoted
The main question is what you would let your users do and how
you would guide them through the process, when the application
of an earlier patch in the series fails. I think it is a
secondary implementation detail which of "git-am", "git-am
--fail" or "git-apply" to implement that process.
QGit is not supposed to be a GUI replacement of git UI. QGit only let
users quickly call some commonly used commands. The process of error
recovering, conflicts resolve and any other complication that could
involve more the one main flow of processing are outside the scope.
QGit simply leaves the job to native git tools any time there
something 'outside tha main flow'.
Yes, either you (1) need to make sure the user is aware what
underlying git commands QGit runs for them, so that the user
knows what workflow to follow when the procedure needs to go
manual, or (2) hide the underlying git commands QGit runs for
users, but then you need to make QGit aware of what workflow to
follow when the procedure needs to go manual, and guide the user
through that workflow. I think either is fine approach;
personally I prefer transparent tools that does (1), which is
the impression I am getting from your description of QGit.
If you take route (1), using "am --fail" number of times
involves QGit runs "am --fail" once, guide user to fix things up
_and_ give control back to QGit, then you run the next "am
--fail", etc, which would be quite cumbersome to implement. But
running multiple am and do reset soft to roll back needed number
of parents might be easier option to implement in QGit, but you
still have the same "you give the control to the user but then
you have to take the control away to proceed" problem when the
patch does not apply cleanly somewhere (you let the user to hand
resolve and say "am --resolved", but then when the series is
depleted, somebody has to run "reset --soft" to roll N commits
back to realize what you wanted to do, so at that point QGit
somehow needs to take control back).
Junio C Hamano wrote:
[...] (you let the user to hand
resolve and say "am --resolved", but then when the series is
depleted, somebody has to run "reset --soft" to roll N commits
back to realize what you wanted to do, so at that point QGit
somehow needs to take control back).
Would it be easier if QGit for "am --squash" generated lightweight temporary
tag before first git-am, so one would need not to remember N for "reset
--soft"?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
On 7/4/06, Junio C Hamano [off-list ref] wrote:
"Marco Costalba" [off-list ref] writes:
Yes, either you (1) need to make sure the user is aware what
underlying git commands QGit runs for them, so that the user
knows what workflow to follow when the procedure needs to go
manual, or (2) hide the underlying git commands QGit runs for
users, but then you need to make QGit aware of what workflow to
follow when the procedure needs to go manual, and guide the user
through that workflow. I think either is fine approach;
personally I prefer transparent tools that does (1), which is
the impression I am getting from your description of QGit.
Yes, I prefer way (1) too. QGit as an error reporting infrastructure
to always report by a message box arguments (starting from 0) of
offending command, be it native git or not.
If you take route (1), using "am --fail" number of times
involves QGit runs "am --fail" once, guide user to fix things up
_and_ give control back to QGit, then you run the next "am
--fail", etc, which would be quite cumbersome to implement. But
running multiple am and do reset soft to roll back needed number
of parents might be easier option to implement in QGit, but you
still have the same "you give the control to the user but then
you have to take the control away to proceed" problem when the
patch does not apply cleanly somewhere (you let the user to hand
resolve and say "am --resolved", but then when the series is
depleted, somebody has to run "reset --soft" to roll N commits
back to realize what you wanted to do, so at that point QGit
somehow needs to take control back).
I have started to implement the feature suggested by Jakub (patch in
working dir only, not committed). The core is a loop of git-am, one
for each patch to import, followed by a:
git-reset --mixed HEAD~<Num of succesfully applied patches>
To note that the above git-reset command is _always_ run be the patch
series apply successfully be it fails at some point, so that in any
case the tree is not dirty up, and you have the working tree with the
information you need in case of manual fixup.
I will plan to push as soon I'm able to reach a "pushable site" ;-)
Comments? could work? not consistent?
Marco
On 7/4/06, Marco Costalba [off-list ref] wrote:
On 7/4/06, Junio C Hamano [off-list ref] wrote:
quoted
"Marco Costalba" [off-list ref] writes:
I have started to implement the feature suggested by Jakub (patch in
working dir only, not committed).
Ok. I have pushed two patches, the first with support for applying a
patch series in working dir only, i.e. without to create new commits,
the second to add "branch that a rev belongs to" info as in gitk, near
tags information was already there.
The difference with gitk is that only loaded branch/tags are
considered, this is to better scale.
Anyhow, due to little tricks ;-) , indexing is very fast, about 250ms
to index the whole Linux tree on my box.
Marco