Version Control Questions Megathread (SVN / git / whatever else)

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Version Control Questions Megathread (SVN / git / whatever else)

welcome to hell: Jun 9, 2006

haywire posted:

Anywho, I'm having a bit of an issue with git, basically every time something gets pulled from a repo, git resets the permissions to rwxr--r-- which sucks, because the group (users) needs to be able to work on the files. Why is this happening? How can I stop it?

The permissions used for files in working copy can be controlled with the core.sharedRepository config option. It can be set to group, all, umask, or a mode in octal. The default is to use the umask. It's documented in the git config documentation.

Edit: Apparently I'm wrong and that only applies to the files in the repository itself. Oh well.

welcome to hell fucked around with this message at 09:25 on Sep 25, 2009

# ¿ Sep 25, 2009 08:46

Adbot: ADBOT LOVES YOU

# ¿ May 7, 2024 23:59

welcome to hell: Jun 9, 2006

Unless you want to edit git-svn's binary rev_map files, filter-branch will break git-svn. I've done it, but wouldn't recommend it.

Trying to have people use both systems at the same time is going to be problematic, as a repo meant for use with git-svn is going to look rather different from one meant to be a full conversion. Creating a good conversion of a repository is likely to involve a bit of history rewriting to match git's world view. You also won't want git-svn's ugly revision markers on all of the commit messages. Doing any of that will mostly break git-svn.

# ¿ Jun 3, 2010 17:48

welcome to hell: Jun 9, 2006

SourceForge isn't a terrible choice for distributing software packages, but you'd be insane to use it for anything else.

# ¿ Mar 7, 2012 05:16

welcome to hell: Jun 9, 2006

oiseaux morts 1994 posted:

Unless the diff is not an accurate representation of how it's stored under the hood oh lawd thinking too much about this

The diff isn't how it's stored under the hood. Every commit points to a full snapshot of the files. When you check out different commits, it doesn't have to look at the history at all, only the files in the new commit.

# ¿ Nov 14, 2013 23:09

welcome to hell: Jun 9, 2006

oiseaux morts 1994 posted:

Commits are immutable with the exception of perhaps the metadata like date, or author.

Nope, date and author are immutable too. The commit id is the hash of all of the commit data. If any of that data changes, the hash is different and therefore it is an entirely separate commit.

oiseaux morts 1994 posted:

Checking out a branch just moves HEAD to the same commit as this new branch pointer.

When you check out a branch, HEAD refers to the branch name. If you check out a tag or commit, HEAD points to the commit directly.

oiseaux morts 1994 posted:

3. Does reordering commits mean anything beyond being a tool to make the log look how the developer wants? If we have a tree like:
pre:
C1 <- C2 <- C3 <- C4
then presumably reordering them by "swapping" C1 and C4 using interactive rebase in this case gives:
pre:
[C1] <- C2 <- C3 <- [C4]
               ^
               |--- C4' <- C1'
Where [X] denotes a deleted commit and X' is a copy of X. Although C4' has C3 as a parent, it appears before C2 in the log because the timestamp is also updated?

You are correct on your first two questions.

There are a couple mistakes in your last question. First, the rewritten history would be C2', C3', C4', C1'. Parent commits are part of the commit data, so if they change you get new commits.

Second, a git log would follow the parent relationships for order. The date is only used when you have parallel branches. git log also has a bunch of options for how to order its output. Git commits actually contain two timestamps, an author timestamp and a committer timestamp. They start out the same, but during a rebase the author timestamp will be left unchanged and the committer timestamp will be updated.

# ¿ Nov 15, 2013 09:19

welcome to hell: Jun 9, 2006

oiseaux morts 1994 posted:

But we can go back to a specific commit, and change date, author, commit message, right? Does that mean the original is deleted and a new commit is made? If so, then what if said original commit is a parent of another commit?

A new commit is created, but the original commit still exists in the repository. It's just no longer connected to the branch in any way. Eventually, if no branches or tags refer to the commit (or any child commits) it will get cleaned up.

quote:

So in the below case, if it isn't the timestamp that defines the order, what is the nature specific to one of the parents of C6 (either C4 or C5) that determines the order? Sure, 5 is greater than 4 in this example, but they're just labels in this case, they could easily be called * and / and have no inherent order. Or do the parent attributes for the commit object contain some hitherto unknown information, or is it a property of the graph structure in some way?

Where there is a parent/child relationship, git log will show the child before its parent. In that image, C4 vs C3+C5 don't have a parent/child relationship, so that can't be used for the order. In that case (parallel branches) timestamps will be used. Your earlier example with C1-C4 was an entirely linear history, so timestamps wouldn't be used to order the commits.

# ¿ Nov 15, 2013 11:48

welcome to hell: Jun 9, 2006

Marsol0 posted:

Almost. git commit -a will include untracked files as well, while git add -u; git commit will only include tracked file.

This is incorrect. commit -a does not include untracked files.

# ¿ Nov 27, 2013 09:17

Adbot: ADBOT LOVES YOU

# ¿ May 7, 2024 23:59

welcome to hell: Jun 9, 2006

Empty repos are a special case that git does handle, and will normally allow you to clone. They don't have any branches or commits though, so they don't always behave as you might expect. It's just more straightforward (and possibly more backward compatible) when you clone a repo with real branches/commits. Also, github displays readme files directly below the file listing on the main repo page, so they encourage you to have some form of readme no matter how you create the repo.

When creating new repos I prefer to initialize it and commit locally, then create the repo on github and add that as a remote. But it all amounts to the same thing in the end.

# ¿ Nov 30, 2013 08:17

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Version Control Questions Megathread (SVN / git / whatever else)