Community
Participate
Working Groups
See http://dev.eclipse.org/mhonarc/lists/orion-dev/msg00975.html for more info.
I think we should present this info in both status and log pages. In status page we should present this in the hear of the remote mini log, while in log page it should be somewhere in the title of banner area.
Sorry I really think this is the wrong direction. The user *cannot* see at a glance any useful information. First it can't be at-a-glance. Rather the dev has to read the last fetch time, look up the local current time, convert the formats in their head, subtract, then make a judgement based on the delta. Second, the entire purpose of the calculation is to decide whether to push the fetch button, a decision they should not have to make. What goes in that decision? A possibly incorrectly calculated delta time, an estimate of the probability of a remote commit, and an estimate of how much more time will be wasted by the UI as the fetch is executed and the UI is updated. The dev is way better off ignoring the last-fetch time and just pushing the fetch button anyway. It's not like it will hurt anything and then we know for sure about recent commits. Oh and third, the dev rarely has a choice anyway. If they have local commits, then they have to fetch before push anyway. If they are just starting new work, they have to fetch and merge to get started. So the use case for not fetching based on time is weak. I might have a different opinion if there was anything one can do with the remote tracking branch other than fetch or merge. But as it is, once you have merged, then the only operation is fetch and the only reason not to push that button is fear of update delay. If the update was done in background, no fear, so no last-fetch-time info is needed.
(In reply to comment #2) > Sorry I really think this is the wrong direction. The user *cannot* see at a > glance any useful information. To me, an info that the last fetch occurred 3 minutes ago would be useful. > First it can't be at-a-glance. Rather the dev has to read the last fetch time, > look up the local current time, convert the formats in their head, subtract, > then make a judgement based on the delta. Actually, I was thinking about doing it for him, by showing a relative time e.g. "30 mins ago". > Second, the entire purpose of the calculation is to decide whether to push the > fetch button, a decision they should not have to make. What goes in that > decision? A possibly incorrectly calculated delta time, an estimate of the > probability of a remote commit, and an estimate of how much more time will be > wasted by the UI as the fetch is executed and the UI is updated. The dev is way > better off ignoring the last-fetch time and just pushing the fetch button > anyway. It's not like it will hurt anything and then we know for sure about > recent commits. Even then you're not 100% that a few seconds later there will be no new commits on the remote. The "Last fetch {time}" was never supposed to be the ultimate solution, but I would definitely find it handy. However, I do agree the info would be just an estimate, nothing more. > Oh and third, the dev rarely has a choice anyway. If they have local commits, > then they have to fetch before push anyway. They can also configure their repos with branch.{branch-name}.rebase. > If they are just starting new work, > they have to fetch and merge to get started. No, they don't. I fetch (pull actually) my repos once a day and it doesn't prevent me from starting off new branches or even comitting on master. I've stopped being afraid of merges pretty soon after I switched to git. > I might have a different opinion if there was anything one can do with the > remote tracking branch other than fetch or merge. But as it is, once you have > merged, then the only operation is fetch and the only reason not to push that > button is fear of update delay. If the update was done in background, no fear, > so no last-fetch-time info is needed. How often should the background fetch be done to make the fear go away? I guess in my case it would have to be least than 10 seconds ;) I don't think banging against a git repo is the best we can do. Finally, please don't get me wrong, I'm not saying the info about the last fetch time is the perfect fix. But I'm not sure if fetching each time a remote branch is displayed is any better. BTW, there is also bug 344046 about adding "git pull". If you have any comments on that, please add them to that bug.
(In reply to comment #3) > Actually, I was thinking about doing it for him, by showing a relative time > e.g. "30 mins ago". Hmm, then it updates the relative time every minute? > > They can also configure their repos with branch.{branch-name}.rebase. Is there any information on how and why to do this? > > > If they are just starting new work, > > they have to fetch and merge to get started. > > No, they don't. I fetch (pull actually) Yes, now I see that my original suggestion was off. I should have said: we should not be shown the remote tracking branch at all. Fetch/merge should be a tedious special case. We should be using pull/push. So the bottom panel should be showing the 5 recent commits on the true remote repo. > > so no last-fetch-time info is needed. > > How often should the background fetch be done to make the fear go away? I guess > in my case it would have to be least than 10 seconds ;) I don't think banging > against a git repo is the best we can do. I don't suggest keeping the info fresh. I am only suggesting that it be fresh when the git status is fresh. The dev understands that git status is only accurate when the pages is loaded. The view of the remote should also be fresh only at that time.
(In reply to comment #4) > > They can also configure their repos with branch.{branch-name}.rebase. > Is there any information on how and why to do this? http://dev.eclipse.org/mhonarc/lists/platform-ui-dev/msg05053.html
We do not reach agreement about the right approach here. Let's discuss it further after M1.
Aligning the target milestone with the blocking bug.
Closing as part of a mass clean up of inactive bugs. Please reopen if this problem still occurs or is relevant to you. For more details see: https://dev.eclipse.org/mhonarc/lists/orion-dev/msg03444.html
