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
> stgit ftdetect plugi
On 22 October 2013 15:31, Pavel Roskin 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
Thanks. Applied.
Catalin
--
To unsubscribe from this lis
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 SHA1
> > >
> > > The resulting notes are stored in a separate revisi
On 23 October 2012 21:51, Jeff King 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 the ch
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
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 whi
Daniel Barkalow <[EMAIL PROTECTED]> wrote:
> On Tue, 23 Aug 2005, Jan Veldeman wrote:
>> The parents which should be visible to the outside, will always be versions
>> of my development tree, which I have previously pushed out. My way of
>> working would become:
>> * make changes, all over the plac
Jan Veldeman <[EMAIL PROTECTED]> wrote:
> The parents which should be visible to the outside, will always be versions
> of my development tree, which I have previously pushed out. My way of
> working would become:
> * make changes, all over the place, using stgit
> * still make changes (none of the
Back from holiday. Thanks to all who replied to this thread.
On Tue, 2005-08-23 at 14:05 -0400, Daniel Barkalow wrote:
> Having a useful diff isn't really a requirement for a parent; the diff in
> the case of a merge is going to be the total of everything that happened
> elsewhere. The point is to
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 h
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 ob
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 talk
On Fri, 2005-08-19 at 20:27 +0200, Jan Veldeman wrote:
> hmm, not exactly, for example, when reordering the patches (including the
> top one), I would like to see this in gitk.
> Or when a patch has been dropped (amongst a lot of patches), it should be
> easily spotted.
I tried your patch but the
Jan Veldeman <[EMAIL PROTECTED]> wrote:
> I like stgit very much, but I feel there is still something missing:
> stgit is very handy when you use it for patches which should be pushed to
> mainline rather quickly. But for pacthes which won't be pushed immediately
> to mainline, it would be usefull
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 co
Marco Costalba <[EMAIL PROTECTED]> wrote:
> I was thinking at two different kind of workflow, one were you are
> tracking a remote repository ( Linux kernel project like ) and one
> as single developer with both stable and develop lines ( qgit or
> StGIT ;-) projects like ).
There is another optio
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 t
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 lis
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 impleme
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,
>
There are other ways to do these, explained in this thread. I will
only show the StGIT way, just choose which one suits you better.
Steve French <[EMAIL PROTECTED]> wrote:
> 1) There is no way to send a particular changeset from the "middle"
> of a set from one tree to another, without exporting i
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
Junio C Hamano <[EMAIL PROTECTED]> wrote:
> If you are happy then I should not complain ;-), and I am
> certainly not complaining, but I still have this feeling that I
> do not get what you are getting at. You can change it to
> directly use pull without intermediate fetch, in order to cope
> with
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.
>
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 chan
Junio C Hamano <[EMAIL PROTECTED]> wrote:
> Here is my understanding of various "temporary heads" left
> directly underneath $GIT_DIR:
>
> HEAD : updated only after successful auto merge.
>
> ORIG_HEAD : records the head value before resolve started.
> if automerge fail
"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
Stacked GIT 0.5 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 ob
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:
Petr Baudis <[EMAIL PROTECTED]> wrote:
> The committer field generally identifies the committer "physically", and
> isn't usually overriden. You'll find <[EMAIL PROTECTED]> in my
> committer field, e.g.
I thought GIT_COMMITTER_{NAME,EMAIL} were added to be able to override
the defaults like [EMAIL
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
--- a/s
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 f
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
> &g
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
Junio C Hamano <[EMAIL PROTECTED]> wrote:
> * When --exclude-per-directory= 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 specif
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
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?
>
> Howev
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, sho
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 f
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 lin
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 $GIT_DIR/co
Junio C Hamano <[EMAIL PROTECTED]> wrote:
> I do not do Porcelain, but wouldn't it be nicer if we had a
> Porcelain neutral "commit log template file" under $GIT_DIR
> somewhere? 'vim: textwidth=75' is completely useless for
> somebody like me (I almost always work inside Emacs).
StGIT uses .git/
On Thu, 2005-07-21 at 16:20 -0400, Bryan larsen wrote:
> The example configuration file makes it appear that the SMTP port is
> configurable. Make it so.
The documentation for smtplib.SMTP says that the smtpserver parameter is
passed to connect(). This latter function parses the smtpserver for
'
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 kerne
Catalin Marinas <[EMAIL PROTECTED]> wrote:
> One note about patch description. I would prefer to have the
> convention of the Linux kernel patches:
>
> ---
> Short description line
Probably without this line in the e-mail body since it is already in
the subject lin
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
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
-
T
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 lik
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
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
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.
> +#
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
Junio C Hamano <[EMAIL PROTECTED]> wrote:
>> "MS" == Marc Singer <[EMAIL PROTECTED]> writes:
> MS> If I've made several commits, I'd like to be able to gather several
> MS> together and produce a patch file. Better still, I'd like to be able
> MS> to pick a set of discontiguous commits an bund
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 object
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 "unsubscr
On Thu, 2005-07-07 at 21:17 +0200, Peter Osterlund wrote:
> I've found an unrelated problem. If I export patches with "stg export
> dirname", there are no diffs included in the patches. The patch
> description is all that is generated. If I omit the dirname parameter,
> the export works correctly t
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 pr
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 pr
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
Ingo Molnar <[EMAIL PROTECTED]> wrote:
> i've converted the Linux kernel CVS tree into 'flat patchset' format,
> which gave a series of 28237 separate patches. (Each patch represents a
> changeset, in the order they were applied. I've used the cvsps
> utility.)
AFAIK, cvsps uses the date/time to
60 matches
Mail list logo
