Google closing Yet Another Service - GoogleCode

EvanED

I see it as being basically more honest as to what actually happened.

I meant to put this in my last reply but forgot.

I can kind of see this position. But I feel like your VCS history is already not honest about what happened. If I typo std::vector as std::vcetor, I don't commit that mistake because it's honest. If I get halfway done with a bug fix or whatever and realize there's a better way, I don't (usually) commit that to illustrate how I got to the final solution.

So rebasing isn't the difference between curating your history (to show a nicer view) and not curating (to be accurate with how you got to the answer); it's the difference between curating some and curating more.

tar

@EvanED said:

Where #2 gets annoying is if both the feature change and the bug fix have like half a dozen files spread around and intermixed, but they are still in independent files. This can be dealt with as in #2, but with most VCSs you have to explicitly name all of the files you want to commit in the commit command. Git's index provides (IMO) a rather nicer way, letting you sort of split up what you want to commit into multiple add commands. I think this can be more convenient, e.g. by doing cd foo; git add foo.c; git add foo.h; cd ../bar; git add bar.c; git add bar.h instead of git commit foo/foo.c foo/foo.h bar/bar.c bar/bar.h because it means you can do other things in between looking at the files, e.g. do diffs. And on top of that, the index somewhat enables git add --interactive,which is basically sort of an interactive status thing: it'll show you a list of the files that have been modified, and you can just type 1, 2, 5, 7 or something to select from that list. The index also enables...

Perforce's changelist concept is the best way I've seen this handled—ever file I check out from the repo is placed into a 'folder' and I can group related changes into logical units and commit each set of changes atomically. TFS has its "Included/Excluded Files" in Pending Changes which gets you part of the way there, but I always preferred the generality of the Perforce approach.

Git's ability to stage parts of a file for commit is probably the one git feature which I could see was uncontraversially a good idea—I don't think it would be impossible for Perforce to add similar functionality so that I could put selected changes in the same file into different changelists (which I think would hit your point #4).

I guess I'm just spoiled from years of Perforce use, once you've got used to having changelists, any other VCS feels underpowered...

EvanED

@tar said:

Perforce's changelist concept is the best way I've seen this handled

Now that you've said that, you reminded me that Subversion has changelists too. I forgot about that feature, and I should probably use it more; I that lets you do something like what I said for Git does well for #3 as well. (I think you can incrementally add things to a change list, then commit a change list. What I don't know is if the changelists are "persistent" or if they go away at commit; I think it might be the latter.)

But, as you say, that still leaves #4 to hit... and while other VCSs certainly could add this feature (e.g. it has nothing to do with being distributed), AFAIK it's still very uncommon.

(I did write a script for Subversion, though it's quite inferior to git commit --patch -- it gets the svn diff, reverts all the files, then asks if you want to commit each hunk; it applies each that you say "yes" to and commits, then applies all the others.)

ben_lubar

git add -p is like the best thing ever.

tar

@EvanED said:

Now that you've said that, you reminded me that Subversion has changelists too. I forgot about that feature,

Wow, you're right! I have some reading to do! :D

Changelists

EvanED

@tar said:

Wow, you're right! I have some reading to do! :D

One good thing I have to say about Subversion is that they aren't sitting idly by; they are actually continuing to make UI improvements.¹ Mergeinfo, ^ syntax, changelists, and more make SVN rather nicer to use now than when I first stated using it (when it was already way better than CVS).

¹ As much as... certain people... will doubt this, it's true of Git as well. :-)

tar

Huh, so AFAICT not one of the Linux Subversion GUIs supports changelists, but they are available from the CLI. Which might explain why I've never discovered them...
Also a being in a changelist is completely independent of the file's modification state, which is slightly different to P4. But it seems easy enough to take all your currently checked-out files and dump them into a changelist:

$ svn stat | grep -v ^? | sed -e 's/^.//' | xargs svn changelist test1

EvanED

I looked through the last few versions of release notes... I should also make use of svn patch (1.7) and see if property inheritance (1.8) can make svn:ignore not awful now.

Edit: at least a quick investigation seems to indicate that the Subversion devs are, in fact, still brain dead, and svn:ignore is still awful.

tar

@EvanED said:

svn:ignore is still awful.

It's always worked for me. Then again, it's not clear what the benefit would be if it was inherited, so there's that. (I always do svn operations from the root of the tree anyway...)

ben_lubar

If you ignore *.o, does it ignore *.o in subdirectories as well?

tar

I have no idea, I've never tried to do that. I have it set to ignore obj/ at the toplevel, and it ignores all the files and subdirectories under that. Most of those probably are *.o files...

EvanED

@ben_lubar said:

If you ignore *.o, does it ignore *.o in subdirectories as well?

There's a set of extensions, including .o, that are ignored by default, so for that specific example it's not needed. But more generally, no.

If you want to ignore some extension .foo, you have two options: ignore all .foos everywhere in the repository, and set svn:ignore on every single directory that has a .foo you want to ignore. If you have a lot of such directories or they change somewhat frequently, but you don't want to ignore it globally for whatever reason, then it sucks to be you, which is why I say svn:ignore is awful.

tar

@EvanED said:

If you have a lot of such directories or they change somewhat frequently, but you don't want to ignore it globally for whatever reason, then it sucks to be you, which is why I say svn:ignore is awful.

I'd agree that it sounds like it would suck to be in that situation, but why do you have a constantly changing list of .foo files of which some but not all need to be version controlled?

Why not just make a foos_to_be_ignored/ folder and add that to svn:ignore at the toplevel?

EvanED

It's not a super common situation, but it's a very natural one that I think Subversion should deal with well (and that most other VCSs deal with well). What you're saying is basically the difference between something like category1/category2 vs category2/category1, and sometimes one of those makes more logical sense than the other.

I'll give you a situation it arises in our repository. We have tests set up as, for example, tests/test1/ where the test1/ subdirectory contains a bunch of files for test1. When a test runs, it dumps a bunch of stuff (scratch space, basically) into a tmp_run subdirectory of that, i.e. tests/test1/tmp_run/. Now, we could have it dump things into, say, tests/tmp_runs/test1/ instead, but this would be less convenient. For example, when a test fails, usually the best way to figure out what is going on is to go into the tmp_run/ directory and run things directly from there; when doing that, we can refer to things in tests/test1/ just with ../whatever. If we were in tests/tmp_runs/test1/ instead, it'd have to be ../../test1/whatever instead, which is both longer and includes the test name, which means that I can't reuse the same command from my Zsh history if I'm dealing with a different test later. Probably I'd wind up enhancing that test script to put a symlink into tests/tmp_run/test1/ pointing back at tests/test1/ to compensate for the fact that the directory structure isn't as good.

(The thing that structure would make more convenient is referring to files from another test, which is something... I'm not sure I've ever done. Maybe once in a blue moon.)

Or another example, this time the opposite, where I don't want to ignore something that's globally ignored. We don't have this problem any more, but I'll put it out there. (We now use a different extension, for other reasons.) The test inputs for the stuff I work on are compiled executables; i.e., we actually had something like tests/test1/test1.exe; this actually gets committed to the repository because many of our tests are extremely sensitive to compilation changes.¹ So what I wanted to do is to have something on tests/ that "unignores" .exe files so that when you add tests/test314/ you don't forget to svn add tests/test314/test314.exe because it wasn't listed by svn stat; but Subversion doesn't let you do that. (Git, for example, would; you would just make tests/.gitignore containing !*.exe, or something like that.)

¹ For example: usually, function prologues start with something that allocates space for local variables with something like sub esp, 16 on x86, which "allocates" 16 bytes for locals. In the special case where the function needs 4 bytes, we've seen some compilers use something like push ecx instead, because that has the side effect of subtracting 4 from the stack pointer but is a shorter instruction. This can change our test results, e.g. if the program then reads the memory just allocated without initializing it. Sometimes this sort of thing is exactly what we're trying to test, sometimes it's probably just a somewhat unfortunate consequence of reality, and sometimes we're just being defensive; but the end result is that we don't trust that the test articles will be rebuilt in a consistent manner and so commit them in built form. (These tests I'm talking about are also quite small -- the couple I just looked at are < 10K -- and don't change very often. Other components have tests where the test articles aren't stored in version control.)

tar

@EvanED said:

Now, we could have it dump things into, say, tests/tmp_runs/test1/ instead, but this would be less convenient. For example, when a test fails, usually the best way to figure out what is going on is to go into the tmp_run/ directory and run things directly from there; when doing that, we can refer to things in tests/test1/ just with ../whatever. If we were in tests/tmp_runs/test1/ instead, it'd have to be ../../test1/whatever instead, which is both longer and includes the test name, which means that I can't reuse the same command from my Zsh history if I'm dealing with a different test later. Probably I'd wind up enhancing that test script to put a symlink into tests/tmp_run/test1/ pointing back at tests/test1/ to compensate for the fact that the directory structure isn't as good.

Hmm... I can kind of see how that could be annoying, but I would probably have a make target (say make test1) which I'd be using to drive the tests, so that the binary file can be bin/debug/tests/test.out and it's writing output to out/debug/test1.txt, and I don't need to care about what the specifics are when I'm running the tests (as I presumably want the test command line to be easily repeatable, which make test1 is).

I've always set my projects up with a set of toplevel folders bin/, dep/, make/, lib/, src/ and obj/ (only make/ and src/ aren't ignored), and every build event is driven by make at the toplevel. Everything always runs from the toplevel, in fact. It does take a little bit of planning up front, but it seems to be a good way to structure your codebase when working with svn (and make actually).

I suppose it all boils down to convenience in one way or another—you have some convenience with your tests that you'd probably argue I don't have, but then again it seems like my approach makes svn:ignore more convenient for me...

EvanED

@tar said:

I would probably have a make target (say make test1) which I'd be using to drive the tests

Don't worry; we have a driver program that we normally use that runs the tests and optionally reports the results to a spiffy database thing we have set up. It's just that if a test fails and you want to muck about with the command line or run it in a debugger or open the resulting file, it's easier to just run the commands directly than to edit our analogue to Makefile. (E.g. when we were using make for that purpose, my usual m.o. was to run make -n and copy the command line it gives.) Our present system is also a little annoying to use in that there's a very large startup cost (maybe 20 seconds or something) as it reads the files that tell it what to do; I've been meaning to write a wrapper script around it that would let it basically eliminate this cost when running just one or two tests, but I haven't gotten around to it. So that also makes it more convenient sometimes to just run the test commands directly.

@tar said:

I suppose it all boils down to convenience in one way or another—you have some convenience with your tests that you'd probably argue I don't have, but then again it seems like my approach makes svn:ignore more convenient for me...

I think that's an accurate statement. I mean, there's nothing that svn:ignore won't do at a fundamental level, and we could probably make our setup work a little nicer with it, but it comes at a cost that, IMO, Subversion shouldn't make us pay.

JBert

Hang on, did you only test with svn:ignoreor did you include the new svn:global-ignores property?

I haven't toyed much with the latter, mainly due to the fact our backend is still on version 1.5 but it does sound more like what you want.

PJH

@EvanED said:

svn:ignore

The problem I have is that (for reasons) we have tarballs of (3rd party) source code in svn and we need to ignore anything and everything that comes out of that tarball (for my sanity at least, when doing stuff like svn st -u)

[<version>:root@centos os]# svn ls httpd
httpd.tar.bz2
make.companyname
Killed by signal 15.
[<version>:root@centos os]# ls httpd
ABOUT_APACHE  buildmark.o     configure     httpd.mak       libhttpd.dep  make.companyname      NOTICE            server
acinclude.m4  CHANGES         configure.in  httpd.spec      libhttpd.dsp  modules         NWGNUmakefile     srclib
Apache.dsw    config.layout   docs          httpd.tar.bz2   libhttpd.mak  modules.c       os                support
build         config.layout~  emacs-style   include         LICENSE       modules.lo      README            test
BuildAll.dsp  config.log      httpd         INSTALL         Makefile      modules.o       README.platforms  VERSIONING
BuildBin.dsp  config.nice     httpd.dep     InstallBin.dsp  Makefile.in   companyname.built     README-win32.txt
buildconf     config.status   httpd.dsp     LAYOUT          Makefile.win  companyname.expanded  ROADMAP
[<version>:root@centos os]# svn propget svn:ignore httpd 
.gdbinit
libhttpd.mak
libhttpd.dep
httpd.dep
httpd.mak
README-win32.txt
VERSIONING
ROADMAP
README.platforms
README
NWGNUmakefile
NOTICE
companyname.expanded
companyname.built
modules.c
Makefile.win
Makefile.in
Makefile
LICENSE
libhttpd.dsp
LAYOUT
InstallBin.dsp
INSTALL
httpd.spec
httpd.dsp
httpd
emacs-style
configure.in
configure
config.status
config.nice
config.log
config.layout
CHANGES
buildconf
BuildBin.dsp
BuildAll.dsp
apachenw.mcp.zip
Apache.dsw
acinclude.m4
ABOUT_APACHE
.deps
test
support
srclib
server
os
modules
include
docs
build
.libs

[<version>:root@centos os]#

So much so, and so frequently, that I ended up scripting this to ignore anything that was present but not in version control:

[root@thinkpad ~]# cat /var/jail/centos5_1/usr/local/bin/svn_ignore 
#!/bin/bash
TMPNAM=`mktemp`
WD=${1:-`pwd`}

if [ -f $WD ]; then
        WD=`dirname $WD`
fi

cd $WD

# Get the current ignores
svn propget svn:ignore . >$TMPNAM

# Add unknown files (but ignore subdirectories)
svn st . | grep "^?" | grep -v "/" | cut -c9- >> $TMPNAM

# Sort alphabetically
sort $TMPNAM -o $TMPNAM
# Remove blank lines
sed -e '/^$/d' $TMPNAM -i

# Reapply
svn propset svn:ignore . -F $TMPNAM

# Output
svn diff . | sed 's/ *\([+-]\)/\1/' | colorize

dkf

@EvanED said:

It bothers me, because from what I can tell your commit D is often unreviewable and ununderstandable.

I'm not convinced that that's true. In fossil, doing a merge doesn't auto-commit the result. You get a changeset (and some metadata recording what happened) but at that point you can review what is proposed, fix anything you want, and only commit (or fossil undo) once you're satisfied.

@EvanED said:

git add --patch and git commit --patch

Those sound interesting.

@EvanED said:

(To preempt another comment: I don't think "just try to fall into #1" is a good answer. I find that a lot of the time I don't realize that what I've done is really two separate logical changes until I've done a lot of both changes. I mean, sure, it's nice when you can do it, but I'd rather have a VCS where I almost don't have to worry about the problem at all because it's barely a problem.)

The silly thing is I've yet to have desperately needed it.

Fossil's model of having a single local repository that you can check out in multiple places at once is quite neat though; if things are getting confusing, I can just open up a second view on the commit (in a parallel directory structure, of course) and sort things out that way.

But maybe being able to selectively commit at the sub-file level would be neat anyway.

EvanED

@JBert said:

Hang on, did you only test with svn:ignoreor did you include the new svn:global-ignores property?

I didn't actually test; I was looking for documentation. Looking again at your link, it sounds like it might be what I want. I initially interpreted it as some repository property that would apply globally; that's probably mistaken. (What confused me was it's the same name as the global-ignores setting in the Svn configuration file.) So that would be good.

(Though I think there's no way to negate a rule at this point still, so hopefully someday they'll get around to adding that.)

EvanED

@dkf said:

I'm not convinced that that's true. In fossil, doing a merge doesn't auto-commit the result. You get a changeset (and some metadata recording what happened) but at that point you can review what is proposed, fix anything you want, and only commit (or fossil undo) once you're satisfied.

....none of which addresses my objection. (In fact, I don't see how "it doesn't commit automatically" is relevant to what I said at all.) If you've been working on a branch for a while and made a ton of changes, your merge commit, automatically committed or not, is going to be too large to do anything with.

dkf

@EvanED said:

....none of which addresses my objection. (In fact, I don't see how "it doesn't commit automatically" is relevant to what I said at all.) If you've been working on a branch for a while and made a ton of changes, your merge commit, automatically committed or not, is going to be too large to do anything with.

This is stupid. I'm sober and well-caffeineated, but I'm still totally failing to understand what you're objecting to. Let's try with pictures (see below). The thing I don't like is having lies told about the order of activities, when commits were made, etc. Rebasing is either lying or violates causality; both offend me in various ways. OTOH, you probably don't like the pattern of cross merges that you get in the non-rebased workflow.

Starting situation

Please excuse the shitty graphics. There's not a great selection of arrows that integrate well with the box drawing elements.

───a┬──b───c───d                ←← trunk
    │
    └──A───B───C                ←← branch

The number of commits on the two branches is only the same for the sake of argument. That's not significant.

After Merge

───a┬──b───c───d───┐
    │              │
    └──A───B───C───D

The tip of the trunk is still d, and the tip of the branch is now D which has the combined versions of b, c and d all rolled into one. This can be then reverse-merged like this:

───a┬──b───c───d───┬──e
    │              │  │
    └──A───B───C───D──┘

The change e consists of the changes A, B and C (plus whatever is required from D) but that consists in itself of a single feature: the change which you opened the branch for.

After Rebasing

───a┬──b───c───d──┐
    │             │
    └─(A)─(B)─(C) └─A′──B′──C′

(The letters in parentheses are typically hidden from view — they are eligible for removal on systems that support that — and have a primed analog on the reconstructed branch.) This can then be merged (in a different sense to the preceding section) to get:

───a┬──b───c───d───A′──B′──C′
    │
    └─(A)─(B)─(C)

This is only this nice if the rebase had no conflicts. When there's a conflict, things get quite a bit messier. Also, rebasing doesn't work well with public branches because you don't know what other branches exist off the original branch.

riking

@blakeyrat said:

Why isn't this all implementation-detail masked by the UI?

Oh, right, because the UI is the implementation.

There's the secret of Git. The UI is the internal structure. The internal structure is the UI.

blakeyrat

Right; like Lunix where they don't see the need for a "rename" command because renaming a file is just "moving" it to the same location with a new name.

Which is a great way of making shitty software everybody hates.

Buddy

I think the idea is that when you're stepping backward through history from e or later, you're going to hit D, find that to be the source of the error you're debugging, and it's going to be a real puzzler, because both parents of D were working fine. Whereas, in a rebasing work-flow, I presume that A', B' and C' would each be individually reworked to take lowercase-branch changes into account. If that assumption holds, I figure the non-trivial amount of work that goes into a rebase merge does lend a fair bit of legitimacy to its claim to a post-abc position in the tree.

Onyx

@blakeyrat said:

Right; like Lunix where they don't see the need for a "rename" command because renaming a file is just "moving" it to the same location with a new name.

I think that particular idiocy was due to "keeping the command names short" craze. rm was already taken for remove, rn might look a bit too similar, I guess?

In any case, my system does have a rename command. No idea if it came stock or got installed along with something, but it's here now. But the fact that I even have to question it's origin is a , we agree there.

dkf

@Buddy said:

I think the idea is that when you're stepping backward through history from e or later, you're going to hit D

Not normally, no. The change from d to e is the summary of the changes due to the branch; you'd normally only dig into the branch if it was actually where the problem arose.

Buddy

Going, again, only on my interpretation of what I think I read, I believe the argument is that D is somewhat of a hot-spot for errors, particularly inadvertent errors.

dkf

@Buddy said:

the argument is that D is somewhat of a hot-spot for errors, particularly inadvertent errors.

As opposed to spreading the problems through A', B' and C'? Squashing the commits prior to the rebase would help I suppose, but that's an even grosser distortion of history, and you'd still have actually the same mess to clean up at some point. Let's face it, if there are colliding changes, you're going to have to sort it out eventually.

Still not as bad as when you've got non-colliding changes that are still incompatible with each other.

SirTwist

@tar said:

not one of the Linux Subversion GUIs supports changelists

That's because the only third-party client that's kept up-to-date is TortoiseSVN on Windows. I think AnkhSVN (also on Windows and VS) is the next closest.
@Onyx said:

keeping the command names short

Then why the fuck is it "mkdir" instead of "md"?

There's no GUI for fossil yet that I'm aware of. TortoiseFossil is a work-in-progress.

dkf

@SirTwist said:

There's no GUI for fossil yet that I'm aware of.

That depends what you mean. There's a (web-based) GUI for the repository, but not for managing a particular checkout.

JBert

@SirTwist said:

That's because the only third-party client that's kept up-to-date is TortoiseSVN on Windows.

It's the only one I know of which supports "Repair Move" or "Repair Copy", and it has some support for partial committing since a few versions ago. Heartily recommended.

The only real trouble is that it implements partial committing backwards: you have to go to the commit screen, right click on files to pick "Restore after commit" and then edit out all changes you don't want to be part of the commit. If you didn't mark a file as to-be-restored, you just lost your changes...

PleegWat

@Onyx said:

In any case, my system does have a rename command. No idea if it came stock or got installed along with something, but it's here now.

There's two rename commands that I have seen, both intended for bulk rename. They are not compatible.

On redhat, you get rename _from_ _to_ _files..._. It replaces the literal from string with the literal to string.
On ubuntu, you get rename _pattern_ _files_., with pattern a perl expression, commonly s/from/to/.

Onyx

man (and the fact this is on Mint) suggests the latter.

EvanED

@dkf said:

───a┬──b───c───d───┐
│ │
└──A───B───C───D

[ed: yay discourse]

The tip of the trunk is still d, and the tip of the branch is now D which has the combined versions of b, c and d all rolled into one.

Yes...

Let me try to restate my point. You're assuming that the unmerged work on the branch is small. This isn't necessarily true, if you have a "feature" that requires a lot of invasive changes (e.g. refactoring a commonly-used class) or your branch is a long-lived branch instead of just something for just a single feature.

So imagine you're in a situation where D's diffstat is +10000~~-9000~~. There's no way any one is going to be able to understand D just by looking at it. And you have questions like the ones I said before: was it entirely automatically merged? Did the programmer have to resolve textual conflicts? Semantic conflicts? Did they have other stray changes that just happened to be committed? The only way to resolve these questions is to re-do the automatic part of the merge yourself, and diff the directories. At the point of commit things aren't very different because the rebase version would have, I dunno, 50 commits of 200 lines apiece, but for someone looking at things way down the road who is interested in only one specific change, the rebased version is much more specific.

That's just kind of obnoxious; but things get really bad on occasion. Suppose there is a semantic conflict between A and b that you don't notice for a while after the merge. So you say "when was this bug introduced" and do a bisect. The bisect tells you that d is good, that C is good, and that D is bad. So the thing that broke it is somewhere in a +10000~~-9000~~ commit. This is pretty much the worst thing in the world¹; this has happened to me a couple of times, and at that point I have no idea how to get useful information out of Git and gave to resort to "traditional" debugging instead of being able to say "how did this particular change affect this outcome?" By contrast, with a rebased branch, bisecting would lead you straight to the rebased version of A. Now you're looking at a small commit that you can hopefully easily understand.

¹ Disclaimer: it is not the worst thing in the world.

boomzilla

@blakeyrat said:

So I typo "rm -rf *", how do I undo it? Enlighten me.

So I select files, Shift+Del, how do I undo it? Enlighten me.

ben_lubar

@Onyx said:

In any case, my system does have a rename command.

That's a cool one. You can do stuff like

rename 's/pancakes/PANCAKES/ig' *.txt

and it'll rename every text file to have the word PANCAKES in all caps.

blakeyrat

@boomzilla said:

So I select files, Shift+Del, how do I undo it? Enlighten me.

Don't go out of your way to hold the Shift key and you'll never have this problem.

tar

@ben_lubar said:

That's a cool one. You can do stuff like
rename 's/pancakes/PANCAKES/ig' *.txt
and it'll rename every text file to have the word PANCAKES in all caps.

Hang on. It won't rename every text file to have 'PANCAKES' in it, just the ones which originally had 'pancakes' in their filename (one would hope...)

boomzilla

@blakeyrat said:

Don't go out of your way to hold the Shift key and you'll never have this problem.

Why are you avoiding the question?

blakeyrat

@boomzilla said:

Why are you avoiding the question?

Because it wasn't intended to be answered literally, you're just being a dick.

If you really want a reply, the answer is: "because GUIs aren't perfect, either. If I designed one, you can trust there wouldn't be a way to delete a file that couldn't be undone (within a short period of time). But I didn't design Windows, so it has a destructive file delete shortcut which is dangerous and useless for the average user."

There, happy?

boomzilla

@blakeyrat said:

Because it wasn't intended to be answered literally, you're just being a dick.

Because you were just being a dick first. It's a problem of mine, I admit.

@blakeyrat said:

There, happy?

I was happy, before. Your actions don't really change that one way or the other. Of course, it was too much to hope that you could apply the wisdom shown in your response to your previous question, but that won't surprise anyone here, either.

blakeyrat

@boomzilla said:

Of course, it was too much to hope that you could apply the wisdom shown in your response to your previous question, but that won't surprise anyone here, either.

What wisdom?

I didn't write Windows. How does pointing out that Windows doesn't do what I think it should constitute "wisdom"? What the holy fuck are you talking about?

Bort

@Eldelshell said:

emojis... taste.

These words don't belong in the same ~~sentence~~ ~~paragraph~~ post.

boomzilla

@blakeyrat said:

What wisdom?

LOL. It's fun when you make my points for me.

blakeyrat

If you're not interested in talking to me, stop hitting "reply" and typing shit.

boomzilla

@blakeyrat said:

If you're not interested in talking to me, stop hitting "reply" and typing shit.

I said some things to you. If you want to not read and think about the words, I can't make you.

PleegWat

@ben_lubar said:

That's a cool one. You can do stuff like
rename 's/pancakes/PANCAKES/ig' *.txt
and it'll rename every text file to have the word PANCAKES in all caps.

Only if you're on a debian derivative (?). If you're on redhat, you need

rename -i 'pancakes' 'PANCAKES' *.txt

Not sure on flags offhand.

kilroo

@blakeyrat said:

@dkf said:
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.

There was a time when it actually seemed possible that Bazaar would reach a point where with the right plugins, you could use Bazaar whether the official repo was in Bazaar, Mercurial, Subversion, Git, or a few other candidates, and barely even have to remember that was what you were doing.

Alas, that didn't happen, I think mostly because Bazaar didn't ever have enough traction for the foreign branch plugins to remain a worthwhile expenditure of time for their maintainers.

dkf

@kilroo said:

Alas, that didn't happen, I think mostly because Bazaar didn't ever have enough traction for the foreign branch plugins to remain a worthwhile expenditure of time for their maintainers.

I've tried a very little to use Bazaar (mostly because I was doing stuff with launchpad at the time) and it was a bit strange to use. It particularly didn't like the idea that there might be several long-term support branches open at once, though that might've been just the launchpad UI.

Since I'm basically not interested in developing a VCS, I just found systems that did what I wanted, settling on a mixture of fossil and git (depending on project). I find git rather more difficult to use without a GUI to help.