Re: [StGit PATCH] contrib/vim: Fix filetype detection in VIM >=7.4

On 15 July 2016 at 19:58, Zane Bitter wrote: > The command "setfiletype" will not override an existing filetype. This was > never a problem for me previously, but since upgrading from VIM 7.3 to 7.4 > the filetype for StGit's files is explicitly set to "text", preventing the >

Re: [PATCH] Catch more exceptions in compat_log_entry()

On 22 October 2013 15:31, Pavel Roskin pro...@gnu.org wrote: Catch exceptions in default_repo(). Catch git.RepositoryException. This suppresses stack trace in stg pull on detached head and outside the repository. Signed-off-by: Pavel Roskin pro...@gnu.org Thanks. Applied. Catalin -- To

Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE

On Tue, Oct 23, 2012 at 10:22:45PM +0100, Jeff King wrote: On Tue, Oct 23, 2012 at 10:09:46PM +0100, Catalin Marinas wrote: It is spelled: git notes add -m comment SHA1 The resulting notes are stored in a separate revision-controlled branch and can be pushed and pulled like

Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE

On 23 October 2012 21:51, Jeff King p...@peff.net wrote: On Tue, Oct 23, 2012 at 10:47:28PM +0200, Thomas Gleixner wrote: I agree that this is a common issue. Acked-by/Reviewed-by mails come in after the fact that the patch has been committed to an immutable (i.e no-rebase mode) branch or if

Re: [PATCH] Show modified files in git-ls-files

Brian Gerst [EMAIL PROTECTED] wrote: Add -m/--modified to show files that have been modified wrt. the index. M was already taken so the tag for modifified files is C (changed). I think git-ls-files should be consistent with git-diff-cache where M means modified and U unmerged (but for the

Re: [PATCH 0/2] Reorganize read-tree

Daniel Barkalow [EMAIL PROTECTED] wrote: I got mostly done with this before Linus mentioned the possibility of having multiple index entries in the same stage for a single path. I finished it anyway, but I'm not sure that we won't want to know which of the common ancestors contributed which,

Re: [RFC] Stgit - patch history / add extra parents

Daniel Barkalow [EMAIL PROTECTED] wrote: One factor not mentioned there is that, as things move upstream, we often want to discard a lot of history; if someone commits constantly to deal with editor malfunction or something, we don't really want to take all of this junk into the project

[ANNOUNCE] Stacked GIT 0.6

Stacked GIT 0.6 release is available from http://www.procode.org/stgit/ StGIT is a Python application providing similar functionality to Quilt (i.e. pushing/popping patches to/from a stack) on top of GIT. These operations are performed using GIT commands and the patches are stored as GIT commit

Re: [RFC] Stgit - patch history / add extra parents

On Fri, 2005-08-19 at 21:48 +0200, Jan Veldeman wrote: I've quickly reread the threads about stg commit. Am I right to assume that _all_ history was being recorded? Because this is not what I want. The person controlling the archive should specify when to record the history. True, I was

Re: Merge conflicts as .rej .orig files

Martin Langhoff [EMAIL PROTECTED] wrote: After using arch for a while, I've gotten used to getting .rej and .orig files instead of big ugly conflict markers inside the file. Emacs has a nice 'diff' mode that is a boon when dealing with conflicts this way. Is there a way to convince

Re: [RFC] Patches exchange is bad?

Johannes Schindelin [EMAIL PROTECTED] wrote: maybe it is time for a quick run through the typical jobs you do with StGIT, much like what Jeff sent the other day? I hope I will find some time this weekend and write some tutorials on an StGIT wiki. -- Catalin - To unsubscribe from this list:

Re: [RFC] Patches exchange is bad?

Marco Costalba [EMAIL PROTECTED] wrote: Catalin Marinas wrote: That's how you would normally do development on Linux using StGIT - clone the mainline kernel, create patches in your StGIT tree and submit them either via e-mail or ask the gatekeeper to pull directly from your tree (assuming

Re: [RFC] Patches exchange is bad?

Marco Costalba [EMAIL PROTECTED] wrote: Suppose a possible scenario involves using a couple of git archives, one for releases and stable code, say MAIN, and one for experimental stuff or new development, say HEAD. Suppose there is stuff in HEAD you don't want merged in MAIN, more, you

Re: [RFC] Patches exchange is bad?

On Wed, 2005-08-17 at 10:35 -0700, Marco Costalba wrote: Sorry if the answer is silly, but I still don't know well StGIT . It's probably because there is no document really explaining the concepts. The Quilt documentation would be a good starting point since StGIT uses the same ideas but

Re: sending changesets from the middle of a git tree

Junio C Hamano [EMAIL PROTECTED] wrote: Petr Baudis [EMAIL PROTECTED] writes: Dear diary, on Sun, Aug 14, 2005 at 09:57:13AM CEST, I got a letter where Junio C Hamano [EMAIL PROTECTED] told me that... Linus Torvalds [EMAIL PROTECTED] writes: Junio, maybe you want to talk about how you

[PATCH] Make curl fail on server error

Some http servers return an HTML error page and git reads it as normal data. Adding -f option makes curl fail silently. Signed-off-by: Catalin Marinas [EMAIL PROTECTED] --- git-clone-dumb-http |2 +- git-fetch-script |2 +- git-ls-remote-script |2 +- 3 files changed, 3

Re: use of temporary refs in resolve

Junio C Hamano [EMAIL PROTECTED] wrote: Catalin Marinas [EMAIL PROTECTED] writes: Is FETCH_HEAD going to be preserved by the git-fetch-script operation? It should be, unless, git-pull-script removes it or it is changed to do the fetch as well. I am not quite sure what is being asked

Re: Email patch - git commit?

H. Peter Anvin [EMAIL PROTECTED] wrote: Anyone have any good scripts for taking patches in email and turning them into git commits, preferrably while preserving the author information? StGIT can do this as well, via the 'stg import -m' command. You will see it as a GIT commit (with 'git log')

Re: [PATCH 1/1] Tell vim the textwidth is 75.

Petr Baudis [EMAIL PROTECTED] wrote: Dear diary, on Fri, Jul 29, 2005 at 11:55:52AM CEST, I got a letter where Catalin Marinas [EMAIL PROTECTED] told me that... The latest StGIT snapshot uses, by default, the committer's details for the From: line when sending patches by e-mail, assuming

Re: [PATCH] stgit: Handle 'A' flag for new files

Peter Osterlund [EMAIL PROTECTED] wrote: Patches that add new files don't work correctly if git reports them with the 'A' flag. StGIT claims there are unresolved conflicts. This patch fixes it. Thanks. Applied (together with the one below). diff --git a/stgit/git.py b/stgit/git.py ---

Re: Stacked GIT 0.4

On Tue, 2005-07-12 at 07:05 -0400, Bryan Larsen wrote: Here's my wishlist. Hopefully I'll be able to dig in and help out. import: the complement to export A first implementation of 'import' is available in the tonight's snapshot (and in the StGIT git repository mirror). template files for

Re: [RFC] extending git-ls-files --exclude.

Junio C Hamano [EMAIL PROTECTED] wrote: * When --exclude-per-directory=name is specified, upon entering a directory that has such a file, its contents are appended at the end of the current list of patterns. They are popped off when leaving the directory. [...] A pattern specified

Re: [RFC] extending git-ls-files --exclude.

On Mon, 2005-07-25 at 13:27 -0700, Junio C Hamano wrote: Linus Torvalds [EMAIL PROTECTED] writes: Imagine, for example, that you have separate subdirectory structures for Documentation and for source - maybe you'd put the *.o rule in the source directory, and a *.1 rule in the Docs

Re: [RFC] extending git-ls-files --exclude.

On Mon, 2005-07-25 at 12:58 -0700, Junio C Hamano wrote: Catalin Marinas [EMAIL PROTECTED] writes: An exclude pattern is of the following format: [...] That's fine. Actually, the Porcelain would care much about it since it gets the information already filtered by git. Your saying

Re: [PATCH 1/1] Tell vim the textwidth is 75.

On Fri, 2005-07-22 at 16:07 -0700, Junio C Hamano wrote: Catalin Marinas [EMAIL PROTECTED] writes: If signed-off-by is the only thing you are worried about, how about making it not part of the commit template and the message user touches with the editor? You first look at the user

Re: [PATCH 1/1] Tell vim the textwidth is 75.

On Sat, 2005-07-23 at 11:30 +0200, Petr Baudis wrote: Dear diary, on Sat, Jul 23, 2005 at 10:41:38AM CEST, I got a letter where Catalin Marinas [EMAIL PROTECTED] told me that... The problem appears when one upstream maintainer changes the configuration, should this be merged again

Re: [PATCH 1/1] Tell vim the textwidth is 75.

On Fri, 2005-07-22 at 16:24 -0700, Junio C Hamano wrote: Petr Baudis [EMAIL PROTECTED] writes: This brings me to another subject, M and N are pretty hard to distinguish visually without close inspection of the output. What about switching to use A instead of N everywhere? However, I'd

Re: [PATCH 1/1] Tell vim the textwidth is 75.

On Sat, 2005-07-23 at 12:33 -0400, Bryan Larsen wrote: how about: .git/refs/heads/master - documented in README, doesn't appear to be used. That's true, README is quite outdated. I created the http://wiki.procode.org/cgi-bin/wiki.cgi/StGIT page (empty now) where I will add StGIT information

Re: [PATCH 1/1] Tell vim the textwidth is 75.

On Fri, 2005-07-22 at 19:24 +, Sam Ravnborg wrote: I would use a neutral commit template, only that it should have a neutral prefix as well for the lines to be removed (neither STG nor CG but GIT maybe). The $GIT_DIR/commit-template is fine as a file name. How about

Re: [PATCH 1/1] Tell vim the textwidth is 75.

On Fri, 2005-07-22 at 13:39 -0700, Junio C Hamano wrote: I would like to see Porcelains stay compatible when the do not have to differ. The commit template [*2*] is one example of such. For StGIT it is not a problem to use any commit template with any prefix. It doesn't generate extra

Re: Barebone Porcelain. Where to stop?

Bryan Larsen [EMAIL PROTECTED] wrote: Any lack of porcelain momentum is probably due to git having better documentation than the current porcelains, such as cogito and stacked git. The documentation, like tutorial.txt and Jeff Garzik's git kernel howto give the impression that most kernel

Re: [PATCH] stgit: allow spaces in filenames

On Wed, 2005-07-13 at 15:26 -0700, Junio C Hamano wrote: Catalin Marinas [EMAIL PROTECTED] writes: I'd very much like to stay on the same list. By the same logic, cogito should have it's own list as well... I'd like this too and it's probably OK with a low traffic (we'll see if we

Re: Is cogito really this inefficient

Russell King [EMAIL PROTECTED] wrote: it appears that cg-diff does a git-update-cache --refresh /dev/null each time it's run, which is taking the bulk of the time. Also note that curiously, it exits with status 1. Does git-ls-files --unmerged show any files? -- Catalin - To

Re: [PATCH] stgit: allow spaces in filenames (second try)

Bryan Larsen [EMAIL PROTECTED] wrote: The current version of stgit does not allow whitespace in filenames. This patch fixes that. It also speeds up operations on large filesets considerably. Signed-off-by: Bryan Larsen [EMAIL PROTECTED] Applied. It will be visible tonight via the ftp

Re: [PATCH] stgit: allow spaces in filenames

Bryan Larsen [EMAIL PROTECTED] wrote: The current version of stgit does not allow whitespace in filenames. This patch fixes that. It also speeds up operations on large filesets considerably. Thanks, I will apply it but I have a few comments below: +# __run: runs cmd using spawnvp. +# +#

Re: [ANNOUNCE] Cogito 0.12.1

Russell King [EMAIL PROTECTED] wrote: I won't bother trying to explain, I'll just paste the errors. We've been here before in a previous cogito revision. [EMAIL PROTECTED]:[linux-2.6-rmk]:1038 cg-branch-ls origin ../linux-2.6 smp ../linux-2.6-smp I noticed that Cogito doesn't work

Re: [PATCH] stgit: allow spaces in filenames

On Wed, 2005-07-13 at 14:17 -0400, Bryan Larsen wrote: Catalin Marinas wrote: I would have hoped that emacs py-mode would do the right thing. Anybody know how to make it do what Catalin wants? It looks like the python-mode in my emacs does the right thing. You could add something like below

Re: Stacked GIT 0.4

Bryan Larsen [EMAIL PROTECTED] wrote: import: the complement to export It is written in the TODO file but didn't have time to do it. I'm working on moving all the commands from main.py into separate files under stgit/commands/ for a clearer view. This should be ready in the next day or two and,

Stacked GIT 0.4

Stacked GIT 0.4 release is available from http://procode.org/stgit/ StGIT is a Python application providing similar functionality to Quilt (i.e. pushing/popping patches to/from a stack) on top of GIT. These operations are performed using GIT commands and the patches are stored as GIT commit

Re: Stacked GIT 0.3 (now more Quilt-like)

Peter Osterlund [EMAIL PROTECTED] wrote: Added possibility to include diffstat output in exported patches. Great. I had a plan to do this but I was busy with the push and resolved commands. I will apply this patch. Thanks. -- Catalin - To unsubscribe from this list: send the line unsubscribe

Re: Stacked GIT 0.3 (now more Quilt-like)

On Mon, 2005-07-04 at 14:32 +0200, Peter Osterlund wrote: I agree with the other comments, it's probably not wise to rely on wiggle, and wiggle sometimes makes a mess. However, it often does the right thing, and with a configurable merge program and an undo function, this should not be a

Re: Stacked GIT 0.3 (now more Quilt-like)

On Mon, 2005-07-04 at 14:32 +0200, Peter Osterlund wrote: I agree with the other comments, it's probably not wise to rely on wiggle, and wiggle sometimes makes a mess. However, it often does the right thing, and with a configurable merge program and an undo function, this should not be a

Re: full kernel history, in patchset format

David Mansfield [EMAIL PROTECTED] wrote: Catalin Marinas wrote: AFAIK, cvsps uses the date/time to create the changesets. There is a problem with the BKCVS export since some files in the same commit can have a different time (by an hour). I posted a mail some time ago about this - http