Closed chadoh closed 10 years ago
chadoh
commented
10 years ago It also completely destroyed my git reflog:
$ git reflog
43bd8e9 HEAD@{0}: clone: from git://github.com/axyz/middleman-zurb-foundation.gitI can't even undo what you've wrought.
chadoh
commented
10 years ago If I'd pushed to github before trying your horrible plugin, I'd be able to blow away my project & re-clone. But I didn't. I think I'll have to start over.
What. The. Hell.
chadoh
commented
10 years ago I'm so angry.
chadoh
commented
10 years ago :-1: :-1: :-1: :-1: :-1: :-1: :-1: :-1: :-1: :-1: :-1: :-1: :-1: :-1:
axyz
commented
10 years ago I'm quite confused about your problem (and about your manners as well...) could you please elaborate on it? What were you trying to do exactly?
Considering that my simple instruction refers to fresh installing the plugin and start over a new blank project, what work could you have lost?
chadoh
commented
10 years ago I'm fairly new to Middleman, but all of the other installers that I've played with could be used to build a new project, or could be used to modify the current project.
I played with Middleman for most of the day on Friday, first trying one, then trying another, using git to undo some changes that the installers made unnecessarily. I did this with the default template, then the blog template. I also tried out the mobile template, running middleman init --template=mobile. That one I didn't like, and used git reset --hard to get rid of it.
Then I tried out yours, confident that if things didn't work out, I'd be able to git reset and make it all ok. However, your installer manipulated my .git files directly, destroying my git history and making it impossible to undo what the installer had done. If I'd had my git history available, I would have been able to see how it changed each file, and kept the parts I needed and reset the others. But I suddenly had an artificial git history, one foisted on me by the installer.
Destroying my git history—that's a horrible thing! I cannot fathom why you would directly manipulate files in my .git directory. Whether it's a fresh install or not, this just strikes me as shockingly poor form.
axyz
commented
10 years ago I'm not sure on how middleman init works internally, but i guess it clones the local git repository of the template in the destination folder, this clearly can lead to conflicts or data loss and i do not think it is a safe way of working to do middleman init on already existent projects. You could have been lucky with your first tests (maybe different filenames and not having git added old files) hower I personally strongly discourage to use middleman and git this way, I'd just start over a new project for each skeleton I would like to test.
However I may be wrong and if there is a doc section talking about using middleman with exisiting git tracked projects please paste me a link so I can check if there are developers recomendation about it.
By the way making this skeleton I've followed the structure of others highly starred skeletons and middleman and zurb guidelines and I'm not informed about options to manage git conflicts.
chadoh
commented
10 years ago It works by only creating project files, and never touching the .git directory. You should never touch someone's .git directory. If I want to use middleman init over & over, I should be able to safely do so, because I'm using git.
I didn't "get lucky" on my first couple tries. It completely changed my Gemfile, and my index.html.erb file, and added other superfluous things that I didn't want or need. But I was able to keep the changes I liked, and remove the ones I didn't like. Because none of them messed with my git history; none of them modified files in .git.
Please tell me if I'm correct: You seem to believe that manipulating .git directly is a fine practice in this case.
I argue that it's NEVER. EVER. ok to mess with someone's git history. I'm completely shocked that you are attempting to justify it.
axyz
commented
10 years ago I don't think that it is a good idea to manipulate your .git directory... I'm just wondering on how my skeleton could do it: clearly the .git directory is not tracked like the other files and considering that the middleman's suggested installation method of skeletons is git cloning them into ~/.middleman dir I simply do not see how could this create a "venomous" .git directory in the skeleton (it just will be a fresh clone).
However I am not a git guru and if you think this is a bug that with no other skeleton occurs, then we have to find out where is the problem: it could be a skeleton bug, a git bug or a middleman init bug (or maybe a mix of the three).
Assuming that the problem is on this skeleton then I ask your and the community's help to find where it is hiding (almost all the skeleton logic should be on config.rb, the rest is just static template itself and bower, gem, and gitignore configs)
However I repeat my request of a middleman documentation about using middleman init on existing projects, because I think that you are correct about the dangerousness of the actual behaviour, but if we found out that at middleman they discourage it or do not consider it then we could eventually be facing a feature request instead of an issue.
chadoh
commented
10 years ago Here are middleman docs that explain that init can be used either in an existing directory or a new one. I do not think this will require a feature request to middleman.
I can help look into the problem a little bit, but not until this Friday.
axyz
commented
10 years ago well, my interpretation of that doc is that you can call middleman init inside an existing "directory" in the way that not specifying a folder name will just scaffold in the current one, but I think that they mean an empty folder in fact.
Assuming that you'd like to scaffold inside an existing project in order to try to convert it to middleman it won't be that easy: your actual work should be inside the source directory and not in the root.
By the way I'm not aware on how the scaffolder manage eventual existing files, and maybe it should warn about possible overwriting and data losses before proceeding.
Anyway any help on a deeper understanding of the problem will be very welcome.
chadoh
commented
10 years ago It doesn't manage conflicts intelligently at all. It just overwrites files if they already exist.
But! If one is armed with git, this doesn't matter so much. Unless the initializer modifies their git.
axyz
commented
10 years ago Here is the point: we have to find out why this could happen. Skeleton are git repositories so, clearly, they have a .git folder inside; by the way if we assume that the initializer copy and overwrite that folders too (and it would be a quite weird behavior) then it should be the same with all the others skeletons too.
Can you please check, when you will have time, if the problem exists with other unofficial skeletons? (maybe the 3 official ones relies on the middleman gem instead of single separated git repos)
plexus
commented
10 years ago This seems to be a Middleman issue, not an issue specific to this template. If I follow the instructions for the biblichor/middleman-blog-bootstrap-template on a folder that already has a .git, the same things happens.
I'm guessing Middleman treats all files in the skeleton dir as equal, including, unfortunately, .git. Your best bet is to report this with Middleman itself, if it hasn't been reported there already, since quite a few projects suggest using git clone to install to ~/.middleman/foo.
$ bundle exec middleman init foo --template=blog-bootstrap
create foo/.editorconfig [0/1845]
identical foo/.git/HEAD
update foo/.git/config
identical foo/.git/description
identical foo/.git/hooks/applypatch-msg.sample
identical foo/.git/hooks/commit-msg.sample
identical foo/.git/hooks/post-update.sample
identical foo/.git/hooks/pre-applypatch.sample
identical foo/.git/hooks/pre-commit.sample
identical foo/.git/hooks/pre-push.sample
identical foo/.git/hooks/pre-rebase.sample
identical foo/.git/hooks/prepare-commit-msg.sample
identical foo/.git/hooks/update.sample
update foo/.git/index
identical foo/.git/info/exclude
update foo/.git/logs/HEAD
update foo/.git/logs/refs/heads/master
create foo/.git/logs/refs/remotes/origin/HEAD
create foo/.git/objects/pack/pack-f1c2f40986452cb5da4f83cc55aed8ead423e6bd.idx
create foo/.git/objects/pack/pack-f1c2f40986452cb5da4f83cc55aed8ead423e6bd.pack
create foo/.git/packed-refs
update foo/.git/refs/heads/master
create foo/.git/refs/remotes/origin/HEAD
update foo/.gitignore
create foo/.project
update foo/Gemfile
create foo/Gemfile.lock
create foo/LICENSE.md
create foo/README.md
create foo/bower.json
create foo/config.rb
create foo/helpers/meta_helper.rb
create foo/source/calendar.html.slim
create foo/source/css/_imports.css.scss.erb
create foo/source/css/_settings.scss
create foo/source/css/all.scss
create foo/source/feed.xml.builder
create foo/source/images/sample-theme-flatly.png
create foo/source/index.html.slim
create foo/source/js/all.js
create foo/source/js/app.coffee
create foo/source/js/ie8.js
create foo/source/layouts/layout.slim
create foo/source/partials/_analytics.slim
create foo/source/partials/_header.slim
create foo/source/partials/_sidebar.slim
create foo/source/posts/2014-01-01-example-article.html.md
create foo/source/posts/2014-01-02-example-article.html.md
create foo/source/posts/2014-01-03-example-article.html.md
create foo/source/robots.txt.erb
create foo/source/sitemap.xml.builder
create foo/source/tag.html.slimHooow about that.
Ok, well, that gives me a good workaround—clone, but delete the .git folder from the skeleton dir after. Or just download the tar ball. I'll do this Friday so I can actually try out your initializer. I'll also open an issue with middleman.
Thank you for helping figure out the problem. Sorry for all the racket.
axyz
commented
10 years ago no problem, I guess the best thing to do is to make the initializer ignore the .git dir to not loose the possibility to use the git clone one-liner that also permit easy and fast updates of the templates.
thanks plexus for your quick and effective help.
plexus
commented
10 years ago :+1: happy to know about this glitch now, before it bites me as well!
I followed your directions to install this and got this:
Then, even though it updated a bunch of my project files, since it directly manipulated my .git directory, my git can't even tell me what changed.
This was horrible.