When will submodules' horrible UI finally be fixed?
Manually running "git submodule update" after every single command is terrible.
Having the submodule in a modified state with "new commits", with no differentiation about whether what changed is the HEAD of the submodule or the parent ptr is also horrible. Did you forget to commit the submodule change? Or did you forget to "git submodule update"? Who knows??
Git clone of a repo that has submodules shows a clean status! It should say: "missing submodules" or ideally, do a "git submodule update --init" by default, but instead you're left wondering why build doesn't work.
Great, and now how do you reasonably share a dependency between multiple repositories while correctly tracking the exact version of that dependency at each point in history?
The command line is a little obscure (at least, I can never remember the command to pull the latest remote changes first time) but overall the use of them is a lot nicer, for the way I work at least. Being able to have "local" edits to subtrees while still allowing remote updating and colleagues to clone the repo with the local updates is rather useful.
Use the repo tool used by android? I'm not sure bout dependency versions at each point in history since AOSP usually just points to tags or branches directly, but it seems to work for their style of large, multiple git repo projects.
Python at least doesn't provide any reasonable dependency tool for third-party test suite data. I can't really package a third-party test suite as a Python program.
Why can't you do that with the language package manager? In Node you simply change the version number, run npm install, test the changes, either commit or don't.
Very nice. I find Atlassian's information and tutorials on Git to be very well written and approachable. When I first moved from SVN to Git their Workflows guide (https://www.atlassian.com/git/workflows) helped connect the dots and eased the transition.
Is anyone here just as surprised about the existence of "git replace"?
Does it does it do what I think it does -- let you rewrite history and keep the rest of commit ids the same?
I thought that would be impossible up to this point (as in you could re-write all your commits, filter some, presumably with some secret passwords or something, but then you'd end up with different commit ids).
I was hoping that it was just a form of `git merge -s ours` but, you're right, the manpage makes it look a lot scarier.
I read the linked blog post and I still don't see a good use case for git replace. I can think up a lot of potential downsides and sources of mass confusion of course!
So, I second that. Anyone know a good, real-world, use for git replace? The example given in the blog post seems overcomplex. It would be easier and more idiomatic to just use rebase. (Yes, rebasing would change the commit SHAs, but would anybody care?)
You could in principal store the old history in a separate repository then (reasons for this may be that the repo historically contained many binary files, possibly because it’s been converted from an SVN repo). After refactoring and rebasing (Note: You do in fact change the SHAs in this scenario – what they do in the blog post is a rebase+squash/fixup basically.) you prepare a new repo which is much smaller and in which you do all further development.
However, sometimes it may be necessary for developers to do a `git blame` which needs to include the old data or similar. If this happens, you add the historical repo as another remote and `git replace` the oldest commit from the dev repo with the historical repo.
Only a few developers will ever need to use `git replace` in this scenario, so it would not say that it is too confusing. (If it was confusing, I’d say everybody would probably have learned that it exists the hard way…) Maybe think of it as a kind of git submodule but for time.
Sometimes using git replace followed by git filter-branch (so that you wind up with a valid history with all hashes correct) is the best way to get the history you want. This is usually in really extreme cases. ie at Loggly we had a frontend repo that we wound up splitting into media, templates, and webapp repos, and then later decided to put back into a frontend repo. The former operation was pretty easy with filter-branch, but for the latter, I used replace + filter-branch.
The most important update by far has got to be the new date formats, e.g.: `--date=teatime` and `--date="midnight the 12th of october, anno domini 1979"` just rock.
It also takes exactly one search for the username to find out the poster here is the author of the article, and since when has posting one's own articles (whether or not they're posted on your employer's blog) been forbidden?
I was under the impression most links to blogs were submitted by the post author, and this is very common behavior on HN and personally I see nothing wrong with it.
I don't believe posting links to your own blog is prohibited. I've done it a few times and I hope plan to in the future. I just thought the only criteria is that the links should not be "crap".
Reddit's actual policy is that excessive self-submission is verboten. If you're actively participating in reddit threads, self submission is OK - their guideline is no more than 10% of activity.
See also "What is spam?" on http://www.reddit.com/rules which says "OK: Submitting links from your own site, talking with redditors in the comments, and also submitting cool stuff from other sites."
Manually running "git submodule update" after every single command is terrible.
Having the submodule in a modified state with "new commits", with no differentiation about whether what changed is the HEAD of the submodule or the parent ptr is also horrible. Did you forget to commit the submodule change? Or did you forget to "git submodule update"? Who knows??
Git clone of a repo that has submodules shows a clean status! It should say: "missing submodules" or ideally, do a "git submodule update --init" by default, but instead you're left wondering why build doesn't work.