<div dir="ltr">Hi,<div class="gmail_extra"><br><div class="gmail_quote">On Sun, Nov 1, 2015 at 1:26 AM, Andrew McCann <span dir="ltr"><<a href="mailto:amccann@gmail.com" target="_blank">amccann@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi all,<div><br></div><div>First, as a new member, it's good to contribute. I've been a user of KDevelop for many years. I am now working to get things working well on OSX.</div><div><br></div><div>For develop & kdevplatform repositories Arcanist is currently configured to commit all 'feature branch' history when 'arc land' is used. When I used the arcanist tool aka 'arc' to commit my most recent diffs it had the surprising effect of committing all of the history of the 'feature branch' as well.  This was unexpected behaviour to me, as my previous use of arcanist has not had this behaviour. I'm of the mind that public history should be somewhat clean, with each commit being a logical change (when possible).</div><div><br></div><div>Apparently this behaviour is not the default behaviour and was configured by adding the "history.immutable" : true configuration to ".arcconfig" in the repository root.  This setting is about controlling the arc workflow, and specifically how feature branches are landed. You can read more about this setting here: <a href="https://secure.phabricator.com/book/phabricator/article/arcanist_new_project/" target="_blank">https://secure.phabricator.com/book/phabricator/article/arcanist_new_project/</a></div><div><br></div><div>This was intentionally configured, so clearly someone gave it some thought.  I just wondered what the ongoing thoughts are on the use of 'arc land'   With the immutable history setting, 'arc land' will make at least 2 commits for every 'arc land'. (one for the feature diff, one for the merge).  </div><div><br></div><div><div>To be clear, I'm not talking about rewriting history of public repository.  Just how the commit history that is generated when working on a given 'diff' in the arcanist workflow. Often there are multiple commits given the code review process.</div></div><div><br></div><div>My personal preference is to keep public history clean, and have just one commit in the public repository per landed "differential".  One can accomplish this now by manually making commits. However, this largely undoes some of the convenience of arcanist.  </div><div><br></div><div>Seems the choices are: </div><div>   1) Don't use arcanist to land changes, manually squash change sets / feature branches, and keep a 'clean' public history.</div><div>   2) Use arcanist, accept multiple-commits per "land"</div><div>   3) Use arcanist, configure to mutate history for 'land"</div></div></blockquote><div><br></div><div>I agree on the 'clean' history, but my definition of the word is likely different from yours. That is the history of the feature branch should not contain any commits that merely make the code compile or fix code-style isues. However I like it if certain conscious decisions are documented as a commit. For example if the feature works fine but it turns out during testing that its not very efficient it would be nice to have a separate commit that improves the efficiency. Or similarly if a particular problem arises that only affects a certain 'environment' (like a particular type of machine setup, or a particular type of data), then a separate commit documenting the fix would be good. Sometimes these things are only discovered after landing the branch, but sometimes they're not.</div><div><br></div><div>So personally I usually cleanup the history via git rebase first and then land that and like to land it with immutable history so that arc land creates a merge commit. (using phabricator at work)</div><div><br></div><div>Unlike Aleix I also like the merge commit from arc land as that gives (more or less) a single point for when the feature was introduced. A merge commit may also make git bisect a bit faster as a whole branch may possibly be excluded from the bisecting.</div><div><br></div><div>Just my 2 cents as someone using phabricator for a while already (though possibly not as extensively as people here will be using it)</div><div><br></div><div>Andreas</div></div></div></div>