| WorkDir dirty after merge [message #1397170] |
Wed, 09 July 2014 05:59  |
Eclipse User |
|
|
|
Hey everyone
I'm posting here and not on the bugtracker since I'm unsure how to proceed (will open a proper ticket later if there's merit).
I've got the following situation:
When I merge two specific branches "t1" and "t2", the merge works without conflicts but leaves the working directory dirty.
About 11 files show up as modified immediately after the merge went through. The files are actually old versions neither contained in t1 nor t2 (nor the resulting merge) but probably in an ancestor commit along the merge path.
Even worse, when there is an actual conflict, those modified files will get displayed in the upper part of the "staged files" view along with the red marked conflicting files. Less knowledgeable users might happily drag these down into the staged area and commit them along with everything else, resulting in faulty merges and making it difficult to merge the new files back in from other branches without touching everything (bad idea).
This happens not just on my machine but for everyone who has a clone of the repository. I'm using EGit/JGit 3.3.0.201403021825-r but also tried 3.4.1.201406201815-r to the same effect.
Both Git for Windows and the official command-line Git on Linux work fine.
Did anyone ever see something similar? I'm willing to go to quite some length to resolve this since our company has been using EGit/JGit for some time and we are really quite happy with it.
Unfortunately, the repository is private so I can't upload it for anyone else to use for testing. We use a build server in the background which does automated merges and results in a really messy/complicated history. So I wouldn't be surprised if the problem is only triggered by our specific branch constellation and may not likely occur in normal projects.
Any ideas or suggestions would be most welcome. I will gladly provide more info or even debug the code when pointed in the right direction...
Best wishes
Rolf
|
|
|
|
|
|
|
| Re: WorkDir dirty after merge [message #1398589 is a reply to message #1398061] |
Fri, 11 July 2014 05:31  |
| Eclipse User |
|
|
|
I know the history is a complete mess. The graph confuses more than it helps.
When we introduced Git, it turned out that a clean history simply wasn't a high priority. We have about 30 to 40 topic branches at any time. We use a central repository for backup and syncing between users. When a branch is done, it gets tested by someone else, though not by looking at the code. We have a release cycle of 3 months, although hotfixes are automatically released, delayed by two weeks. When a release is being prepared, only tested branches get merged.
Developers are more comfortable knowing their long-running topic branches don't diverge too much from the code base so we previously did nightly automatic merges (recently switched to weekly). That's what blows up the history in this manner.
Using rebases instead of merges would greatly simplify everything but I'm not sure people can handle that properly. Besides, things have worked out great for us so far. Automatic merges can always be filtered out of the history if need be. Still, I'd love to hear about a better solution or get a few tips how to produce a cleaner history.
I'm not sure we can use Gerrit as it seems tailored to the needs of open-source projects. We have too few developers to code review and possibly reject anyone's work.
[Updated on: Fri, 11 July 2014 10:24] by Moderator |
|
|
| Re: WorkDir dirty after merge [message #1398987 is a reply to message #1398589] |
Fri, 11 July 2014 18:17 |
| Eclipse User |
|
|
|
Rolf Meier skrev 2014-07-11 11.31:
> I know the history is a complete mess. The graph confuses more than it helps.
>
> When we introduced Git, it turned out that a clean history simply wasn't a high priority. We have about 30 to 40 topic branches at any time. We use a central repository for
> backup and syncing between users. When a branch is done, it gets tested by someone else, though not by looking at the code. We have a release cycle of 3 months, although
> hotfixes are automatically released, delayed by two weeks. When a release is being prepared, only tested branches get merged.
>
> Developers are more comfortable knowing their long-running topic branches don't diverge too much from the code base so we previously did nightly automatic merges (recently
> switched to weekly). That's what blows up the history in this manner.
>
> Using rebases instead of merges would greatly simplify everything but I'm not sure people can handle that properly. Besides, things have worked out great for us so far.
If they can handle merge, they can probably handle rebase. Some education doesn't hurt, but basically it's the same problem.
> Automatic merges can always be filtered out of the history if need be. Still, I'd love to hear about a better solution or get a few tips how to produce a cleaner history.
>
> I'm not sure we can use Gerrit as it seems tailored to the needs of open-source projects. We have too few developers to code review and possibly reject anyone's work.
Devs can approve their own work (well you can set it up anyway you want). E.g. in EGit/JGit itself committers can submit their own changes, but we frown on it when it happens.
> Concerning the problem: I tried various ways to filter out all except a single subdirectory but it always lead to greatly simplified graphs where the problem is no longer
> reproducible. Is there any way to remove most files but leave the commit/merge structure intact?
No not now, but I think it's a sane idea.
> The problem is that the commit graph is so complicated that it's probably hard to understand where exactly JGit might do something wrong. In that sense, we might really be
> stress testing JGit in more ways than one.
Lots of merges do lead to complicated graphs, which is one reason for preferring rebase and fast-forward merging. Gitk, unlike JGit, has some tricks to try to visually
simplify the graph by omitting details. It doesn't make the graph less complicated though.
That aside we've had bugs in the graph layout closed only recently.
-- robin
|
|
|
|
|
Powered by
FUDForum. Page generated in 1.05315 seconds
Home
. Have you looked at 
