* Re: Mark Levedahl's gitk patches
From: Junio C Hamano @ 2007-06-27 0:41 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Mark Levedahl, Johannes Sixt, git
In-Reply-To: <18048.36797.283166.952377@cargo.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> writes:
> Mark Levedahl writes:
>
>> I found a bug in the highlight patch (the color picker updated the wrong
>> panel in the chooser but did set the correct color), and updated the
>> tab-stop patch to use a spin control to enforce entry of small integers
>> only. As there is possible interest, I am sending the amended series.
>
> Ah. I just pushed out a pile of patches to gitk.git including your
> three. Could you do an incremental patch on top of that for me?
I took a look at differences between your gitk.git and what I
have. It appears that our "proc readrefs" differ a bit.
Most notably, the global hash tagcontents is read when readrefs
run in the version I have, while gitk.git version fills it
lazily in showtag, where it is actually used. Because you read
the refs using "show-ref -d", you do not need to do extra forks
to figure out the objects referred to by the tags in your code.
I think what you have is a lot better from interactive latency
point of view. I'll take the version from gitk.git and push the
results out.
^ permalink raw reply
* Re: [PATCH] Ignore submodule commits when fetching over dumb protocols
From: Junio C Hamano @ 2007-06-27 0:41 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Sven Verdoolaege, git
In-Reply-To: <alpine.LFD.0.98.0706261434540.8675@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
>
> This should probably be put in the maintenance branch, since I think we've
> tried to make sure that the current 1.5.x series plumbing can handle
> superproject data even if it doesn't then have the porcelain to make it
> all easy..
Thanks, both.
^ permalink raw reply
* Re: GIT + CVS workflow query.
From: Junio C Hamano @ 2007-06-27 0:36 UTC (permalink / raw)
To: Eoin Hennessy; +Cc: git
In-Reply-To: <47281e410706261520r5b3549c7t39d93924d0a8ceea@mail.gmail.com>
"Eoin Hennessy" <eoin.hennessy@gmail.com> writes:
> I'd like to use GIT to track changes in a CVS repository. As well as
> tracking changes, I will also need to push patches back to CVS from
> GIT. My workflow is currently as follows:
>
> - Use git-cvsimport to import and update a mirror of the CVS
> repository; 'project.git'.
> - Pull changes from the mirror to a cloned working copy; 'project'.
> - Fix bugs in the working copy and push commits back to the mirror.
Fix bugs, yes, but push back to the mirror is probably not what
you want.
> - Use git-cherry to identify commits in master not currently in the
> branch updated by git-cvsimport. Then use git-cvsexportcommit to push
> these commits into a CVS checkout.
What I do with my day-job project is that I keep a separate CVS
checkout like you do, and
- cvsimport keeps track of the "project.git" mirror as you do;
- pull changes from that to my "project" as you do (but see below);
- fix things in "project", as you do;
- identify the needed changes with 'git-cherry' as you do;
- exportcommit to push them back to CVS through the CVS checkout;
Then the next cvsimport will get my changes (among other
people's changes) to "project.git".
- fetch changes from the "project.git" to my "project";
- 'git-rebase' my changes on top of the tip of "project.git";
This will remove the duplicates that I had but now are in CVS.
^ permalink raw reply
* Re: Darcs
From: Martin Langhoff @ 2007-06-27 0:00 UTC (permalink / raw)
To: Dan Chokola; +Cc: Linus Torvalds, Junio C Hamano, Bu Bacoo, git
In-Reply-To: <61e816970706242144y5dd07464ue6b06478a5920699@mail.gmail.com>
On 6/25/07, Dan Chokola <dan@chokola.com> wrote:
> So, relating back to the original post, and extending on Linus'
> 'academic' analogy, Darcs is like a thesis project from university
> that proves how DSCM can be done scientifically. Git is grown-up Darcs
> that proves how DSCM can be done practically.
I don't think it's like that. More like
- BK showed it's done
- Darcs picked some good bits from BK (while no other foss dscm did
until git/hg/bzr came along) but got distracted with interesting but
not-that-useful stuff - see patch algebra.
cheers,
m
^ permalink raw reply
* [PATCH] cleanup merge-base test script
From: Sam Vilain @ 2007-06-26 23:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Sam Vilain
Add a picture, and keep the setup and the tests together.
Signed-off-by: Sam Vilain <sam.vilain@catalyst.net.nz>
---
t/t6010-merge-base.sh | 30 ++++++++++++++++++------------
1 files changed, 18 insertions(+), 12 deletions(-)
diff --git a/t/t6010-merge-base.sh b/t/t6010-merge-base.sh
index b15920b..22e0893 100755
--- a/t/t6010-merge-base.sh
+++ b/t/t6010-merge-base.sh
@@ -34,6 +34,12 @@ doit() {
echo $commit
}
+# E---D---C---B---A
+# \'-_ \ \
+# \ `---------G \
+# \ \
+# F----------------H
+
# Setup...
E=$(doit 5 E)
D=$(doit 4 D $E)
@@ -44,6 +50,18 @@ A=$(doit 1 A $B)
G=$(doit 7 G $B $E)
H=$(doit 8 H $A $F)
+test_expect_success 'compute merge-base (single)' \
+ 'MB=$(git-merge-base G H) &&
+ expr "$(git-name-rev "$MB")" : "[0-9a-f]* tags/B"'
+
+test_expect_success 'compute merge-base (all)' \
+ 'MB=$(git-merge-base --all G H) &&
+ expr "$(git-name-rev "$MB")" : "[0-9a-f]* tags/B"'
+
+test_expect_success 'compute merge-base with show-branch' \
+ 'MB=$(git-show-branch --merge-base G H) &&
+ expr "$(git-name-rev "$MB")" : "[0-9a-f]* tags/B"'
+
# Setup for second test to demonstrate that relying on timestamps in a
# distributed SCM to provide a _consistent_ partial ordering of commits
# leads to insanity.
@@ -82,18 +100,6 @@ PL=$(doit 4 PL $L2 $C2)
PR=$(doit 4 PR $C2 $R2)
test_expect_success 'compute merge-base (single)' \
- 'MB=$(git-merge-base G H) &&
- expr "$(git-name-rev "$MB")" : "[0-9a-f]* tags/B"'
-
-test_expect_success 'compute merge-base (all)' \
- 'MB=$(git-merge-base --all G H) &&
- expr "$(git-name-rev "$MB")" : "[0-9a-f]* tags/B"'
-
-test_expect_success 'compute merge-base with show-branch' \
- 'MB=$(git-show-branch --merge-base G H) &&
- expr "$(git-name-rev "$MB")" : "[0-9a-f]* tags/B"'
-
-test_expect_success 'compute merge-base (single)' \
'MB=$(git-merge-base PL PR) &&
expr "$(git-name-rev "$MB")" : "[0-9a-f]* tags/C2"'
--
1.5.2.1.1131.g3b90
^ permalink raw reply related
* [PATCH] git-submodule: Instead of using only annotated tags, use any tag found in .git/refs/tags
From: Emil Medve @ 2007-06-26 23:40 UTC (permalink / raw)
To: git; +Cc: Emil Medve
Some repositories might not use/have annotated tags (for example repositories created with
git-cvsimport) and git-submodule status might fail because git-describe might fail to find a tag.
This change allows the status of a submodule to be described/displayed relative to lightweight tags
as well.
Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com>
---
git-submodule.sh | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index 89a3885..56ea935 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -155,7 +155,7 @@ modules_list()
say "-$sha1 $path"
continue;
fi
- revname=$(unset GIT_DIR && cd "$path" && git-describe $sha1)
+ revname=$(unset GIT_DIR && cd "$path" && git-describe --tags $sha1)
if git diff-files --quiet -- "$path"
then
say " $sha1 $path ($revname)"
@@ -163,7 +163,7 @@ modules_list()
if test -z "$cached"
then
sha1=$(unset GIT_DIR && cd "$path" && git-rev-parse --verify HEAD)
- revname=$(unset GIT_DIR && cd "$path" && git-describe $sha1)
+ revname=$(unset GIT_DIR && cd "$path" && git-describe --tags $sha1)
fi
say "+$sha1 $path ($revname)"
fi
--
1.5.2.2.549.gaeb59
^ permalink raw reply related
* [PATCH] git-send-email: Add --threaded option
From: Adam Roben @ 2007-06-26 22:57 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Adam Roben
The --threaded option controls whether the In-Reply-To header will be set on
any emails sent. The current behavior is to always set this header, so this
option is most useful in its negated form, --no-threaded. This behavior can
also be controlled through the 'sendemail.threaded' config setting.
Signed-off-by: Adam Roben <aroben@apple.com>
---
Documentation/git-send-email.txt | 7 +++++++
git-send-email.perl | 25 ++++++++++++++++++-------
2 files changed, 25 insertions(+), 7 deletions(-)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index 946bd76..1f5d57d 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -86,6 +86,13 @@ The --cc option must be repeated for each user you want on the cc list.
Do not add the From: address to the cc: list, if it shows up in a From:
line.
+--threaded, --no-threaded::
+ If this is set, the In-Reply-To header will be set on each email sent.
+ If disabled with "--no-threaded", no emails will have the In-Reply-To
+ header set.
+ Default is the value of the 'sendemail.threaded' configuration value;
+ if that is unspecified, default to --threaded.
+
--dry-run::
Do everything except actually send the emails.
diff --git a/git-send-email.perl b/git-send-email.perl
index 9f75551..b8b8fe7 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -74,6 +74,9 @@ Options:
--suppress-from Suppress sending emails to yourself if your address
appears in a From: line.
+ --threaded Specify that the "In-Reply-To:" header should be set on all
+ emails. Defaults to on.
+
--quiet Make git-send-email less verbose. One line per email
should be all that is output.
@@ -138,8 +141,8 @@ my (@to,@cc,@initial_cc,@bcclist,@xh,
$initial_reply_to,$initial_subject,@files,$from,$compose,$time);
# Behavior modification variables
-my ($chain_reply_to, $quiet, $suppress_from, $no_signed_off_cc,
- $dry_run) = (1, 0, 0, 0, 0);
+my ($threaded, $chain_reply_to, $quiet, $suppress_from, $no_signed_off_cc,
+ $dry_run) = (1, 1, 0, 0, 0, 0);
my $smtp_server;
my $envelope_sender;
@@ -154,9 +157,16 @@ if ($@) {
$term = new FakeTerm "$@: going non-interactive";
}
-my $def_chain = $repo->config_bool('sendemail.chainreplyto');
-if (defined $def_chain and not $def_chain) {
- $chain_reply_to = 0;
+my %config_settings = (
+ "threaded" => \$threaded,
+ "chainreplyto" => \$chain_reply_to,
+);
+
+foreach my $setting (keys %config_settings) {
+ my $default = $repo->config_bool("sendemail.$setting");
+ if (defined $default) {
+ $config_settings{$setting} = $default ? 1 : 0;
+ }
}
@bcclist = $repo->config('sendemail.bcc');
@@ -181,6 +191,7 @@ my $rc = GetOptions("from=s" => \$from,
"no-signed-off-cc|no-signed-off-by-cc" => \$no_signed_off_cc,
"dry-run" => \$dry_run,
"envelope-sender=s" => \$envelope_sender,
+ "threaded!" => \$threaded,
);
unless ($rc) {
@@ -287,7 +298,7 @@ if (!defined $initial_subject && $compose) {
$prompting++;
}
-if (!defined $initial_reply_to && $prompting) {
+if ($threaded && !defined $initial_reply_to && $prompting) {
do {
$_= $term->readline("Message-ID to be used as In-Reply-To for the first email? ",
$initial_reply_to);
@@ -484,7 +495,7 @@ Date: $date
Message-Id: $message_id
X-Mailer: git-send-email $gitversion
";
- if ($reply_to) {
+ if ($threaded && $reply_to) {
$header .= "In-Reply-To: $reply_to\n";
$header .= "References: $references\n";
--
1.5.2.2.549.gaeb59-dirty
^ permalink raw reply related
* [PATCH] git-send-email: Add --threaded option
From: Adam Roben @ 2007-06-26 22:48 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Adam Roben
The --threaded option controls whether the In-Reply-To header will be set on
any emails sent. The current behavior is to always set this header, so this
option is most useful in its negated form, --no-threaded. This behavior can
also be controlled through the 'sendemail.threaded' config setting.
Signed-off-by: Adam Roben <aroben@apple.com>
---
Documentation/git-send-email.txt | 7 +++++++
git-send-email.perl | 25 ++++++++++++++++++-------
2 files changed, 25 insertions(+), 7 deletions(-)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index 946bd76..1f5d57d 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -86,6 +86,13 @@ The --cc option must be repeated for each user you want on the cc list.
Do not add the From: address to the cc: list, if it shows up in a From:
line.
+--threaded, --no-threaded::
+ If this is set, the In-Reply-To header will be set on each email sent.
+ If disabled with "--no-threaded", no emails will have the In-Reply-To
+ header set.
+ Default is the value of the 'sendemail.threaded' configuration value;
+ if that is unspecified, default to --threaded.
+
--dry-run::
Do everything except actually send the emails.
diff --git a/git-send-email.perl b/git-send-email.perl
index 9f75551..b8b8fe7 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -74,6 +74,9 @@ Options:
--suppress-from Suppress sending emails to yourself if your address
appears in a From: line.
+ --threaded Specify that the "In-Reply-To:" header should be set on all
+ emails. Defaults to on.
+
--quiet Make git-send-email less verbose. One line per email
should be all that is output.
@@ -138,8 +141,8 @@ my (@to,@cc,@initial_cc,@bcclist,@xh,
$initial_reply_to,$initial_subject,@files,$from,$compose,$time);
# Behavior modification variables
-my ($chain_reply_to, $quiet, $suppress_from, $no_signed_off_cc,
- $dry_run) = (1, 0, 0, 0, 0);
+my ($threaded, $chain_reply_to, $quiet, $suppress_from, $no_signed_off_cc,
+ $dry_run) = (1, 1, 0, 0, 0, 0);
my $smtp_server;
my $envelope_sender;
@@ -154,9 +157,16 @@ if ($@) {
$term = new FakeTerm "$@: going non-interactive";
}
-my $def_chain = $repo->config_bool('sendemail.chainreplyto');
-if (defined $def_chain and not $def_chain) {
- $chain_reply_to = 0;
+my %config_settings = (
+ "threaded" => \$threaded,
+ "chainreplyto" => \$chain_reply_to,
+);
+
+foreach my $setting (keys %config_settings) {
+ my $default = $repo->config_bool("sendemail.$setting");
+ if (defined $default) {
+ $config_settings{$setting} = $default ? 1 : 0;
+ }
}
@bcclist = $repo->config('sendemail.bcc');
@@ -181,6 +191,7 @@ my $rc = GetOptions("from=s" => \$from,
"no-signed-off-cc|no-signed-off-by-cc" => \$no_signed_off_cc,
"dry-run" => \$dry_run,
"envelope-sender=s" => \$envelope_sender,
+ "threaded!" => \$threaded,
);
unless ($rc) {
@@ -287,7 +298,7 @@ if (!defined $initial_subject && $compose) {
$prompting++;
}
-if (!defined $initial_reply_to && $prompting) {
+if ($threaded && !defined $initial_reply_to && $prompting) {
do {
$_= $term->readline("Message-ID to be used as In-Reply-To for the first email? ",
$initial_reply_to);
@@ -484,7 +495,7 @@ Date: $date
Message-Id: $message_id
X-Mailer: git-send-email $gitversion
";
- if ($reply_to) {
+ if ($threaded && $reply_to) {
$header .= "In-Reply-To: $reply_to\n";
$header .= "References: $references\n";
--
1.5.2.2.549.gaeb59-dirty
^ permalink raw reply related
* Re: GIT + CVS workflow query.
From: Yann Dirson @ 2007-06-26 22:46 UTC (permalink / raw)
To: Eoin Hennessy; +Cc: git
In-Reply-To: <47281e410706261520r5b3549c7t39d93924d0a8ceea@mail.gmail.com>
On Tue, Jun 26, 2007 at 11:20:24PM +0100, Eoin Hennessy wrote:
> Hi there,
>
> I'd like to use GIT to track changes in a CVS repository. As well as
> tracking changes, I will also need to push patches back to CVS from
> GIT. My workflow is currently as follows:
I have done a similar thing for some time, with some differences.
> - Use git-cvsimport to import and update a mirror of the CVS
> repository; 'project.git'.
> - Pull changes from the mirror to a cloned working copy; 'project'.
> - Fix bugs in the working copy
Yes.
> and push commits back to the mirror.
No, the mirror should solely be a mirror of cvs. If you de-sync your
mirror, you're looking for trouble.
> - Use git-cherry to identify commits in master not currently in the
> branch updated by git-cvsimport. Then use git-cvsexportcommit to push
> these commits into a CVS checkout.
Rather, the patches you have not committed yet are simply
remotes/origin/master..master. What I did was simply
git-cvsexportcommit'ing them to my "CVS gateway checkout".
In the next iteration, cvsps will identify your commits as patchsets,
and what I did was registering the "merge to cvs" with an info/grafts
entry. Nowaday, I would rather have my local commits in an stgit
stack, and "stg pull" would take care of detecting the merged patches
(not to mention that uncommitted patches would trivially map to stgit
patches).
But I occasionally had problems of cvs patches missed by the import,
and other issues because of cvsps not being able to cope with branches
created by cvs 1.12 (which is why I changed my workflow and wrote
stg-cvs, which in turn needs to be replaced).
Hope this helps,
--
Yann
^ permalink raw reply
* Re: [PATCH] git-rev-list: give better diagnostic for failed write
From: Linus Torvalds @ 2007-06-26 22:32 UTC (permalink / raw)
To: Theodore Tso; +Cc: Jim Meyering, git
In-Reply-To: <20070626220440.GB27828@thunk.org>
On Tue, 26 Jun 2007, Theodore Tso wrote:
> On Tue, Jun 26, 2007 at 10:32:23AM -0700, Linus Torvalds wrote:
> > But we actually _do_ want fully buffered from a performance angle.
> > Especially for the big stuff, which is usually the *diffs*, not the commit
> > messages. Not so much an issue with git-rev-list, but with "git log -p"
> > you would normally not want it line-buffered, and it's actually much nicer
> > to let it be fully buffered and then do a flush at the end.
>
> Well, sometimes we do and sometimes we don't right?
No.
We basically _never_ want "line buffered" or "unbuffered", which is what
stdio knows how to do. That sucks in _all_ cases.
What we want is "fully buffered" for plain files, and "record buffered"
for anything else (where a "record" is basically the "commit + optional
diff").
We can get the record buffered by adding the fflush() calls, but the thing
is, we'd want to _avoid_ that if it was a file. It's just that there is no
way to set that kind of flag portably with stdio, we'd have to carry it
around _separately_ from stdio, which is a big pain.
But if we decide that this only matters with stdout (which currently is
what the patches have done), we could of course just make it a single
global variable (like "stdout" itself already is). Then we could just make
git.c start out by testing stdout at startup and setting the global
variable.
Linus
^ permalink raw reply
* Re: [StGIT RFC] Changing patch@branch syntax
From: Yann Dirson @ 2007-06-26 22:31 UTC (permalink / raw)
To: Catalin Marinas; +Cc: GIT list
In-Reply-To: <b0943d9e0706251522s6baf7997r48beae7f57681d77@mail.gmail.com>
On Mon, Jun 25, 2007 at 11:22:15PM +0100, Catalin Marinas wrote:
> >I have often wondered if it would be useful to have a given
> >patch@stack as a base for another stack, or maybe as one of the
> >"heads" of an hydra. Still not sure it would make any sense, however
> >- especially, proper use of hydras would possibly suppress the need
> >for the former.
>
> There are situations when I want a separate branch but it relies on
> patches in other branches. I currently duplicate the patches and use
> the 'sync' command to keep them up to date (though this command would
> be more useful with support for git-rerere to avoid fixing the same
> conflict several times).
>
> Can a patch series be part of multiple pools? This would be useful to
> my workflow.
In the current prototype, yes, since the current "hydra" object only
binds existing stacks. In the design we've discussed, not directly -
let's find a solution.
My idea of what we've discussed most recently is that stackables will
be *contained* in patchsets. Ie. a pool will be able to contain both
patches-as-we-know-them, and stacks, but those stacks won't be git
heads, only refs in a namespace still to be decided upon - something
similar to how we currently store patch refs.
To allow sharing a stack between several pools, I can see 2 options.
The easiest to implement (but not necessarily the easiest to live
with) is to clone and sync the stack.
Another one is to add another Stackable subclass (eg. StackableLink),
that would figure some sort of symbolic link to the reference
Stackable. It would provide in the current patchset a local name for
the linked Stackable, but may need to be more than a simple alias: a
pool is, at least for now, an octopus, and thus only supports
conflict-less members; thus, if the linked Stackable changes to be
incompatible with the link siblings, the patchset containing the
conflict would instantly become invalid. Either we add support for
this "invalidated" status, or we find a better way. One possibility I
thought of, is that the link will point a specific version of its
referenced stackable (a point always reachable from new versions of
the referenced stackable through its patch/ref/stack/whatever-log),
and the user will need to explicitely stg-pull to get the new version,
with the option to "pull --undo" if he does not like it.
All these options leave room for innovative workflows :)
> >In current StGIT, in cases where
> >"name" matches both a local patch a git ref... well, we can still ask
> >for refs/heads/name as fully-qualified name - looks like I had
> >forgotten that one ;)
>
> StGIT could default to patches and fall back to git commits if no ":"
> are found in the name.
I'd rather leave this fallback to the minimum (esp. if only "show" and
"pick" can make sense out of it).
> >I consider we have a couple of special cases:
> >
> > clean currently does not care, but see task #5235
> > rebase currently only needs patchets, do we need to extend that to
> > patches ?
>
> 'rebase' could only work on the current patchset because of the
> possibility of getting conflicts during push (unless you implement the
> branch switching as well).
That's not what I was thinking about. I was mentionning the
possibility to rebase to a given patch, so "pull" will follow later
versions of that patch. Not sure it is useful, though, and it can
probably already be done by rebasing to refs/patches/<branch>/<patch>
(although that accesses implementation details, that rebasing to
<branch>:<patch> would not need to).
> > new creates a patch in the current stack, we may want to unify
> > this with "branch -c" in some way (maybe "stg
> > (patch|stack|pool) new" ?)
>
> This might be a possibility once we refactor the command line.
Right - that was subliminally suggesting to refactor the command-line
before 1.0, in fact ;)
> >> Also, shourt stgit/git.py be aware of the repository?
> >
> >I'd rather think that we should have git.Repository (and further
> >structurate git.py with more objects, like git.Branch), with
> >stgit-specific stuff in the stgit.Repository subclass.
>
> Sounds good.
Cool.
Best regards,
--
Yann
^ permalink raw reply
* GIT + CVS workflow query.
From: Eoin Hennessy @ 2007-06-26 22:20 UTC (permalink / raw)
To: git
Hi there,
I'd like to use GIT to track changes in a CVS repository. As well as
tracking changes, I will also need to push patches back to CVS from
GIT. My workflow is currently as follows:
- Use git-cvsimport to import and update a mirror of the CVS
repository; 'project.git'.
- Pull changes from the mirror to a cloned working copy; 'project'.
- Fix bugs in the working copy and push commits back to the mirror.
- Use git-cherry to identify commits in master not currently in the
branch updated by git-cvsimport. Then use git-cvsexportcommit to push
these commits into a CVS checkout.
My question is; as a next step in the workflow, should I be applying
the list of commits identified by git-cherry to the branch updated by
git-cvsimport? How else does one clear this list so that they do not
interfere with the next iteration of the workflow.
I hope I've been clear, and thanks for any suggestions.
^ permalink raw reply
* Re: [PATCH] git-rev-list: give better diagnostic for failed write
From: Theodore Tso @ 2007-06-26 22:04 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jim Meyering, git
In-Reply-To: <alpine.LFD.0.98.0706261024210.8675@woody.linux-foundation.org>
On Tue, Jun 26, 2007 at 10:32:23AM -0700, Linus Torvalds wrote:
> But we actually _do_ want fully buffered from a performance angle.
> Especially for the big stuff, which is usually the *diffs*, not the commit
> messages. Not so much an issue with git-rev-list, but with "git log -p"
> you would normally not want it line-buffered, and it's actually much nicer
> to let it be fully buffered and then do a flush at the end.
Well, sometimes we do and sometimes we don't right? Some of it
depends on how large the *stuff* we are dumping out (diffs vs. commit
objects), and what the receiving process on the other bit of the
pipeline is doing with the data --- is it doing some kind of
statistical reduction (git-rev-log .. | wc -l) versus some kind of
asynchronous processing (git-rev-log as used by gitk).
So maybe the answer is that when outputing to a file, we always use
full stdio buffering, and in other cases there should be some
intelligent defaults plus command-line overrides. So when we emit
lists of commit identifiers, it should probably be line buffered, and
if it is diffs, it should probably be fully buffered, etc.?
- Ted
^ permalink raw reply
* Re: [PATCH] Ignore submodule commits when fetching over dumb protocols
From: Linus Torvalds @ 2007-06-26 21:36 UTC (permalink / raw)
To: Sven Verdoolaege; +Cc: git, Junio C Hamano
In-Reply-To: <20070626211940.GA27221@liacs.nl>
On Tue, 26 Jun 2007, Sven Verdoolaege wrote:
>
> Without this patch, the code would look for the submodule
> commits in the superproject and (needlessly) fail when it
> couldn't find them.
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
This should probably be put in the maintenance branch, since I think we've
tried to make sure that the current 1.5.x series plumbing can handle
superproject data even if it doesn't then have the porcelain to make it
all easy..
Linus
^ permalink raw reply
* Fix zero-object version-2 packs
From: Linus Torvalds @ 2007-06-26 21:34 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List; +Cc: Tjernlund
A pack-file can get created without any objects in it (to transfer "no
data" - which can happen if you use a reference git repo, for example,
or just otherwise just end up transferring only branch head information
and already have all the objects themselves).
And while we probably should never create an index for such a pack, if we
do (and we do), the index file size sanity checking was incorrect.
This fixes it.
Reported-and-tested-by: Jocke Tjernlund <tjernlund@tjernlund.se>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
---
Tjernlund <tjernlund@tjernlund.se> wrote:
>
> [SNIP patch]
>
> Tested your patch and the error went away, many thanks
.. so here's an "official" submission for Junio.
Of course, the simpler thing would be to just remove the "-1". It's really
pretty pointless. The only reason it exists is that yes, the first object
obviously cannot have an offset that doesn't fit in 31 bits, so there can
be at most "n-1" of the extended offsets, but still, I'm not sure that
particular "clever" sanity test narrowing is worth it.
diff --git a/sha1_file.c b/sha1_file.c
index 7628ee9..f2b1ae0 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -510,7 +510,10 @@ static int check_packed_git_idx(const char *path, struct packed_git *p)
* for offsets larger than 2^31.
*/
unsigned long min_size = 8 + 4*256 + nr*(20 + 4 + 4) + 20 + 20;
- if (idx_size < min_size || idx_size > min_size + (nr - 1)*8) {
+ unsigned long max_size = min_size;
+ if (nr)
+ max_size += (nr - 1)*8;
+ if (idx_size < min_size || idx_size > max_size) {
munmap(idx_map, idx_size);
return error("wrong index file size in %s", path);
}
^ permalink raw reply related
* [PATCH] Ignore submodule commits when fetching over dumb protocols
From: Sven Verdoolaege @ 2007-06-26 21:19 UTC (permalink / raw)
To: git, Junio C Hamano
Without this patch, the code would look for the submodule
commits in the superproject and (needlessly) fail when it
couldn't find them.
Signed-off-by: Sven Verdoolaege <skimo@liacs.nl>
---
fetch.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/fetch.c b/fetch.c
index dda33e5..811be87 100644
--- a/fetch.c
+++ b/fetch.c
@@ -46,6 +46,9 @@ static int process_tree(struct tree *tree)
while (tree_entry(&desc, &entry)) {
struct object *obj = NULL;
+ /* submodule commits are not stored in the superproject */
+ if (S_ISGITLINK(entry.mode))
+ continue;
if (S_ISDIR(entry.mode)) {
struct tree *tree = lookup_tree(entry.sha1);
if (tree)
--
1.5.2.2.549.gaeb59
^ permalink raw reply related
* RE: error: wrong index file size in /usr/local/src/jffs2_mtd_patches/.git/objects/pack/pack-da39a3ee5e6b4b0d32 55bfef95601890afd80709.idx
From: Tjernlund @ 2007-06-26 21:14 UTC (permalink / raw)
To: 'Linus Torvalds'; +Cc: git
In-Reply-To: <alpine.LFD.0.98.0706261341190.8675@woody.linux-foundation.org>
> -----Original Message-----
> From: Linus Torvalds [mailto:torvalds@linux-foundation.org]
> Sent: den 26 juni 2007 22:45
> To: Tjernlund
> Cc: git@vger.kernel.org
> Subject: Re: error: wrong index file size in
> /usr/local/src/jffs2_mtd_patches/.git/objects/pack/pack-da39a3
> ee5e6b4b0d32 55bfef95601890afd80709.idx
>
>
>
> On Tue, 26 Jun 2007, Tjernlund wrote:
> >
> > Did this and got a small error that I don't think should be there:
>
> Heh. I think I see what's wrong..
>
> > Indexing 0 objects...
> > remote: Total 0 (delta 0), reused 0 (delta 0)
>
> Ok, there were no objects that weren't in the reference repo.
> So far so
> good.
>
> But:
>
> > error: wrong index file size in
> /usr/local/src/jffs2_mtd_patches/.git/objects/pack/pack-da39a3
ee5e6b4b0d3255bfef95601890afd80709.idx
>
> I think this is because of that zero size:
>
> /*
> * Minimum size:
> * - 8 bytes of header
> * - 256 index entries 4 bytes each
> * - 20-byte sha1 entry * nr
> * - 4-byte crc entry * nr
> * - 4-byte offset entry * nr
> * - 20-byte SHA1 of the packfile
> * - 20-byte SHA1 file checksum
> * And after the 4-byte offset table might be a
> * variable sized table containing 8-byte entries
> * for offsets larger than 2^31.
> */
> unsigned long min_size = 8 + 4*256 + nr*(20 +
> 4 + 4) + 20 + 20;
> if (idx_size < min_size || idx_size >
> min_size + (nr - 1)*8) {
>
> Notice the "(nr - 1)*8" thing. And notice how "nr-1"
> underflows when nr is
> zero..
>
> I bet it goes away if you remove the "-1", or if you do
> something like
> this (totally untested!) patch.
>
> Linus
[SNIP patch]
Tested your patch and the error went away, many thanks
Jocke
^ permalink raw reply
* git-send-email and --suppress-from
From: Kumar Gala @ 2007-06-26 21:14 UTC (permalink / raw)
To: git
I was wondering if its intentional that if --from address doesn't
match the address in the mbox that its added to the CC even if --
suppress-from is set?
- k
^ permalink raw reply
* Re: error: wrong index file size in /usr/local/src/jffs2_mtd_patches/.git/objects/pack/pack-da39a3ee5e6b4b0d3255bfef95601890afd80709.idx
From: David Woodhouse @ 2007-06-26 20:55 UTC (permalink / raw)
To: Tjernlund; +Cc: git
In-Reply-To: <001401c7b82d$106f30b0$0e67a8c0@Jocke>
On Tue, 2007-06-26 at 22:03 +0200, Tjernlund wrote:
> Did this and got a small error that I don't think should be there:
>
> git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6
>
> cd linux-2.6
> git gc
> cd ..
>
> git clone --reference linux-2.6 ssh://git.infradead.org/~/public_git/jffs2_mtd_patches
Your jffs2_mtd_patches tree is just a clone of
git://git.infradead.org/mtd-2.6.git, isn't it?
I get the same error when cloning that:
pmac /home/dwmw2/x $ git-clone --reference /pmac/git/linux-2.6 git://git.infradead.org/mtd-2.6.git
Initialized empty Git repository in /home/dwmw2/x/mtd-2.6/.git/
remote: Generating pack...
remote: Done counting 0 objects.
remote: Total 0 (delta 0), reused 0 (delta 0)
Indexing 0 objects...
error: wrong index file size in /home/dwmw2/x/mtd-2.6/.git/objects/pack/pack-da39a3ee5e6b4b0d3255bfef95601890afd80709.idx
Checking 21649 files out...
100% (21649/21649) done
The mtd-2.6.git tree has _no_ objects of its own at the moment; I've
committed nothing since Linus' last pull, and there's a weekly
'git-repack -a -l -d', which will remove any local objects which are
already in git://git.infradead.org/linux-2.6.git. Cloning linux-2.6.git
from there works fine, but cloning mtd-2.6.git shows the above error.
--
dwmw2
^ permalink raw reply
* Re: error: wrong index file size in /usr/local/src/jffs2_mtd_patches/.git/objects/pack/pack-da39a3ee5e6b4b0d32 55bfef95601890afd80709.idx
From: Linus Torvalds @ 2007-06-26 20:45 UTC (permalink / raw)
To: Tjernlund; +Cc: git
In-Reply-To: <001401c7b82d$106f30b0$0e67a8c0@Jocke>
On Tue, 26 Jun 2007, Tjernlund wrote:
>
> Did this and got a small error that I don't think should be there:
Heh. I think I see what's wrong..
> Indexing 0 objects...
> remote: Total 0 (delta 0), reused 0 (delta 0)
Ok, there were no objects that weren't in the reference repo. So far so
good.
But:
> error: wrong index file size in /usr/local/src/jffs2_mtd_patches/.git/objects/pack/pack-da39a3ee5e6b4b0d3255bfef95601890afd80709.idx
I think this is because of that zero size:
/*
* Minimum size:
* - 8 bytes of header
* - 256 index entries 4 bytes each
* - 20-byte sha1 entry * nr
* - 4-byte crc entry * nr
* - 4-byte offset entry * nr
* - 20-byte SHA1 of the packfile
* - 20-byte SHA1 file checksum
* And after the 4-byte offset table might be a
* variable sized table containing 8-byte entries
* for offsets larger than 2^31.
*/
unsigned long min_size = 8 + 4*256 + nr*(20 + 4 + 4) + 20 + 20;
if (idx_size < min_size || idx_size > min_size + (nr - 1)*8) {
Notice the "(nr - 1)*8" thing. And notice how "nr-1" underflows when nr is
zero..
I bet it goes away if you remove the "-1", or if you do something like
this (totally untested!) patch.
Linus
---
diff --git a/sha1_file.c b/sha1_file.c
index 7628ee9..f2b1ae0 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -510,7 +510,10 @@ static int check_packed_git_idx(const char *path, struct packed_git *p)
* for offsets larger than 2^31.
*/
unsigned long min_size = 8 + 4*256 + nr*(20 + 4 + 4) + 20 + 20;
- if (idx_size < min_size || idx_size > min_size + (nr - 1)*8) {
+ unsigned long max_size = min_size;
+ if (nr)
+ max_size += (nr - 1)*8;
+ if (idx_size < min_size || idx_size > max_size) {
munmap(idx_map, idx_size);
return error("wrong index file size in %s", path);
}
^ permalink raw reply related
* error: wrong index file size in /usr/local/src/jffs2_mtd_patches/.git/objects/pack/pack-da39a3ee5e6b4b0d3255bfef95601890afd80709.idx
From: Tjernlund @ 2007-06-26 20:03 UTC (permalink / raw)
To: git
Did this and got a small error that I don't think should be there:
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6
cd linux-2.6
git gc
cd ..
git clone --reference linux-2.6 ssh://git.infradead.org/~/public_git/jffs2_mtd_patches
Initialized empty Git repository in /usr/local/src/jffs2_mtd_patches/.git/
The authenticity of host 'git.infradead.org (18.85.46.34)' can't be established.
RSA key fingerprint is 45:df:f2:54:81:cf:42:05:1d:59:bb:dd:60:b5:0e:81.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'git.infradead.org' (RSA) to the list of known hosts.
remote: Generating pack...
remote: Done counting 0 objects.
Indexing 0 objects...
remote: Total 0 (delta 0), reused 0 (delta 0)
error: wrong index file size in /usr/local/src/jffs2_mtd_patches/.git/objects/pack/pack-da39a3ee5e6b4b0d3255bfef95601890afd80709.idx
Checking 21649 files out...
100% (21649/21649) done
git --version
git version 1.5.2.2
the ~ in above ssh: is jocke
^ permalink raw reply
* [PATCH] git.spec: RPM failed, looking for wrong files.
From: Quy Tonthat @ 2007-06-26 15:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Quy Tonthat
RPM build broke with "File not found" error on git-gui.1 and git-citool.1
They actually are git-gui.1.gz and git-citool.1.gz
Signed-off-by: Quy Tonthat <qtonthat@gmail.com>
---
git.spec.in | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/git.spec.in b/git.spec.in
index 287057e..27182ba 100644
--- a/git.spec.in
+++ b/git.spec.in
@@ -164,9 +164,9 @@ rm -rf $RPM_BUILD_ROOT
%{_bindir}/git-gui
%{_bindir}/git-citool
%{_datadir}/git-gui/
-%{!?_without_docs: %{_mandir}/man1/git-gui.1}
+%{!?_without_docs: %{_mandir}/man1/git-gui.1*}
%{!?_without_docs: %doc Documentation/git-gui.html}
-%{!?_without_docs: %{_mandir}/man1/git-citool.1}
+%{!?_without_docs: %{_mandir}/man1/git-citool.1*}
%{!?_without_docs: %doc Documentation/git-citool.html}
%files -n gitk
@@ -187,6 +187,9 @@ rm -rf $RPM_BUILD_ROOT
%{!?_without_docs: %doc Documentation/technical}
%changelog
+* Tue Jun 26 2007 Quy Tonthat <qtonthat@gmail.com>
+- Fixed problems looking for wrong manpages.
+
* Thu Jun 21 2007 Shawn O. Pearce <spearce@spearce.org>
- Added documentation files for git-gui
--
1.5.2.2.2q
^ permalink raw reply related
* git-svn error "Unable to extract revision information from commit ...~1"
From: Victor Bogado da Silva Lins @ 2007-06-26 19:09 UTC (permalink / raw)
To: git
First of all, before I state the problems I am running into, I must say
that I loved git. It is easy to setup, since there is no need to
initialize a server or repository, powerful, because one can branch and
merge as needed something that was harder in others. And on top of
everything it is very easy to follow up the history with gitk. :-)
But not everything are flowers in my git-life. I have to use svn to
commit upstream, in fact there are two different upstream svn servers. I
tryied to maintain both coordinates using two git-svn repositories. But
there are ocasions that the git-svn repository gets into a state that
dcommit simply does not work anymore. :-(
The problem seem to be that when I merge the head with another branch
git-svn does not know where to follow to meet the "svn trunk". So what
happens it that I have a head that was merged from a side track
development (usually rooted on the other svn server) and then it goes to
the wrong side.
for instance :
o master (merge commit) 17696dc402da59f8eba0dcd60f15a66859cb0c2a
|\
| o remotes/trunk svn head c0691ffaa3a41c6b5c13aec5b06b64f6321efd35
| |
o | mine local modifications f1494e9bb4c237253587c1ffdc150394c6813100
| |
...
...
When I try to use dcommit the command fails to find the coorect path to
make and send the diffs. I saw that svn-git user uses git-rev-list to
make this path, but look at the list this command gives me :
17696dc402da59f8eba0dcd60f15a66859cb0c2a
f1494e9bb4c237253587c1ffdc150394c6813100
c0691ffaa3a41c6b5c13aec5b06b64f6321efd35
the problem is that the last element is not a git-svn commit and the
tool simply whants him to be son of a git-svn commit, this is the commit
that goes "f1494e9bb4c237253587c1ffdc150394c6813100", an it is not on
the last position as expected.
Got searchs for metadata in the wrong place and "boom" break... I don't
know how to rever into a sane state, nor how can I avoid to get into
this situatiom, since I havo not yet found a clear reason on how this
came to be.
^ permalink raw reply
* Re: [PATCH] gitk - Make selection highlight color configurable
From: Brian Downing @ 2007-06-26 17:54 UTC (permalink / raw)
To: mdl123; +Cc: gitster, paulus, git
In-Reply-To: <1182825801300-git-send-email-mdl123@verizon.net>
Mark Levedahl wrote:
> Cygwin's tk by default uses a very dark selection background color
> that makes the currently selected text almost unreadable. On linux,
> the default selection background is a light gray which is very usable.
> This makes the default a light gray everywhere but allows the user to
> configure the color as well.
I noticed this, and also noticed that the dark color in question was
in fact the default Windows selection background color. Unfortunately,
wish/gitk doesn't also use the default Windows selection foreground color
(white), so the result is pretty unreadable.
When playing with Git on Windows I worked around the problem by changing
the selection color system-wide.
(This patch is perhaps better than making it work the "Windows way"
with the right system foreground color, though, as the tag and branch
markers are also pretty ugly against a dark background...)
-bcd
--
*** Brian Downing <bdowning@lavos.net>
^ permalink raw reply
* Re: [PATCH] git-rev-list: give better diagnostic for failed write
From: Linus Torvalds @ 2007-06-26 17:32 UTC (permalink / raw)
To: Theodore Tso; +Cc: Jim Meyering, git
In-Reply-To: <20070626171127.GA28810@thunk.org>
On Tue, 26 Jun 2007, Theodore Tso wrote:
>
> Is there something obviously wrong with doing something like this?
>
> if ((fstat(fileno(stdout), &st) < 0) &&
> !S_ISREG(st.st_mode))
> setbuf(stdout, NULL);
>
> This would change stdout to use completely unbuffered I/O we're not
> sending the output to a file.
Well, we might as well keep it line-buffered, so I'd use setvbuf(_IOLBF)
instead. Totally unbuffered is bad, since we often do printf's in smaller
chunks.
But we actually _do_ want fully buffered from a performance angle.
Especially for the big stuff, which is usually the *diffs*, not the commit
messages. Not so much an issue with git-rev-list, but with "git log -p"
you would normally not want it line-buffered, and it's actually much nicer
to let it be fully buffered and then do a flush at the end.
Even pipes are often used for "throughput" stuff if you end up doing some
post-processing (ie "git log -p | gather-statistics"), and yes, I actually
do things like that - it's nice for things like looking at how many lines
have been added during the last release cycle:
git log -p v2.6.21.. | grep '^+' | wc -l
and I'd really like thigns like that to be close to optimal.
How much the system call overhead is, I don't know, though. So it might be
worth testing out. Under Linux, you'll probably have a fairly hard time
seeing any difference, but under other OS's you have both system call
latency issues *and* possible scheduling issues (ie the above kind of
pipeline can act very differently from a scheduling standpoint if you send
lots of small things rather than buffer things a bit on the generating
side)
Linus
^ 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