You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Oct 27, 2022. It is now read-only.
Repository navigation
This repository was archived by the owner on Oct 27, 2022. It is now read-only.
New created ReviewTask using a very old commit - why? #3
As you can see in the screenshot the picked commit is 5 month old and it is not the first one in the whole history of that repo.
how select appraise this commit?
it would be cool to create new code reviews from the git history log itself? I would like to contribute such extension (if this is technical possible g) - what would be good starting point for development?
@ahoehma The commit used to anchor the review is the oldest one that is not yet in the target ref.
The Eclipse git-appraise plugin always sets the target ref to master (which is not a good fit for everyone but more general support for that hasn't been a high priority), so that means it always picks the oldest ref from your current branch that is not yet in master.
The reason for picking the oldest is so that later read operations do not need to scan the whole history to see which commit holds the review notes; instead they can just read directly from the oldest commit.
it would be cool to create new code reviews from the git history log itself?
That does sound cool, and I would be happy to review such a change.
Unfortunately, I don't know enough about Eclipse to know whether or not the history view is extensible, or how to add extensions to it.
@ojarjur so does this mean our master seems to be very "outdated"? We currently using "jgitflow" ... but from my point of view it's a "pain in the ass" ;) I did't see at least one release without "problems(conflicts)" :/
In my case this very old commit caused more then 2000 changes in the review task :) I would prefer to start the code review at any commit as I like :-) Maybe it would also be cool to remove changes from that task ... currently the task editor is not usable because of the many content inside :)
so does this mean our master seems to be very "outdated"?
Not necessarily. It means that the very old commit is not in the master branch, but the changes from that commit might be. In particular, if you squash all of the commits from 'develop' onto 'master', then the individual commits will be discarded even though the changes from them will be kept.
What this boils down to is that creating reviews against the 'master' branch just won't do the right thing for your use case. You want your reviews to be against 'develop' instead of 'master', and until we add support for that to the Eclipse plugin, you won't be able to use it effectively with your workflow.
In my case this very old commit caused more then 2000 changes in the review task :) I would prefer to start the code review at any commit as I like :-) Maybe it would also be cool to remove changes from that task ... currently the task editor is not usable because of the many content inside :)
As an experiment, can you try the following?:
Fetch from the remote, one of the feature branches you are currently working on (or create a new one locally and commit some changes to it).
Then, try opening that newly create review in Eclipse (Obviously, this requires having the command line tool installed, so if that is out of the question, then nevermind).
If that works, then you can use it as a workaround until we get the Eclipse plugin updated to support your use case.
Activity
ojarjur commentedon Oct 10, 2016
@ahoehma The commit used to anchor the review is the oldest one that is not yet in the target ref.
The Eclipse git-appraise plugin always sets the target ref to master (which is not a good fit for everyone but more general support for that hasn't been a high priority), so that means it always picks the oldest ref from your current branch that is not yet in master.
The reason for picking the oldest is so that later read operations do not need to scan the whole history to see which commit holds the review notes; instead they can just read directly from the oldest commit.
That does sound cool, and I would be happy to review such a change.
Unfortunately, I don't know enough about Eclipse to know whether or not the history view is extensible, or how to add extensions to it.
ahoehma commentedon Oct 10, 2016
@ojarjur so does this mean our master seems to be very "outdated"? We currently using "jgitflow" ... but from my point of view it's a "pain in the ass" ;) I did't see at least one release without "problems(conflicts)" :/
In my case this very old commit caused more then 2000 changes in the review task :) I would prefer to start the code review at any commit as I like :-) Maybe it would also be cool to remove changes from that task ... currently the task editor is not usable because of the many content inside :)
ojarjur commentedon Oct 10, 2016
Not necessarily. It means that the very old commit is not in the master branch, but the changes from that commit might be. In particular, if you squash all of the commits from 'develop' onto 'master', then the individual commits will be discarded even though the changes from them will be kept.
What this boils down to is that creating reviews against the 'master' branch just won't do the right thing for your use case. You want your reviews to be against 'develop' instead of 'master', and until we add support for that to the Eclipse plugin, you won't be able to use it effectively with your workflow.
As an experiment, can you try the following?:
Fetch from the remote, one of the feature branches you are currently working on (or create a new one locally and commit some changes to it).
Checkout that feature branch.
Run, from the command line, the following:
git appraise request --target 'refs/heads/develop'
Then, try opening that newly create review in Eclipse (Obviously, this requires having the command line tool installed, so if that is out of the question, then nevermind).
If that works, then you can use it as a workaround until we get the Eclipse plugin updated to support your use case.