venta

That is a good point.

Though to be honest, I don't really like that behaviour either, since I usually end up resolving the conflict, staging the file to mark it resolved, and then un-staging it again.

Our of curiosity, what is your VCS of choice? As far as I can tell, everyone always hates the one they use :-)

From:

simont

Why do you unstage it again? I'm not sure what purpose that serves – wouldn't you then have to re-stage it all again (perhaps with git commit -a) when you come to commit the merge? I'm getting the feeling that there's some extra part to your workflow that I don't understand, which needs things not to be staged for some other reason.

I didn't find any option in git help pull to not scatter failed-merge detritus across the index, but I suppose if you wanted to just unstage everything after a failed merge then there's probably a fairly easy git checkout-index rune.

My VCS of choice is git :-) I've always felt that git is the anti-Marmite: the correct response is to both love and hate it, at the same time. When I have to use anything else, I wish it had all the advantages of git, but when I use git, I get annoyed with it constantly...

From:

Currently, I have some long-term work going on, which may cause conflicts to do with incoming merges (as I take other people's changes) but which I'm not ready to commit yet. I will ultimately want to re-stage the resolved file and commit it, but there's more work to be done and a chance of doing several unrelated commits before I get to that point. This is partly brought on my own head by not using branches as much as I should. Largely because I constantly forget which branch I'm in and then terrible things happen (which would, of course, become less of a problem if I did it more rather than avoiding it...)

I read "I've not been with git since the beginning" as meaning "In the beginning I was with git, now I am not" rather than "I am with git, but was not at the beginning" so thought you'd moved on to something preferable. Or less hatable :)

From:

simont

Sorry about my confusing wording. Yes, I meant to say that I'm only a recent migrant to git, so I wasn't around when early design decisions got made, and wouldn't have heard of any discussions about them at the time on mailing lists or in changelogs etc.

From:

I blame the English language, not you!

From:

hirez.livejournal.com

Oh god. I think I've gone from PVCS to CVS (to hating SVN as an admin and thus rarely using it) to git.

Branch more. Merge more. Branches that are old enough to vote are The Devil no matter what VCS you're using.

Ok, so I have one that's six months old because Other People, but I fully accept that if I don't keep refreshing it from master I will be the one who is sad.

(Also, round here, people who emit thumping great merge-requests get them bounced.)

From:

Merge requests that thump here don't get bounced, but they do incur displeasure.

In my particular case, my long-term work is a large piece of work that will result in not a huge amount of code. And would be a lot less long-term if I didn't get interrupted by other things on a daily basis. So I don't think the merge will be all that horrible when it comes :-) I'm merging unrelated bits as I go.

But you're almost certainly correct that I should branch more.

From:

hirez.livejournal.com

I suspect our work/code types are quite different.

That said, we used to have to cope with devs emitting vast diffs and then being surprised we got rather narky when the relevant website exploded. Once we allowed/made them their own deploys, it could all happen faster and so the diffs are (usually) smaller.

These days, we're one dev/ops amorphous blob, so you are allowed/expected to go 'Too many notes, Mozart. Make it simpler and show me the tests', which has make progress entirely not antagonistic.

Apart from one 'team' 'lead' on another floor, who really doesn't see why he should share with the other children. Boy howdy, he's going to find out how things work the hard way.. :)

From:

I tend to prefer "rebase my commits on top when you pull" (using Eclipse, I do all day-to-day VCS operations within my IDE; most of my coworkers use IntelliJ, seem to prefer merge over rebase, and use Git on the command line). This is a Git setting, but I'm not sure what its underlying name is. I don't recognise the problem you describe, which might mean ths avoids it; though perhaps more probable is that I tend to have committed locally before pulling, so there are no unstaged files at the time. (Commit early, commit and rebase often, and don't be afraid of squashing commits when you want to tidy up before you push. And if it's not open source, don't be afraid of force-pushing so long as anyone else who's likely to have a copy of your branch knows about it. Are there any rules I haven't broken?).

From:

don't be afraid of squashing commits

I am mostly afraid of everything with git. A typo or a not-very-well-understood command line can have such... surprising and far-reaching consequences :)

From:

Yes, Git can be unforgiving ... I had to make the jump straight from CVS to Git about 18 months ago and some aspects were quite disorienting. But I'm more comfortable now and it usually does what I expect it to.

From:

octalbunny.livejournal.com

The command-line git tools recognise "branchname@{ten.minutes.ago}" for where your branch was before, and you can create new a new branch from that so that it appears in the GUI tool. I normally create a local temporary branch before doing a history rewrite that I'm not certain about.

The help pages for this syntax are git-reflog and git-rev-parse.

From:

pm215

The awkward thing about trying to give advice about git is that it allows a wide range of different workflows, most of which will work to at least some extent, so any particular bit of advice might or might not fit into whatever else the recipient is already doing...

That said, I think the thing I would suggest not doing is trying to do a merge when you have uncommitted local changes. If the merge doesn't work then things are going to get very confused between the changes in your working tree which need to be committed as part of the merge commit to resolve conflicts, and changes in your working tree which you didn't want to commit in the merge at all. (This is why git is staging modified files, I think -- it expects them to be modified because they're merge-conflicts that got resolved either automatically or manually.)

There are several ways you can avoid having uncommitted local changes when you merge. The simplest I think is to use 'git stash', which will let you squirrel away your local changes before trying a merge; then you can 'git stash pop' to reapply them afterwards (which might give conflicts that need resolving at that point, of course). Or you can go more serious and start maintaining your local changes as effectively a stack of patches in a set of git commits on a branch that you rebase onto the top of whatever upstream is now. (There are also extra tooling/wrapper scripts that can help with this; I use stgit and like it a lot because practically my whole interaction with git is "maintain, update and edit patch series". But it is a whole bunch of extra commands to get confused with, so I'm always slightly hesitant about recommending it to people.)

From:

In theory I use git stash. However, I am not terribly organised, so it often goes:

Me: right, ready! Commit these files, and push them.
Git. No.
Me: Why not?
Git: New stuff in the repo. Try pulling.
Me: Oh, all right.
Git: Ha! Merge conflict, I've staged everything!
Me: Dammit, should have stashed.

Every so often I think I really should get to grips properly with git, but I always get instantly bogged down reading about it, because everything basically reads like this: http://git-man-page-generator.lokaltog.net/

From:

Aha! Maybe you should not think of commit and push as a single step. You should be able to commit locally regardless of changes in a remote repo. Commit, then pull and resolve conflicts, then push.

From:

I don't really think of them as a single step, I was just trying to stop my dialogue getting too long :)

From:

You do know about http://git-scm.com/book/en/v2 ?

From:

I'm not sure that I've tried that reference specifically - I'll give it a go if you recommend it!

From:

We cheat.

I use tortoisegit for a lot of my day to day git stuff, but for merges and diffs, we've set up beyond compare to do the changes. If you haven't used Beyond Compare or Tortoise git they are wonderful tools. Beyond compare is really useful when you are doing mass file comparrisons, eg working out what has changed on a website and which changes you want to bring across. Only downside is it defaults to timestamp rather than content comparrison but a quick change of the options of a compare does wonders.

https://www.youtube.com/watch?v=pp2S2lHjzZI
https://www.youtube.com/watch?v=eGAyWvstKCI

From:

I've used TortoiseSVN in a previous job, which I'm guessing is related. I can't now remember why, but I avoided the TortoiseSVN merge tool like the plague - I think someone cleverer than me had written a load of helper scripts to deal with our particular set-up, and perhaps they didn't play nicely with Tortoise.

Most of the time I'm dealing with tiny numbers of files at once (say <15) so doing things manually isn't really much of an issue. Thanks for the recommendations, though, I'll have a look!

From:

Google how to set up Beyond compare in TortoiseGit - it isn't intuitive to set up but make life so much easier (and now merges and resolving them are easy).

From:

I'm just going to mention

ao_lai so that he finds this comment, because I think he might want to read it :)

From:

Just be aware beyond compare costs money - think it is about $30-40 but it does make life a lot easier (it has a 1 month trial).

From:

Let me know how you get on with it (out of interest)

From:

Tortoisegit and tortoisesvn are by the same people.

From:

bateleur.livejournal.com

Very useful, this thread.

Occasionally I think that maybe I should be using a VCS instead of my horribly primitive habit of zipping complete source trees and archiving them. Reading about other people's VCS experiences is an important reminder of why I stopped using them. :-P

From:

Since you are (I think?) largely working alone these days, zipping probably works fine :) Though when I finally get round to those website updates I'm meant to be doing, I had been considering using git just for ease of deploying files.

Also hello, I didn't think you read LJ any more!

From:

bateleur.livejournal.com

I don't read it regularly anymore, but I come back from time to time when I remember. I still miss it.

From:

Y'know, if all the people who said they miss LJ could be persuaded to come back, no-one would have to miss it :)

From:

bateleur.livejournal.com

It's true. But I'm not persuaded, because I left looong after the tumbleweed arrived.

Some people write just to keep journals, which I respect, but I use social media mainly to communicate and that doesn't work well if nobody sees the posts. Crosslinking between services sort of works, but means everyone has to have accounts on both services or you can't lock stuff (not a problem, I usually post public) and the intended audience for posts on both has to overlap (is a problem for me).

From: