* Re: git-bisect problem
From: Andrew Morton @ 2006-02-13 10:44 UTC (permalink / raw)
To: ltuikov; +Cc: ryan, junkio, git
In-Reply-To: <20060213104036.67433.qmail@web31811.mail.mud.yahoo.com>
Luben Tuikov <ltuikov@yahoo.com> wrote:
>
> Andrew,
>
> Here is the output:
>
> $ git-diff-tree --pretty -p 386093ef9a6c88576d8b418bf1c8616d5e410a20
Yes, that is decent. But for many patches, I'd end up having to call the
files "386093ef9a6c88576d8b418bf1c8616d5e410a20.patch". git-format-patch
chooses nice filenames. Slowly.
Anyway, repeated applications of the one-diff git-format-patch (based on a
grep of the git-log output) got me the 69 patches which I want, so I can
find this bug now, thanks.
^ permalink raw reply
* cat-file (was Re: git-bisect problem)
From: Joshua N Pritikin @ 2006-02-13 12:21 UTC (permalink / raw)
To: git
In-Reply-To: <20060213095859.GA17115@ferdyx.org>
[-- Attachment #1: Type: text/plain, Size: 340 bytes --]
On Mon, Feb 13, 2006 at 10:58:59AM +0100, Fernando J. Pereda wrote:
> This gives you the whole info about the commit, including a patch:
>
> git cat-file commit 386093ef9a6c88576d8b418bf1c8616d5e410a20
Eh? Then why not call the command "cat-object" or simply "cat"?
--
Make April 15 just another day, visit http://fairtax.org
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [ANNOUNCE] pg - A patch porcelain for GIT
From: Catalin Marinas @ 2006-02-13 14:40 UTC (permalink / raw)
To: git
In-Reply-To: <20060210195914.GA1350@spearce.org>
Shawn Pearce <spearce@spearce.org> wrote:
> I just posted the first public version of pg, a GIT porcelain for
> managing patches. Think StGIT, but better in some ways:
Couldn't help replying to such a topic :-) (only that the ":" ending
of the above phrase might make people think that some features you
listed are not available in StGIT).
Without much testing, I think pg is a good tool but it is different
from StGIT in many ways. It mainly resembles the topic branches way of
working with the advantage of having them stacked on each-other. Each
patch seems to be equivalent to a topic branch where you can commit
changes. Rebasing a patch is equivalent to a merge in a branch with
the merge commit having a general description like "Refreshed patch
..." and two parents - the new base and the old top.
While I don't say the above is a bad thing, it is pretty different
from StGIT. With StGIT, the history of the tree only shows one commit
per patch with the patch description chosen by the user. If you edit
the description or modify the patch, the old patch or description is
dropped from the main branch (visible via HEAD) and you only get the
latest one. This clean history has many advantages when sending
patches upstream either via e-mail or by asking for a pull.
> - Simplified command line user interface.
>
> pg tries to simplify GIT by 'hiding' the index and behaving like
> more traditional SCMs which only look at `HEAD` (last commit)
> and the working directory (files).
This is the case with StGIT as well. It doesn't usually require the
use of GIT commands directly.
> - Preserves change history of patches.
>
> The complete change history associated with each patch is
> maintained directly within GIT. By storing the evolution of a
> patch as a sequence of GIT commits standard GIT history tools
> such as gitk can be used.
There have been discussions to adding this to StGIT as well (and there
is a patch already from Chuck). It is a good thing to have but I'm
opposed to the idea of having the history accessible from the top of
the patch. Since the patch can be refreshed indefinitely, it would
make the main history (visible from HEAD) really ugly and also cause
problems with people pulling from a tree. I prefer to have a separate
command (like 'stg id patch/log') that gives access to the history.
> - Its prune proof.
>
> The metadata structure is stored entirely within the refs
> directory and the object database, which means you can safely use
> git-prune without damaging your work, even for unapplied
> patches.
That's missing indeed in StGIT but it will be available in the next
release. I didn't push this yet because I wasn't sure what to do with
the refresh history of a patch.
> - Automatic detection (and cancellation) of returning patches.
>
> pg automatically detects when a patch is received from
> the upstream GIT repository during a pg-rebase and deletes
> (cancels) the local version of the patch from the patch series.
> The automatic cancelling makes it easy to use pg to track and
> develop changes on top of a GIT project.
StGIT has been doing this from the beginning. You would need to run a
'stg clean' after a rebase (or push). I prefer to run this command
manually so that 'stg series -e' would show the empty patches and let
me decided what to do with them.
> - Fast
>
> pg operations generally perform faster than StGIT operations,
> at least on my large (~7000 file) repositories.
Might be possible but I haven't done any tests. There are some
optimisations in StGIT that make it pretty fast: (1) if the base of
the patch has not changed, it can fast-forward the pushed patches
which is O(1) and (2) StGIT first tries to use git-apply when pushing
a patch and use a three-way merge only if this fails (the operation
usually succeeds for most of the patches). There are some speed
problems with three-way merging if there are many file
removals/additions because the external merge tool is called for each
of them but the same problem exists for any other tool.
--
Catalin
^ permalink raw reply
* Re: [PATCH 0/2] More git-send-email updates
From: Nicolas Vilz 'niv' @ 2006-02-13 15:58 UTC (permalink / raw)
To: git
In-Reply-To: <11398189232404-git-send-email-ryan@michonline.com>
Ryan Anderson wrote:
> To follow up on some conversations related to git-send-email this week, here are two updates:
>
> The first adds a command line option to suppress adding the "From" address to
> the list of addresses to Cc, when it appears in a From: header line. (Note
> that git-send-email never looked for From: lines inside the body of a message
> to use as a source for Cc: addresses, which, given the patch formats Linus has
> previously talked about, is probably a bug.)
>
> The second patch adds the mythical "--cc" option. I say "mythical" because it
> has never existed, but both Junio and I have mentioned it (or used it)
> recently, so we both *assumed* that it existed. I think that's justification
> for adding it.
>
it is a very nice idea to use git-send-email together with
git-format-patch --stdout, but i think, maybe i do something wrong... I
tried that cli-syntax Junio mentioned in "Whats in git.git"
git format-patch --stdout <branch_01>..<branch_02>|git send-email --to
<email_address>
and got a "Error: Please specify a file or a directory on the command
line.".
Besides, git asks me for a From-Header (which is fixed with this patch,
I suppose)
I use git 1.2.0 directly from your git-repository.
so actually git-send-email does not work with this syntax above.
If I first produce the patches, save them into another directory and
afterwards give git-send-email that directory for lunch, it works...
is there any other work-around for this everyday-task but a shellscript
which temporarily creates a patch-dir which contains the patches and
removes it after git-send-email is done with it?
Sincerly
Nicolas
^ permalink raw reply
* Re: Handling large files with GIT
From: Linus Torvalds @ 2006-02-13 16:19 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Ben Clifford, Martin Langhoff, Florian Weimer, git
In-Reply-To: <43F01F5A.5020808@pobox.com>
On Mon, 13 Feb 2006, Jeff Garzik wrote:
>
> Linus Torvalds wrote:
> > I've never used maildir layout, but if it is a couple of large _flat_
> > subdirectories,
>
> That's what it is :/ One directory per mail folder, with each email an
> individual file in that dir.
Ok.
Anyway, I double-checked, and I'm wrong anyway. While the "static
directories" thing is a huge performance optimization for doing many
things (diffing trees, file history in git-rev-list, etc etc), for merging
it doesn't help. We always end up expanding the whole tree.
Which is kind of sad.
It's inevitable in one sense: we do the merge in the index, after all, and
the index - unlike the tree structures - is a flat file (like the
"manifest" in mercurial or monotone). It's also represented that way in
memory.
However, it is a total and complete waste in other cases.
Thinking more about it, this is also why merging causes all the horrible
index performance: not only do we (unnecessarily) read the same trees over
and over again only to collapse them back to stage0 later when they are
the same, but because we keep the index in a linear format, when we read
the other trees, we'll have to move things around with memmove() (just the
pointers, but still).
We'd actually be a _lot_ better off if we split "git-read-tree" up into
two phases: one that did the recursive tree operation (which can optimize
the "same tree everywhere" case), and the second stage that actually
populated the index.
I'll have to think about this. It would be an absolutely _huge_
optimization for merging in certain patterns, it just doesn't matter for
something like the kernel with "just" 18,000 files and not a lot of
strange merging going on.
In contrast, I can see a mail archive easily having hundreds of thousands
of individual emails. At which time it's horribly stupid to read them all
in three times (for a merge - base, origin, new) and do so in a pretty
inefficient manner.
Ho humm. It doesn't look _hard_ per se, and I think the two-stage
git-read-tree is actually also what the recursive merge strategy wants
anyway (it can't use the index - it really just wants to get a list of
conflict information). So this definitely sounds like the RightThing(tm)
to do anyway, and it fits the git data structures really well.
So no downsides. Except that this is some rather core code, and you can't
afford to get it wrong. And the fact that I'm a lazy bastard, of course.
Linus
^ permalink raw reply
* Re: Fake linear history in a deterministic manner.
From: Linus Torvalds @ 2006-02-13 16:34 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Junio C Hamano, git
In-Reply-To: <46a038f90602122158n51fc94a8h2ff2631c16cd28b5@mail.gmail.com>
On Mon, 13 Feb 2006, Martin Langhoff wrote:
>
> In any case, I'm undecided whether to use --topo-order or
> --merge-order. Does it really matter?
Use topo-order.
merge-order is much more expensive to calculate, and doesn't even exist if
NO_OPENSSL is set.
Anyway, while linearization in general is impossible, I'd suggest a few
heuristics:
- you obviously must remember the head of the previous linearization. Any
tree choices you made in the past are not something you can change any
more for cvs export.
This may sound obvious, but the fact is, especially if you do the cvs
export frequently, and the main maintainer updates the tree in a timely
manner, it will limit your choices a LOT. In fact, most of the time
you'll have no choice at all: you will have an unambiguous "TRUNK" that
is defined by the fact that there is only one linear path from the
previous export-head to the current HEAD.
In short, most of the time you won't have any issues in a stable system.
You'll see a true "fork in the road" choice only when the maintainer
hasn't pushed his tree to the thing you export in a while, long enough
that no CVS exporting has taken place over a whole parallel cycle. It's
probably rare.
So the main issue of "which child to choose" becomes one of the initial
export, and then just occasionally thereafter. And in that case, there's
really just one obvious algorithm:
- simply enumerate the possible paths (not that hard - it's just
enumerating a tree once you've generated the graph in memory with child
and parent pointers), and just selecting the one with the "longest
weighted path".
I say "weighted path", because you might want to consider different
commits to have different weights. For example, you might want to consider
merge commits to be less interesting (so weight them as 0.5 commits) in
order to get as many "real" commits as possible. And you might consider
commits made by a certain person to be "more TRUNKish", and give them a
weight of 2, so that you'll be more likely to follow the "maintainer view"
over any other linearized history.
No other algorithm seems very sane.
Linus
^ permalink raw reply
* Quick question
From: Radoslaw Szkodzinski @ 2006-02-13 16:36 UTC (permalink / raw)
To: Git Mailing List
[-- Attachment #1: Type: text/plain, Size: 316 bytes --]
How to display ignored files of the whole project using only core git?
I've tried:
git-ls-files -o -i -X .git/info/exclude
and it only showed me the excluded files in the current directory...
--
GPG Key id: 0xD1F10BA2
Fingerprint: 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2
AstralStorm
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
^ permalink raw reply
* Re: git-bisect problem
From: Linus Torvalds @ 2006-02-13 16:44 UTC (permalink / raw)
To: Andrew Morton; +Cc: Ryan Anderson, junkio, git
In-Reply-To: <20060213022527.3f888666.akpm@osdl.org>
On Mon, 13 Feb 2006, Andrew Morton wrote:
> Ryan Anderson <ryan@michonline.com> wrote:
> >
> > git format-patch -o ~/a 386093ef9a6c88576d8b418bf1c8616d5e410a20^1..386093ef9a6c88576d8b418bf1c8616d5e410a20
>
> That worked.
Well, really, it's much nicer these days to just say
git show 386093ef9
and you're done.
For me, it gives a nice
diff-tree 386093ef9a6c88576d8b418bf1c8616d5e410a20 (from ce5f8d70ba6e3d7ffcaff86b2cf91a42c27f77af)
Author: Alexey Dobriyan <adobriyan@gmail.com>
Date: Wed Feb 1 03:04:57 2006 -0800
[PATCH] ipw2200: fix ->eeprom[EEPROM_VERSION] check
priv->eeprom is a pointer.
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Acked-by: Yi Zhu <yi.zhu@intel.com>
Cc: James Ketrenos <jketreno@linux.intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
diff --git a/drivers/net/wireless/ipw2200.c b/drivers/net/wireless/ipw2200.c
index 916b24c..14beab4 100644
--- a/drivers/net/wireless/ipw2200.c
+++ b/drivers/net/wireless/ipw2200.c
@@ -2456,7 +2456,7 @@ static void ipw_eeprom_init_sram(struct
copy. Otherwise let the firmware know to perform the operation
on it's own
*/
- if ((priv->eeprom + EEPROM_VERSION) != 0) {
+ if (priv->eeprom[EEPROM_VERSION] != 0) {
IPW_DEBUG_INFO("Writing EEPROM data into SRAM\n");
/* write the eeprom data to sram */
which looks sane.
> I'm still not having much success geting a string of patches out of it.
>
> git format-patch -o ~/a d834a41c966c6a20368fadb59248740935e6fbae..826eeb53a6f264842200d3311d69107d2eb25f5e
well, that's 1003 patches you're asking for.
That's almost certainly _not_ what you want.
Do "gitk ..args.." to visually see what you're doing. Or, what I did:
git-rev-list d834a41c966c6a20368fadb59248740935e6fbae..826eeb53a6f264842200d3311d69107d2eb25f5e |
wc -l
which is how I got the 1003.
I'm pretty sure it wasn't what you meant to do.
> How do I get the IPW patches out of Jeff's tree, in order?
>
> I guess since I found a command which actually works, I can type that
> 20-odd times.
"git show". Much simpler. HOWEVER. Doing that 20-odd times sounds insane.
Just use gitk to see that you actually have the right starting and ending
points.
Visualizing the history really is very important. If you had tried gitk,
you'd have immediately seen what you were doing, and that it wasn't what
you wanted.
Only after you're really comfortable with git should you do anything at
all without looking at it visually first.
(After you've done that a few months, you won't need it any more - your
brain will be able to visualize things on its own. gitk is just the
training wheels).
Linus
^ permalink raw reply
* Re: Quick question
From: Linus Torvalds @ 2006-02-13 16:54 UTC (permalink / raw)
To: Radoslaw Szkodzinski; +Cc: Git Mailing List
In-Reply-To: <43F0B577.4070608@gorzow.mm.pl>
On Mon, 13 Feb 2006, Radoslaw Szkodzinski wrote:
>
> How to display ignored files of the whole project using only core git?
>
> I've tried:
>
> git-ls-files -o -i -X .git/info/exclude
>
> and it only showed me the excluded files in the current directory...
Well, since you're telling it to only show excluded files, it will also
only show excluded directories.
Which is admittedly insane. You don't want to exclude directories. Or
maybe you do, but then we should add the "/" to the end before we do the
exclusion.
This patch (untested) will never exclude directories. Which may or may not
be the right thing.
Junio? Others? Comments?
Linus
---
diff --git a/ls-files.c b/ls-files.c
index 7024cf1..b923f92 100644
--- a/ls-files.c
+++ b/ls-files.c
@@ -276,8 +276,6 @@ static void read_directory(const char *p
continue;
len = strlen(de->d_name);
memcpy(fullname + baselen, de->d_name, len+1);
- if (excluded(fullname) != show_ignored)
- continue;
switch (DTYPE(de)) {
struct stat st;
@@ -304,6 +302,8 @@ static void read_directory(const char *p
case DT_LNK:
break;
}
+ if (excluded(fullname) != show_ignored)
+ continue;
add_name(fullname, baselen + len);
}
closedir(dir);
^ permalink raw reply related
* Re: Quick question
From: Radoslaw Szkodzinski @ 2006-02-13 18:26 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0602130848220.3691@g5.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 793 bytes --]
Linus Torvalds wrote:
>
> Well, since you're telling it to only show excluded files, it will also
> only show excluded directories.
>
> Which is admittedly insane. You don't want to exclude directories. Or
> maybe you do, but then we should add the "/" to the end before we do the
> exclusion.
>
> This patch (untested) will never exclude directories. Which may or may not
> be the right thing.
>
> Junio? Others? Comments?
>
For me it seems to do the right thing, although I have no need to exclude directories.
If I really needed to, I'd say something like:
/excluded_dir/*
in .git/info/exclude, and it would show the files as being excluded.
--
GPG Key id: 0xD1F10BA2
Fingerprint: 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2
AstralStorm
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
^ permalink raw reply
* Re: Quick question
From: Alex Riesen @ 2006-02-13 20:17 UTC (permalink / raw)
To: Radoslaw Szkodzinski; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <43F0CF3B.6040807@gorzow.mm.pl>
Radoslaw Szkodzinski, Mon, Feb 13, 2006 19:26:03 +0100:
> Linus Torvalds wrote:
> >
> > Well, since you're telling it to only show excluded files, it will also
> > only show excluded directories.
> >
> > Which is admittedly insane. You don't want to exclude directories. Or
> > maybe you do, but then we should add the "/" to the end before we do the
> > exclusion.
> >
> > This patch (untested) will never exclude directories. Which may or may not
> > be the right thing.
I actually quiet like it how it is.
> > Junio? Others? Comments?
> >
>
> For me it seems to do the right thing, although I have no need to exclude directories.
> If I really needed to, I'd say something like:
>
> /excluded_dir/*
>
> in .git/info/exclude, and it would show the files as being excluded.
>
What's wrong with .gitignore in the excluded_dir containing everything
you don't want to see, or even just "*"?
^ permalink raw reply
* git-svnimport -d and -D options (was Re: [PATCH] Use a relative path for SVN importing)
From: Eduardo Pereira Habkost @ 2006-02-13 20:52 UTC (permalink / raw)
To: Christian Biesinger; +Cc: git, Matthias Urlichs
In-Reply-To: <1139672651713-git-send-email-cbiesinger@web.de>
[-- Attachment #1: Type: text/plain, Size: 959 bytes --]
Hi,
On Sat, Feb 11, 2006 at 04:44:11PM +0100, Christian Biesinger wrote:
> The absolute path (with the leading slash) breaks SVN importing, because it then
> looks for /trunk/... instead of /svn/trunk/... (in my case, the repository URL
> was https://servername/svn/)
I've hit this bug today, and fortunately I've found the fix from
Christian. Thanks! :)
I am wondering if this bug was the initial reason why the -d and -D
options where added to git-svnimport.
Is there another real reason why the -d and -D options exist in
git-svnimport?
The documentation for the options say that the "wrong" option will die
with 40x, but the commit message[1] says something about "internal server
error". I don't know which one is right.
Mathias, couldn't be the errors you described in the commit message
related to this bug?
[1] http://www.kernel.org/git/?p=git/git.git;a=commit;h=25f6f325d7a8f7cb686a9ffd9fa2c00b3aa85a60
--
Eduardo
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* StGIT mail configuration
From: Aubin LaBrosse @ 2006-02-13 20:47 UTC (permalink / raw)
To: catalin.marinas, git
[-- Attachment #1: Type: text/plain, Size: 1451 bytes --]
Hello,
I'm using StGIT 0.8.1 on top of the latest release of Cogito - in
.git/stgitrc of a local git repo, I have the following part related to
my mail configuration:
smtpserver: mail.stormboxes.com:25
smtpuser: username@stormboxes.com
smtppassword: myPassword
(actual username and password redacted, of course) - the point is, the
username actually is that entire string 'username@stormboxes.com' (no
quotes) because the box it's on is a virtual server for many domains and
the usernames must contain the domain to which they belong. anyway, i
was getting authentication failures, so i hacked up mail.py and set the
debug level on the smtp object - i found out that it's trying to auth
using CRAM-MD5. And I'm not sure whether the server doesn't support
that or not, but i didn't see anything in the python doc that would
indicate that i could make the login() method use auth login or auth
plain or something else, and it seems like it gets a valid response from
the server that tells it that the authentication failed - and i'm not
sure why - thunderbird works fine but i can't figure out which auth type
it's using. (suppose i could tcpdump it and see) I have, of course,
triple checked my auth credentials at this point.
does anyone have any hints or insights, or is this a server
configuration problem? any help would be greatly appreciated. Please
CC, as I am not subscribed to the git list.
Thanks,
Aubin LaBrosse
[-- Attachment #2: aubin.vcf --]
[-- Type: text/x-vcard, Size: 160 bytes --]
begin:vcard
fn:Aubin LaBrosse
n:LaBrosse;Aubin
email;internet:aubin@stormboxes.com
tel;work:589-0692
tel;home:429-1520
tel;cell:493-0121
version:2.1
end:vcard
^ permalink raw reply
* Re: [ANNOUNCE] pg - A patch porcelain for GIT
From: Petr Baudis @ 2006-02-13 21:00 UTC (permalink / raw)
To: git
In-Reply-To: <20060210211740.GO31278@pasky.or.cz>
Hi,
Dear diary, on Fri, Feb 10, 2006 at 10:17:40PM CET, I got a letter
where Petr Baudis <pasky@suse.cz> said that...
> > I just posted the first public version of pg, a GIT porcelain for
> > managing patches. Think StGIT, but better in some ways:
>
> it sounds interesting. I've been thinking about wrapping some patch
> queue tool in Cogito (post-1.0) and pg might be a better choice than
> StGIT.
so I've used it a bit and I'm going back to StGIT, at least for now.
It is not really usable for me so far, since it is missing two crucial
things:
* Patch description tracking. Patch description is almost as
important as patch contents for me, and pg just doesn't track it
for now. It would be best if it just seeded the patch
description by the first commit message and then allow you edit
it at the refresh time.
* Mail interface. StGIT can pre-fill the patch description with
my signoff line, but more importantly when I write
stg mail patchname
it will mail the patch to the addresses I configured it to,
prepend [PATCH] to the subject line and stuff.
So, my patchqueue workflow is "I do some random third-party patches
for some software and want to manage, update, and submit them easily."
PG does not make it much easier now, unfortunately.
Some common gripes for both StGIT and pg (well, I'm using some
ridiculously old StGIT version, so this may not apply anymore there):
* stg new --force - seriously, what's the point?! I always to
the change first and when it's any good, I want to create a
patch for it.
* I can't just get the patch in its "canonical ready-to-mail
form" on stdout so that I could easily review it. Why is
pg-export insisting to dump it to a file?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply
* Re: StGIT mail configuration
From: Catalin Marinas @ 2006-02-13 21:45 UTC (permalink / raw)
To: Aubin LaBrosse; +Cc: git
In-Reply-To: <43F0F072.90609@stormboxes.com>
On 13/02/06, Aubin LaBrosse <aubin@stormboxes.com> wrote:
> I'm using StGIT 0.8.1 on top of the latest release of Cogito - in
> .git/stgitrc of a local git repo, I have the following part related to
> my mail configuration:
>
> smtpserver: mail.stormboxes.com:25
> smtpuser: username@stormboxes.com
> smtppassword: myPassword
>
> (actual username and password redacted, of course) - the point is, the
> username actually is that entire string 'username@stormboxes.com' (no
> quotes) because the box it's on is a virtual server for many domains and
> the usernames must contain the domain to which they belong. anyway, i
> was getting authentication failures, so i hacked up mail.py and set the
> debug level on the smtp object - i found out that it's trying to auth
> using CRAM-MD5. And I'm not sure whether the server doesn't support
> that or not, but i didn't see anything in the python doc that would
> indicate that i could make the login() method use auth login or auth
> plain or something else
At least with Python 2.4, the authentication type is detected
automatically based on server's response to the ehlo command. It
supports cram-md5, plain and login (and I think it tries them in this
order). If the server responds with something different, the login()
command would raise an exception like "No suitable authentication
method found.". You could print s.esmtp_features["auth"] in mail.py in
StGIT after ehlo.
I haven't read the RFC2554 but you could also try to replace the '@' with '%40'.
> thunderbird works fine but i can't figure out which auth type
> it's using. (suppose i could tcpdump it and see) I have, of course,
> triple checked my auth credentials at this point.
Probably using tcpdump or ethereal would be the easiest.
--
Catalin
^ permalink raw reply
* Prune-safe StGIT (was Re: Two crazy proposals for changing git's diff commands)
From: Catalin Marinas @ 2006-02-13 22:00 UTC (permalink / raw)
To: Mark Wooding; +Cc: git
In-Reply-To: <slrnduphvr.2i8.mdw@metalzone.distorted.org.uk>
Mark Wooding wrote:
> (I really look forward to a StGIT which can withstand git-prune.)
Since there were a few requests for this feature, I pushed it to the
public repository (and also included it in the latest snapshot).
As it was discussed a few months ago, the top id of each patch
(including the popped ones) is added to the
.git/refs/patches/<branch>/<patch> file. The git-prune command will
preserve these objects and their referents, making even the unapplied
patches safe. There is another advantage with this approach - gitk shows
the patch name for every corresponding commit.
Running any command (apart from help) on the current branch would create
the initial references. You would need to do the same with all the other
branches. Since this is a new feature, make sure you have backups before
pruning (though it worked OK for me).
--
Catalin
^ permalink raw reply
* [PATCH] s/SHELL/SHELL_PATH/ in Makefile
From: Fredrik Kuivinen @ 2006-02-13 23:15 UTC (permalink / raw)
To: git; +Cc: junkio
With the current Makefile we don't use the shell chosen by the
platform specific defines when we invoke GIT-VERSION-GEN.
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
---
Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
86d29e725d299d2bba7404809d81c61d7dab590c
diff --git a/Makefile b/Makefile
index f240e45..d40aa6a 100644
--- a/Makefile
+++ b/Makefile
@@ -67,7 +67,7 @@ all:
# change being considered an inode change from the update-cache perspective.
GIT-VERSION-FILE: .FORCE-GIT-VERSION-FILE
- @$(SHELL) ./GIT-VERSION-GEN
+ @$(SHELL_PATH) ./GIT-VERSION-GEN
-include GIT-VERSION-FILE
# CFLAGS and LDFLAGS are for the users to override from the command line.
--
1.1.6.g4dc8
^ permalink raw reply related
* Re: Handling large files with GIT
From: Martin Langhoff @ 2006-02-13 23:19 UTC (permalink / raw)
To: Ian Molton; +Cc: Linus Torvalds, Ben Clifford, Florian Weimer, git
In-Reply-To: <43F113A5.2080506@f2s.com>
On 2/14/06, Ian Molton <spyro@f2s.com> wrote:
> Im curious as to why anyone would want to use a SCM tool on a mail dir
> anyway - surely no-one edits their pasnt mails and needs to keep logs?
>
> surely incremental backups would be a better way to manage something
> like this ?
Well, the maildir arrangement is friendlier to something content-smart
like git than to something content-stupid like a backup tool. Files
inside a maildir change name/location to reflect changes in status,
but their content tends to remain the same.
git does great in this scenario, except for the "dealing with a
bazillion files" part of it.
cheers,
martin
^ permalink raw reply
* Re: Handling large files with GIT
From: Ian Molton @ 2006-02-13 23:17 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Ben Clifford, Martin Langhoff, Florian Weimer, git
In-Reply-To: <Pine.LNX.4.64.0602122058260.3691@g5.osdl.org>
Linus Torvalds wrote:
> Taking advantage of those kinds of things is what makes git good at
> handling software projects. But it wouldn't necessarily be how you lay out
> a mail directory, for example. An automated file store might want to
> spread out the changes on purpose.
Indeed...
Im curious as to why anyone would want to use a SCM tool on a mail dir
anyway - surely no-one edits their pasnt mails and needs to keep logs?
surely incremental backups would be a better way to manage something
like this ?
^ permalink raw reply
* Re: Handling large files with GIT
From: Keith Packard @ 2006-02-13 6:07 UTC (permalink / raw)
To: Jeff Garzik
Cc: keithp, Linus Torvalds, Ben Clifford, Martin Langhoff,
Florian Weimer, git
In-Reply-To: <43F01F5A.5020808@pobox.com>
[-- Attachment #1: Type: text/plain, Size: 458 bytes --]
On Mon, 2006-02-13 at 00:55 -0500, Jeff Garzik wrote:
> Linus Torvalds wrote:
> > I've never used maildir layout, but if it is a couple of large _flat_
> > subdirectories,
>
> That's what it is :/ One directory per mail folder, with each email an
> individual file in that dir.
and, named to include a hash of the contents so that they are always
unique within a multi-folder mail store (makes refile easier).
--
keith.packard@intel.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Make "git clone" less of a deathly quiet experience
From: Keith Packard @ 2006-02-12 21:04 UTC (permalink / raw)
To: Andreas Ericsson
Cc: keithp, Linus Torvalds, Junio C Hamano, Git Mailing List,
Petr Baudis
In-Reply-To: <43EF15D1.1050609@op5.se>
[-- Attachment #1: Type: text/plain, Size: 800 bytes --]
On Sun, 2006-02-12 at 12:02 +0100, Andreas Ericsson wrote:
> Caching features have been discussed, but that means the daemon needs to
> have write-access to some directory within the repository.
Caching seems a bit dicey to me; security concerns and all. I would much
rather have it discover packs on disk that provided a subset of the
necessary objects; repository cloning would then be a process of
delivering any available packs and then packing up the remaining
objects. Clever administration of the repository could then construct a
single pack of 'historical' data followed by periodic packs of
incremental data.
Yeah, I know, I should just implement this and see how well it works in
practice. I apologize for thinking in public.
--
keith.packard@intel.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Handling large files with GIT
From: Martin Langhoff @ 2006-02-14 0:07 UTC (permalink / raw)
To: Keith Packard
Cc: Jeff Garzik, Linus Torvalds, Ben Clifford, Florian Weimer, git
In-Reply-To: <1139810847.4183.85.camel@evo.keithp.com>
On 2/13/06, Keith Packard <keithp@keithp.com> wrote:
> and, named to include a hash of the contents
really? I thought it was something like md5(hostname+datestamp+random).
cheers,
m
^ permalink raw reply
* Re: git-bisect problem
From: Junio C Hamano @ 2006-02-14 0:33 UTC (permalink / raw)
To: git; +Cc: Andrew Morton
In-Reply-To: <20060213015146.26e6c09d.akpm@osdl.org>
Andrew Morton <akpm@osdl.org> writes:
> git-format-patch -o ~/a 386093ef9a6c88576d8b418bf1c8616d5e410a20 git-netdev-all
>
> and that chewed 10 minutes CPU time and produced no output, so I killed it.
A single commit is either:
git format-patch -o ~/a 386093^ 386093
git show 386093
But if you _did_ want to get everything that builds on top of
386093 (and Linus counted 1000+ commits if I recall),
format-patch could be optimized. It currently does a lot more
than just format 1000+ commits, to handle case where "his" and
"mine" are not linear history and may have the same change
acquired by applying the same patch:
1---2---3 mine
/
---4---5---6 his
In this picture, it does not just format 1 2 3. It first checks
1 2 3 5 6, and if each of 1 2 3 introduces the same change as
either 5 or 6 introduces to omit it from the output. If 2 and 5
are the same change from 1 and 4 respectively, the final result
has 1 and 3. This is OK and useful for smaller branch, but
clearly expensive for long branches.
This is omitted when the ancestry graph would look like this:
1---2---3 mine
/
---4 his
but that would not have helped in this case anyway.
Maybe we could have --no-omit-common flag or something to
disable this check.
^ permalink raw reply
* Re: git-bisect problem
From: Junio C Hamano @ 2006-02-14 0:32 UTC (permalink / raw)
To: Andrew Morton; +Cc: git
In-Reply-To: <20060213021917.742b2b10.akpm@osdl.org>
Andrew Morton <akpm@osdl.org> writes:
> Junio C Hamano <junkio@cox.net> wrote:
>>
>> Andrew Morton <akpm@osdl.org> writes:
>>
>> > My current theory is that I was bisecting Linus's tree all along.
>>
>> Sorry, I did not realize that was _not_ what you were doing.
>> Your log started by saying 2.6.16-rc1 is good but 2.6.16-rc2 was
>> not, so I just assumed your bug was between those two.
>
> So how am I supposed to find this bug in Jeff's tree?
Sorry, this question is what I do not quite understand.
Here is my understanding of the situation.
- Betweeen 2.6.16-rc1 and 2.6.16-rc2 a bug you are chasing was
introduced. You know rc1 works fine but rc2 is bad.
- You suspect that changes introduced by merging Jeff's tree
at some point between -rc1 and -rc2 may be causing this.
Am I totally misunderstanding the situation?
Bisecting, starting from -rc1 and -rc2 marked good and bad would
find the bug provided if the symptom is caused by a single bug
(that is, before that commit things work but after that things
stop working) that is in any commit that was not present in -rc1
but in -rc2. That includes what was merged from Jeff's tree, so
even if you were "bisecting Linus' tree all along", if -rc1 was
good and -rc2 was bad, that would have found the bug in Jeff's
tree (if it was what introduced the bug). As long as that was
merged between these two -- but otherwise breakage in -rc2 would
not have anything to do with Jeff's tree, so that is one reason
I am confused by your emphasis on "in Jeff's tree" part.
good bad
-rc1 -rc2
---o---o---o---*---*---*---*---*---*
\ \ / /
\ *---* /
\ /
*---*---*---*---*
Jeff's
Your bisection that starts with good -rc1 and bad -rc2 would try
to bisect commits that are not reachable from good ones (that
is, parents before good ones are assumed to be good, since
bisect is only good to look for a single regression), so at the
beginning, all '*' commits are suspects. bisection picks one of
them and after testing it, depending on it is good or bad, mark
about the half of the remaining graph "unsuspected". So even if
you start out with two commits on Linus' tree, you will wander
into Jeff's tree, if the suspect commit is in there. I am
confused by your emphasis on "in Jeff's tree" part.
Maybe you are saying that you _know_ what broke was from Jeff's
tree, and felt bisecting other parts of Linus' tree was
wasteful?
If so, you can use gitk to visualize the graph, find the merge
Linus' did to merge from Jeff (and I presume you already did so
and that is why you are suspecting Jeff's tree). Mark that as
bad, not -rc2. Also if you know the commit on Linus' tree
before that merge was good (and I presume you already did so
and that is why you are suspecting Jeff's tree), mark that as
good, not -rc1.
-rc1 good bad -rc2
---o---o---o---o---o---o---*---o---o
\ \ / /
\ o---o /
\ /
*---*---*---*---*
Jeff's
Then your bisect will walk over commits on Jeff's tree.
Is this helpful, or am I still completely useless?
^ permalink raw reply
* Re: Quick question
From: Junio C Hamano @ 2006-02-14 0:40 UTC (permalink / raw)
To: Radoslaw Szkodzinski; +Cc: git
In-Reply-To: <43F0B577.4070608@gorzow.mm.pl>
Radoslaw Szkodzinski <astralstorm@gorzow.mm.pl> writes:
> How to display ignored files of the whole project using only core git?
>
> I've tried:
>
> git-ls-files -o -i -X .git/info/exclude
>
> and it only showed me the excluded files in the current directory...
With the git.git repository itself, I tried:
$ cat /var/tmp/i
*.c
$ git ls-files -i -X /var/tmp/i | head -n 6
apply.c
arm/sha1.c
blob.c
cat-file.c
check-ref-format.c
checkout-index.c
So I am not sure what you mean. You wanted to "display ignored
files of the whole project", right? I am getting arm/sha1.c
here in my output, so I do not understand the issue here...
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox