* Re: Update local tracking refs when pushing- no way to disable
From: Johannes Schindelin @ 2007-07-06 18:59 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Dan McGee, git
In-Reply-To: <Pine.LNX.4.64.0707061440050.14638@iabervon.org>
Hi,
On Fri, 6 Jul 2007, Daniel Barkalow wrote:
> On Fri, 6 Jul 2007, Johannes Schindelin wrote:
>
> > Related, but not identical, is the problem illustrated in
> > http://thread.gmane.org/gmane.comp.version-control.git/49888
> >
> > IMHO there is a bug. IIUC git push first looks for common ref names on
> > the local and remote side (yes, refs/remotes are excluded since
> > v1.5.3-rc0~9, but the underlying problem is still there). Then it
> > pushes them. But here, something seems to have gone wrong:
> > refs/remotes/origin/HEAD is a symref. And the corresponding ref is
> > updated. Should git-push not just _not_ update symrefs?
>
> I believe this actually have nothing to do with git-push; it's actually
> git-receive-pack and maybe git-send-pack. Probably git-receive-pack
> shouldn't list symrefs at all, or should somehow report them as links so
> that they can be compared as links. The only refs that git-push itself
> updates are tracking refs on the local side for refs on the remote side
> which were updated. In the report, the reporter had (obviously) not
> configured any local tracking refs for the remote's tracking refs.
Sorry, I think I did not make myself clear. The updates refs were _local_
refs. And they _were_ symrefs.
Ciao,
Dscho
^ permalink raw reply
* Re: Update local tracking refs when pushing- no way to disable
From: Daniel Barkalow @ 2007-07-06 18:56 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Dan McGee, git
In-Reply-To: <Pine.LNX.4.64.0707061340350.4093@racer.site>
On Fri, 6 Jul 2007, Johannes Schindelin wrote:
> Hi,
>
> Related, but not identical, is the problem illustrated in
> http://thread.gmane.org/gmane.comp.version-control.git/49888
>
> IMHO there is a bug. IIUC git push first looks for common ref names on the
> local and remote side (yes, refs/remotes are excluded since v1.5.3-rc0~9,
> but the underlying problem is still there). Then it pushes them. But here,
> something seems to have gone wrong: refs/remotes/origin/HEAD is a symref.
> And the corresponding ref is updated. Should git-push not just _not_
> update symrefs?
I believe this actually have nothing to do with git-push; it's actually
git-receive-pack and maybe git-send-pack. Probably git-receive-pack
shouldn't list symrefs at all, or should somehow report them as links so
that they can be compared as links. The only refs that git-push itself
updates are tracking refs on the local side for refs on the remote side
which were updated. In the report, the reporter had (obviously) not
configured any local tracking refs for the remote's tracking refs.
Now, if there are symref heads on the remote (maybe somebody wants to have
a "dominus" branch which is a symref to "master" for people who only speak
Latin), and this was in tracking refs as a symref as well, and the user
pushed to both (with the remote side somehow identifying that the same
change is being made to both names, and that's okay), then the tracking
refs would need this same logic as well. But that requires an
unimplemented and unrequested feature, with fixes in a number of other
places first, before it's even possible to have git-push need to worry
about it.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] git-commit: don't add multiple Signed-off-by: from the same identity
From: Junio C Hamano @ 2007-07-06 18:11 UTC (permalink / raw)
To: Gerrit Pape; +Cc: git
In-Reply-To: <20070706144227.11736.qmail@046ba2bc1a0185.315fe32.mid.smarden.org>
If you are trying to avoid a run of Signed-off-by: lines like this:
Signed-off-by: Original Author <oa@example.com>
Signed-off-by: First Reviewer <fr@example.com>
Signed-off-by: Second Reviewer <sr@example.com>
Signed-off-by: Original Author <oa@example.com>
Signed-off-by: Subsystem Integrator <si@example.com>
It is not a bug. If the last signed-off-by is not from
yourself, your signed-off-by is added when you ask with "-s",
and this is very much intentionally done to follow the existing
practice of patch passing done in the kernel community, where
Signed-off-by: was invented (Linus or somebody from the kernel
circle can correct me if I am wrong).
When you are passing patches around, tweaks to the patch
contents can be made. If your patch comes back to you from the
second reviewer, it is not what you originally sent out. You
would want to sign it off again.
We have deliberately excluded what your other patch tries to do
for a reason. Even though these lines are not digitally signed,
the intent of adding a Signed-off-by: line with your name is
that you are certifying its origin, according to the definition
of DCO (see Documentation/SubmittingPatches). This should be a
conscious act from the signer's part, and making it automatic
with a config variable that you set once and forget makes it
much less meaningful.
^ permalink raw reply
* Re: being nice to patch(1)
From: Linus Torvalds @ 2007-07-06 18:08 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <86644xd7wr.fsf@lola.quinscape.zz>
On Fri, 6 Jul 2007, David Kastrup wrote:
>
> Well, hmph! I just rewrote my git-diff-using script to not check
> stuff into a throw-away git repository, and guess what: with real-life
> use cases (diffing trees of about 500MB size), git-diff runs out of
> memory (the machine probably has something like 1.5GB of virtual memory
> size) when operating outside of a git repository.
Ok, that's probably some huge memory leak that just doesn't show up with
any normal git operations, likely simply because all the normal git
operations will have thrown out the case of "identical files" without ever
even looking at the file.
I'd guess that when using the diff logic on outside files, we'll read them
all in, compare them, and keep them all in memory even though they are
identical.
Generally, though, "git diff" has a much higher memory footprint than any
normal file-by-file recursive diff, exactly because of the rename logic.
An external "diff" won't ever have any reason to keep more than two files
in memory at a time, but because git diff does rename and copy detection,
it wants to keep the file data in memory over much longer times.
But I bet there is some stupid bug where we just make it much much worse
for the "no git tree/index" case, and keep the whole tree in memory or
something.
(The same is true of "git apply", btw, for a different reason: because
git-apply will refuse to write out partial results in case some later
patch fails, git-apply will keep the whole result in memory until the very
end, and then do the write-out in one go. Again, that obviously means
that it will potentially use a lot more memory than the "one patch at a
time" approach that regular "patch" does)
Linus
^ permalink raw reply
* Re: [PATCH] Per-path attribute based hunk header selection.
From: Linus Torvalds @ 2007-07-06 17:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7v8x9uexji.fsf_-_@assigned-by-dhcp.cox.net>
On Fri, 6 Jul 2007, Junio C Hamano wrote:
>
> This makes"diff -p" hunk headers customizable via gitattributes mechanism.
> It is based on Johannes's earlier patch that allowed to define a single
> regexp to be used for everything.
Ok, I think this is really nice, but I do wonder a bit about the syntax.
In particular, the "funcname" thing is really a pretty ugly special-case
approach.
Wouldn't it be nicer to consider the "funcname=java" to be less of a
"special case for the built-in diff", and instead think of it as a more
generic issue of "how do we want to generate diffs for java files?"
IOW, wouldn't this be much nicer to be thought about as a "custon diff
driver" issue?
So I like your patches, but dislike the config syntax, and would suggest
something like
In .gitattributes:
*.java diff=java
*.perl diff=perl
*.doc diff=doc
In .git/config
[diff "java"]
command = internal
funcname = ... # ugly and complicated regexp to override the built-in one.
[diff "perl"]
command = internal
funcname = ...
[diff "doc"]
command = ms-doc-diff
Doesn't this make more sense and mesh much better with the already
existing custom diff driver?
(And yeah, maybe we could instead of "command=internal" just have the rule
that "internal" is the default, and you'd not have a command at all when
you want to run the internal diff.
Just an idea. I don't have any code.
Linus
^ permalink raw reply
* [PATCH] Disallow empty GIT_AUTHOR_NAME or GIT_COMMITTER_NAME
From: Brandon Casey @ 2007-07-06 17:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
Attempt normal methods for determining user name if
GIT_AUTHOR_NAME or GIT_COMMITTER_NAME is set to the empty
string. Then fall back to using the user login name.
Previously, if these environment variables were set to the
empty string, a message would be printed complaining about
missing gecos information. In this case the gecos information
was never checked.
This still allows an empty GIT_AUTHOR_EMAIL or GIT_COMMITTER_EMAIL.
Possibly someone would want to use these variables to disable
the respective email address string?
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
Trivial one-liner. I made this patch against master, not
on top of my previous patch. I assume this is the preferred way.
In case anyone is interested, I am submitting this using thunderbird
by the following method.
Set thunderbird config variables according to SubmittingPatches doc.
i.e.:
Compose messages in HTML format
mailnews.send_plaintext_flowed => false
mailnews.wraplength => 0
Then I send the patch to myself using git-format-patch and then
git-send-email. These two format the patch appropriately for
submission and allow me to set the message-id.
Then I select the message, right-click and choose "Edit As New...",
edit, select the recipients, and send. I also now have a record of
the sent message which I would not have if I used only git-send-email.
-brandon
ident.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/ident.c b/ident.c
index 3d49608..6932ccf 100644
--- a/ident.c
+++ b/ident.c
@@ -193,7 +193,7 @@ const char *fmt_ident(const char *name, const char *email,
int i;
setup_ident();
- if (!name)
+ if (!name || !*name)
name = git_default_name;
if (!email)
email = git_default_email;
--
1.5.3.rc0.30.g114f-dirty
^ permalink raw reply related
* [PATCH] git-submodule(1): update description and key names
From: Lars Hjemli @ 2007-07-06 17:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
When git-submodule was updated to allow mapping between submodule name and
submodule path, the documentation was left untouched.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
---
Documentation/git-submodule.txt | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index 7f0904e..e5a6c51 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -32,8 +32,8 @@ status::
init::
Initialize the submodules, i.e. register in .git/config each submodule
- path and url found in .gitmodules. The key used in git/config is
- `submodule.$path.url`. This command does not alter existing information
+ name and url found in .gitmodules. The key used in .git/config is
+ `submodule.$name.url`. This command does not alter existing information
in .git/config.
update::
@@ -64,7 +64,7 @@ FILES
When initializing submodules, a .gitmodules file in the top-level directory
of the containing repository is used to find the url of each submodule.
This file should be formatted in the same way as $GIR_DIR/config. The key
-to each submodule url is "module.$path.url".
+to each submodule url is "submodule.$name.url".
AUTHOR
--
1.5.2.2
^ permalink raw reply related
* Re: [PATCH] git-diff: don't use colors when stdout is not a tty.
From: Matthias Lederhofer @ 2007-07-06 16:37 UTC (permalink / raw)
To: Michel Marti; +Cc: git
In-Reply-To: <468E612E.2070903@objectxp.com>
Michel Marti <mma@objectxp.com> wrote:
> Currently, with diff-coloring enabled, git-diff outputs color escape
> sequences even if stdout is redirected (not a tty). This is rather annoying
> when trying to further process the output. This patch teaches the diff command
> to only do its coloring stuff when a pager is in use or stdout is a tty.
Set color.diff to auto instead of true.
^ permalink raw reply
* [PATCH] Deprecate git-cherry
From: Johannes Schindelin @ 2007-07-06 16:29 UTC (permalink / raw)
To: git, gitster
A cleaner alternative was introduced in v1.5.2~185^2~1, which not only
allows you to list the commits, but to inspect them, too:
git log --cherry-pick <upstream>...[<head>]
There is a functional difference, though: git cherry shows both
directions, <upstream>...<head> and <head>...<upstream>, and prefixes
the commits with '+' and '-', respectively.
'git rev-list --cherry-pick <upstream>...[<head>]' only shows one
direction, and does not prefix the commits.
However, in practice you are usually only interested in one direction
anyway (as seen in the cvsexportcommit example).
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
It might make sense to also allow "--cherry", since it is shorter
to type ;-)
Documentation/core-tutorial.txt | 4 ++--
Documentation/git-cherry.txt | 6 ++++++
Documentation/git-cvsexportcommit.txt | 2 +-
t/t3401-rebase-partial.sh | 2 +-
4 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/Documentation/core-tutorial.txt b/Documentation/core-tutorial.txt
index 4fb6f41..accd0dc 100644
--- a/Documentation/core-tutorial.txt
+++ b/Documentation/core-tutorial.txt
@@ -1571,8 +1571,8 @@ like this:
half of `git pull` but does not merge. The head of the
public repository is stored in `.git/refs/remotes/origin/master`.
-4. Use `git cherry origin` to see which ones of your patches
- were accepted, and/or use `git rebase origin` to port your
+4. Use `git log --cherry-pick origin...` to see which ones of your
+ patches were accepted, and/or use `git rebase origin` to port your
unmerged changes forward to the updated upstream.
5. Use `git format-patch origin` to prepare patches for e-mail
diff --git a/Documentation/git-cherry.txt b/Documentation/git-cherry.txt
index e694382..16e170f 100644
--- a/Documentation/git-cherry.txt
+++ b/Documentation/git-cherry.txt
@@ -11,6 +11,12 @@ SYNOPSIS
DESCRIPTION
-----------
+THIS COMMAND IS DEPRECATED:
+Use 'git rev-list --cherry-pick upstream...head' instead. This will
+display the commits that would have been prefixed with '+' by
+'git cherry upstream..head'. If you need the commits prefixed with '-',
+use 'git rev-list --cherry-pick head...upstream' instead.
+
The changeset (or "diff") of each commit between the fork-point and <head>
is compared against each commit between the fork-point and <upstream>.
diff --git a/Documentation/git-cvsexportcommit.txt b/Documentation/git-cvsexportcommit.txt
index 6c423e3..3055764 100644
--- a/Documentation/git-cvsexportcommit.txt
+++ b/Documentation/git-cvsexportcommit.txt
@@ -81,7 +81,7 @@ Merge pending patches into CVS automatically -- only if you really know what you
------------
$ export GIT_DIR=~/project/.git
$ cd ~/project_cvs_checkout
-$ git-cherry cvshead myhead | sed -n 's/^+ //p' | xargs -l1 git-cvsexportcommit -c -p -v
+$ git rev-list --cherry-pick cvshead...myhead | xargs -l1 git-cvsexportcommit -c -p -v
------------
Author
diff --git a/t/t3401-rebase-partial.sh b/t/t3401-rebase-partial.sh
index 4934a4e..6902737 100755
--- a/t/t3401-rebase-partial.sh
+++ b/t/t3401-rebase-partial.sh
@@ -43,7 +43,7 @@ test_expect_success \
'
test_debug \
- 'git cherry master &&
+ 'git log --cherry-pick master... &&
git format-patch -k --stdout --full-index master >/dev/null &&
gitk --all & sleep 1
'
^ permalink raw reply related
* Re: [PATCH] Prefer $EMAIL over auto-generated user@hostname.
From: Alex Riesen @ 2007-07-06 16:23 UTC (permalink / raw)
To: Vincent Hanquez
Cc: Brandon Casey, Johannes Schindelin, Uwe Kleine-König,
torvalds, gitster, mkraai, madcoder, git
In-Reply-To: <81b0412b0707060922sf0e3c17wcbd55dd65e1c1e14@mail.gmail.com>
On 7/6/07, Alex Riesen <raa.lkml@gmail.com> wrote:
> >
> > tab isn't 8 spaces. a tab is a tab.
>
> Of course. It is used to indent the text to the next position
> which multiple of 8.
>
Oh, damn... Sorry everyone, for that stupid mail.
I meant to answer only to Vincent.
^ permalink raw reply
* Re: [PATCH] Prefer $EMAIL over auto-generated user@hostname.
From: Alex Riesen @ 2007-07-06 16:22 UTC (permalink / raw)
To: Vincent Hanquez
Cc: Brandon Casey, Johannes Schindelin, Uwe Kleine-König,
torvalds, gitster, mkraai, madcoder, git
In-Reply-To: <20070706155902.GA17489@snarc.org>
On 7/6/07, Vincent Hanquez <tab@snarc.org> wrote:
> On Fri, Jul 06, 2007 at 05:59:19PM +0200, Alex Riesen wrote:
> > On 7/6/07, Brandon Casey <casey@nrlssc.navy.mil> wrote:
> > >
> > >Is the recommended tab stop 8 characters as it is for linux? or 4?
> > >
> >
> > Tab is always 8 spaces. It is indentation which can be 8, 4, 3, 2, and even
> > 1.
> > It is 8 in Git.
>
> tab isn't 8 spaces. a tab is a tab.
Of course. It is used to indent the text to the next position
which multiple of 8.
> It's usually *APPEARING* at 8 spaces. they *may* appears as a different
> size (to fit anyone preferences), as long as they stay as a tab (not
> expanded), and that nobody is aligning on tabs.
>
> => this way the how many spaces should indentation be has no meaning
> since everybody can choose it on their own terminal/display without
> setting any value across readers of the code.
The symbol in question, HT, is used to indent source in the project Git.
^ permalink raw reply
* Re: [PATCH] Prefer $EMAIL over auto-generated user@hostname.
From: Vincent Hanquez @ 2007-07-06 15:59 UTC (permalink / raw)
To: Alex Riesen
Cc: Brandon Casey, Johannes Schindelin, Uwe Kleine-König,
torvalds, gitster, mkraai, madcoder, git
In-Reply-To: <81b0412b0707060859u6a1c3a24p4399a71d84038615@mail.gmail.com>
On Fri, Jul 06, 2007 at 05:59:19PM +0200, Alex Riesen wrote:
> On 7/6/07, Brandon Casey <casey@nrlssc.navy.mil> wrote:
> >
> >Is the recommended tab stop 8 characters as it is for linux? or 4?
> >
>
> Tab is always 8 spaces. It is indentation which can be 8, 4, 3, 2, and even
> 1.
> It is 8 in Git.
tab isn't 8 spaces. a tab is a tab.
It's usually *APPEARING* at 8 spaces. they *may* appears as a different
size (to fit anyone preferences), as long as they stay as a tab (not
expanded), and that nobody is aligning on tabs.
=> this way the how many spaces should indentation be has no meaning
since everybody can choose it on their own terminal/display without
setting any value across readers of the code.
Cheers,
--
Vincent Hanquez
^ permalink raw reply
* [PATCH] Prefer $EMAIL over auto-generated user@hostname.
From: Brandon Casey @ 2007-07-06 16:14 UTC (permalink / raw)
To: Alex Riesen
Cc: Johannes Schindelin, Uwe Kleine-König, Linus Torvalds,
Junio C Hamano, mkraai, madcoder, Git Mailing List
This makes $EMAIL the second to last resort ahead of
username@hostname rather than the last resort when
GIT_AUTHOR_EMAIL or GIT_COMMITER_EMAIL and user.email
are not set.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
Alex Riesen wrote:
> On 7/6/07, Brandon Casey <casey@nrlssc.navy.mil> wrote:
>>
>> Is the recommended tab stop 8 characters as it is for linux? or 4?
>>
>
> Tab is always 8 spaces. It is indentation which can be 8, 4, 3, 2, and
> even 1.
> It is 8 in Git.
Here's an updated patch using tabs.
-brandon
ident.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/ident.c b/ident.c
index 3d49608..be5efcd 100644
--- a/ident.c
+++ b/ident.c
@@ -73,6 +73,7 @@ static void copy_email(const struct passwd *pw)
static void setup_ident(void)
{
struct passwd *pw = NULL;
+ char *email;
/* Get the name ("gecos") */
if (!git_default_name[0]) {
@@ -82,6 +83,9 @@ static void setup_ident(void)
copy_gecos(pw, git_default_name, sizeof(git_default_name));
}
+ if (!git_default_email[0] && (email = getenv("EMAIL")) != NULL)
+ strlcpy(git_default_email, email, sizeof(git_default_email));
+
if (!git_default_email[0]) {
if (!pw)
pw = getpwuid(getuid());
@@ -197,8 +201,6 @@ const char *fmt_ident(const char *name, const char *email,
name = git_default_name;
if (!email)
email = git_default_email;
- if (!email)
- email = getenv("EMAIL");
if (!*name) {
struct passwd *pw;
--
1.5.3.rc0.30.g114f-dirty
^ permalink raw reply related
* [PATCH] git-diff: don't use colors when stdout is not a tty.
From: Michel Marti @ 2007-07-06 15:35 UTC (permalink / raw)
To: Git Mailing List
Currently, with diff-coloring enabled, git-diff outputs color escape
sequences even if stdout is redirected (not a tty). This is rather annoying
when trying to further process the output. This patch teaches the diff command
to only do its coloring stuff when a pager is in use or stdout is a tty.
Signed-off-by: Michel Marti <mma@objectxp.com>
---
diff.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/diff.c b/diff.c
index 1958970..988e741 100644
--- a/diff.c
+++ b/diff.c
@@ -451,7 +451,7 @@ static void free_diff_words_data(struct emit_callback *ecbdata)
const char *diff_get_color(int diff_use_color, enum color_diff ix)
{
- if (diff_use_color)
+ if (diff_use_color && (pager_in_use || isatty(STDOUT_FILENO)))
return diff_colors[ix];
return "";
}
--
1.5.2.2
^ permalink raw reply related
* Re: [PATCH] Prefer $EMAIL over auto-generated user@hostname.
From: Alex Riesen @ 2007-07-06 15:59 UTC (permalink / raw)
To: Brandon Casey
Cc: Johannes Schindelin, Uwe Kleine-König, torvalds, gitster,
mkraai, madcoder, git
In-Reply-To: <468E64F9.9080805@nrlssc.navy.mil>
On 7/6/07, Brandon Casey <casey@nrlssc.navy.mil> wrote:
>
> Is the recommended tab stop 8 characters as it is for linux? or 4?
>
Tab is always 8 spaces. It is indentation which can be 8, 4, 3, 2, and even 1.
It is 8 in Git.
^ permalink raw reply
* Re: [PATCH] Prefer $EMAIL over auto-generated user@hostname.
From: Brandon Casey @ 2007-07-06 15:51 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Uwe Kleine-König, torvalds, gitster, mkraai, madcoder, git
In-Reply-To: <Pine.LNX.4.64.0707061631560.4093@racer.site>
Johannes Schindelin wrote:
> Hi,
>
> On Fri, 6 Jul 2007, Brandon Casey wrote:
>
>> Uwe Kleine-K?nig wrote:
>>> Hello Brandon,
>>>
>>> Brandon Casey wrote:
>>>> struct passwd *pw = NULL;
>>>> + char *email;
>>> Indention error. Otherwise it looks good (just from reading the patch).
>> huh. It doesn't look like that in my mail reader.
>> I have
>> struct passwd...
>> + char *email;
>>
>> and the patch applied cleanly when I saved the email and applied it
>> using git-am
>>
>> cat git_email.patch | git-am
>
> Yes, it applies cleanly. But it has 8 spaces before "char *email", not a
> tab (otherwise it would be lined up with "struct passwd").
Ahh. I have expandtab set in .vimrc
This wouldn't happen to be part of the war on white space? converting
spaces to tabs where applicable?
Is the recommended tab stop 8 characters as it is for linux? or 4?
-brandon
^ permalink raw reply
* Re: [PATCH] Prefer $EMAIL over auto-generated user@hostname.
From: Johannes Schindelin @ 2007-07-06 15:32 UTC (permalink / raw)
To: Brandon Casey
Cc: Uwe Kleine-König, torvalds, gitster, mkraai, madcoder, git
In-Reply-To: <468E5E31.8040504@nrlssc.navy.mil>
Hi,
On Fri, 6 Jul 2007, Brandon Casey wrote:
> Uwe Kleine-K?nig wrote:
> > Hello Brandon,
> >
> > Brandon Casey wrote:
> >> struct passwd *pw = NULL;
> >> + char *email;
> > Indention error. Otherwise it looks good (just from reading the patch).
>
> huh. It doesn't look like that in my mail reader.
> I have
> struct passwd...
> + char *email;
>
> and the patch applied cleanly when I saved the email and applied it
> using git-am
>
> cat git_email.patch | git-am
Yes, it applies cleanly. But it has 8 spaces before "char *email", not a
tab (otherwise it would be lined up with "struct passwd").
Hth,
Dscho
^ permalink raw reply
* Re: [PATCH] Prefer $EMAIL over auto-generated user@hostname.
From: Brandon Casey @ 2007-07-06 15:22 UTC (permalink / raw)
To: Uwe Kleine-König, Brandon Casey, torvalds, gitster, mkraai,
madcoder, git
In-Reply-To: <20070706151145.GA15341@informatik.uni-freiburg.de>
Uwe Kleine-König wrote:
> Hello Brandon,
>
> Brandon Casey wrote:
>> struct passwd *pw = NULL;
>> + char *email;
> Indention error. Otherwise it looks good (just from reading the patch).
huh. It doesn't look like that in my mail reader.
I have
struct passwd...
+ char *email;
and the patch applied cleanly when I saved the email and applied it
using git-am
cat git_email.patch | git-am
-brandon
^ permalink raw reply
* git-diff memory/speed/disk impacts (was: being nice to patch(1))
From: David Kastrup @ 2007-07-06 15:22 UTC (permalink / raw)
To: git
In-Reply-To: <86644xd7wr.fsf@lola.quinscape.zz>
Some more experiments:
David Kastrup <dak@gnu.org> writes:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>>> > >
>>> > > I guess the second choice generally isn't an option, but dammit,
>>> > > "git-apply" really is the better program here.
>>> >
>>> > Why not? git-apply works outside of a git repo ;-)
>>>
>>> I was more thinking that people are not necessarily willing to install git
>>> just to get the "git-apply" program..
>>
>> But maybe they would be willing to install git to get that wonderful
>> git-apply program, and that wonderful rename-and-mode-aware
>> git-diff, and the git-merge-file program, all of which can operate
>> outside of a git repository. (Take that, hg!)
>
> Well, hmph! I just rewrote my git-diff-using script to not check
> stuff into a throw-away git repository, and guess what: with real-life
> use cases (diffing trees of about 500MB size), git-diff runs out of
> memory (the machine probably has something like 1.5GB of virtual memory
> size) when operating outside of a git repository.
>
> So the usefulness still seems limited, even now that the output format
> of --name-status has been fixed.
>
> Any idea whether this is a bug, sloppy programming, or an inherent
> restriction/necessity?
>
> Also an idea which of the following scenarios would be best for
> catching all of moves/renames/deletes/adds? Note: any repository is
> strictly throw-away.
>
> Experiments are somewhat time-consuming, so every hunch helps.
>
> a) diff directories outside of git (works, but fatal memory footprint
> for large cases)
> b) diff index against work directory
fatal memory footprint
> c) diff revision against work directory
fatal memory footprint
> d) diff revision against index
does not detect copies/renames
> e) diff revision against revision (works, but high disk footprint and
> likely slower than alternatives)
So it seems like option e) is the only feasible option. In the total
numbers, git-add is by far the slowest operation, followed by
git-commit. git-diff on revisions is quite fast and with moderate
memory footprint.
Committing itself does not seem to add much disk space: adding into
the index seems to be the main disk space allocation.
So while the behavior of d) appears puzzling, doing another commit
before the diff is cheap, so the motivation for asking people to find
out the problems with d) is low for me.
Somewhat dissatisfactory that rewriting my script for using the
repository-less variant of git-diff fails for seriously large use
cases due to out-of-memory conditions.
I suppose that's life.
--
David Kastrup
^ permalink raw reply
* Re: [PATCH] Fix guilt to work correctly even if the refs are packed
From: Josef Sipek @ 2007-07-06 15:12 UTC (permalink / raw)
To: Theodore Ts'o; +Cc: git
In-Reply-To: <E1I6pF5-0003V9-2R@candygram.thunk.org>
On Fri, Jul 06, 2007 at 10:57:07AM -0400, Theodore Ts'o wrote:
>
> Explicitly referencing .git/refs/heads/$branch is bad; use git
> show-ref -h instead.
Applied, I fixed up the commit message; you say -h but the code used -s.
Thanks.
Josef "Jeff" Sipek.
--
If I have trouble installing Linux, something is wrong. Very wrong.
- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] Prefer $EMAIL over auto-generated user@hostname.
From: Uwe Kleine-König @ 2007-07-06 15:11 UTC (permalink / raw)
To: Brandon Casey; +Cc: torvalds, gitster, mkraai, madcoder, git
In-Reply-To: <468E59B3.7080007@nrlssc.navy.mil>
Hello Brandon,
Brandon Casey wrote:
> struct passwd *pw = NULL;
> + char *email;
Indention error. Otherwise it looks good (just from reading the patch).
Best regards
Uwe
--
Uwe Kleine-König
Set the I_WANT_A_BROKEN_PS environment variable to force BSD syntax ...
-- manpage of procps
^ permalink raw reply
* Re: Cherry-picking to remote branches
From: Sean Kelley @ 2007-07-06 15:10 UTC (permalink / raw)
To: VMiklos; +Cc: Johannes Schindelin, git
In-Reply-To: <20070706150155.GV32766@genesis.frugalware.org>
Hi,
On 7/6/07, VMiklos <vmiklos@frugalware.org> wrote:
> Na Fri, Jul 06, 2007 at 09:39:47AM -0500, Sean Kelley <svk.sweng@gmail.com> pisal(a):
> >> > git checkout -b stable linux-stable/master
> >> >
> >> > git cherry-pick b3b1eea69a (a commit from linux-devel)
> >> >
> >> > git push linux-stable
> >> >
> >> > error: remote 'refs/heads/master' is not a strict subset of local ref
> >> > 'refs/heads/master'. maybe you are not up-to-date and need to pull
> >> > first?
> >> > error: failed to push to 'git://mysite.com/data/git/linux-stable.git'
> >>
> >> Since you are obviously only interested in pushing the stable branch, why
> >> don't you
> >>
> >> git push linux-stable stable
> >>
> >> Hm?
> >>
> >> If you do not specify which branches to push, "git push" will find all
> >> refnames which are present both locally and remotely, and push those.
> >> Evidently, however, your local "master" disagrees with the remote
> >> "master".
> >
> > It is not entirely clear to me from the documentation. So I was
> > trying to cobble together something that seemed to make sense. I want
> > to work from the devel clone. On occasion I want to cherry-pick
> > changesets and push those to the stable branch. I don't want
> > everything that goes into devel to go into stable.
>
> what about this?
>
> git push linux-stable stable:master
That creates a new head on my remote server. Where as I wanted to
push to the remotes head.
Sean
>
> VMiklos
>
> --
> developer of Frugalware Linux - http://frugalware.org
>
>
^ permalink raw reply
* [PATCH] Prefer $EMAIL over auto-generated user@hostname.
From: Brandon Casey @ 2007-07-06 15:03 UTC (permalink / raw)
To: torvalds, gitster; +Cc: mkraai, madcoder, git
This makes $EMAIL the second to last resort ahead of
username@hostname rather than the last resort when
GIT_AUTHOR_EMAIL or GIT_COMMITER_EMAIL and user.email
are not set.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
Linus Torvalds wrote:
>If you want it to prefer $EMAIL, you'd need to change the initialization
>of git_default_email, methinks.
How about this?
ident.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/ident.c b/ident.c
index 3d49608..dc13510 100644
--- a/ident.c
+++ b/ident.c
@@ -73,6 +73,7 @@ static void copy_email(const struct passwd *pw)
static void setup_ident(void)
{
struct passwd *pw = NULL;
+ char *email;
/* Get the name ("gecos") */
if (!git_default_name[0]) {
@@ -82,6 +83,9 @@ static void setup_ident(void)
copy_gecos(pw, git_default_name, sizeof(git_default_name));
}
+ if (!git_default_email[0] && (email = getenv("EMAIL")) != NULL)
+ strlcpy(git_default_email, email, sizeof(git_default_email));
+
if (!git_default_email[0]) {
if (!pw)
pw = getpwuid(getuid());
@@ -197,8 +201,6 @@ const char *fmt_ident(const char *name, const char *email,
name = git_default_name;
if (!email)
email = git_default_email;
- if (!email)
- email = getenv("EMAIL");
if (!*name) {
struct passwd *pw;
--
1.5.3.rc0.30.g114f-dirty
^ permalink raw reply related
* Re: Email address from username and hostname preferred over $EMAIL
From: Brandon Casey @ 2007-07-06 15:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, mkraai, git
In-Reply-To: <7vir8yib4d.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Brandon Casey <casey@nrlssc.navy.mil> writes:
> Are Brandon Casey and Matt Kraai the same person?
heh, no. :) I see now that my patch did not make it. I tried
to use git-send-email on my system and it successfully delivered
to my imap mailbox, but failed delivering to the other recipients.
> I do not mind threadedness of the patch too much
ok.
> , but the patch
> recently posted by the latter does not have any description
> other than the title.
>
> Other than that, I think the change itself seems sane.
I'll go ahead and post my patch again since I think it is a
little simpler and I like it better (imagine that :)
But it's such a simple fix it will be just an exercise for me.
-brandon
^ permalink raw reply
* Re: Cherry-picking to remote branches
From: VMiklos @ 2007-07-06 15:01 UTC (permalink / raw)
To: Sean Kelley; +Cc: Johannes Schindelin, git
In-Reply-To: <a2e879e50707060739s4c8e751dj494618d3d545277b@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1346 bytes --]
Na Fri, Jul 06, 2007 at 09:39:47AM -0500, Sean Kelley <svk.sweng@gmail.com> pisal(a):
>> > git checkout -b stable linux-stable/master
>> >
>> > git cherry-pick b3b1eea69a (a commit from linux-devel)
>> >
>> > git push linux-stable
>> >
>> > error: remote 'refs/heads/master' is not a strict subset of local ref
>> > 'refs/heads/master'. maybe you are not up-to-date and need to pull
>> > first?
>> > error: failed to push to 'git://mysite.com/data/git/linux-stable.git'
>>
>> Since you are obviously only interested in pushing the stable branch, why
>> don't you
>>
>> git push linux-stable stable
>>
>> Hm?
>>
>> If you do not specify which branches to push, "git push" will find all
>> refnames which are present both locally and remotely, and push those.
>> Evidently, however, your local "master" disagrees with the remote
>> "master".
>
> It is not entirely clear to me from the documentation. So I was
> trying to cobble together something that seemed to make sense. I want
> to work from the devel clone. On occasion I want to cherry-pick
> changesets and push those to the stable branch. I don't want
> everything that goes into devel to go into stable.
what about this?
git push linux-stable stable:master
VMiklos
--
developer of Frugalware Linux - http://frugalware.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ 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