 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
My version control system of choice is Darcs. But obviously nobody
actually uses that. I gather a number of people do use Git, however. And
NetBeans has Git capabilities built-in.
I did look to see where it installs the Git binaries. It doesn't. It
uses JGit, a complete reimplementation of Git in Java. (This makes me
nervous... How do we know the two implementations work the same way?)
So anyway, I downloaded the /real/ Git implementation, which comes with
some visualisation tools. (NetBeans does a really useless job of showing
you the current state of your repository. It shows you the ID of the
current commit and that's about it.)
I had another look over "Understanding Git"
http://www.eecs.harvard.edu/~cduan/technical/git/
If I'm understanding this correctly, history is stored as commit
objects, which one storing the complete state of the entire codebase,
plus the IDs of its ancestor commit(s). The "branches" or "heads"
themselves are merely bookmarks into this tree of commits. They let you
conveniently get from place to place and label your stuff, but you can
create new ones or destroy existing ones at will. The commits themselves
are the actual history.
So far, that understanding hasn't caused me too many problems. And I
quite like the way that a single repository holds multiple branches.
Darcs follows an "every repository /is/ a branch" mentality. Which
works, but makes it kinda long-winded to change branches. In NetBeans, I
can click "switch branch" and all my code suddenly changes.
OTOH, it's irritating to have to switch branches, click "merge
revision...", select the branch I was just on, and then switch back
again every single time I want to update one branch to match another. I
imagine this is a limitation of the NetBeans, and if I used Git directly
there would be a command to immediately update a branch without actually
switching to it.
One extremely irritating issue is that it's apparently impossible to
create a commit object of a completely empty repository. So there can
never be a branch where you start again from scratch. Every branch must
always start out with /something/ in it. I suppose I could just create a
dummy file to create commit 0, and then delete it again. But it's
irritating.
Rather /more/ irritating is this: I made a commit, and then realised the
description was wrong. (NetBeans defaults to using the exact same
description as the previous commit - because that's SO USEFUL, right?)
So I looked for the command to undo the last commit. Apparently there
isn't one. I even found a question on Stack Overflow about it. Lots of
people suggesting various complex workarounds to try to solve it, but
nothing that says "just delete the last commit object!"
Using the GUI, I was able to create a /new/ commit object identical to
the old one but with a different description. The old commit object is
still there though, showing up is a dangling branch. And I cannot find
any way to get rid of it. It's all very annoying.
(I could mutter something about how in Darcs this problem takes about 15
seconds to fix... But what would that prove?)
One mildly niggling thing is that Git imposes an artificial order on
things. Like, with Darcs, if I edit file X, and then make some
completely unrelated change to file Y, then as far as Darcs is
concerned, there is no ordering relation between these unrelated
changes. But to Git, one commit is descended from the other, even though
there's no logical relationship.
Conversely, with Darcs, if I edit file X to add a new function, and then
edit file Y to /use/ that new function, then Darcs doesn't see any
relationship, but there /is/ one, and Darcs' idea that the two changes
are unrelated is flat-out wrong. Then again, shouldn't you be recording
those two changes in the same commit?
The way Git does things does have the advantage that a situation like
this just never happens. On the other hand, if I change file X on one
branch and file Y on another branch (so the changes are /definitely/
unrelated), you still have to "merge" the changes to get back to a
single branch. To Darcs, this would just be adding in a few more
changes. Still, it seems to /work/ just fine, so who's complaining?
All of this stuff gets /much/ easier to follow with gitk to show me WTF
is actually happening. Unfortunately, Git seems to be a Unix
application, meaning that you cannot install it without first installing
a Unix emulator. The default installer binary seems to install MSYS,
including Bash, Perl, Tk, and a whole bunch of other stuff. *sigh*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> OTOH, it's irritating to have to switch branches, click "merge
> revision...", select the branch I was just on, and then switch back
> again every single time I want to update one branch to match another. I
> imagine this is a limitation of the NetBeans, and if I used Git directly
> there would be a command to immediately update a branch without actually
> switching to it.
Another irritating thing is that creating a new branch does not /switch
to/ that branch. Just now I created a new branch, did a commit, and then
realised it updated the old branch, not the new one.
Fortunately, since a "branch" is simply a bookmark, all I need to do is
wind the new branch forward and wind the old one backwards.
Unfortunately, NetBeans can wind a branch forward, but cannot easily
wind backwards. Fortunately gitk can, but then NetBeans is confused,
until I switch branches back and forth a few times.
Damn that was irritating! LOL.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 10/04/2012 14:55, Invisible nous fit lire :
>
> Rather /more/ irritating is this: I made a commit, and then realised the
> description was wrong. (NetBeans defaults to using the exact same
> description as the previous commit - because that's SO USEFUL, right?)
> So I looked for the command to undo the last commit. Apparently there
> isn't one. I even found a question on Stack Overflow about it. Lots of
> people suggesting various complex workarounds to try to solve it, but
> nothing that says "just delete the last commit object!"
>
> Using the GUI, I was able to create a /new/ commit object identical to
> the old one but with a different description. The old commit object is
> still there though, showing up is a dangling branch. And I cannot find
> any way to get rid of it. It's all very annoying.
Trick learned from mercurial (hg): always work on a secondary repository
(not the "reference" one). Even better, a tertiary or deeper one.
If you did a wrong commit on the secondary, instead of pushing back
(well, its "git push" !) to the parent, just delete it and start over
(you might keep your delta first with some patch-compatible commands, so
as to reply them automatically: "hg diff" is very useful, i guess there
is some version for git too)
Basic of distributed revision control: as long as you did not export
your commit, you can hide your fault by just deleting the whole issue.
Once exported, you're doomed.
(Well, there is a few extension in hg to move/rewrite commits (even
regroup a few one), but they work only as far as the repositories which
know the details are erased from existence in order to never provide the
original pieces of information again)
As they say: Mount a scrap monkey!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Rather /more/ irritating is this: I made a commit, and then realised the
>> description was wrong. (NetBeans defaults to using the exact same
>> description as the previous commit - because that's SO USEFUL, right?)
>> So I looked for the command to undo the last commit. Apparently there
>> isn't one.
>
> Trick learned from mercurial (hg): always work on a secondary repository
> (not the "reference" one). Even better, a tertiary or deeper one.
> If you did a wrong commit on the secondary, instead of pushing back
> (well, its "git push" !) to the parent, just delete it and start over
> (you might keep your delta first with some patch-compatible commands, so
> as to reply them automatically: "hg diff" is very useful, i guess there
> is some version for git too)
Presumably you could just delete the .git subfolder and recopy... oh
wait, you're supposed to do git clone, aren't you? I wonder if that does
anything extra beyond just copying the files...
> Basic of distributed revision control: as long as you did not export
> your commit, you can hide your fault by just deleting the whole issue.
> Once exported, you're doomed.
Well, yes. Once it's public, it's part of history. And then if you want
to change it, you must rewrite history. Which isn't easy...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible escreveu:
> I gather a number of people do use Git, however.
the understatement of the year! well, since it's Andrew, perhaps just
of the month, we'll see...
It's now all around us. Plus, it's a cool word. I hope Gimp uses Git. :)
> All of this stuff gets /much/ easier to follow with gitk to show me WTF
> is actually happening. Unfortunately, Git seems to be a Unix
> application, meaning that you cannot install it without first installing
> a Unix emulator. The default installer binary seems to install MSYS,
> including Bash, Perl, Tk, and a whole bunch of other stuff. *sigh*
way to go!
You know git was written as a reverse engineering of the proprietary cvs
the Linux kernel project was using at some point, right?
--
a game sig: http://tinyurl.com/d3rxz9
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 10/04/2012 20:52, Orchid Win7 v1 nous fit lire :
> Presumably you could just delete the .git subfolder and recopy... oh
> wait, you're supposed to do git clone, aren't you? I wonder if that does
> anything extra beyond just copying the files...
Lesson learned a long time ago: never try to be smarter by going in the
backstage. Just play fair, respect the rules.
(of course, as you become a wizard, the limit of the backstage moves)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 10/04/2012 08:38 PM, Le_Forgeron wrote:
> Le 10/04/2012 20:52, Orchid Win7 v1 nous fit lire :
>> Presumably you could just delete the .git subfolder and recopy... oh
>> wait, you're supposed to do git clone, aren't you? I wonder if that does
>> anything extra beyond just copying the files...
>
> Lesson learned a long time ago: never try to be smarter by going in the
> backstage. Just play fair, respect the rules.
> (of course, as you become a wizard, the limit of the backstage moves)
Indeed. This definitely works with Darcs. But I'm not sure if it works
for Git. I don't see why it wouldn't, but you never know...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 10/04/2012 08:05 PM, nemesis wrote:
> Invisible escreveu:
>> I gather a number of people do use Git, however.
>
> the understatement of the year!
It's only April.
> It's now all around us. Plus, it's a cool word. I hope Gimp uses Git. :)
A number of people use Git. A number of others use RCS, CVS, Subversion,
Mercurial, BitKeeper, Bazaar, Perforce, Visual Source Safe...
(Hell, there are even large projects which use Darcs. Though the main
one, GHC, recently switched to Git. It is unclear to me whether this is
because Darcs wasn't good enough, or just because all the would-be
contributers use Git not Darcs.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4/10/2012 12:05, nemesis wrote:
> You know git was written as a reverse engineering of the proprietary cvs the
> Linux kernel project was using at some point, right?
Are you sure? I thought it was written to replace the reverse engineering of
the proprietary cvs?
--
Darren New, San Diego CA, USA (PST)
"Oh no! We're out of code juice!"
"Don't panic. There's beans and filters
in the cabinet."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4/10/2012 5:55, Invisible wrote:
> How do we know the two implementations work the same way?)
Given thatall objects in the repository are looked up by the cryptographic
hash of their contents, the whole thing would fall apart if they weren't.
That said, the git book extensively documents the format of the repository,
which is completely trivial in practice. So... it's not hard.
> If I'm understanding this correctly, history is stored as commit objects,
Basically, yes.
Try this: http://book.git-scm.com/
It's excellent. (If it's the one I remember, which I think it is.)
> OTOH, it's irritating to have to switch branches, click "merge revision...",
> select the branch I was just on, and then switch back again every single
> time I want to update one branch to match another. I imagine this is a
> limitation of the NetBeans, and if I used Git directly there would be a
> command to immediately update a branch without actually switching to it.
Yes. Or you'd write a shell script. :-)
> One extremely irritating issue is that it's apparently impossible to create
> a commit object of a completely empty repository. So there can never be a
> branch where you start again from scratch. Every branch must always start
> out with /something/ in it. I suppose I could just create a dummy file to
> create commit 0, and then delete it again. But it's irritating.
Your commit has to point to a tree (aka directory). But you can start a
repository with an empty directory. If you manipulate things with the
lower-level commands, you can stick stuff in the repository without any
commits at all. (Which is how "commit" creates a commit - it puts the things
in the repository, then points a commit at them.)
> Rather /more/ irritating is this: I made a commit, and then realised the
> description was wrong. (NetBeans defaults to using the exact same
> description as the previous commit - because that's SO USEFUL, right?) So I
> looked for the command to undo the last commit. Apparently there isn't one.
You can only add to the repository, unless you prune it. But that doesn't
mean you need to see it.
http://stackoverflow.com/questions/927358/git-undo-last-commit
> I even found a question on Stack Overflow about it. Lots of people
> suggesting various complex workarounds to try to solve it, but nothing that
> says "just delete the last commit object!"
Uh, pretty much the first hit on google for "git revert commit."
> Using the GUI, I was able to create a /new/ commit object identical to the
> old one but with a different description. The old commit object is still
> there though, showing up is a dangling branch. And I cannot find any way to
> get rid of it. It's all very annoying.
"git gc" with the appropriate options to prune.
> (I could mutter something about how in Darcs this problem takes about 15
> seconds to fix... But what would that prove?)
It proves that Darcs isn't too worried about losing commits? ;-)
> One mildly niggling thing is that Git imposes an artificial order on things.
> Like, with Darcs, if I edit file X, and then make some completely unrelated
> change to file Y, then as far as Darcs is concerned, there is no ordering
> relation between these unrelated changes. But to Git, one commit is
> descended from the other, even though there's no logical relationship.
Git doesn't store changes. It stores snapshots. The order isn't so much
artificial as irrelevant to what you happen to be doing right now.
> Then again, shouldn't you be recording those
> two changes in the same commit?
Heavens no!
> The way Git does things does have the advantage that a situation like this
> just never happens. On the other hand, if I change file X on one branch and
> file Y on another branch (so the changes are /definitely/ unrelated), you
> still have to "merge" the changes to get back to a single branch.
Which makes sense. Commits are the fundamental unit of atomic change in git.
Now you have a snapshot with X changed, a different snapshot with Y changed,
and a snapshot with the two changes together. What could be easier?
--
Darren New, San Diego CA, USA (PST)
"Oh no! We're out of code juice!"
"Don't panic. There's beans and filters
in the cabinet."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> How do we know the two implementations work the same way?)
>
> Given thatall objects in the repository are looked up by the
> cryptographic hash of their contents, the whole thing would fall apart
> if they weren't.
>
> That said, the git book extensively documents the format of the
> repository, which is completely trivial in practice. So... it's not hard.
Well, you know, HTML is quite extensively documented. And yet, different
implementations don't interoperate too well...
>> OTOH, it's irritating to have to switch branches, click "merge
>> revision...",
>> select the branch I was just on, and then switch back again every single
>> time I want to update one branch to match another. I imagine this is a
>> limitation of the NetBeans, and if I used Git directly there would be a
>> command to immediately update a branch without actually switching to it.
>
> Yes. Or you'd write a shell script. :-)
It looks like "git reset" will do it, though I'm not completely sure on
the syntax. It doesn't really matter; NetBeans is still going to force
me to follow a 3-stage process.
>> One extremely irritating issue is that it's apparently impossible to
>> create a commit object of a completely empty repository.
>
> Your commit has to point to a tree (aka directory). But you can start a
> repository with an empty directory.
Mmm, OK.
>> Rather /more/ irritating is this: I made a commit, and then realised the
>> description was wrong.
>> So I
>> looked for the command to undo the last commit. Apparently there isn't
>> one.
>
> You can only add to the repository, unless you prune it.
I'm used to Darcs, where you can almost arbitrarily add, remove and
reorder changes. In particular, if you commit something, and then do "oh
bugger, I didn't mean to do that", it's one command to delete the
commit, which then makes all the changes it contained appear as "new" again.
> But that doesn't mean you need to see it.
>
> http://stackoverflow.com/questions/927358/git-undo-last-commit
Right... so... my options are:
1. Delete the last commit /and the changes it contained/. (Why would you
ever want to do this?)
2. Move the head back one commit, but not actually delete the commit.
3. Move the head back one commit, but not actually delete the commit,
and leave the changes in the staging area.
Nowhere is there an option that says "perform the exact inverse of what
I just told you to do".
>> I even found a question on Stack Overflow about it. Lots of people
>> suggesting various complex workarounds to try to solve it, but nothing
>> that says "just delete the last commit object!"
>
> Uh, pretty much the first hit on google for "git revert commit."
...which lists the three options above, none of which undo the commit.
It seems the best you can do is create a /new/ commit - which isn't much
help when the whole problem is that you have a commit that's labelled as
something it isn't, which is misleading and bound to cause confusion later.
> "git gc" with the appropriate options to prune.
That at least might work. (Somebody somewhere says prune only removes
dangling branches older than 2 weeks.) It's really quite frustrating how
all this documentation seems to be tutorials, blog posts and SO
questions. Isn't there a /reference manual/ somewhere??
>> (I could mutter something about how in Darcs this problem takes about 15
>> seconds to fix... But what would that prove?)
>
> It proves that Darcs isn't too worried about losing commits? ;-)
If your commit is wrong, you don't /want/ to keep it. :-P But seriously,
if I want to change something, why shouldn't I be able to change it? Git
has an "amend" command, it's just that it doesn't /amend/ the commit -
it creates a new one, but leaves the old one in place. The Darcs "amend"
command actually deletes the amended commit - you know, like what you'd
expect an amendment to consist of. :-P
I agree it's not a good idea to go back and start changing history from
2 years ago. But I don't see why you can't edit the last committed
change. That just seems like a silly limitation.
In a sense, Darcs /isn't/ that worried about losing commits. In Darcs, a
branch is a repository, and so to remove changes from a branch, you have
to delete commits. That's just how it works.
>> Then again, shouldn't you be recording those
>> two changes in the same commit?
>
> Heavens no!
You shouldn't group related changes together, no?
That's the other thing. With Darcs, I edit some files for a while, and
then say "commit this". It shows me each and every change, and asks if I
want to include that. And even though I've only got one set of changed
files, I can syphon off the changes and ground them into several
logically separate commits. Git can't seem to do that. If I want to
record some but not all changes, I have to manually construct the file
contents that I want committed. (And obviously NetBeans does nothing to
help with this.)
What I end up doing is just committing /everything/, because it's less
hassle. But then if I ever need to go back, I'd have to go in big giant
steps rather than small logical increments.
>> The way Git does things does have the advantage that a situation like
>> this
>> just never happens. On the other hand, if I change file X on one
>> branch and
>> file Y on another branch (so the changes are /definitely/ unrelated), you
>> still have to "merge" the changes to get back to a single branch.
>
> Which makes sense. Commits are the fundamental unit of atomic change in
> git. Now you have a snapshot with X changed, a different snapshot with Y
> changed, and a snapshot with the two changes together. What could be
> easier?
How about /not/ having to make a commit that records changes that I've
already committed? :-P
Actually, it would probably be easier if NetBeans would actually show
me, you know, /a history/, so I can see what's actually /happening/,
rather than just having to try to guess from the hashes which branches
contain what...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 11/04/2012 03:15, Darren New nous fit lire :
> On 4/10/2012 12:05, nemesis wrote:
>> You know git was written as a reverse engineering of the proprietary
>> cvs the
>> Linux kernel project was using at some point, right?
>
> Are you sure? I thought it was written to replace the reverse
> engineering of the proprietary cvs?
>
CVS is a version control system (a real one, like rcs and svn).
You should reword "proprietary cvs" as "proprietary SCM"
Git was written to get away from a license issue with BitKeeper.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 11/04/2012 10:27 AM, Le_Forgeron wrote:
> You should reword "proprietary cvs" as "proprietary SCM"
Serial Copy Management? No, wait... >_<
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] dev null> wrote:
> I gather a number of people do use Git, however.
At least git is much better than another extremely popular versioning
system, namely svn, which is a real PITA.
Git has this marvelous idea of keeping all of its versioning files in
one single directory in the root of the project. Seems rather self-evident,
one would think.
Svn, on the other hand, has this completely braindead idea of having a
versioning directory in each single subdirectory of the project. Which
means that it breaks badly if you do *anything* to *any* directory in
your project. Copy a directory from one place to another? Svn breaks.
Rename a directory? Svn breaks. Copy an unversioned directory from
somewhere else onto a versioned directory in your project? Svn breaks.
Copy a directory from one project to another? Svn breaks.
And "svn breaks" means that it will refuse to commit, update, fix or
do anything to the directory. (Fixing the problem usually involves
either removing the .svn subdirectories manually, or removing the
entire offending directory hierarchy, updating, and then copying the
files inside the directories (rather than entire directory structures)
from one place to another, which can be really annoying if you have
subdirectories inside subdirectories...)
This can be *extremely* annoying when you have a complex directory
structure that you would want to copy from one place to another. With
git it isn't a problem: Just copy it and that's it. With svn you will
be breaking your project.
Who thought this would be a good idea?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 11/04/2012 10:57 AM, Warp wrote:
> At least git is much better than another extremely popular versioning
> system, namely svn, which is a real PITA.
>
> Git has this marvelous idea of keeping all of its versioning files in
> one single directory in the root of the project. Seems rather self-evident,
> one would think.
>
> Svn, on the other hand, has this completely braindead idea of having a
> versioning directory in each single subdirectory of the project. Which
> means that it breaks badly if you do *anything* to *any* directory in
> your project.
>
> Who thought this would be a good idea?
That's pretty screwed up, man...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] devnull> wrote:
> That's pretty screwed up, man...
It's not fun trying to fix a coworker's local copy of the project using
skype as a communication interface, when he once again accidentally broke
the versioning system via a very simple file operation (such as copying
the contents of a directory to the project). And he didn't even do anything
stupid; it's usually just a simple and normal file operation you would do
as a matter of course, and in fact I have broken the project several times
in the same way as well. It's svn that's the stupid one.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 11/04/2012 11:23 AM, Warp wrote:
> Invisible<voi### [at] devnull> wrote:
>> That's pretty screwed up, man...
>
> It's not fun trying to fix a coworker's local copy of the project using
> skype as a communication interface, when he once again accidentally broke
> the versioning system via a very simple file operation (such as copying
> the contents of a directory to the project). And he didn't even do anything
> stupid; it's usually just a simple and normal file operation you would do
> as a matter of course, and in fact I have broken the project several times
> in the same way as well. It's svn that's the stupid one.
Isn't an SCM supposed to /help you/, not constantly get in your way?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 10/04/2012 01:55 PM, Invisible wrote:
> So anyway, I downloaded the /real/ Git implementation, which comes with
> some visualisation tools. (NetBeans does a really useless job of showing
> you the current state of your repository. It shows you the ID of the
> current commit and that's about it.)
> All of this stuff gets /much/ easier to follow with gitk to show me WTF
> is actually happening.
Question: Who designed gitk to default to using black text on a navy
blue background? That's frigging *absurd*! Fortunately, you can change
it - because it's utterly illegible!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 11/04/2012 12:25, Invisible nous fit lire :
> Isn't an SCM supposed to /help you/, not constantly get in your way?
Yep, but not all SCM fit all the people.
The same way a hammer is a helpful tool for a carpenter, but in the way
of a gardener. (ok, give me a usage of a hammer for a gardener ?)
The choice of a SCM must be made in perspective of the usage of the work
place. A good choice for a carpenter might be a poor choice for a
gardener, copying your neighbor is not always the best move. (but might
be ok if you're a mason and you're next a carpenter).
As usual, there is no universal best solution (otherwise, it would
dominate the place and you wouldn't have a choice).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 11/04/2012 11:33 AM, Le_Forgeron wrote:
> Le 11/04/2012 12:25, Invisible nous fit lire :
>
>> Isn't an SCM supposed to /help you/, not constantly get in your way?
>
> Yep, but not all SCM fit all the people.
Well, that's true, but a tool that breaks if you do something very
simple and common strikes me as being a bad tool. At a minimum, it ought
to provide an easy way to fix the problem...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 10/04/2012 01:55 PM, Invisible wrote:
> So far, that understanding hasn't caused me too many problems. And I
> quite like the way that a single repository holds multiple branches.
> Darcs follows an "every repository /is/ a branch" mentality. Which
> works, but makes it kinda long-winded to change branches. In NetBeans, I
> can click "switch branch" and all my code suddenly changes.
It also means that you can fairly easily copy a file from one branch to
another, as I just discovered...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 11/04/2012 02:19 PM, Invisible wrote:
> On 10/04/2012 01:55 PM, Invisible wrote:
>
>> So far, that understanding hasn't caused me too many problems. And I
>> quite like the way that a single repository holds multiple branches.
>> Darcs follows an "every repository /is/ a branch" mentality. Which
>> works, but makes it kinda long-winded to change branches. In NetBeans, I
>> can click "switch branch" and all my code suddenly changes.
>
> It also means that you can fairly easily copy a file from one branch to
> another, as I just discovered...
OTOH, if you do this with Darcs, you keep the file history, since Darcs
tracks individual files, not entire repositories. But on the first hand
again, you can't copy a history if it involves files you don't want to
copy...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4/11/2012 2:23, Invisible wrote:
> 1. Delete the last commit /and the changes it contained/. (Why would you
> ever want to do this?)
Changes aren't stored in git, so naturally deleting a commit deletes the
changes. Delete the commit without deleting the changes in your working
copy, and then create a new commit based on those changes.
> 2. Move the head back one commit, but not actually delete the commit.
If nothing points to the commit, it's effectively deleted.
> 3. Move the head back one commit, but not actually delete the commit, and
> leave the changes in the staging area.
There you go.
> Nowhere is there an option that says "perform the exact inverse of what I
> just told you to do".
I'm not sure what you're trying to say. #3 does what you want, if you follow
it up with "delete commits that no heads or other commits point to."
It's like you're complaining "there's no one option that both deletes the
directory element *and* removes the file's data."
>> "git gc" with the appropriate options to prune.
>
> That at least might work. (Somebody somewhere says prune only removes
> dangling branches older than 2 weeks.)
That would be the "appropriate options" to modify. Tell it to use zero days.
Why are you hell-bent on getting rid of that commit? Do you zero out all the
sectors of your hard drive every time you delete a file?
> It's really quite frustrating how all
> this documentation seems to be tutorials, blog posts and SO questions. Isn't
> there a /reference manual/ somewhere??
I pointed you to it. Plus, there's the man pages, which you often complain
you don't like because it's not tutorial enough. :-)
> If your commit is wrong, you don't /want/ to keep it. :-P
And in git, you don't. You just have the option of undeleting it for a week
or two.
> But seriously, if
> I want to change something, why shouldn't I be able to change it? Git has an
> "amend" command, it's just that it doesn't /amend/ the commit - it creates a
> new one, but leaves the old one in place.
Files are named after their contents. If you want to make a change, by
definition, you have to give it a new name.
> The Darcs "amend" command actually
> deletes the amended commit - you know, like what you'd expect an amendment
> to consist of. :-P
So your concern is that there's a commit out in the git data store that
nothing points to, that will get gc'ed in a couple of weeks, and which you
don't want to manually have to run an extra step to get rid of it before then?
> I agree it's not a good idea to go back and start changing history from 2
> years ago. But I don't see why you can't edit the last committed change.
> That just seems like a silly limitation.
You can. That's exactly what the -amend option does. It creates a new commit
because you changed the content and it has to be given a new name.
> In a sense, Darcs /isn't/ that worried about losing commits. In Darcs, a
> branch is a repository, and so to remove changes from a branch, you have to
> delete commits. That's just how it works.
Right. And you can remove commits from git by deleting them. You're just
unhappy that git asks you to take two steps (or wait a while) to remove a
commit irrevocably.
>>> Then again, shouldn't you be recording those
>>> two changes in the same commit?
>>
>> Heavens no!
>
> You shouldn't group related changes together, no?
No. You should group the minimum number of changes that gives you a
consistent state. What if you find the implementation of the routine is
right, but the code calling it is all screwed up?
> That's the other thing. With Darcs, I edit some files for a while, and then
> say "commit this". It shows me each and every change, and asks if I want to
> include that. And even though I've only got one set of changed files, I can
> syphon off the changes and ground them into several logically separate
> commits. Git can't seem to do that.
Sure it can. That's the coolest thing about git. Indeed, that's exactly the
point of the staging area being different from the working directory. You
copy the changes you want to commit into the staging area, then commit it.
What you mean is "netbeans interface to git doesn't do that."
> What I end up doing is just committing /everything/, because it's less
> hassle. But then if I ever need to go back, I'd have to go in big giant
> steps rather than small logical increments.
You're doing it wrong. Don't blame git for netbeans not being git.
> How about /not/ having to make a commit that records changes that I've
> already committed? :-P
You never made the change before where both pieces of code are in the same file.
> Actually, it would probably be easier if NetBeans would actually show me,
> you know, /a history/, so I can see what's actually /happening/, rather than
> just having to try to guess from the hashes which branches contain what...
Again, you're looking at a bad interface to git, and then complaining git
doesn't work. It's like looking at command.com and complaining "there's no
way to automate access to excel spreadsheets!" Nothing you're complaining
about is true of the git tools, only netbeans.
--
Darren New, San Diego CA, USA (PST)
"Oh no! We're out of code juice!"
"Don't panic. There's beans and filters
in the cabinet."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4/11/2012 2:57, Warp wrote:
> Who thought this would be a good idea?
On the other hand, it prevents you from having to check out the entire
repository just to get one project.
--
Darren New, San Diego CA, USA (PST)
"Oh no! We're out of code juice!"
"Don't panic. There's beans and filters
in the cabinet."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4/11/2012 3:33, Le_Forgeron wrote:
> (ok, give me a usage of a hammer for a gardener ?)
Snails. Wheeee!
--
Darren New, San Diego CA, USA (PST)
"Oh no! We're out of code juice!"
"Don't panic. There's beans and filters
in the cabinet."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4/11/2012 3:27, Invisible wrote:
> Question: Who designed gitk to default to using black text on a navy blue
> background? That's frigging *absurd*! Fortunately, you can change it -
> because it's utterly illegible!
Had the same problem with Eclipse. Turns out that it's picking up half the
configuration from its own files, the other half from the "system colors",
and assuming the system colors are (for example) that windows of certain
types are light colored instead of dark colored.
--
Darren New, San Diego CA, USA (PST)
"Oh no! We're out of code juice!"
"Don't panic. There's beans and filters
in the cabinet."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4/11/2012 6:37, Invisible wrote:
> OTOH, if you do this with Darcs, you keep the file history, since Darcs
> tracks individual files, not entire repositories.
Git deduces this, which is the right way to do it, methinks. Darcs can't
*really* tell if this file came from that file. It can only record what you
told it.
--
Darren New, San Diego CA, USA (PST)
"Oh no! We're out of code juice!"
"Don't panic. There's beans and filters
in the cabinet."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12/04/2012 05:20 PM, Darren New wrote:
> On 4/11/2012 3:33, Le_Forgeron wrote:
>> (ok, give me a usage of a hammer for a gardener ?)
>
> Snails. Wheeee!
CANNOT UNSEE. >_<
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12/04/2012 05:21 PM, Darren New wrote:
> On 4/11/2012 3:27, Invisible wrote:
>> Question: Who designed gitk to default to using black text on a navy blue
>> background? That's frigging *absurd*! Fortunately, you can change it -
>> because it's utterly illegible!
>
> Had the same problem with Eclipse. Turns out that it's picking up half
> the configuration from its own files, the other half from the "system
> colors", and assuming the system colors are (for example) that windows
> of certain types are light colored instead of dark colored.
Hmm. Well, under Windows XP, the window title colour /is/ navy blue... I
notice that when I ran it under GNOME, it looked fine. So yeah, maybe
that's it.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12/04/2012 05:22 PM, Darren New wrote:
> On 4/11/2012 6:37, Invisible wrote:
>> OTOH, if you do this with Darcs, you keep the file history, since Darcs
>> tracks individual files, not entire repositories.
>
> Git deduces this, which is the right way to do it, methinks. Darcs can't
> *really* tell if this file came from that file. It can only record what
> you told it.
I have repository A, which contains file X. I have repository B, which
does not contain file X. I pull all the changes relating to file X from
repository A into repository B. Now B contains X, and all its history.
If I do this with Git branches, then on branch B, a file named X
suddenly shows up, but there's no record that it was actually copied
from branch A. It just records what's /in/ the file.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12/04/2012 05:16 PM, Darren New wrote:
> On 4/11/2012 2:23, Invisible wrote:
>> 1. Delete the last commit /and the changes it contained/. (Why would you
>> ever want to do this?)
>
> Changes aren't stored in git, so naturally deleting a commit deletes the
> changes. Delete the commit without deleting the changes in your working
> copy, and then create a new commit based on those changes.
That's what I'm saying - option #1 deletes the commit AND REVERTS THE
WORKING COPY. I can't fathom why you'd want to revert your working copy.
That means that anything that was in the commit is now /gone forever/.
Which is no help if you actually want to redo the commit.
>> 2. Move the head back one commit, but not actually delete the commit.
>
> If nothing points to the commit, it's effectively deleted.
Except that every single time I look at the history tree, this dangling
commit shows up, with a description which doesn't match what's actually
in it. Which is the problem I was trying to sort out in the first place.
>> Nowhere is there an option that says "perform the exact inverse of what I
>> just told you to do".
>
> I'm not sure what you're trying to say. #3 does what you want, if you
> follow it up with "delete commits that no heads or other commits point to."
> That would be the "appropriate options" to modify. Tell it to use zero
> days.
>
> Why are you hell-bent on getting rid of that commit? Do you zero out all
> the sectors of your hard drive every time you delete a file?
I made a trivial mistake. It just surprises me that it's this long and
complex to undo such a simple and common mistake.
[Although it would be much /less/ common if NetBeans wasn't being so
retarded. :-P ]
>> But seriously, if
>> I want to change something, why shouldn't I be able to change it? Git
>> has an
>> "amend" command, it's just that it doesn't /amend/ the commit - it
>> creates a
>> new one, but leaves the old one in place.
>
> Files are named after their contents. If you want to make a change, by
> definition, you have to give it a new name.
Darcs also names changes after their hash. The Darcs amend command also
changes the commit name. It's just that Darcs automatically deletes the
old, incorrect commit, and keeps only the new, corrected one. Isn't that
what "amending" something would be expected to mean?
>> In a sense, Darcs /isn't/ that worried about losing commits.
>
> Right. And you can remove commits from git by deleting them. You're just
> unhappy that git asks you to take two steps (or wait a while) to remove
> a commit irrevocably.
It would just be nice if there was a way to actually mark unwanted
commits as "deleted", rather than them still showing up as part of the
valid history of the project.
>>> Heavens no!
>>
>> You shouldn't group related changes together, no?
>
> No. You should group the minimum number of changes that gives you a
> consistent state. What if you find the implementation of the routine is
> right, but the code calling it is all screwed up?
Heck, I generally don't even worry about consistent states. Not, as in,
whether the project is runnable. I work in whole logical changes. Like,
I group all the changes to do with X together, all the changes to do
with Y together, and so on. It might be that you need to apply X, Y and
Z to get back to a runnable state again. But it's more that if I'm in
the middle of editing and I screw it up, I want to be able to back out
just the thing I'm trying to edit, not the whole of X, Y and Z and start
over.
>> That's the other thing. With Darcs, I edit some files for a while, and
>> then
>> say "commit this". It shows me each and every change, and asks if I
>> want to
>> include that. And even though I've only got one set of changed files,
>> I can
>> syphon off the changes and ground them into several logically separate
>> commits. Git can't seem to do that.
>
> Sure it can. That's the coolest thing about git. Indeed, that's exactly
> the point of the staging area being different from the working
> directory. You copy the changes you want to commit into the staging
> area, then commit it.
No. This still requires you to manually edit the files to the right
point. Like, if I edit a file and change X, Y and Z, then when I decide
I want to commit it, I have to go through the file, undo Y and Z (but
not forget how to redo them), commit the file with just X changed, then
redo Y, and commit that, and finally redo Z and commit that. The fact
that there are two copies of the file is no help at all here. It's not
like you can edit the staging copy.
> What you mean is "netbeans interface to git doesn't do that."
Actually, NetBeans seems to have its own internal history tracking, so
in a sense, it /can/. You can find the lines you changed, hit "revert
change", do your commit, and then jab Undo a few times to redo the
changes. It's klunky and hard, but it's better than just Git by itself.
> You're doing it wrong.
Or rather, "Git isn't really supporting my workflow".
> Don't blame git for netbeans not being git.
Oh, /some/ of the problems I've had are definitely to do with NetBeans
being lame. I won't blame Git for that.
>> How about /not/ having to make a commit that records changes that I've
>> already committed? :-P
>
> You never made the change before where both pieces of code are in the
> same file.
I meant more that of you change one file on one branch, and an unrelated
file on another branch, to get those changes together, you need to
record a new commit. Even through there's no new changes, another than
both files being in the same branch now.
>> Actually, it would probably be easier if NetBeans would actually show me,
>> you know, /a history/, so I can see what's actually /happening/,
>> rather than
>> just having to try to guess from the hashes which branches contain
>> what...
>
> Again, you're looking at a bad interface to git, and then complaining
> git doesn't work.
No. With /this/ point, I'm complaining squarely about NetBeans. If you
install the actual Git binary, it comes with some passable tools for
visualising what's actually going on. It's not pretty, but it works.
(I'm still trying to figure out how to get gitk to resize so I can see
the whole history tree. There doesn't seem to be a way to enlarge the
tiny tree view at the top and shrink the enormous commit viewer at the
bottom which I don't care about...)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> On 4/11/2012 2:57, Warp wrote:
> > Who thought this would be a good idea?
> On the other hand, it prevents you from having to check out the entire
> repository just to get one project.
Shouldn't different projects go into different branches?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 13/04/2012 09:46 AM, Warp wrote:
> Darren New<dne### [at] sanrrcom> wrote:
>> On 4/11/2012 2:57, Warp wrote:
>>> Who thought this would be a good idea?
>
>> On the other hand, it prevents you from having to check out the entire
>> repository just to get one project.
>
> Shouldn't different projects go into different branches?
Depends on your SCM I suppose.
I know that, for example, GHC is managed as several interrelated
projects. GHC is a Haskell compiler written in Haskell, and as such
depends on the Haskell standard libraries, which are separate from the
actual compiler. The test suite is also a separate project. But all of
these projects live in the same source tree, so you can actually build
the compiler...
What it means is that you can, for example, update the test suite,
independent of any particular compiler version. Or if there's a
performance improvement to one of the standard libraries, you can
rebuild the compiler with that, without actually changing the compiler.
Stuff like that.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4/13/2012 1:36, Invisible wrote:
> That's what I'm saying - option #1 deletes the commit AND REVERTS THE
> WORKING COPY. I can't fathom why you'd want to revert your working copy.
Because you realized (say) that you've just made a change and a commit on
the wrong repository? If it's not the behavior you want, don't use that
option. :-)
> Except that every single time I look at the history tree, this dangling
> commit shows up,
That's kind of odd. I don't think commits with no pointers to them should be
showing up. But if it bothers you, git gc it. I suspect netbeans is what's
at fault here, not git.
> I made a trivial mistake. It just surprises me that it's this long and
> complex to undo such a simple and common mistake.
You made a simple mistake committing code changes to a repository
potentially shared with the entire world. :-) That's not a small mistake in
the grand scheme of things, and certainly worthy of requiring two entire
command lines to entirely eliminate.
> Darcs also names changes after their hash. The Darcs amend command also
> changes the commit name. It's just that Darcs automatically deletes the old,
> incorrect commit, and keeps only the new, corrected one. Isn't that what
> "amending" something would be expected to mean?
So does git. Maybe it's netbeans screwing things up.
> Heck, I generally don't even worry about consistent states. Not, as in,
> whether the project is runnable.
Generally, one is expected to not commit broken code. That's like one of the
fundamental no-no's of repositories. I guess you don't have coworkers tho.
Just so you know.
> I work in whole logical changes. Like, I
> group all the changes to do with X together, all the changes to do with Y
> together, and so on. It might be that you need to apply X, Y and Z to get
> back to a runnable state again. But it's more that if I'm in the middle of
> editing and I screw it up, I want to be able to back out just the thing I'm
> trying to edit, not the whole of X, Y and Z and start over.
Sure. But if logical change X can be broken into 4 separate steps, each of
which leaves you with a working system, why not commit in even smaller
steps? Why not commit the code to add records to the database, *then*
commit the UI that invokes that code? Then if you utterly screw up the UI,
you don't have to revert the database code.
> No. This still requires you to manually edit the files to the right point.
No. Really. It doesn't. Heck, you can even do it from the command line.
http://book.git-scm.com/4_interactive_adding.html
If you prefer the GUI, try this:
http://nathanj.github.com/gitguide/images/11.png
See the "unstage hunk" and "unstage lines"? There's also "stage hunk" and
"unstage hunk".
(Parent URL: http://nathanj.github.com/gitguide/tour.html )
Again, you're being borked by netbeans. Remember that git commits whatever
is in staging, without looking at your working copy. And it's not
remembering where diffs came from and such. So if this really was a feature
you needed, it would be trivial to add at the client end, and thus likely
would have been added already. Deciding what changes get committed and what
don't isn't part of git per se. It's just part of the front end. If you
wanted to write a program to commit any different lines with the letter X in
them, you could write that code pretty trivially.
> It's not like you can edit the staging copy.
It really is.
> Actually, NetBeans seems to have its own internal history tracking, so in a
> sense, it /can/. You can find the lines you changed, hit "revert change", do
> your commit, and then jab Undo a few times to redo the changes. It's klunky
> and hard, but it's better than just Git by itself.
No, it really isn't. It's harder than just git-via-netbeans by itself,
apparently.
>> You're doing it wrong.
> Or rather, "Git isn't really supporting my workflow".
What workflow are you trying to do? Submit only some of the changed
hunks/lines in a commit without submitting the others? Trust me - I do this
all the time. It's trivial. When I've finished a feature, I go thru the
git-gui to mark all the bugfixes, and commit them in separate commits, then
mark each feature and commit them. I tend to get something working and then
turn it into 5 or 6 commits.
>> You never made the change before where both pieces of code are in the
>> same file.
>
> I meant more that of you change one file on one branch, and an unrelated
> file on another branch, to get those changes together, you need to record a
> new commit. Even through there's no new changes, another than both files
> being in the same branch now.
So, there's no change, other than just this one change? Right, got it. ;-)
> (I'm still trying to figure out how to get gitk to resize so I can see the
> whole history tree. There doesn't seem to be a way to enlarge the tiny tree
> view at the top and shrink the enormous commit viewer at the bottom which I
> don't care about...)
Given it's in Tk, I'm assuming you grab the bar and drag it down, like any
other pane in Tk or Windows or X. :-)
--
Darren New, San Diego CA, USA (PST)
"Oh no! We're out of code juice!"
"Don't panic. There's beans and filters
in the cabinet."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4/13/2012 1:46, Warp wrote:
> Darren New<dne### [at] sanrrcom> wrote:
>> On 4/11/2012 2:57, Warp wrote:
>>> Who thought this would be a good idea?
>
>> On the other hand, it prevents you from having to check out the entire
>> repository just to get one project.
>
> Shouldn't different projects go into different branches?
You mean different repositories? Yes, you can do it that way, but then you
have to deal with people checking out branches in different places.
E.g., if I have a GUI for some code, and the back end, (or the kernel and a
bunch of drivers,) I might want to have them both in the same tree because
they make references to files via relative paths, but I might want to be
able to compile the back end without compiling the GUI.
--
Darren New, San Diego CA, USA (PST)
"Oh no! We're out of code juice!"
"Don't panic. There's beans and filters
in the cabinet."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4/13/2012 1:07, Invisible wrote:
> If I do this with Git branches, then on branch B, a file named X suddenly
> shows up, but there's no record that it was actually copied from branch A.
Sure there is. Otherwise, if you update X and push it, git won't know what
to push. Now, yes, if you copy just one file without actually copying the
commit from A, then you're not going to know the file came from A. But
that's the case if you stick the file on a USB stick and copy it that way
too. Answer: don't do that. Copy commits, not individual files.
--
Darren New, San Diego CA, USA (PST)
"Oh no! We're out of code juice!"
"Don't panic. There's beans and filters
in the cabinet."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Answer: don't do that. Copy commits, not individual files.
How do you actually do that?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Except that every single time I look at the history tree, this dangling
>> commit shows up,
>
> That's kind of odd. I don't think commits with no pointers to them
> should be showing up. But if it bothers you, git gc it. I suspect
> netbeans is what's at fault here, not git.
No, NetBeans won't show you a tree *at all*. It won't show you any
remotely useful information about the state of your Git repo. All it
shows is the names of the branches and the hash each one points to.
The dangling branch shows up in gitk though.
>> I made a trivial mistake. It just surprises me that it's this long and
>> complex to undo such a simple and common mistake.
>
> You made a simple mistake committing code changes to a repository
> potentially shared with the entire world. :-) That's not a small mistake
> in the grand scheme of things, and certainly worthy of requiring two
> entire command lines to entirely eliminate.
IF the change has already been shared with the world, then yes, that's
not going to be easy to fix at all. But I haven't - that's the point.
I'm used to it being trivial to fix mistakes that you haven't shared yet.
>> Heck, I generally don't even worry about consistent states. Not, as in,
>> whether the project is runnable.
>
> Generally, one is expected to not commit broken code. That's like one of
> the fundamental no-no's of repositories. I guess you don't have
> coworkers tho. Just so you know.
So if adding a new feature means performing a major refactor of the
entire codebase, you're supposed to do that as one giant commit?
> Sure. But if logical change X can be broken into 4 separate steps, each
> of which leaves you with a working system, why not commit in even
> smaller steps?
More to the point, if what you need to do involves making a major
breaking change in step 1, and not fixing the last of the things it
breaks until step 25, are you really going to put all 25 steps into a
single giant commit?
Like I said, I generally work in terms of points in time that I'm likely
to want to go back to, rather than points in time where the code
compiles. (If I did the latter, the entire project history would be,
like, 3 giant commits with nothing inbetween!)
>> No. This still requires you to manually edit the files to the right
>> point.
>
> No. Really. It doesn't. Heck, you can even do it from the command line.
>
> http://book.git-scm.com/4_interactive_adding.html
Ah, so there *is* an interactive diff mode, it's just hidden?
> Again, you're being borked by netbeans.
Yeah, it's not the best. Then again, it appears to support Mercurial and
Subversion as well, so maybe the problem is that it tries to handle them
all the same way...
> Remember that git commits
> whatever is in staging, without looking at your working copy.
Sure. But if you want to record a particular version of that file, you
still need to generate it somehow. Git only allows you to stage the
current working copy of each file - or so I thought.
>> It's not like you can edit the staging copy.
>
> It really is.
Really? And how exactly do you do that? Does Git even store the staged
copy as a flat file, or is it a compressed image somewhere?
>>> You're doing it wrong.
>> Or rather, "Git isn't really supporting my workflow".
>
> What workflow are you trying to do? Submit only some of the changed
> hunks/lines in a commit without submitting the others? Trust me - I do
> this all the time. It's trivial.
As in "so trivial that I can't figure out how to do it"? :-P
> So, there's no change, other than just this one change? Right, got it. ;-)
With Git, moving a change from one branch to another is itself a change.
With Darcs, it is not.
>> (I'm still trying to figure out how to get gitk to resize so I can see
>> the
>> whole history tree. There doesn't seem to be a way to enlarge the tiny
>> tree
>> view at the top and shrink the enormous commit viewer at the bottom
>> which I
>> don't care about...)
>
> Given it's in Tk, I'm assuming you grab the bar and drag it down, like
> any other pane in Tk or Windows or X. :-)
Yeah, you'd *think* that would work... but alas, no.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4/16/2012 1:24, Invisible wrote:
> The dangling branch shows up in gitk though.
Are you sure it's dangling? There's no head pointing to it at all?
> IF the change has already been shared with the world, then yes, that's not
> going to be easy to fix at all. But I haven't - that's the point. I'm used
> to it being trivial to fix mistakes that you haven't shared yet.
So, it's two command lines instead of one. Not exactly "trivial" but far
from "difficult". And of course it'll go away on its own if you just leave
it, so yeah, pretty trivial I'd say. Certainly "trivial" for anyone writing
a sufficiently complex system that git is helpful.
>> Generally, one is expected to not commit broken code. That's like one of
>> the fundamental no-no's of repositories. I guess you don't have
>> coworkers tho. Just so you know.
>
> So if adding a new feature means performing a major refactor of the entire
> codebase, you're supposed to do that as one giant commit?
Nope. First, you refactor, bit by bit, with a commit for each refactor. Then
you add the new feature. Give an example, and I'd tell you where I'd split
it up.
>> Sure. But if logical change X can be broken into 4 separate steps, each
>> of which leaves you with a working system, why not commit in even
>> smaller steps?
>
> More to the point, if what you need to do involves making a major breaking
> change in step 1, and not fixing the last of the things it breaks until step
> 25, are you really going to put all 25 steps into a single giant commit?
Yes. If the system doesn't compile, you don't commit it. Otherwise, you've
broken everyone who is supposed to be working on the code except yourself.
It's not really 25 steps if it doesn't compile in the middle, is it?
> Like I said, I generally work in terms of points in time that I'm likely to
> want to go back to, rather than points in time where the code compiles. (If
> I did the latter, the entire project history would be, like, 3 giant commits
> with nothing inbetween!)
Like *I* said, this doesn't fly when you're actually working on a team.
>> http://book.git-scm.com/4_interactive_adding.html
> Ah, so there *is* an interactive diff mode, it's just hidden?
If by "hidden" you mean "interactive commit" in google taking you to the
official documentation telling you how to do it, yes.
>> Again, you're being borked by netbeans.
>
> Yeah, it's not the best. Then again, it appears to support Mercurial and
> Subversion as well, so maybe the problem is that it tries to handle them all
> the same way...
That's my suspicion.
>> Remember that git commits
>> whatever is in staging, without looking at your working copy.
>
> Sure. But if you want to record a particular version of that file, you still
> need to generate it somehow. Git only allows you to stage the current
> working copy of each file - or so I thought.
It lets you stage whatever you want. You can put files into the repository
that don't exist anywhere outside the repository.
>>> It's not like you can edit the staging copy.
>>
>> It really is.
>
> Really? And how exactly do you do that? Does Git even store the staged copy
> as a flat file, or is it a compressed image somewhere?
It's a file in the repository. The "staging" directory is essentially a
head. If you look at the lowest level commands, the way git works is it
creates a blob for each file as you stage it, then creates the appropriate
trees, then when you commit, all it's really doing is creating the commit
blob. A commit doesn't actually add any files per se to the repository.
>>>> You're doing it wrong.
>>> Or rather, "Git isn't really supporting my workflow".
>>
>> What workflow are you trying to do? Submit only some of the changed
>> hunks/lines in a commit without submitting the others? Trust me - I do
>> this all the time. It's trivial.
>
> As in "so trivial that I can't figure out how to do it"? :-P
If you use the right interface, it's trivial. If you go through an interface
that also works with svn (which doesn't let you commit files not in the
working directory), then it'll be less trivial.
>> So, there's no change, other than just this one change? Right, got it. ;-)
>
> With Git, moving a change from one branch to another is itself a change.
> With Darcs, it is not.
Darcs only has one branch per repository anyway, yes?
>> Given it's in Tk, I'm assuming you grab the bar and drag it down, like
>> any other pane in Tk or Windows or X. :-)
>
> Yeah, you'd *think* that would work... but alas, no.
Huh. Maybe grab it on the little square? I don't remember.
--
Darren New, San Diego CA, USA (PST)
"Oh no! We're out of code juice!"
"Don't panic. There's beans and filters
in the cabinet."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4/16/2012 1:18, Invisible wrote:
>> Answer: don't do that. Copy commits, not individual files.
>
> How do you actually do that?
The commands are "pull" and "push" I believe. Look for something talking
about say "origin/head" in the book. Or, even better, read that book. It'll
take you about 20 minutes, and then you'll know how git works.
--
Darren New, San Diego CA, USA (PST)
"Oh no! We're out of code juice!"
"Don't panic. There's beans and filters
in the cabinet."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 16/04/2012 06:07 PM, Darren New wrote:
> On 4/16/2012 1:24, Invisible wrote:
>
>> The dangling branch shows up in gitk though.
>
> Are you sure it's dangling? There's no head pointing to it at all?
Pretty sure. You want a screenshot?
>> IF the change has already been shared with the world, then yes, that's
>> not
>> going to be easy to fix at all. But I haven't - that's the point. I'm
>> used
>> to it being trivial to fix mistakes that you haven't shared yet.
>
> So, it's two command lines instead of one. Not exactly "trivial" but far
> from "difficult". And of course it'll go away on its own if you just
> leave it, so yeah, pretty trivial I'd say. Certainly "trivial" for
> anyone writing a sufficiently complex system that git is helpful.
The whole point is, I've got a commit that's labelled as the wrong
thing. That's confusing. Making even /more/ commits just makes things
more confusing. Now I've got two commits containing the same stuff but
with different names and labels. I was trying to make it /less/
confusing, not /more/...
>> So if adding a new feature means performing a major refactor of the
>> entire codebase, you're supposed to do that as one giant commit?
>
> Nope. First, you refactor, bit by bit, with a commit for each refactor.
> Then you add the new feature. Give an example, and I'd tell you where
> I'd split it up.
OK. So suppose that I have a class, and to use it you're supposed to
call the methods A(), B() and C(), in that order. And then I decide
"hey, actually that doesn't work so great", and I change it to that you
have to call A(), then X(), and then Z(), and the type signature for A()
is now different.
I've now broken all 16 subclasses, which I'll now have to refactor to
juggle the existing code into the new locations. In some cases, I'll
have to actually change the fundamental way the logic works. (That's the
entire point of the refactor, after all.) And I've also broken all 25
clients of these classes, which will also need to be rearranged if not
completely rewritten.
So... /how/ do I do this without making the project not compile while
I'm fixing all these dozens of broken classes?
>> are you really going to put all 25 steps into a single giant commit?
>
> Yes. If the system doesn't compile, you don't commit it. Otherwise,
> you've broken everyone who is supposed to be working on the code except
> yourself.
...which is why you don't push any changes until you've finished /all/
of them?
> Like *I* said, this doesn't fly when you're actually working on a team.
Well, obviously I'm never going to be in that situation, am I? (Let's
face it, nobody's going to hire /me/ to write code...)
>>> http://book.git-scm.com/4_interactive_adding.html
>> Ah, so there *is* an interactive diff mode, it's just hidden?
>
> If by "hidden" you mean "interactive commit" in google taking you to the
> official documentation telling you how to do it, yes.
I did spend some time playing with this. I couldn't figure out for the
life of me how to make it work. Git doesn't appear to behave the way the
examples say it does. (E.g., selecting a menu item doesn't change the
command prompt.)
Fortunately, the Git GUI seems to work. For reasons I don't comprehend,
if you change any file, by default /all/ the changes in that file are
considered to be "one hunk", so you have to select line-by-line which
changes you want. Which is kind of tedious if you want to select the 25
consecutive lines in the middle of the files without the 2 lines you
changed right at the bottom. But hey, it works.
I guess the real solution is to never make more than one edit at once.
(Oh, and I was trying this under Linux today. Unfortunately, hitting the
"edit" button trapped me inside Vi...)
>>> Again, you're being borked by netbeans.
>>
>> Yeah, it's not the best. Then again, it appears to support Mercurial and
>> Subversion as well, so maybe the problem is that it tries to handle
>> them all
>> the same way...
>
> That's my suspicion.
I gather a few people use Mercurial too. Maybe I'll have a look at that
sometime... Don't think I'll bother with Subversion though. Warp's sold
it to me.
>>>> Or rather, "Git isn't really supporting my workflow".
>>>
>>> What workflow are you trying to do? Submit only some of the changed
>>> hunks/lines in a commit without submitting the others? Trust me - I do
>>> this all the time. It's trivial.
>>
>> As in "so trivial that I can't figure out how to do it"? :-P
>
> If you use the right interface, it's trivial. If you go through an
> interface that also works with svn (which doesn't let you commit files
> not in the working directory), then it'll be less trivial.
Even talking to Git directly from the command line, it's very far from
trivial.
>> With Git, moving a change from one branch to another is itself a change.
>> With Darcs, it is not.
>
> Darcs only has one branch per repository anyway, yes?
Yeah. So to move a change from one "branch" to another, really you're
just copying a changeset from one repository to another.
I will admit, having multiple branches per repository is much more
convenient.
>>> Given it's in Tk, I'm assuming you grab the bar and drag it down, like
>>> any other pane in Tk or Windows or X. :-)
>>
>> Yeah, you'd *think* that would work... but alas, no.
>
> Huh. Maybe grab it on the little square? I don't remember.
I managed to figure it out. You can't grab the /edge/ of the divider;
that doesn't work. But if you point at the gab between the text box in
the left and the bottom below it, you can drag that. In other words, the
edges aren't draggable, but some random pixel in the middle of the
tangle of boxes and buttons /is/, and it drags the whole lot with it.
Obviously. I mean, why did't I think of that before? :-P
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4/16/2012 11:26, Orchid Win7 v1 wrote:
> Pretty sure. You want a screenshot?
Not really. That wouldn't actually tell you anyway. :-) I don't remember if
git's gui tools tell you about dangling commits or not or what.
> The whole point is, I've got a commit that's labelled as the wrong thing.
So garbage collect it! The solution is trivial. Read the "git gc" page.
> OK. So suppose that I have a class, and to use it you're supposed to call
> the methods A(), B() and C(), in that order. And then I decide "hey,
> actually that doesn't work so great", and I change it to that you have to
> call A(), then X(), and then Z(), and the type signature for A() is now
> different.
OK.
> I've now broken all 16 subclasses, which I'll now have to refactor to juggle
> the existing code into the new locations. In some cases, I'll have to
> actually change the fundamental way the logic works. (That's the entire
> point of the refactor, after all.) And I've also broken all 25 clients of
> these classes, which will also need to be rearranged if not completely
> rewritten.
That's a bad way to do it.
> So... /how/ do I do this without making the project not compile while I'm
> fixing all these dozens of broken classes?
Make B() and C() do the right thing w.r.t. X() and Z(), and make the version
of A() with the old arguments invoke the correct version of A() with the new
arguments.
So, basically, write the new code but don't use it. Commit. Make the old
interface invoke the new code. Commit. Make the old code invoke the new
interface. Commit commit commit. Throw away the old code. Commit.
>>> are you really going to put all 25 steps into a single giant commit?
>>
>> Yes. If the system doesn't compile, you don't commit it. Otherwise,
>> you've broken everyone who is supposed to be working on the code except
>> yourself.
>
> ...which is why you don't push any changes until you've finished /all/ of them?
If you're modifying code in a way that breaks lots of other code, then yes.
If you're doing something that doesn't break other code, then yes. If you're
committing broken code locally just so it doesn't get lost or something,
then rebase your commit before you push it, or whatever it's called when you
roll up a bunch of commits into one big one.
The point is that if you make changes to the code of 40 other people, and it
takes you three or four weeks to finish it, then likely other people have
used the old interface while you've been refactoring it, and you're screwed
when you push it anwyay.
>> Like *I* said, this doesn't fly when you're actually working on a team.
>
> Well, obviously I'm never going to be in that situation, am I? (Let's face
> it, nobody's going to hire /me/ to write code...)
Not with that attitude, no. :)
> Fortunately, the Git GUI seems to work. For reasons I don't comprehend, if
> you change any file, by default /all/ the changes in that file are
> considered to be "one hunk", so you have to select line-by-line which
> changes you want.
One hunk is one contiguous set of changed lines. Are you sure you didn't do
something like add spaces to the end of each line or something? A "hunk" is
a list of lines, and it's what diff outputs with line numbers at the top.
> Which is kind of tedious if you want to select the 25
> consecutive lines in the middle of the files without the 2 lines you changed
> right at the bottom. But hey, it works.
Read up the options on diff to see how to make your hunks smaller.
> I guess the real solution is to never make more than one edit at once.
I've never had a problem. It's like you're complaining you keep crashing
into walls, and the only possible solution is to always drive in reverse or
something. What *are* you doing wrong?
> (Oh, and I was trying this under Linux today. Unfortunately, hitting the
> "edit" button trapped me inside Vi...)
export EDITOR=nano
or whatever editor you most approve. This has been a UNIX thing since long
before emacs was invented.
> Even talking to Git directly from the command line, it's very far from trivial.
I had zero problems figuring out gitk's interface.
> I managed to figure it out. You can't grab the /edge/ of the divider; that
> doesn't work. But if you point at the gab between the text box in the left
> and the bottom below it, you can drag that. In other words, the edges aren't
> draggable, but some random pixel in the middle of the tangle of boxes and
> buttons /is/, and it drags the whole lot with it. Obviously. I mean, why
> did't I think of that before? :-P
Sounds poorly configured, yes. I'm pretty sure that's explicitly why there's
a little box on the line. But yah, you have to wave the mouse around until
the cursor changes into the "move a line" cursor. Kind of annoying sometimes.
--
Darren New, San Diego CA, USA (PST)
"Oh no! We're out of code juice!"
"Don't panic. There's beans and filters
in the cabinet."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Pretty sure. You want a screenshot?
>
> Not really. That wouldn't actually tell you anyway. :-) I don't remember
> if git's gui tools tell you about dangling commits or not or what.
gitk shows you a little tree, with a node for each commit object, and a
square for each head. (And the current head is in bold.) There is no
square pointing to the old commit, so presumably it's dangling.
(Suddenly I feel like Neo...)
>> The whole point is, I've got a commit that's labelled as the wrong thing.
>
> So garbage collect it! The solution is trivial. Read the "git gc" page.
That's a pretty obscure thing to need to look up just to fix an obvious
problem.
>> I've now broken all 16 subclasses, which I'll now have to refactor to
>> juggle
>> the existing code into the new locations. In some cases, I'll have to
>> actually change the fundamental way the logic works. (That's the entire
>> point of the refactor, after all.) And I've also broken all 25 clients of
>> these classes, which will also need to be rearranged if not completely
>> rewritten.
>
> That's a bad way to do it.
So... what do you suggest?
> So, basically, write the new code but don't use it. Commit. Make the old
> interface invoke the new code. Commit. Make the old code invoke the new
> interface. Commit commit commit. Throw away the old code. Commit.
Damn. Way to make a complex change that much more complex. o_O
>> ...which is why you don't push any changes until you've finished /all/
>> of them?
>
> If you're modifying code in a way that breaks lots of other code, then
> yes. If you're doing something that doesn't break other code, then yes.
> If you're committing broken code locally just so it doesn't get lost or
> something, then rebase your commit before you push it, or whatever it's
> called when you roll up a bunch of commits into one big one.
And here I thought big commits were a bad idea. :-P
> The point is that if you make changes to the code of 40 other people,
> and it takes you three or four weeks to finish it, then likely other
> people have used the old interface while you've been refactoring it, and
> you're screwed when you push it anwyay.
Isn't that why you create a new branch for breaking changes? Especially
in an SCM that makes branching particularly easy...
>>> Like *I* said, this doesn't fly when you're actually working on a team.
>>
>> Well, obviously I'm never going to be in that situation, am I? (Let's
>> face it, nobody's going to hire /me/ to write code...)
>
> Not with that attitude, no. :)
I doubt any amount of attitude is going to change the fact that I'm
useless at all the popular programming languages. :-P
>> Fortunately, the Git GUI seems to work. For reasons I don't
>> comprehend, if
>> you change any file, by default /all/ the changes in that file are
>> considered to be "one hunk", so you have to select line-by-line which
>> changes you want.
>
> One hunk is one contiguous set of changed lines. Are you sure you didn't
> do something like add spaces to the end of each line or something? A
> "hunk" is a list of lines, and it's what diff outputs with line numbers
> at the top.
If I had, wouldn't the changed lines show up as part of the hunk?
I changed a header file. Added two lines at the top, and one at the
bottom (25 lines away). It showed up as two separate changes, but
clicking on the top and selecting "stage hunk" staged the entire file. I
had to go through and stage it line by line to get it to work right.
> Read up the options on diff to see how to make your hunks smaller.
That's not going to work from the GUI. (And I can't make it work at all
from the CLI. Like I said, Git's behaviour doesn't match the instructions.)
> I've never had a problem. It's like you're complaining you keep crashing
> into walls, and the only possible solution is to always drive in reverse
> or something. What *are* you doing wrong?
*shrugs*
>> (Oh, and I was trying this under Linux today. Unfortunately, hitting the
>> "edit" button trapped me inside Vi...)
>
> export EDITOR=nano
> or whatever editor you most approve. This has been a UNIX thing since
> long before emacs was invented.
Sure. This still doesn't help me find a way out of Vi without rebooting
the VM.
>> I managed to figure it out. You can't grab the /edge/ of the divider;
>> that doesn't work. In other words, the edges aren't
>> draggable, but some random pixel in the middle of the tangle of boxes and
>> buttons /is/. Obviously. I mean, why did't I think of that before? :-P
>
> Sounds poorly configured, yes. I'm pretty sure that's explicitly why
> there's a little box on the line. But yah, you have to wave the mouse
> around until the cursor changes into the "move a line" cursor. Kind of
> annoying sometimes.
Very random and annoying, yes... But hey, I fixed it now. I guess.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4/17/2012 2:03, Invisible wrote:> gitk shows you a little tree, with a
node for each commit object, and a
> square for each head. (And the current head is in bold.) There is no square
> pointing to the old commit, so presumably it's dangling. (Suddenly I feel
> like Neo...)
OK. I don't know. I never really worried about it.
>> So garbage collect it! The solution is trivial. Read the "git gc" page.
>
> That's a pretty obscure thing to need to look up just to fix an obvious
> problem.
Only if having a dangling commit bothers you.
>> That's a bad way to do it.
> So... what do you suggest?
Don't break the old code before the new code works.
>> So, basically, write the new code but don't use it. Commit. Make the old
>> interface invoke the new code. Commit. Make the old code invoke the new
>> interface. Commit commit commit. Throw away the old code. Commit.
>
> Damn. Way to make a complex change that much more complex. o_O
Welcome to working with lots of other people on the same project. Why do you
think people complain about the problems of legacy code?
In practice, it's usually not that hard, because the likelihood that you
need to break 25 separate classes is low if you've designed your code decently.
>> If you're modifying code in a way that breaks lots of other code, then
>> yes. If you're doing something that doesn't break other code, then yes.
>> If you're committing broken code locally just so it doesn't get lost or
>> something, then rebase your commit before you push it, or whatever it's
>> called when you roll up a bunch of commits into one big one.
>
> And here I thought big commits were a bad idea. :-P
They are. But if you're going to break lots of code at once, yes, you don't
have a lot of choice. I.e., if you only want to push big commits, you can do
that, even if you do it with a bunch of small commits.
> Isn't that why you create a new branch for breaking changes? Especially in
> an SCM that makes branching particularly easy...
That's part of it, but you still have to merge it back in, which is going to
be a mess of 25 people have been working on the 25 classes you've been changing.
>> One hunk is one contiguous set of changed lines. Are you sure you didn't
>> do something like add spaces to the end of each line or something? A
>> "hunk" is a list of lines, and it's what diff outputs with line numbers
>> at the top.
>
> If I had, wouldn't the changed lines show up as part of the hunk?
It should, sure.
> I changed a header file. Added two lines at the top, and one at the bottom
> (25 lines away). It showed up as two separate changes, but clicking on the
> top and selecting "stage hunk" staged the entire file. I had to go through
> and stage it line by line to get it to work right.
Did you already stage the entire file? You have to unstage the file as a
whole, then stage it one hunk at a time. Or unstage the hunks on the bottom
half?
> Sure. This still doesn't help me find a way out of Vi without rebooting the VM.
Use ":q!" to exit vi. Then set your EDITOR variable for next time.
Really? You couldn't figure out google enough to figure out how to get out
of VI?
> Very random and annoying, yes... But hey, I fixed it now. I guess.
Tk is still, in many ways, stuck in the 80's of X-Windows development.
--
Darren New, San Diego CA, USA (PST)
"Oh no! We're out of code juice!"
"Don't panic. There's beans and filters
in the cabinet."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>> So garbage collect it! The solution is trivial. Read the "git gc" page.
>>
>> That's a pretty obscure thing to need to look up just to fix an obvious
>> problem.
>
> Only if having a dangling commit bothers you.
Having stuff that's incorrectly labelled bothers me, yes. That's why I
amended it in the first place. :-P
> Don't break the old code before the new code works.
>> Damn. Way to make a complex change that much more complex. o_O
>
> Welcome to working with lots of other people on the same project. Why do
> you think people complain about the problems of legacy code?
>
> In practice, it's usually not that hard, because the likelihood that you
> need to break 25 separate classes is low if you've designed your code
> decently.
Apparently having 25 token classes is "not designing your code decently"
then...
>> Isn't that why you create a new branch for breaking changes?
>
> That's part of it, but you still have to merge it back in, which is
> going to be a mess of 25 people have been working on the 25 classes
> you've been changing.
Isn't that why you /talk to/ the other developers?
I'm pretty sure that without communication, any development effort is
doomed to end in failure. Multiple people developing the same code,
fixing the same bugs different ways, and generally getting in each
other's way.
>> Sure. This still doesn't help me find a way out of Vi without
>> rebooting the VM.
>
> Use ":q!" to exit vi. Then set your EDITOR variable for next time.
>
> Really? You couldn't figure out google enough to figure out how to get
> out of VI?
Gotta work out that it's Vi first. :-P It's not like it says "Vi" on it.
> Tk is still, in many ways, stuck in the 80's of X-Windows development.
Yeah, I never did like Tk. :-P
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4/20/2012 1:14, Invisible wrote:
>> In practice, it's usually not that hard, because the likelihood that you
>> need to break 25 separate classes is low if you've designed your code
>> decently.
>
> Apparently having 25 token classes is "not designing your code decently"
> then...
Note that if what you're changing is mindless, then sure, make lots of
changes. If you're (for example) renaming a routine inherited by 25 classes
or something, sure.
If you have to spend an hour on each one thinking how to fix it, chances are
you're either making too big a change, or your design was wrong to start
with. (Of course, fixing that design implies breaking 25 classes, so...)
>> That's part of it, but you still have to merge it back in, which is
>> going to be a mess of 25 people have been working on the 25 classes
>> you've been changing.
>
> Isn't that why you /talk to/ the other developers?
Sure. If you can get people to stop development on those things for however
long it takes you to fix them, that works. Sometimes that's not feasible.
Especially if it's live production code.
> I'm pretty sure that without communication, any development effort is doomed
> to end in failure. Multiple people developing the same code, fixing the same
> bugs different ways, and generally getting in each other's way.
Sure. But if those 25 classes are in (say) 25 different projects run by 25
different groups, you're going to get in their way. If you're changing the
parser library, and you affect everyone in your 15,000-developer company
that uses that parser library, you're going to have a world of trouble
getting everyone to stop.
>> Tk is still, in many ways, stuck in the 80's of X-Windows development.
> Yeah, I never did like Tk. :-P
It has always been ugly, yes. :-)
--
Darren New, San Diego CA, USA (PST)
"Oh no! We're out of code juice!"
"Don't panic. There's beans and filters
in the cabinet."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>> In practice, it's usually not that hard, because the likelihood that you
>>> need to break 25 separate classes is low if you've designed your code
>>> decently.
>>
>> Apparently having 25 token classes is "not designing your code decently"
>> then...
>
> Note that if what you're changing is mindless, then sure, make lots of
> changes. If you're (for example) renaming a routine inherited by 25
> classes or something, sure.
>
> If you have to spend an hour on each one thinking how to fix it, chances
> are you're either making too big a change, or your design was wrong to
> start with. (Of course, fixing that design implies breaking 25 classes,
> so...)
Actually, it took me about 20 minutes to fix all the changes. It's just
that for those 20 minutes, the code is broken. And if anybody got some
of the commits but not the rest, that'd have broken code.
>> Isn't that why you /talk to/ the other developers?
>
> Sure. If you can get people to stop development on those things for
> however long it takes you to fix them, that works. Sometimes that's not
> feasible. Especially if it's live production code.
Which leads me back to "isn't that what branches are for?"
>> I'm pretty sure that without communication, any development effort is
>> doomed
>> to end in failure. Multiple people developing the same code, fixing
>> the same
>> bugs different ways, and generally getting in each other's way.
>
> Sure. But if those 25 classes are in (say) 25 different projects run by
> 25 different groups, you're going to get in their way. If you're
> changing the parser library, and you affect everyone in your
> 15,000-developer company that uses that parser library, you're going to
> have a world of trouble getting everyone to stop.
So create a new branch. Play around with the new design in your
experimental branch. /When it's finished/, merge it back into the main
trunk.
Isn't that how this game is supposed to work?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4/21/2012 11:22, Orchid Win7 v1 wrote:
> Actually, it took me about 20 minutes to fix all the changes. It's just that
> for those 20 minutes, the code is broken. And if anybody got some of the
> commits but not the rest, that'd have broken code.
Then that's not a really big change. It should be all one commit.
>>> Isn't that why you /talk to/ the other developers?
>>
>> Sure. If you can get people to stop development on those things for
>> however long it takes you to fix them, that works. Sometimes that's not
>> feasible. Especially if it's live production code.
>
> Which leads me back to "isn't that what branches are for?"
Only if you like doing the merges. If you're talking about 20 minutes, sure,
you don't even need a branch. If you're talking about a few weeks, you're
going to have a mess of a merge.
> So create a new branch. Play around with the new design in your experimental
> branch. /When it's finished/, merge it back into the main trunk.
>
> Isn't that how this game is supposed to work?
Indeed, as long as the merge isn't too messy. Imagine if two people do the
same sort of thing at once.
--
Darren New, San Diego CA, USA (PST)
"Oh no! We're out of code juice!"
"Don't panic. There's beans and filters
in the cabinet."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 23/04/2012 04:22 AM, Darren New wrote:
> On 4/21/2012 11:22, Orchid Win7 v1 wrote:
>> Actually, it took me about 20 minutes to fix all the changes. It's
>> just that
>> for those 20 minutes, the code is broken. And if anybody got some of the
>> commits but not the rest, that'd have broken code.
>
> Then that's not a really big change. It should be all one commit.
The entire codebase is under 25KB. Arguably the project is too tiny for
version control to actually matter. :-P
>> Which leads me back to "isn't that what branches are for?"
>
> Only if you like doing the merges. If you're talking about 20 minutes,
> sure, you don't even need a branch. If you're talking about a few weeks,
> you're going to have a mess of a merge.
OK, fair enough.
>> Isn't that how this game is supposed to work?
>
> Indeed, as long as the merge isn't too messy. Imagine if two people do
> the same sort of thing at once.
Which is why you need communication. If nothing else, having two people
try to implement the same thing is a waste of effort.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 11 Apr 2012 05:57:16 -0400, Warp wrote:
> Copy an unversioned directory from somewhere else onto a
> versioned directory in your project? Svn breaks.
Actually that does not break Svn. Those are just files
that Svn does not track. But the other points you mentioned
are quite valid.
--
Joel Yliluoma - http://iki.fi/bisqwit/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
