Well, you mean two things:
1) Be able to hide/show current columns
2) Be able to create custom columns, correct? This is slightly more tricky since it can have an impact on the view calculation. I mean, you can create a column but if it takes long to calculate, the entire rendering can be potentially affected.
Uhm... interesting point! :-)
In fact if this was the standard merging would be much simpler :-)
I'll check with the team.
You can already do that with a little bit of scripting.
Why don't you use the "cm ls --tree" and "cm cat" commands to do that? You can use CmdRunner on top of "cm shell" to make it fly. http://codicesoftware.blogspot.com/2012/01/cmdrunner-power.html
What you propose is certainly interesting. The only downside is that so far we never allowed to modify history since we consider 'immutable' history to be a good thing. I mean, as a whole concept I sort of prefer immutable history than being able to edit it.
That being said, there are certainly cases where splitting a checkin makes sense... I'll ask Borja and Rubén, the two main coders behind the entire merge system, to join to this discussion.
You can configure the tool to include what we call 'symbolic info' for each contributor.
It means you can set it up to be invoked from Git so that it adds any meaningful info you want, for instance the names of the branches together with the file names.
That being said, I see your points about the log message, the blame and the log. It is a really good idea. We've to figure out how to get it integrated with the tool but it really makes sense.
Regarding the "self installation": yes, we didn't focus on that yet since we provide a guide to integrate with a bunch of different tools: http://www.semanticmerge.com/sm-guides/main.shtml but as you point is something worth the effort.
21 votespsantosl supported this idea ·
Really good points! I voted up for it too! :-)
Hi Rober! :P
Rewriting history is one of the cool features in Git, but it is somehow counter intuitive in the commercial software development world where you would like version control history to be immutable.
That being said, sounds like a cool thing to do.
Now, is your graph correct? I mean, what D-E-F have to do here? Not sure if I'm missing something.
You can already do that customizing the way how you invoke Semantic. You can specify 'symbolic names' when launching the tool... so it is a matter of setup.
Check semanticmergetool --help
Do you know we just added a Delphi Parser? It can probably help.
Steven, if you look at the window title you'll see the full caption of the tab... does it help?
Won't it be a pain from the CLI?
Which means we need to finish the MacOS X version first... which is something we'll be working on quite sooon! :-)
Michael, this is the kind of thing that your version control tool should let you do, don't you think so?
Why don't you take a look at Plastic SCM (our version control! :-P), I think you'll find your answers there...
Can you give us a little bit more background about it?
Do you mean launching from the CLI or really doing the merge from the CLI?
Also, it would be awesome if the people interested on this is able to join our next webinar: https://www2.gotomeeting.com/register/520572034 so we can discuss about it in detail
Ian, I guess what you need is to solve merge conflicts during gated checkins, correct? Can't you simply invoke semanticmergetool during the gated checkin process?
What do you expect?
I mean, we will be publishing soon how to use it from TFS, so I guess you'll be able to use it inside your environment flawlessly.
We also consider making the entire tool a visual studio plugin, but since the merge tends to be "a modal dialog", I'm not sure it will really fit.
Comments and suggestions will be more than welcome.
Awesome! The initial draft of the semantic merge tool was actually a web based interface, supposed to run in the cloud. But then we tried to make something usable from day one, and today merge is performed on the desktop.
We are committed to come up with something like this, but it will of course greatly depend on customer feedback.
Actually, you can use the "report bug" button on the merge tool to send us the 3 files you detected to have an issue :-)