Re: Python script for automatic synchronization based on inotify
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
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
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
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
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
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
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
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
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
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
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
