Re: Python script for automatic synchronization based on inotify

2011-03-23 Thread martin f krafft
also sprach Dieter Plaetinck die...@plaetinck.be [2011.03.20.1235 +0100]:
 oh, one more thing.
 you can query the current branch in a pure-python way, by reading .git/HEAD

No, please do not use this. Use

  git symbolic-ref -q HEAD || git name-rev --name-only HEAD

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
sex an und für sich ist reine selbstbefriedigung.
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
___
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-23 Thread René Mayrhofer
Am Mittwoch, 23. März 2011, um 09:33:37 schrieb Dieter Plaetinck:
 On Wed, 23 Mar 2011 08:00:27 +0100
 martin f krafft madd...@madduck.net wrote:
 
  also sprach Dieter Plaetinck die...@plaetinck.be [2011.03.20.1235
  +0100]:
   oh, one more thing.
   you can query the current branch in a pure-python way, by
   reading .git/HEAD
  
  No, please do not use this. Use
  
git symbolic-ref -q HEAD || git name-rev --name-only HEAD
  
 
 well, the idea behind doing it in pure-python is removing the overhead
 of spawning extra processes, do you have an argument why reading the
 branchname of the current HEAD in a few lines of python is bad?

I agree with Martin that parsing git internals does not seem the right way to 
do it - they might change at some point. Additionally, I'd like to keep 
dvcs-autosync as agnostic to the used DVCS as possible (otherwise it will 
quickly become a git-autosync). At the moment, the DVCS can be swapped out by 
changing only the config file options. If I can keep that without sacrificing 
too much performance, I'd like to do so.

best regards,
Rene


signature.asc
Description: This is a digitally signed message part.
___
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-23 Thread martin f krafft
also sprach Dieter Plaetinck die...@plaetinck.be [2011.03.23.0933 +0100]:
 well, the idea behind doing it in pure-python is removing the
 overhead of spawning extra processes, do you have an argument why
 reading the branchname of the current HEAD in a few lines of
 python is bad?

.git/* is not a public API. It's considered internal.

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
america may be unique in being a country which has leapt
 from barbarism to decadence without touching civilization.
-- john o'hara
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
___
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-23 Thread Felix Kaiser
On Wed, Mar 23, 2011 at 11:50 AM, martin f krafft madd...@madduck.net wrote:

 also sprach Dieter Plaetinck die...@plaetinck.be [2011.03.23.0933 +0100]:
  well, the idea behind doing it in pure-python is removing the
  overhead of spawning extra processes, do you have an argument why
  reading the branchname of the current HEAD in a few lines of
  python is bad?

 .git/* is not a public API. It's considered internal.


Not its not.

Its even documented[1]: ... a valid git repository must have the HEAD
file; some porcelains may use it to guess the designated default
branch of the repository (usually master).

(dvcs-autosync is such a porcelain)

Greetings
Felix

[1] http://www.kernel.org/pub/software/scm/git/docs/gitrepository-layout.html
___
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-23 Thread martin f krafft
also sprach Felix Kaiser felix.kai...@fxkr.net [2011.03.23.1250 +0100]:
  .git/* is not a public API. It's considered internal.
 
 
 Not its not.
 
 Its even documented[1]: ... a valid git repository must have the
 HEAD file; some porcelains may use it to guess the designated
 default branch of the repository (usually master).

Ha. This is news to me. Interesting, thanks.

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
next the statesmen will invent cheap lies, putting the blame upon the
 nation that is attacked, and every man will be glad of those
 conscience-soothing falsities, and will diligently study them, and
 refuse to examine any refutations of them; and thus he will by and by
 convince himself that the war is just, and will thank god for the
 better sleep he enjoys after this process of grotesque
 self-deception.
 -- mark twain
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
___
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-20 Thread Dieter Plaetinck
On Sun, 20 Mar 2011 08:31:39 +0100
René Mayrhofer r...@mayrhofer.eu.org wrote:

 Am Freitag, 18. März 2011, 22:59:07 schrieb Dieter Plaetinck:
  Note if you do this, server:test.git won't actually have a master branch 
  yet.
  So when i touch ~/autosync/test, I get this:
  
  No refs in common and none specified; doing nothing.
  Perhaps you should specify a branch such as 'master'.
  fatal: The remote end hung up unexpectedly
  error: failed to push some refs to 'server:autosync.git'
  
  workaround is typing `git push origin master` once. after that it works 
  fine.
 
 You're right. I've never actually tried it on a completely empty repository. 
 We should either document this in README (the setup process) or make the 
 script realize when there is no master branch and do a git push origin 
 master in this case. I will need to dig into the git remote command a bit 
 more to see what the best option is here (I don't like parsing the output if 
 I can avoid it).
 
 best regards,
 Rene

I also thought of some options.
What about always explicitly pushing the current branch? unfortunately there is 
nothing like `git push origin --currentbranch`, so we would need to do ask git 
what is the current branch, and then `git push origin $branchname`, but that 
involves an extra process; we could try to cache the result but that gets ugly 
quickly (you need to know when to invalidate the cache, i.e. when the user 
creates a new branch).  on the other hand, something like this would 
transparently allow the user to work with multiple branches; as far as i see 
there is currently no notion of the branch in autosync.py (i.e. master is 
always assumed), if we always do `git push master` we can fix the problem at 
hand (but then the user is restricted to the master branch, if he creates a new 
branch and we do a push of master, his new branch won't be pushed), if we do 
`git push $currentbranch` and also have a notion of the involved branch in the 
jabber messages, then the user could transparently use multiple branches.
Either way I don't think we should query the remote for what do you have, 
frankly we shouldn't care.  we only care about pushing (explicitly enough) the 
thing that we need to push.

If you only want to support a master branch, hardcoding `git push origin 
master` is a good choice, but I don't like restricting ourselves like that. We 
can also say in the readme every time you create a new branch, push it 
manually once, from then on, we can just `git push origin` and it will do the 
right thing.  it involves a tiny bit of manual work, but maybe this is the most 
sensible.

Dieter
___
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-19 Thread René Mayrhofer
Am Dienstag, 15. März 2011, 10:05:17 schrieb Dieter Plaetinck:
 On Mon, 14 Mar 2011 15:53:44 -0500
 Chanoch (Ken) Bloom kbl...@gmail.com wrote:
 
  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
  
 
 +1 on that.

Done and pushed --force to gitorious. Whoever cloned the repo, please discard 
the local history and clone afresh. This was painful and took me about 4h to go 
through. I therefore hope it was worth it and that I will receive many patches 
;-)

 Also be aware that the suggestion of somebody else rewriting the
 entire history and contributing that is quite awkward: which author
 should those new commits have? you (Rene) did all the work originally so
 it should probably stay you, OTOH the contributor would be responsible
 for the changes to the commits he did (especially when he messed
 something up during the cleaning process), and currently git supports
 only 1 author per commit.

Now that I am more familiar with rebase --interactive, I agree.

best regards,
Rene


signature.asc
Description: This is a digitally signed message part.
___
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-19 Thread René Mayrhofer
Am Samstag, 19. März 2011, 20:33:08 schrieb Dieter Plaetinck:
 that person was me.  as you can see, i already have a bunch of patches queued 
 up in a pull request on gitorious.
 i'll treat it as a git exercise for myself to port my patches to the new 
 history branch.

I already saw the patches and highly appreciate the documentation improvements! 
This was one of my first priorities (besides packaging) at this point.
 
 btw, are you on irc or jabber? I have some more ideas for contributions but 
 email is soo slow to discuss them.

Will send you my Jabber ID via private email to avoid it being crawled too 
easily.

best regards,
Rene


signature.asc
Description: This is a digitally signed message part.
___
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-15 Thread Dieter Plaetinck
On Mon, 14 Mar 2011 15:53:44 -0500
Chanoch (Ken) Bloom kbl...@gmail.com wrote:

 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
 

+1 on that.
Also be aware that the suggestion of somebody else rewriting the
entire history and contributing that is quite awkward: which author
should those new commits have? you (Rene) did all the work originally so
it should probably stay you, OTOH the contributor would be responsible
for the changes to the commits he did (especially when he messed
something up during the cleaning process), and currently git supports
only 1 author per commit.

for more info on rewriting history:
* how: any tutorial on git rebase --interactive, i.e. 
http://progit.org/book/ch6-4.html
* why: 
http://dieter.plaetinck.be/why-rewriting-git-history-and-why-commits-imperative-present-tense.html
(shameless self-plug)

Dieter
___
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 Dieter Plaetinck
On Mon, 14 Mar 2011 17:02:01 +0100
René Mayrhofer r...@mayrhofer.eu.org wrote:

 Btw, the project is now online at http://gitorious.org/dvcs-autosync
 and should even include the full history (already close to a year,
 although with very irregular commit intervals ;-) ).

ugh.
why are many code changes committed as autocommit? why do you
commit .pyc files? why do you use meaningless commit messages like
move another file ?
This looks very messy.

Dieter
___
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 Rene Mayrhofer

On 14.03.2011 17:15, Dieter Plaetinck wrote:

ugh.
why are many code changes committed as autocommit? why do you
commit .pyc files? why do you use meaningless commit messages like
move another file ?
Well, it is the full history so far, and that includes the autocommits 
made by the script itself whenever I worked on it while it was running. 
For source code, this is obviously not optimal. The pyc was also 
auto-committed and should probably be removed from the history (which 
might get rid of some of the commits altogether).



This looks very messy.
You're welcome to have a go at cleaning up the history, I will happily 
force-push into gitorious with a cleaned up history.


best regards,
Rene
___
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