2

Been using git for a little bit now, but only the basic features.

In order to switch to Textmate and keep the cool local history feature that Eclipse had, I did this. Which is working great.

But now I'm working on a team with a private github repository. I don't want to pollute the team with my full local history of useless commits.

I know there are some tools to edit my commits, but:

git rebase -i

You asked me to rebase without telling me which branch you want to rebase against,

SNIP

What branch? :)

So I'm wondering if you have tips on how to manage all this. I'd like to combine all commits for one file into one commit max. And edit the message so it says something useful.

Thanks!

Community
  • 1
  • 1
joedevon
  • 2,649
  • 4
  • 28
  • 43
  • Maybe unhook `git commit` from your Textmate save and commit whenever you feel like it? – Shahbaz Dec 06 '11 at 18:00
  • 3
    In truth, a commit per every save is really not a good idea. One might save ten times a minute, which creates a lot of incomplete useless-and-misleading commits. – Shahbaz Dec 06 '11 at 18:01
  • I prefer to have a lot of incomplete and useless/misleading commits in my personal repository than lose everything if I overwrite a file by mistake. But my goal is to not force those commits on the entire team :) – joedevon Dec 06 '11 at 21:47
  • A commit per save probably isn't ideal, and will lead to a lot of subsequent `rebase -i` to squash and split commits. It's still far better than the other extreme, though: committing very rarely, and ending up with a dozen distinct changes lumped into one commit. – Cascabel Dec 06 '11 at 21:55
  • I was hoping there was a workaround, but perhaps not. Shame, I have a bunch of projects this worked great on, but I may have to unhook the save thing. Or at least not default to it. – joedevon Dec 06 '11 at 22:01
  • @joedevon, I don't know how you code, but mistakenly deleting a file you're working on is very unlikely. I'm not against committing often, but I recommend committing at least when the code is compilable or you got something fixed, or a new feature is written (even if not tested). You know, something meaningful to continue working on, rather than code that has a line cut in the middle. I personally commit between 1 to 5~6 times a day and never had a problem. – Shahbaz Dec 06 '11 at 23:05
  • @Shahbaz It was just an example. This is the one feature I really love in Eclipse. You don't use it often, but when you need it, it's invaluable. Not to mention, when I'm not on a team, I don't have an external repository, so this was a good hack. I'll probably be removing it though because of git push. – joedevon Dec 06 '11 at 23:38

1 Answers1

5
git rebase -i

expects you tell it what range of commits to work on. The most common use is

git rebase -i HEAD~4

which would allow you to "edit" the last 4 commits in the current checked out branch.

I'm not sure why you would want to do this "per file". Also, 'rebase -i' will give you headaches if you have merges in there. From what I can infer, you can do this:

Set the current commit to be at the start of your changes, but keep the working directory as is.

git reset --mixed HEAD~10

This would move you back to where you started if you had 10 commits for your changes. "mixed" will ensure that you don't stage any of those changes and the index is clean.

Then, commit changes to each individual file:

git add path/to/one/of/the/files/file.txt
git commit -m "added feature X to file.txt"

repeat for the rest of the files. Inspect along the way with git status.

When you push, you may need to add the -f option (--force) if you already pushed some of those commits. If others were working off of those commits, let them know you did this. They will have to rebase their changes.

user229044
  • 232,980
  • 40
  • 330
  • 338
Adam Dymitruk
  • 124,556
  • 26
  • 146
  • 141
  • +1, with a few notes: `--mixed` is the default for `git reset`, and if you already pushed some of these commits, then you should probably just not try to edit them. It sounds like you and others may not be the most experienced with Git, and a force-update is a great way to confuse people. (Also FYI Adam: http://stackoverflow.com/faq#signatures) – Cascabel Dec 06 '11 at 20:01
  • Playing with your suggestion I did: "$ git rebase -i HEAD~4 fatal: Needed a single revision invalid upstream HEAD~4" >>I'm not sure why you would want to do this "per file". << Not necessarily per file, but I just want to get rid of the useless commits. @Jefromi, Right! Definitely don't want to edit pushed files! I hope there's some way to get a good workflow. – joedevon Dec 06 '11 at 21:49
  • @joedevon: `HEAD~4` should only be invalid if there are fewer than four commits in your repository. Have a look at your history, make sure things are sane, and worst case, paste in an SHA1 instead. Once you do work out that kink, you might also try searching around for other questions about interactive rebase (or just reading documentation), since it's a pretty powerful tool, and providing a full description is out of the scope of this question/answer. – Cascabel Dec 06 '11 at 21:53
  • Thanks @Jefromi. Indeed, I was in a test directory, that's why it failed. P.S. I did read other questions and some of the documentation before asking here, but it's a bit overwhelming (and I need to git push today). Just wanted some more general direction. Will def. read more of the docs. – joedevon Dec 06 '11 at 22:00