Re: Please add (upstream) changelog to vcsh

2012-02-18 Thread Chanoch (Ken) Bloom
On Sat, 2012-02-18 at 14:20 +0100, Richard Hartmann wrote:
 On Sat, Feb 18, 2012 at 11:53, Thomas Koch tho...@koch.ro wrote:
  Just entered Debian Testing: git2cl
 
 I tried that on sid, but I really don't like the output. It's a
 firehose, not a changelog.

Yes, in general one wants to create git commit messages from new
changelog entries, so that when you make a notable change, your users
can see it and your developers can see it, but you generally don't want
fix typo commit messages in your changelog, and you generally want to
collapse multi-commit changes into a single changelog entry.

But for historical work, I guess it helps as a start.
___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home


Re: Python script for automatic synchronization based on inotify

2011-03-14 Thread Chanoch (Ken) Bloom
On Mon, Mar 14, 2011 at 08:53:03PM +0100, Rene Mayrhofer wrote:
 On 14.03.2011 17:15, Dieter Plaetinck wrote:
 why are many code changes committed as autocommit? why do you
 commit .pyc files?
 .pyc removed from history with --force push to gitorious done.
 However, my git-fu is not yet good enough to properly change the
 past commit messages and merge them for a cleaner history. If you'd
 like to have a go at, I would welcome a clean history and could
 (probably as the owner of the project) do another force push to get
 it on gitorious.

I just took a look at your repository, and here's how to fix it.

First, run `git filter-branch` with the `--prune-empty` option to get
rid of the empty commits that used to contain only changes to the .pyc
file.

Second, rewriting the history to be sane should be a simple (though
potentially time consuming) application of `git rebase --interactive`.
Look over the tree using gitk to see which commits can be grouped into
logically related sets of changes, then find the number of the first
commit on the repository (or the first commit where the history starts
to get really hairy) and start rebasing from there. Make liberal use
of the `squash` operation to merge commits that should be related but
were broken up by the way autocommit works. Write a useful commit
message for each of the new commits you're creating.

When you're done, look over the tree again with gitk. You can run `git
rebase --interactive` again (on the rebased tree) if you spot errors.

--Ken

-- 
Chanoch (Ken) Bloom. PhD candidate. Linguistic Cognition Laboratory.
Department of Computer Science. Illinois Institute of Technology.
http://www.iit.edu/~kbloom1/
___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home


Backing up Evolution files in Git

2011-03-09 Thread Chanoch (Ken) Bloom
I have keeping my .evolution directory (among others) in Git, but the
recent upgrade in Debian unstable from evolution 2.30 to 2.32 migrated
evolution's configuration data from .evolution and split it into two
directories: .config/evolution and .local/share/evolution

It appears that calendar and addressbook data live in
.local/share/evolution, so it looks like I'm going to have to migrate
that into git.

Before I do so, does anyone know of better ways to keep evolution
backed up in git? (I'm interested in backing up the non-email stuff.)

--Ken

-- 
Chanoch (Ken) Bloom. PhD candidate. Linguistic Cognition Laboratory.
Department of Computer Science. Illinois Institute of Technology.
http://www.iit.edu/~kbloom1/
___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home


Re: Version control system better suted than SVN

2009-04-19 Thread Chanoch (Ken) Bloom
On Sun, Apr 19, 2009 at 02:55:28PM -0700, Eric Hanchrow wrote:
 On Sun, Apr 19, 2009 at 1:03 PM, Chanoch (Ken) Bloom kbl...@gmail.com wrote:
   * Git keeps a local repository with full history in your working
 directory. This means at least two copies of everything are
 stored.
 
 Git's compression is good enough that I'd be surprised if this were a
 problem in practice.
 
 On the other hand, git too uses SSH for write access, so I suspect
 it'll get hung up there.

It appears that git supports WebDAV for pushing over HTTP(S) as well.

See 
http://www.xiaoka.com/blog/2008/04/13/git-repository-over-http-webdav-with-nginx/
 
which talks about how to configure a certain web server for WebDAV and
Git. I didn't see anything suggesting out of the ordinary patching or
configuration was necessary on the client side of things.

--Ken

-- 
Chanoch (Ken) Bloom. PhD candidate. Linguistic Cognition Laboratory.
Department of Computer Science. Illinois Institute of Technology.
http://www.iit.edu/~kbloom1/


signature.asc
Description: Digital signature
___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home