|
|
| Re: WorkDir dirty after merge [message #1397653 is a reply to message #1397505] |
Thu, 10 July 2014 01:51   |
 Rolf Meier
Messages: 4
Registered: July 2014 |
Junior Member |
|
|
Hello Matthias
Yes, a lot of zig-zaging going on. I'm sure you'll be horrified (remove spaces):
http :// i.pictr.com / 0551k4co3d.png
I've marked tbase1 and tbase2 that are output by "git merge-base -a t1 t2".
We work with a central repository model and topic branches. We only use merges since we don't trust users to handle rebases correctly. Our build server does automatic weekly merges from main branches "master" to "hotfix" to "update" to "release" and from there into individual topic branches depending on what they're based on.
This leads to a truly convoluted history cluttered by lots of automatic merges but makes life simple for normal users. Any changes to master will flow upwards into all topic branches by the end of the week. After reading up on recursive merges and multiple parents I realize how much work Git does in the background and wonder if the above model is sustainable... (I hope so)
I guess it might be a slight bug in JGit at that. The merge does work correctly, just taints the working directory. If I squash either t1 or t2 or both then the problem goes away which would probably be the simplest/quickest solution. However, I'd really hate to leave even a slight bug in JGit as users tend to have enough issues with trust.
I could set up a VNC session if anyone cared to have a look but I guess that's probably asking a bit too much. I might also try to reproduce the problem with a dummy repository somehow (doubtful that'll work) or debug it myself although I'm probably way in over my head.
As always, I'd appreciate any input (concerning the problem and/or our workflow).
Cheers
Rolf
Edit: Corrected the image. tbase2 was marked incorrectly.
[Updated on: Thu, 10 July 2014 11:27] Report message to a moderator |
|
|
|
|
| Re: WorkDir dirty after merge [message #1398589 is a reply to message #1398061] |
Fri, 11 July 2014 09:31 |
Rolf Meier
Messages: 4
Registered: July 2014 |
Junior Member |
|
|
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 14:24] Report message to a moderator |
|
|
| Re: WorkDir dirty after merge [message #1398987 is a reply to message #1398589] |
Fri, 11 July 2014 22:17 |
Robin Rosenberg
Messages: 332
Registered: July 2009 |
Senior Member |
|
|
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 0.02731 seconds
] 
Search
Help
Register
Login
Home
. Have you looked at 
