Google closing Yet Another Service - GoogleCode
-
svn branches are literally just folders with specific paths. There isn't any special handling done to prevent you from making folders with those names on GitHub.
-
No, there isn't a good way to do that other than making 2 different working copies...
I'm OK with that! I have something like 5 or 6 working copies of the trunk of my SVN codebase, and a couple of branches on the go at the same time. It means if I get bored implementing any particular feature, I can just drop it and work on something unrelated until I feel motivated to work on it again.
This might be an idiosyncratic way of working, but it works for me, and I have the diskspace, so why not? :D
-
svn branches are literally just folders with specific paths. There isn't any special handling done to prevent you from making folders with those names on GitHub.
Hmm OK, does git allow you to arbitrarily merge from one folder to another inside the same "branch"? If so, maybe I can subvert it into working how I'd like it to.
-
Yikes. Well, hey, whatever floats your root beer. That should work fine then, and you should be happy. Just don't forget which working copy which branch is on... You could get lost quickly
-
Just don't forget which working copy which branch is on... You could get lost quickly
The trick is to rename to toplevel folder to something which reflects the work in that WC. Once you're done with your
GRAPHICS/work, you can rename it toAUDIO/and off you go...
-
No... Git's merge feature only works across branches (well, merges but meh), not internally to a branch
-
I think SourceForge allows subversion. Not that I can be sure... Forge / Documentation / svn - SourceForge
-
Because git rhymes with shit for a reason.
-
I'm an egotistical bastard, and I name all my projects after myself. First 'Linux', now 'Git'.
-
I mean have two separate working copies of the two branches sitting next to each other, so I can do work in either branch and merge from one to the other, without needing to make a 'context switch' or something equally disruptive to my workflow...
There is nothing preventing you from creating multiple clones. They will be repositories, but if you want to work like in Subversion, you will just have one branch in each and synchronize through the central repo and basically the only difference will be that you will use
git pull(possibly withgit commitbefore it) instead ofsvn updateandgit commit+git pushinstead ofsvn commit. Git clone usually takes up less space than Subversion working copy, even with full history, and Git supports sharing the data between clones (using the--referenceoption toclone).It's probably Doing It Wrong according to Torvalds,
Policy does not belong to Kernel and apparently does not belong in Git either. I don't think there is doing it right or wrong. Here's the tool and here's how we use it and do
you want with it. It tends to make git a maze of twisty little configuration options, all alike, unfortunately.so it's not supported.
It is supported. Why else would the
--referenceoption togit cloneexist? (It is a bit dangerous though; I believe bazaar handles sharing the data better.)FWIW, I kinda missed that from SVN when I went to git at first, but I found I didn't really need it that much.
FWIW I usually preferred
svn switchover making another checkout anyway, because it was faster (at work we have a big bunch of images in the repository that don't change often) and because I didn't want to set up the build directories (multi-platform handled by CMake requires creating a build directory for each platform and setting a bunch of options there) and prepare the execution environment (requires downloading some more data). On the other hand I did have additional Git clone for some long-running work to reduce switching to and from it.Hmm OK, does git allow you to arbitrarily merge from one folder to another inside the same "branch"? If so, maybe I can subvert it into working how I'd like it to.
It does allow you to merge a lot more arbitrarily than subversion.
The important thing here is that “branch” means different things in Subversion and in Git and in Git it's somewhat ambiguous, so the answer depends on what you call “the same branch”.
In subversion “branch” is a directory in the repository. In Git it can mean either a particular path in the directed acyclic graph of commits or it can mean the ref that points to the head of such chain of commits.
If you want to work like you were used to in Subversion, you should only call “branch” a named ref in the central repository. And you can pull from it and push to it from multiple working copies. Which are clones, but you don't create local refs that would not correspond to refs/branches in the central repo and work mostly like in subversion.
Additionally Git allows you to pull/push/merge between those checkouts directly. You may pass on it. You may realize it is useful later when you get more comfortable with things.
It is useful to start thinking about revisions (a.k.a. commits a.k.a. changesets) as an acyclic oriented graph. You have some state and you do a change and that creates a new revision that is based on the previous one. And branches are parallel paths in that graph. That is the way distributed systems directly represent them, but you can think about the centralized systems that way too.
One interesting thing that it will make you realize is that a working copy is a kind of branch too. You have some changes there that are based on the state you checked out and they are independent of changes on other working copies and are made in parallel with those other changes. However in Subversion they are very limited. They can only have one revision on them, the uncommitted state, and when you merge them (with
update), they forget the previous state, so if you make a mistake, you can't look back.What Git (and any other distributed version control system — the model is the same in all of them) does is it makes the local branches explicit and promotes them to full-featured branches. You can pass on most of those features and still use them the way you used them in subversion. With one exception; Git refuses to merge uncommitted changes. This is for your safety as it means you can always look or go back if you make a mistake in the merge. It is a difference that hurts the muscle memory though.
I've had this mental model since I've learned about Darcs' and it's patch algebra sometime around 2003. It was a bit less formal back then though. It's been very useful for being able to switch between different version control systems—and I've used CVS, GNU Arch, Svk, Subversion, ClearCase, Bazaar and Git—with ease.
Git's merge feature only works across branches (well, merges but meh), not internally to a branch
It depends on what you call a branch. If you choose it to match subversion (branch is a ref in the central repo), you can. See above. Git can emulate any Subversion workflow except those that abuse the fact branches are directories (changes to multiple branches, merging subdirectories differently).
-
That's not what that word means.
(The word in question: "charm")This reminded me of something my aunt said once. She is a retired teacher, and on one memorable occasion, given the task "Use each of these vocabulary words in a sentence", one of the ten year olds in her class wrote, "When my sister said she was pregnant, my father said 'Charming!'"
-
They could also close Gmail, or remove their stupid emojis, I mean, look at this shit:
Oh well, this isn't as stupid as the above ones, but with all the people working in Google you would expect that this shit would be done correctly or with a little bit more of taste.
-
Git is much more complex than svn.
Complexity is either evil, or a necessary evil.
-
Reading is a barrier to posting.
I'm not sure anything is a barrier to posting for @accalia and @RaceProUK
-
I'm not sure anything is a barrier to posting for @accalia and @RaceProUK
Well, my current post rate is >500 a month more than the next most active user…But @boomzilla's still noisier than the fox.
-
-
-
No. I mean have two separate working copies of the two branches sitting next to each other, so I can do work in either branch and merge from one to the other, without needing to make a 'context switch' or something equally disruptive to my workflow...
I've done this a fair amount with hg. I just...copy or clone the repo. And I push and pull back and forth all the time.
I do this with svn, too.
-
you have sex with svn?
-
It's got branches that just go on forever.
-
My last repo wanted to tag my head, but I couldn't commit.
-
They could also close Gmail, or remove their stupid emojis, I mean, look at this shit:
We could get them here ya know:
http://pjh.homeip.net/uploads/default/25/e6ab14604316870c.png
-
Never mind Blakey; I think I'd have a fit if we did!
-
Not the same ones, completely different. Also, the ones in Gmail are.... ANIMATED!
-
why? i like them!
-
Never mind Blakey; I think I'd have a fit if we did!
So, that's a vote in favor then.
-
So, that's a vote in favor then.
Eh, I'd only make one post to complain, and then forget the whole thing anyway ;)
-
I haven't used it for a while and it's a minor player, but there's BitBucket. Not sure how it stacks up.
Bitbucket works quite nicely IME...
-
Bitbucket works quite nicely IME...
That doesn't have SVN support though (it didn't when I checked recently anyway)
-
does git allow you to arbitrarily merge from one folder to another inside the same "branch"?
TDEMS. In svn, branches and tags are things that only exist by convention; the deep reality is that you've got a versioned directory system, and branches and tags are just directories within that. (You can put tags inside branches inside a trunk inside nothing very much at all. Because.)
In git, branches have a stronger existence, in that they correspond to branches in the history graph. Formally, branches and tags are actually local labelings of nodes in that graph, with the difference being that branch labels get updated when commits happen to point to the committed child state, and tag labels can be digitally signed. Both branch and tag labels may optionally be shared with others. The problem comes when you compare notes with another repository; though you can refer to the same commits, you can't in general talk about the same branches or tags. This is f'ing crazy.
Proponents of other DVCSs (which would include both @boomzilla and myself) think that while git might be OK for very large projects, most people would be better off with something else, such as Mercurial or Fossil, where more of the state gets shared by default. Things are a bit more synchronised, but for a smaller team that's no bad thing.
-
It is useful to start thinking about revisions (a.k.a. commits a.k.a. changesets) as an acyclic oriented graph.
After all, you use those in your everyday routine, don't you? They're so commonplace and intuitive.
-
For this purpose they are as intuitive as any other way of thinking about branches and match reality better.
-
-
It is useful to start thinking about revisions (a.k.a. commits a.k.a. changesets) as an acyclic oriented graph.
Yes I know exactly what that is. I look around, and the place is lousy with acyclic oriented graphs. There's obviously absolutely no reason you would need to explain what the holy fuck you're talking about!!!
Although, to be fair, you sound exactly like every "Git for beginners" tutorial I've ever tried to read, so at least you're on-message.
You know some of us, and yes I know we're crazy whackjobs, just want use tools to get fucking work done instead of reading 37 advanced calculus texts before we can use them.
-
Let me put it this way: It's useful to whom?
Sure, it's useful to you, but the people reading your post are not you. You are making assumptions about the reader and treating those as obvious.
I can infer what an acyclic oriented graph is from what I remember of graph theory, but it's not useful to me to think of it that way if it requires that I visit wikipedia for a refresher course. What's useful to me is to think of it as water going through a stream. When the stream hits a rock, the stream splits, and each split is a branch. Further downstream the "branches" might merge again, but the water never flows backwards.
I wouldn't assume that description helps anyone else, but until I need to refine my mental model of git it's useful. If I was trying to describe it to someone else, I'd try to use less technical terms and more relatable metaphors. Not the exact mathematical construct that precisely describes it.
-
What's useful to me is to think of it as water going through a stream. When the stream hits a rock, the stream splits, and each split is a branch. Further downstream the "branches" might merge again, but the water never flows backwards.
That's 100 times better, but then you have someone talk about "cherry picking" a commit and you're totally fucking lost again. Because while the stream can't go backwards, you can take 3 cubic meters of water from a bit of the stream and somehow pour it in another bit of the stream, but it also still exists in both streams.
-
You can photocopy a cherry and drop the photocopy into the river.
-
That's 100 times better, but then you have someone talk about "cherry picking" a commit and you're totally fucking lost again.
Precise language is useful. It's difficult to target your language to arbitrary levels of experience. I didn't think an acyclic oriented graph was terribly out of place for here. A native speaker should be able to figure out what's going on just from the words (and it wouldn't surprise me if ESL speakers could, too).
I mean, come on...acyclic...no cycles, oriented: there's a forward and backward (or whatever metaphor you like) and a graph is drawing things. Combine that with your commits and it should be pretty obvious.
-
Look, the real problem here is that I need to know this shit at all. Why isn't this all implementation-detail masked by the UI?
Oh, right, because the UI is shit. Forgot for a second there.
-
-
Look, the real problem here is that I need to know this shit at all. Why isn't this all implementation-detail masked by the UI?
Calling this stuff an implementation detail isn't really accurate. I mean, there's an implementation detailedness about it, but the branch structure is determined by you and what you're trying to do.
I'm not defending git or its UI (I've barely touched it), but if you think branching and shit should just magically conform to whatever your workflow is then you're just delusional and clueless.
-
The problem (well one of the many problems) is that Git isn't strongly opinionated. If I'm using it for source control, it should tell me what my workflow is. Or at the very least, guide me in the correct direction.
Right now it just plops down a giant tangled ball of feature and says, "here. Whatever. Done."
-
The problem (well one of the many problems) is that Git isn't strongly opinionated. If I'm using it for source control, it should tell me what my workflow is. Or at the very least, guide me in the correct direction.
Ah, yes, I can see that you're a big fan of the Unix way. Do one thing and do it well.
-
Ah, yes, I can see that you're a big fan of the Unix way. Do one thing and do it well.
I don't understand this comment at all, and yet you are Boomzilla so I do not care.
-
The problem (well one of the many problems) is that Git isn't strongly opinionated. If I'm using it for source control, it should tell me what my workflow is. Or at the very least, guide me in the correct direction.
Right now it just plops down a giant tangled ball of feature and says, "here. Whatever. Done."
You'd probably be better off using one of the other DVCSs, as they've got stronger ideas about what sort of workflows make sense. Except I've no idea how well they integrate with VS, which is a feature you probably care about a lot. (More than I do for sure. ;))
And every time I use the word “workflow” I have to double-take because I write workflow software. That's a very different thing…
-
I don't understand this comment at all,
Normally, we'd bitch about changing our lives to work around the way a particular program operates. But now you express a desire to do exactly that. You want git to be
simplifieddumbed down so that it forces a workflow on its users. That sounds like the classic Unix philosophy, which I quoted.As astute forum goers will note, you're a fan of many monolithic applications, so this is obviously a sarcastic comment on my part, because your oblivious cognitive dissonance amuses me.
-
VisualHG integrates Mercurial into VS fairly nicely
-
You'd probably be better off using one of the other DVCSs, as they've got stronger ideas about what sort of workflows make sense.
I have to use what my employer gives me to use.
Normally, we'd bitch about changing our lives to work around the way a particular program operates.
I would?
Who is "we" in this scenario? I'm always bitching the exact opposite. For example, I bitch at people who whine and gripe about Windows 8 because they didn't learn to work the way Windows 8 encourages you to work (or Windows 7, or Windows Vista, for that matter.)
That sounds like the classic Unix philosophy, which I quoted.
If you interpret "one thing" as "be a good source control program", then I guess it does?
As astute forum goers will note, you're a fan of many monolithic applications,
I wouldn't say I'm a "fan of many monolithic applications", I'd say I think the Unix philosophy is shit. And none of the most successful programs in the world have ever done "one thing well". Unless you define "one thing" in a ludicrously vague way.
-
I would?
Who is "we" in this scenario? I'm always bitching the exact opposite. For example, I bitch at people who whine and gripe about Windows 8 because they didn't learn to work the way Windows 8 encourages you to work (or Windows 7, or Windows Vista, for that matter.)
I guess you're right about that. Must have been projecting there. This is still a stupid argument against git.
-
Although, to be fair, you sound exactly like every "Git for beginners" tutorial I've ever tried to read, so at least you're on-message.
Except I was not talking (specifically) about Git at all! I was not talking (specifically) about distributed version control either. I was talking about any version control. In any version control you need to see the revisions that have zero (in initial revision) or more predecessors and zero or more successors. It's like that in SCCS, it's like that in CVS, it's like that in Subversion, it's like that everywhere. Branches are on top of that. Subversion is complex, because it takes one concept, directories, and repurposes it for another thing, branches, for which it is not a good fit. Distributed systems are simpler, they use the base concept directly (still not talking about Git; Git adds a lot of complexity at the higher levels).
Look, the real problem here is that I need to know this shit at all. Why isn't this all implementation-detail masked by the UI?
Because it's fundamental to the problem of version control. Every version control is revisions with predecessors and successors, a.k.a. acyclic oriented graph. Without the concept, merging is black magic. With it merging in general, and about any version control system you come across, is obvious. Plus you immediately notice deficiencies in the way centralized systems (all of them so far) do merging as they can't find the most recent common ancestor in certain cases even though it is well defined.
The problem (well one of the many problems) is that Git isn't strongly opinionated. If I'm using it for source control, it should tell me what my workflow is.
@Bulb said:Policy does not belong to Kernel and apparently does not belong in Git either.
Then Git is not for you. Git won't hold your hand. It will give you enough rope to shoot yourself in the foot instead. If you want to be kept on a short leash, you have to look elsewhere.
That does not exempt you from needing to know the relations between revisions, as they are, fundamentally, the same in anything you choose.
Normally, we'd bitch about changing our lives to work around the way a particular program operates. But now you express a desire to do exactly that. You want git to be
simplifieddumbed down so that it forces a workflow on its users. That sounds like the classic Unix philosophy, which I quoted.You correctly crossed the word “simplified”, but then it is not the Unix philosophy, because the Unix philosophy calls precisely for simple, not dumb. And git is simple. It isn't easy.
I have to use what my employer gives me to use.
@blakeyrat said:Which means I have no place to store my Skyrim mods now.
Sure for those you can use whatever you choose, no?
Directed acyclic graph - Wikipedia
