|
Plorkyeran posted:The direct equivalent of that would be <Import Project="$(MSBuildThisFileDirectory)userconfig\*.props" /> in your default config property sheet. If there's some way to make these new fields referenceable by multiple projects, this is exactly what I want. If there's not, it still looks like the best option. But how do I actually do it? Google is impossible here.
|
#
?
Nov 14, 2013 17:47
|
|
|
|
| # ? May 12, 2024 16:24 |
|
|
GrumpyDoctor posted:If there's some way to make these new fields referenceable by multiple projects, this is exactly what I want. If there's not, it still looks like the best option. But how do I actually do it? Google is impossible here. Cross-project settings aren't directly supported, but you can import the user settings file from one project in the other ones. Getting this all working will probably require a nontrivial amount of time fiddling with include orders and cursing msbuild's miserable documentation.
|
|
#
?
Nov 14, 2013 18:05
|
|
|
Definitely I've got the model in my head wrong, but allow me to make assumptions so I can correct them as I get them wrong.Vanadium posted:Each commit knows it parent(s). Given a commit you can always follow the ancestry chain upwards. This image from the git book may be confusing me, then:  It implies that C6 has two parents. If that were the case, which path should C6 follow? Or does the merge commit change the commit's parents so now C5 points to C4 points to C3? If so, then the iss53 branch still has C5 pointing to C3 - are commits allowed to store more than one pointer to a parent, depending on branch? Evidently not, because if I checked out C5 as a tag, then how does C5 decide to point to C4 or C3?
|
|
#
?
Nov 14, 2013 18:35
|
|
|
oiseaux morts 1994 posted:It implies that C6 has two parents. If that were the case, which path should C6 follow? Or does the merge commit change the commit's parents so now C5 points to C4 points to C3? oiseaux morts 1994 posted:Evidently not, because if I checked out C5 as a tag, then how does C5 decide to point to C4 or C3?
|
|
#
?
Nov 14, 2013 18:43
|
|
|
oiseaux morts 1994 posted:It implies that C6 has two parents. If that were the case, which path should C6 follow? Or does the merge commit change the commit's parents so now C5 points to C4 points to C3? Yes, merge commits have multiple parents. That's what a merge commit is, by definition: a commit that ties together multiple lines of development by having multiple parents. oiseaux morts 1994 posted:If so, then the iss53 branch still has C5 pointing to C3 - are commits allowed to store more than one pointer to a parent, depending on branch? Evidently not, because if I checked out C5 as a tag, then how does C5 decide to point to C4 or C3? Commits don't point to different parents "depending on branch". Commits have no notion of what branch they're on. A Git "branch" is merely a pointer to a commit and nothing more. C5 has C3 as its sole parent, and always will. It doesn't decide to point to C4 or C3. It just always points to C3. It doesn't matter what branch you're on, whether you check out a tag, or whatever other scenario you can contrive.
|
|
#
?
Nov 14, 2013 18:43
|
|
|
oiseaux morts 1994 posted:It implies that C6 has two parents. oiseaux morts 1994 posted:If that were the case, which path should C6 follow? oiseaux morts 1994 posted:Or does the merge commit change the commit's parents so now C5 points to C4 points to C3? oiseaux morts 1994 posted:If so, then the iss53 branch still has C5 pointing to C3 - are commits allowed to store more than one pointer to a parent, depending on branch? Evidently not, because if I checked out C5 as a tag, then how does C5 decide to point to C4 or C3?
|
|
#
?
Nov 14, 2013 18:44
|
|
|
this is cool, now i just have some posts to point at when people ask me why i prefer svn to git
|
|
#
?
Nov 14, 2013 19:46
|
|
|
I agree, anything that anybody has ever been confused by is an unworkable system.
|
|
#
?
Nov 14, 2013 20:02
|
|
|
Opinion Haver posted:I agree, anything that anybody has ever been confused by is an unworkable system. i have a lot of complex things in my job, i dont need version control to be another one.
|
|
#
?
Nov 14, 2013 20:10
|
|
|
A dag of immutable objects with pointers to various objects in the graph should not be a "complex thing" for a programmer.
|
|
#
?
Nov 14, 2013 20:22
|
|
|
oh ok I guess we're pretending that git is just as simple as a versioned file system here, sorry, I'll find my own way out
|
|
#
?
Nov 14, 2013 20:36
|
|
|
Plorkyeran posted:A dag of immutable objects with pointers to various objects in the graph should not be a "complex thing" for a programmer. This. And use hg to get essentially the same featureset in a wrapper that is not explicitly designed to make you feel stupid.
|
|
#
?
Nov 14, 2013 20:54
|
|
|
copy a directory? no, I'll just mentally traverse this dag. oh also the commits are just meaningless hashes. this is so much simpler. no, the term 'cognitive load' doesn't ring a bell, why do you ask?
|
|
#
?
Nov 14, 2013 21:05
|
|
|
I'd rather traverse a dag than a flattened dag. By the way rotor, this isn't YOSPOS, you're allowed to use capital letters here.
|
|
#
?
Nov 14, 2013 21:07
|
|
|
I think in my life I've had to draw a diagram of svn versions to figure out where I am like twice. with git it's at least once a month.
|
|
#
?
Nov 14, 2013 21:11
|
|
|
Are you not using a tool that draws the dag for you or something? Git would be a tremendous pain in the rear end if I had to do my own visualization.
|
|
#
?
Nov 14, 2013 21:20
|
|
|
Plorkyeran posted:It does have two parents. The log for C6 will show both. Commits in git are immutable. Because C4 was made after C3 and before C5, so in the commit log, after the merge commit C6, I would expect to see C6, C5, C4, C3. My understanding that commits will appear in chronological order when they're merged into another branch, but perhaps not then? Plorkyeran posted:A dag of immutable objects with pointers to various objects in the graph should not be a "complex thing" for a programmer. If you're getting frustrated with people trying to learn then maybe this isn't the thread for you, dear goon.
|
|
#
?
Nov 14, 2013 21:22
|
|
|
oiseaux morts 1994 posted:If you're getting frustrated with people trying to learn then maybe this isn't the thread for you, dear goon. rotor is not a newbie trying to learn.
|
|
#
?
Nov 14, 2013 21:24
|
|
|
Sorry, I read in haste and presumed it was directed at me. Apologies, Plorky.
|
|
#
?
Nov 14, 2013 21:26
|
|
|
I mean come on now, are people actually arguing that git is simpler than svn? like in sum total?
|
|
#
?
Nov 14, 2013 21:35
|
|
|
oiseaux morts 1994 posted:Because C4 was made after C3 and before C5, so in the commit log, after the merge commit C6, I would expect to see C6, C5, C4, C3. My understanding that commits will appear in chronological order when they're merged into another branch, but perhaps not then? Note that in general "chronological order" isn't really a thing in git; the commit timestamp is purely informational, and you can set it to any valid date when you're making a commit with --date. rotor posted:I mean come on now, are people actually arguing that git is simpler than svn? like in sum total?
|
|
#
?
Nov 14, 2013 21:54
|
|
|
Plorkyeran posted:
so that's a no then, good, good.
|
|
#
?
Nov 14, 2013 22:00
|
|
|
Plorkyeran posted:git log --graph --oneline may make things make more sense. git log has to display the commits in some order, and whether C5 or C4 comes first in the log is fairly arbitrary, and whichever git log chooses doesn't reflect anything about the actual graph. A "correct" display would show C4 and C5 next to each other, but that'd be pretty unusable in a command line interface. Thanks. Are snapshots invariant under commit order? My instinct says no, because if C3 removed a line from C2, and C4 added it back then swapping C3 and C4 would be adding a line that already existed. Unless the diff is not an accurate representation of how it's stored under the hood oh lawd thinking too much about this So anyway, my confusion is that in iss53, C5 doesn't have have "knowledge" of C4 - presumably if I looked at iss53 with its HEAD at C5, I would be looking at a snapshot, a "sum" of the diffs C1, C2, C3, C5. But after the merge, when I look at C5, at least on master, I've got C4's changes in there as well. If I create a tag from C5 in iss53, and a tag from C5 from master, the snapshots will be different, right? But C5 has only one parent... C3. o.m. 94 fucked around with this message at 22:51 on Nov 14, 2013 |
|
#
?
Nov 14, 2013 22:42
|
|
|
oiseaux morts 1994 posted:But after the merge, when I look at C5, at least on master, I've got C4's changes in there as well. What do you mean by "when I look at C5, at least on master"? If you're on master, you're looking at C6, not C5, because master points to C6. C6 includes changes from all of the commits reachable from it, including C4 and C5. C5 does not includes changes from C4 at all, ever, regardless of what branch you're on. Commits never, ever change; they are immutable. Switching branches just changes which state of the project has been "checked out" into your working directory, it does not affect the contents of commits in any way. oiseaux morts 1994 posted:If I create a tag from C5 in iss53, and a tag from C5 from master, the snapshots will be different, right? But C5 has only one parent... C3. Not trying to be rude, but I can't interpret this in any way that makes sense. If you create 2 tags at C5, they will both point to C5, and have identical "contents". Which branch you are on when you create the tag is irrelevant.
|
|
#
?
Nov 14, 2013 22:51
|
|
|
No that's cool, that makes sense. I have been operating on the assumption that you can "slide" the branch HEAD to earlier commits, say, from C6 to C5 and have C5 the most recent commit. But now all we know is C5 -> C3, but again that's operating on my assumption that the info is stored in the branch which it's not and ah gently caress it it's 10 o clock, whatever, let me read all this again tomorrow, thanks.
|
|
#
?
Nov 14, 2013 22:56
|
|
|
oiseaux morts 1994 posted:No that's cool, that makes sense. I have been operating on the assumption that you can "slide" the branch HEAD to earlier commits, say, from C6 to C5 and have C5 the most recent commit. But now all we know is C5 -> C3, but again that's operating on my assumption that the info is stored in the branch which it's not and ah gently caress it it's 10 o clock, whatever, let me read all this again tomorrow, thanks. HEAD isn't a branch. You can point it at any commit you want, but branches stop being involved. This is called a "detached" HEAD.
|
|
#
?
Nov 14, 2013 22:58
|
|
|
oiseaux morts 1994 posted:But after the merge, when I look at C5, at least on master, I've got C4's changes in there as well. oiseaux morts 1994 posted:No that's cool, that makes sense. I have been operating on the assumption that you can "slide" the branch HEAD to earlier commits, say, from C6 to C5 and have C5 the most recent commit.
|
|
#
?
Nov 14, 2013 23:01
|
|
|
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
|
|
#
?
Nov 14, 2013 23:09
|
|
|
GrumpyDoctor posted:HEAD isn't a branch. You can point it at any commit you want, but branches stop being involved. This is called a "detached" HEAD. I mean the HEAD belonging to a branch, not a branch called HEAD. Plorkyeran posted:Then it's not C5. If the branch was rebased onto C4 before merging it could be a different commit with the same commit message and changes, but that is not the scenario in the picture. Ah, well in that case it makes perfect sense. C6 has access to C5 and C4 as parents, so it has the information, it just conveniently displays them in commit date order. If we move back to C5, that information about C4 is no longer part of the graph. Party on
|
|
#
?
Nov 14, 2013 23:10
|
|
|
Feel free to shout at me because I only recently started using this myself in the most basic way, but maybe this will help As far as I understand it, commits are basically a conceptual snapshot of stuff. C3 has a bunch of files in a certain state. Later someone made some changes - adding files, deleting files, changing code etc - and pushed them as a commit. C5 is basically the result of making those changes to C3. C6 is the result of taking whatever is in C4, whatever is in C5, and merging them to get a new set of stuff. Branches are just pointers to places in that history, certain versions out of all the versions that have existed. Master's just the common name for your main version, it's set to the merged C6 on your diagram because - I assume - that's where the project people feel the project is currently up to, they wanted to take the work done up to C4 and the work done elsewhere up to C5, and put that together. The iss54 branch is still pointing to C5, so if you checked that branch out it would check out that commit, and that's the version you'd be working with. It wouldn't have any of the C4 stuff in it, and if you did more work and committed that you'd end up with C7, splitting off from C5. C7 is whatever was in C5 plus whatever changes you made. It has nothing to do with whatever is going on in C4. It's sort of like an alternate universe scenario, where you can have multiple paths and things like hey, what if we made these changes? What if I could go back to an earlier version, before we added that code, and do things a completely different way? You could spin off all kinds of different paths, merge paths together and so on, which is why you get this tree linking different versions of the project. Branches are really just current positions in that tree, a way of easily switching between different paths you've been taking. The Master branch took the path of merging C4 and C5 together, and is now in situation C6 which is the result of merging those two. The iss54 branch is still in the world of C5, where the C6 merge hasn't happened. You could do make some changes to that C5 version and spin off an entirely new path from C5, or jump iss54 to C6 or any other place on the tree and work from there, or delete the iss54 branch entirely. The iss54 'you are here' reference pointer would be thrown away, that's all. The commits would stay, because they're part of the history of C6 - it's the result of both paths, it's based on the evolution of both versions. I hope that wasn't horribly confusing, this is what happens when I can't sleep
|
|
#
?
Nov 15, 2013 06:06
|
|
|
Yep I re-read the Git book after this, went to bed, and woke up this morning feeling like I've finally got it, or at least, I have a consistent model in my head. It's a pretty satisfying feeling, and it's amazingly simple but I can see how hard it can be to explain because its dependent on an understanding of how each part works. Anyway, if you could sanity check my summary: The repository is a graph with directed edges and commits are vertices. Commits are immutable with the exception of perhaps the metadata like date, or author. Commits are a snapshot of everything being tracked by the repository at that time, and are essentially not dependent on parent or other commits in any way. The one thing that can happen in say the case of rebase is that commits can be removed entirely and replaced with copies but generally it's just one big, ever growing tree of immutable objects. Branches are essentially convenient variable names that point to commits, and when we do a "git log foo" we simply start at the commit foo points to, then traverse the graph via the parent edges, grabbing any commit that is connected and then outputting this "bag" of commits in date order for our fleshy convenience. Fast-forward commits just move the pointer of the branch we're in to the merged branch pointer. Merge commits move the pointer of the branch we're in to a new commit which has parents of both commits that the branch pointers point to. HEAD is just whatever commit we're looking at locally, which will move with the branch pointer when we make a new commit provided we're not headless. Checking out a branch just moves HEAD to the same commit as this new branch pointer. Questions: 1. I do some work on my local dev repo and push it to my remote origin. I have a staging server repo that also has the same origin. When I do a git fetch, I essentially grab the updated graph from origin, but with the exception that the branch pointers are not updated? Which is why I'll see [10 behind] or whatever when I inspect the branches locally after fetching? By doing a "git pull" on master for instance, it's the same as doing "git fetch origin/master" followed by "git merge origin/master" which is inevitably just going to be a fast forward since the local master should not have a divergent history from origin. 2. About git log - when invoked without any argument like a commit hash or branch name, does it log from HEAD? I don't have access to the CLI right now, but I'm assuming yes. 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 pre:[C1] <- C2 <- C3 <- [C4]
^
|--- C4' <- C1'
o.m. 94 fucked around with this message at 08:22 on Nov 15, 2013 |
|
#
?
Nov 15, 2013 07:58
|
|
|
rotor posted:I mean come on now, are people actually arguing that git is simpler than svn? like in sum total? git is more complex than svn and has more features than svn, features which are useful enough to justify the increase in complexity for many this isn't a strange concept, professionals who have time to learn more complex-yet-powerful tools will frequently find it beneficial??
|
|
#
?
Nov 15, 2013 08:25
|
|
|
git is more confusing than it should be but I would take git over svn. svn is the worst.
|
|
#
?
Nov 15, 2013 08:27
|
|
|
speaking of git! does anyone know about good git server/wrapper software that is *easy to host on Windows*? imagine an environment where words like "linux" or "java" are met by an angry mob, or a pink slip. it doesn't have to do much; stuff like web access, pull request hosting, code reviews, that would all be *nice* but all I really want is something that works faster and more reliably than "put your repo.git directories on a share", which is all we've managed to date.
|
|
#
?
Nov 15, 2013 08:29
|
|
|
Strong Sauce posted:git is more confusing than it should be but I would take git over svn. svn is the worst. no, visual source safe is the worst
|
|
#
?
Nov 15, 2013 08:38
|
|
|
Gul Banana posted:git is more complex than svn and has more features than svn it has _different_ features.
|
|
#
?
Nov 15, 2013 08:39
|
|
|
oiseaux morts 1994 posted:Commits are immutable with the exception of perhaps the metadata like date, or author. oiseaux morts 1994 posted:Checking out a branch just moves HEAD to the same commit as this new branch pointer. 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: 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 posted: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. 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? quote: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. 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?
|
|
#
?
Nov 15, 2013 09:53
|
|
|
Gul Banana posted:speaking of git! does anyone know about good git server/wrapper software that is *easy to host on Windows*? Install GitLab on a virtual machine running Ubuntu
|
|
#
?
Nov 15, 2013 10:05
|
|
|
|
| # ? May 12, 2024 16:24 |
|
|
rotor posted:it has _different_ features. You seem quite insistent to rationalize why you should not invest time in Git. While you can just keep on using SVN if you want to. I'm not going to go into a discussion about Hg vs Git, but both offer more features and vast improvements over SVN. While Git's underlying structure is actually pretty simple I do agree the commandline tools are more confusing than they should be, but even that is improved on with every release.
|
|
#
?
Nov 15, 2013 11:46
|
|