git: automatically add/remove/rename files?

[Red Squirrel]

I'm working on setting up git for a project between me and someone else as it will make it much easier to sync files between each other instead of sending stuff back and forth through email.

Problem I see is you still need to call git commands such as git add when you add a new file or folder. Is there a catch all command to just automate that? I just want it to compare the file structure with the repo, and if nothing clashes, then it just syncs the changes. New files, deleted files, etc. Or is git not the right tool for this?

 

[paperwastage]

looks like you need something like DropBox for teams?

git isn't the right tool for this...

 

[purbeast0]

git doesn't care about folders/directories. you can't commit empty directories. it only will create them if there is a file inside of it.

i'm not really sure what you are asking about a catch all command to automate something. what are you wanting to automate? do you mean like you add a bunch of new files, and want to do a batch "git add" command?

http://stackoverflow.com/questions/572549/difference-between-git-add-a-and-git-add

i'm not sure what you mean about "syncing changes" either.

with git, if you want, there is a master repo. then when you do a clone, you create a local repo.

say your buddy makes changes locally to his own repo. he then does a 'git push' to push those changes to the remote repo. now the remote repo and yours will be different. if you want his most recent changes, you will do a 'git pull'.

if you however have changes locally, it will not let you do a pull until you either stash your changes or commit your changes. if you commit your changes, you will then want to do a 'git pull rebase' instead. what this does, is it will try to put your changes ON TOP of the changes that are currently in the remote repo. if there are conflicts, it will tell you and you will have to resolve them.

git didn't really "click" for me personally until i saw it drawn out and understood visually what was going on. perhaps something like this could help you get it a bit more.

https://marklodato.github.io/visual-git-guide/index-en.html

 

[dave_the_nerd]

If your OS supports something like Folder Actions on OS X, you could add git commands (git add . && git commit -m 'newfiles' && git push) to a folder action.

But in general, I'm agreeing with the "You should use DropBox" idea.

 

[Red Squirrel]

By syncing I basically mean if I create a new file, I want that file to automatically be included when I do commit -a and git push. Then when my friend does git pull he gets that file or if I delete a file, same idea, the file gets deleted from his repo. I have a central "git server" that acts as the master repository that we both push/pull to/from. The idea is that rather than manually sending each other our changes we want to automate that process.

Currently it seems any time you add or delete files you need to call the respective git command on the file or it will get ignored. I just need a way (without relying on a 3rd party service) to sync changes between each of our repositories.

Edit: Actually it looks like git add -a may be what I want. What about when I delete files, is there a way to handle that?

Basically once we have this setup I'll probably have a ./sync script that we just run and it does everything to sync our changes to the main repo by calling git commit -a and git push and any other command needed. But I'm almost wondering if there are better ways and that git is not the right tool for this. I just assumed that keeping project repos in sync so everyone is coding on the same page was the point of it.

As a side note, does the windows version of git support SSH with public key auth? I don't want to actually open up the git port on the server, just SSH and make it use a public key. I have this working for myself in Linux, but my friend is using Windows.

 

[purbeast0]

you're going to need a 'git commit' message in there after the 'git add' command. calling 'git add' stages your changes, meaning that those files are ready to be committed. that is why you can have new/modified files in your git directory, however until you add/stage them, they won't be in line to be committed to the repo.

i'd also recommend adding a 'git pull rebase' in there between your commit and push methods.

so in my opinion, this is what you would want.

git add (this will stage the local changes in the git directory - use whatever flags you need)
git commit (this will actually commit them to your local repo on your machine)
git pull rebase (this will make sure that you have the latest code from the remote repo and try to replay your changes on top of this - could have a conflict here if you and your buddy modify the same code)
git push (push your changes out to the remote server)

also, if you delete a file locally, then do 'git add', it will stage the deletion of that file, so when you do a git commit, it will delete it from the local repo.

i'm not 100% sure because i'm not knowledgable of the whole security/SSL stuff but i'm pretty confident it can do what you want it to do on windows. just make sure your buddy on windows installs git properly and runs his commands from the git bash command line. on windows i actually use 2 tools for git - tortoisegit and the command line. tortoisegit i find easier to use to commit changes, as it does the add/commit all in one step in a gui, and i also like it better for reverting changes, looking at the logs, repo browsing, and diff'ing. the command line though is all i will use for rebasing, cherrypicking, pulling, and pushing. the GUI's sometimes will do multiple steps in 1 click which can cause for some funky reflogs.

and if you don't understand git immediately, trust me, you are in the norm. it took me quite a while to understand how it actually worked and what was going on, and i'm still learning things in odd situations. coming from something like svn it's just a completely different beast and more complex, but a whole lot more powerful.

 

[Red Squirrel]

Ah good to know about git pull rebase. I usually just do git pull. What does rebase do, does it just check if it's different without actually pulling?

Also good to know that git add will handle deletes. So I should be good to go then. We're not actually using it yet, well I've been using it to get used to it, but I still need to get him setup to use it too. Still fairly new to the idea of git or programs of that nature but figured it's something I want to start using more, even for some of my own personal projects.

I have not really played with having branches yet, but that's something I plan to play with too which will come in handy even for my own projects that I'm the sole dev.

 

[purbeast0]

so rebase is kind of a weird concept to understand, it is very easy to understand when drawn out though.

say you're head is currently at revision A. your remote repo is currently at A. your buddy is currently at A.

your buddy then makes a change locally to his repo and is now at B. he makes another change and is now locally at C.

your buddy then pushes his changes to the remote branch. so now you have ...

you are at A, remote is at C, and your buddy is at C.

now you make a change to your local branch and commit it locally. now you are at D.

so now if you go to push your changes, it will not let you, because you are behind the remote branch. this is when you will want to do a 'git pull rebase'.

what this will do (in one command that will either succeed or fail), is pull your current repo to C, and it will then attempt to commit your changes on top of C. so you are basically rewriting history (locally) at this point. if there are no conflicts, it will then put your change D (locally) on top of C. if there are conflicts you will manually have to resolve them before you can continue with the pull/rebase process. there will be messages in the command line if you have issues and it tells you how to resolve them.

after it succeeds, your local repo will have changed from A->D, to A->B->C->D.

and since the remote branch is A->B->C you can now push your change cleanly to the remote repo, which will then have A->B->C->D afterwards.

so does that make sense? it took me quite a while to understand rebasing and i didn't fully "get" it until my coworker drew it on a whiteboard for me. merging is a different beast, but merging is actually very easy with the rebase and merge commands. you literally just rebase your branch with the base-branch, and then merge that back into the base-branch and it will be a smooth process (other than resolving conflicts with the rebase). i like to use the no-ff flag when merging branches because you can see a very fine line of where the branch was merged in when looking at the history in the log.

this example is also only with 2 people and very few commits. but in the real world, you can have a lot more commits when doing these rebase processes. in that example, say you committed E, F, G, H, I, J, K after D. all of those commits will then be rebased on top of B and C in that example, and if your buddy had committed a lot more commits, well you can see why there is a chance of more conflicts and things that need to be resolved.

at work i've had branches out for over a month that i constantly rebase with develop, and by the end of the feature being finished, i have like 60 commits that have to be rebased with develop. usually it's pretty smooth though since i rebase frequently (every day or so) so there won't be many conflicts typically.

 

[Crusty]

I've found http://pcottle.github.io/learnGitBranching/ to be the best tool for teaching new people what git is all about.

I've also found the slides available at http://gitolite.com/gcs.html#(1) to be very informative about some of the more inner workings of git.

The concepts behind git are really simple, there's just a lot of terminology you need to grasp before you can really 'get it'.

 

[Red Squirrel]

Ahhh I think I understand now so basically it will just resync my local with the server before my commit is applied, and deal with any conflicts.

But yeah I need to read up further on it too anyway, I do have the basic usage down path.

Typically we try to avoid working on same files at same time so conflicts should not be too much of an issue.

 

[veri745]

I've found http://pcottle.github.io/learnGitBranching/ to be the best tool for teaching new people what git is all about.

I've also found the slides available at http://gitolite.com/gcs.html#(1) to be very informative about some of the more inner workings of git.

The concepts behind git are really simple, there's just a lot of terminology you need to grasp before you can really 'get it'.

Great tutorial, this is what I send to anyone new to git

 

[IHateMyJob2004]

i went from CVS to Git. There were times I read what things meant (like rebase) for 1-2 hours.

Once you learn it, CVS will make you cry.

What IDE are you using? Does it have Git Integration?

 

[Red Squirrel]

I just use Kate, though I'm looking at moving towards Codeblocks as kate has lot of bugs such as a lag bug where it's unusable over NFS if there's any kind of high IO activity going on. Basically it writes every individual character to disk as you type. I run git off the dev server (basically a glorified file server for development, it has some master scripts such as to push projects from dev to test to prod) as that's where all my code is, though I'm wondering if I might be better off running it locally. All the git related config will still reside on the server anyway.

We don't work much on this project, my friend has not gotten around to setting himself up yet with it so I've been using it alone (mostly so I can get used to the process). Once we're both using it it will go better as right now we send each other files by email and manually place them where they go, kinda a pain in the ass.

I have read some of the tutorials but I have not really gotten around to playing with branching but once I get comfortable with it I'll probably start using it for even my own individual projects, as the branching is where it can come in handy as well if you want to try something and revert back if it fails.

I like the way git is structured in that you can have a simple local repository, or a git server, or just a bunch of repositories that can update with each other. It opens up lot of doors for different situations from single dev to multiple devs.

 

[Maximilian]

what this will do (in one command that will either succeed or fail), is pull your current repo to C, and it will then attempt to commit your changes on top of C. so you are basically rewriting history (locally) at this point. if there are no conflicts, it will then put your change D (locally) on top of C. if there are conflicts you will manually have to resolve them before you can continue with the pull/rebase process. there will be messages in the command line if you have issues and it tells you how to resolve them.

Would two people working on the exact same file cause a conflict?

 

[purbeast0]

Would two people working on the exact same file cause a conflict?

it all depends on where their changes in the file are made. if it's literally the same line of code both people changed, it will cause a conflict and will have to be manually resolved. if one person changed the first line in the file and the other changed the last line in the file, it will auto-resolve.