-
Notifications
You must be signed in to change notification settings - Fork 49
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Option to display diff even without --dry-run #208
Comments
Running two commands doesn't seem unreasonable to me. It might look more natural if you did Does git have a similar feature (i.e. show a diff after commit)? |
Yes, this feels more natural than my original proposition. I was actually thinking, maybe the easiest way to do this is just
which would also go some way towards reducing my main gripe with
I was going to jokingly reply "even git doesn't have ALL the features", but actually it does... I just checked, and But anyway, the workflows with git and Pinto are different in this respect. With git, you prepare a commit by adding exactly the changes you want -- it doesn't add stuff by itself. With Pinto, you have your desired end state ("update Acme::Foobar") and it calculates what needs to be done to get there. There needs to be a simple way to ask it "what just happened?" |
Yes, that would work nicely too. I would still want to implement that in a git-like way. So the argument could be a stack name, or a commit id, or some symbolic thing like
And that's exactly what pinto does. But you're doing this non-interactively so you never see the template message. I think that's the key difference in this situation. |
Since about version 0.085 pinto streams output to the client, so you should get a pretty quick response. Which version do you have? NB: |
The client is 0.09996 and the server is 0.09995. These are large repositories with very frequent changes though:
The output of On one of our smaller repositories, which has 65 revisions currently, it still takes ~5s to start displaying stuff, ~17s if piped to a pager -- so basically all the time, and 20.5s to finish (measured by |
Depending on your machine, most Having said all that, I turned on autoflush in 35342ee and I saw a pretty big improvement for both local and remote repositories. You're welcome to try it out yourself, or just wait for the next release (maybe next week). To get the speedup with a remote repository, you'll have to upgrade both server and client. This probably won't improve your |
Would really need to get NTYprof or similar running on that to see what the Kahlil (Kal) Hodgson GPG: C9A02289 Suite 1416 "All parts should go together without forcing. You must remember that On 14 May 2015 at 11:17, Jeffrey Ryan Thalhammer notifications@github.com
|
Neat! I'd like to try it now, but I suspect my colleagues don't want me cowboy-patching the Pinto server, and I don't have a huge Pinto repository of my own to test on. I'll wait for the release. On the topic of git-like revsets, it sounds pretty cool and it will definitely help. I can work on it if you like. |
That would be much appreciated. |
@fgabolde Pinto-0.09998 has shipped. |
@fgabolde so did this work out for you? Is it fast enough now to just use |
@thaljef It's faster but it's still pretty slow :/ It got a little better for a while but since then the repository size has kept increasing, and so has the running time of I came across this as well while trying to add options to |
Well, rendering all log entries is always going to take more time as the history gets longer. But the time to render the first N log entries should be constant, and I thought that was the primary issue here. Is that not the case? Yeah, the data structure pretty much requires a query for each revision. I wonder if it would be any faster to just fetch all revisions (or some large chunk of them) and then build the tree in memory. |
If you check back to the first comment on this ticket, the issue was originally that I wanted to show dep diffs in Jenkins build logs, and I was using Regarding the current speed of
Rather than all revisions, we only need the ancestry table and one starting revision for building the tree (fortunately the ancestry table is likely to be much smaller, with fewer columns, all ints). From there we can fetch the revisions in batches. |
Currently, commitable ops display the diff only if
--dry-run
is set, e.g.I'm using Pinto from within Jenkins, to automate "promoting" distributions from one Pinto to another (e.g. from preproduction to production). I'd like my build logs to include the changes in all cases, not just when doing dry-run ops.
As a workaround, I'm running
pinto update
first with--dry-run
, then again without.The text was updated successfully, but these errors were encountered: