* Re: files are disappearing in git
From: Linus Torvalds @ 2005-11-25 19:12 UTC (permalink / raw)
To: Nico -telmich- Schottelius; +Cc: Ryan Anderson, Git ML, Petr Baudis
In-Reply-To: <20051125103048.GB30691@schottelius.org>
Ok,
Nico gave me private access to the tree, so I quickly cloned it and
started bisecting it to figure out where the problem was. I haven't looked
at the source code, and all the commit messages seem to be in German
(which I can kind of understand if I work at it, but not very well), but
it definitely turns out none of that matters.
The problem is a bad merge. And in fact, that merge lost _more_ than just
the three files under Code/Spikes/Statistik/, it also lost a file called
Code/lw1/Client/Pics/icon/lw1-icon.png.
I don't quite see _how_ it lost them. The merge in question is a totally
trivial in-index merge, and when I re-do it, I don't lose those files. In
this case, all the lost files were from the "other branch" of the merge,
and they were new to that branch. IOW, in git-merge-one-file parlance, it
is that trivial "added in one" case.
Pasky - do you know of any historical cogito problems like this?
Nico: the files were added in commit
- 9e9b91166bfca448a8f1ddeb4580d73ac8ea0986:
Neuer Spike: Statistik ...
and they stayed around in that branch until commit (which is still good):
- dcd70e89dc7b2280260628fd699aa906c319c68f:
Bug 359 - Defektmeldungen ...
but they disappeared when the that branch was merged with commit
- 056c65efea28066b7b241240f0d8421d3204b624
Bug 195 - Tagesarbeitsplan: ...
and the result is the bad merge commit:
- 228b94dd0a7aa1516eb867674cdf8c7c7b2bfd4c:
Merge with /home/server/git/walderlift.git
After that merge, those new files are gone - they were never added by the
merge.
Quite frankly, this is clearly a bug, and it looks very much like a really
serious bug in cg-merge. It's not in the core git: even old versions of
git should never have been able to generate that broken merge.
But when I try to do that same merge with current cogito, I can't make it
break _either_. In all cases, regardless of how I do the merge, when I do
(bad-merge is the merge in your tree, "cg-test" in this case is the merge
I did using cogito):
git-diff-tree -r bad-merge cg-test
I get
:000000 100644 0000000000000000000000000000000000000000 5c8c47d855ee0f78a7fb81c4a49224b1607a88b7 A Code/Spikes/Statistik/Project.dpr
:000000 100644 0000000000000000000000000000000000000000 7bd2de9b7142999bc6bbadde06e73267d1b5ee0e A Code/Spikes/Statistik/Statistik.pas
:000000 100644 0000000000000000000000000000000000000000 a0fb45e2b906bdac7929cfd8174053015ab629b4 A Code/Spikes/Statistik/Statistik.xfm
:000000 100644 0000000000000000000000000000000000000000 24f8254c06ea5efc89944a3a9f52d2c79c841c0b A Code/lw1/Client/Pics/icon/lw1-icon.png
ie the "bad merge" thing (commit 228b94dd0a7aa1516eb867674cdf8c7c7b2bfd4c
in your tree) will not have those four files, and the good merge (whether
I use the git "recursive" or git "resolve" merge, or use "cg-merge" to do
it) will always have those four files.
So I do not see how that bad commit happened, especially since it's even
a fairly recent commit (the date of the merge is 2005-11-17).
I wonder if there's a really old and broken version of cogito somewhere
around. If so, it's on "srsyg03".
I also went through every single merge in your tree, and apart from two
merges that had merge conflicts and were fixed up by hand (and that I thus
didn't check), all other merges looked ok. So as far as I can tell it's
only that 228b94dd0a7aa1516eb867674cdf8c7c7b2bfd4c merge that is bad.
(And the two commits that needed manual merging _look_ fine. No lost files
at least, except for one of the merges losing "bitte_bitte_loesch_mich",
which judging by it's name _should_ be lost ;)
Finally: Nico, I've deleted the trees on my machine, and you can remove my
ssh key. I don't think I can tell you anything more.
Linus
^ permalink raw reply
* Re: git-send-mail in sh
From: Junio C Hamano @ 2005-11-25 18:30 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <43874935.2080804@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> It doesn't CC them, but any number of email-addresses can be specified
> on the command line (so long as they don't include spaces, but that can
> be taken care of).
Again I do not think I'd ever use that feature from the original
send-email myself, but the difference is that this CC list
depends on each commit (sign-offs taken from a commit are
added to CC list for only that commit).
>> * <bottom>..<top> pair is to format changes in <top> but not in
>> <bottom>; typically <top> is the name of a topic branch, and
>> <bottom> is typically "origin". This is to encourage the use
>> of topic branches.
>
> Would that be
>
> git-send-patch origin..HEAD
>
> to get the changes in the current branch since head?
Yes, and that could be spelled "git-send-patch ..HEAD" as well,
if we go with my suggestion to default <bottom> to "origin".
>> * <commit> is a shorthand for <commit>^1..<commit>; this is to
>> allow you to quickly pick just one commit and send it out.
>
> Marvellous the things one learn. I didn't know about that syntax before. :)
Just to make sure you did not misunderstand me, I meant: the
proposed program acts as if <commit>^1..<commit> was given when
single <commit> is given.
But you are right. We could make a single <commit> a short-hand
for "origin"..<commit>; if somebody wants to pick just one
commit from a topic branch, he can always say <commit>^1..<commit>.
> I'm wondering if it wouldn't be better to move much of
> git-format-patch's functionality to git-send-patch and support a
> "--todisk" option. After all, how many patches are created but not sent
> anywhere?
Manymanymanymanymany. I do all my rebases and cherry-picks via
format-patch piped to git-am, and obviously they are never sent
out.
^ permalink raw reply
* Re: git-send-mail in sh
From: Andreas Ericsson @ 2005-11-25 17:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7jaxou5b.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Andreas Ericsson <ae@op5.se> writes:
>
>>It's worse than the perl version because;
>>1. It doesn't thread the patch-series (which I personally prefer anyway
>>since it's easier to follow a thread on a particular patch that way).
>
>
> I think that is an improvement, actually ;-)
>
Agreed to that then. Good thing since that was the hardest to solve.
>
>>2. The patches sent within the same second arrive in random order.
>
>
> I think you can fudge the "Date: " yourself. Count the number
> of messages you are going to send out, grab the wallclock time
> before starting to send the first message, subtract that number
> of seconds and give it to the first message, add 1 second and
> give it to the second message, and so on.
>
> 3. It does not CC signers and authors. Although I personally
> consider not doing it "better", some people _might_ want to keep
> that behaviour as an option.
>
It doesn't CC them, but any number of email-addresses can be specified
on the command line (so long as they don't include spaces, but that can
be taken care of).
These below needs a bit of clarification. It's friday afternoon here, so
I'm a bit slow.
> <commits> = ".." <top> | <bottom> ".." <top> | <commit>
> <bottom> = <extended SHA1 expression>
> <top> = <extended SHA1 expression>
> <commit> = <extended SHA1 expression>
>
> * ..<top> is a shorthand of "origin"..<top> (the choice of
> "origin" might be debatable, but probably sane).
>
I'd rather specify the entry-point, as in "get all patches from this
commit to HEAD", if only one commit is specified, so:
git-send-patch git@vger.kernel.org origin
would do just that.
> * <bottom>..<top> pair is to format changes in <top> but not in
> <bottom>; typically <top> is the name of a topic branch, and
> <bottom> is typically "origin". This is to encourage the use
> of topic branches.
>
Would that be
git-send-patch origin..HEAD
to get the changes in the current branch since head?
> * <commit> is a shorthand for <commit>^1..<commit>; this is to
> allow you to quickly pick just one commit and send it out.
>
Marvellous the things one learn. I didn't know about that syntax before. :)
>
>># [ "$email" ] || git repo-config --get patch_email_address
>
>
> Storing the default addressee in the config is a good idea,
> since typically e-mail submissions are to a single address.
>
If values can have spaces there can be any number of email-addresses.
>
>>[ $commits -gt 1 ] && opts=-n
>
>
> You can always say -n if you want to do this; format-patch -n
> with a single patch would not say [PATCH 1/1].
>
Didn't know that. Good thing though.
>
> This is the first script I saw that uses the standard output
> from format-patch, and I do not think nobody else used it so
> far. If the standard output from format-patch is useful like
> this, I would like to drop the '* ' prefix from it, so that you
> do not have to sed it out.
>
I'll do that then. It doesn't really add any value anyways.
> You would probably want to do "format-patch -o $tmpdir" at least
> not to smudge the toplevel directory.
>
Perhaps support the -o flag in git-send-patch?
I'm wondering if it wouldn't be better to move much of
git-format-patch's functionality to git-send-patch and support a
"--todisk" option. After all, how many patches are created but not sent
anywhere?
That way we could rework the syntax to only support that of
git-rev-list. I think it's the most standard-like thing there is in git.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git-send-mail in sh
From: A Large Angry SCM @ 2005-11-25 17:20 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Johannes Schindelin, Git Mailing List
In-Reply-To: <43871ED8.9040506@op5.se>
Andreas Ericsson wrote:
> Johannes Schindelin wrote:
...
>> The hints in SubmittingPatches did not help?
>>
>
> Nopes. Perhaps because I started editing the message before I changed
> the settings. I'll investigate further and make amendments if necessary.
Definitely need to do the settings changes *before* opening the compose
window for them to have an effect.
^ permalink raw reply
* Re: git-send-mail in sh
From: Andreas Ericsson @ 2005-11-25 17:04 UTC (permalink / raw)
To: Ryan Anderson; +Cc: Git Mailing List
In-Reply-To: <20051125163358.GF16995@mythryan2.michonline.com>
Ryan Anderson wrote:
> On Fri, Nov 25, 2005 at 10:45:41AM +0100, Andreas Ericsson wrote:
>
>>Finally giving up on git-send-email (I won't install the 6 perl-modules
>>it requires and I don't know perl enough to remove the need for them), I
>>hacked up a replacement in sh. It's more aptly named as well. ;)
>
>
> Scanning the list, 2 are related to option handling (one of which is
> builtin), one isn't used (Data::Dumper), and two are related to sending
> valid emails.
When I try to install Email::Valid (using apt) it wants an additional
two modules. Mail::Sendmail wants one other, so that's Data::Dumper, the
two actually used and the three those two use. Six, for short.
> The email address verification is ridiculously hard to get
> correct, so using pre-written code for that seemed justified.
>
But it isn't necessary to validate it to such exactness. Nothing worse
will happen than the user chiding himself for his butterfingers if
he/she makes a mistake.
Besides, I think typos are by far the most common error. Those are
usually valid email addresses while still not being correct.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git-send-mail in sh
From: Ryan Anderson @ 2005-11-25 16:33 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Git Mailing List
In-Reply-To: <4386DD45.6030308@op5.se>
On Fri, Nov 25, 2005 at 10:45:41AM +0100, Andreas Ericsson wrote:
> Finally giving up on git-send-email (I won't install the 6 perl-modules
> it requires and I don't know perl enough to remove the need for them), I
> hacked up a replacement in sh. It's more aptly named as well. ;)
Scanning the list, 2 are related to option handling (one of which is
builtin), one isn't used (Data::Dumper), and two are related to sending
valid emails. The email address verification is ridiculously hard to get
correct, so using pre-written code for that seemed justified.
> It's worse than the perl version because;
> 1. It doesn't thread the patch-series (which I personally prefer anyway
> since it's easier to follow a thread on a particular patch that way).
You can use --no-chain-reply-to in git-send-email.perl, and put a 0/N
message in, and all subsequent replies get attached to that instead of
in order, if you want. This keeps everything in one thread, but all as
responses to the first email, so the people that want everything in one
thread can get that behavior.
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* Re: git-send-mail in sh
From: Andreas Ericsson @ 2005-11-25 14:25 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.63.0511251200190.30119@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
>
>>Sorry about the attachment btw. Thunderbird seems to wrap lines no
>>matter what I tell it.
>
>
> The hints in SubmittingPatches did not help?
>
Nopes. Perhaps because I started editing the message before I changed
the settings. I'll investigate further and make amendments if necessary.
>
>>Thoughts? Comments?
>
>
> I find it very cool. And easy to read. Just a few nits: You could use
> git-sh-setup.sh to ensure that you're in a valid git repository. Also, you
> could reuse the "die" function contained therein instead of a new
> function, "abort".
>
Will do. Thanks for the feedback.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* [PATCH] Fix segfault in git-shell when given no argument.
From: Tommi Virtanen @ 2005-11-25 11:49 UTC (permalink / raw)
To: git; +Cc: Tommi Virtanen
The bug is trivially reproducible with "git-shell -c git-receive-pack"
Signed-off-by: Tommi Virtanen <tv@inoi.fi>
---
shell.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
applies-to: 2ada0cb8fce070b6b2c56fa689791230636f1857
4fbfea212a9afcd123a213e20388b1fa775fc7fe
diff --git a/shell.c b/shell.c
index 2c4789e..7fab432 100644
--- a/shell.c
+++ b/shell.c
@@ -5,6 +5,8 @@ static int do_generic_cmd(const char *me
{
const char *my_argv[4];
+ if (!arg)
+ die("missing argument");
arg = sq_dequote(arg);
if (!arg)
die("bad argument");
---
0.99.9.GIT
^ permalink raw reply related
* [PATCH] Make git-mv work in subdirectories, too
From: Johannes Schindelin @ 2005-11-25 11:36 UTC (permalink / raw)
To: git, junkio
Turns out, all git programs git-mv uses are capable of operating in
a subdirectory just fine. So don't complain about it.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
I am no Perl guru, so this might not be the best way to go
about it. Also, if people agree, I would like to remove the
extra check for GIT_DIR validity, since git-rev-parse --git-dir
does that already.
git-mv.perl | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
applies-to: 6b942d45a420cf8f4064f77713d9b218e7fa53cb
fa750ba9ea3a27b39c8931b18cf0e60a89bf9fd7
diff --git a/git-mv.perl b/git-mv.perl
index bf54c38..bb61add 100755
--- a/git-mv.perl
+++ b/git-mv.perl
@@ -34,7 +34,8 @@ EOT
}
# Sanity checks:
-my $GIT_DIR = $ENV{'GIT_DIR'} || ".git";
+my $GIT_DIR = `git-rev-parse --git-dir`;
+$GIT_DIR =~ s/\n$//;
unless ( -d $GIT_DIR && -d $GIT_DIR . "/objects" &&
-d $GIT_DIR . "/objects/" && -d $GIT_DIR . "/refs") {
---
0.99.9.GIT
^ permalink raw reply related
* Re: git-send-mail in sh
From: Junio C Hamano @ 2005-11-25 11:15 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <4386DD45.6030308@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> It's better than the perl version because;
Good.
> It's worse than the perl version because;
> 1. It doesn't thread the patch-series (which I personally prefer anyway
> since it's easier to follow a thread on a particular patch that way).
I think that is an improvement, actually ;-)
> 2. The patches sent within the same second arrive in random order.
I think you can fudge the "Date: " yourself. Count the number
of messages you are going to send out, grab the wallclock time
before starting to send the first message, subtract that number
of seconds and give it to the first message, add 1 second and
give it to the second message, and so on.
3. It does not CC signers and authors. Although I personally
consider not doing it "better", some people _might_ want to keep
that behaviour as an option.
> # Instead of applying the 8942 chars long RFC-exact regex to
> # match recipients email addresses against, we're satisfied with
> # a simple @ somewhere inside an argument and just assume that
> # people won't try anything obviously stupid
This is probably adequate in practice. I have not seen an
e-mail address other than local-part@domain (RFC2822-speak
"addr-spec") form of mailbox on the kernel list for some time.
> function usage() {
> echo "Usage: git submit upstream@email.org <commit-ish> [<commit-ish>]"
> exit 1
> }
I'm old fashioned and tend to omit noise word "function".
The original format-patch parameters are my fault, but I'd
rather see newly written commands done like this:
"git-send-email" <param>+
<param> = <patch> | <addressee> | <commits>
<patch> = <anything that passes "test -f">
<addressee> = <RFC2822 addr-spec>
<commits> = ".." <top> | <bottom> ".." <top> | <commit>
<bottom> = <extended SHA1 expression>
<top> = <extended SHA1 expression>
<commit> = <extended SHA1 expression>
* ..<top> is a shorthand of "origin"..<top> (the choice of
"origin" might be debatable, but probably sane).
* <bottom>..<top> pair is to format changes in <top> but not in
<bottom>; typically <top> is the name of a topic branch, and
<bottom> is typically "origin". This is to encourage the use
of topic branches.
* <commit> is a shorthand for <commit>^1..<commit>; this is to
allow you to quickly pick just one commit and send it out.
> function abort() {
> echo "Aborting."
> exit 0
> }
Abort but exit 0? You do not seem to be using it though ;-).
> commits=0
> if [ "$com1" ]; then
> if [ -z "$com2" ]; then
> com2="$com1"
> com1=HEAD
> fi
>
> commits=$(git rev-list $com1 ^$com2 | wc -l)
> fi
You do not want to count commits like this. format-patch drops
patches that are already in upstream even if they are recorded
as diffrent commit objects, so the number you get from rev-list
is just an upper bound, and may not match the number of commits
that would be formatted.
> [ $commits -eq 0 -a -z "$patches" ] && usage
And I'd probably drop this one as well; you can have the check
before sending things out, right?
> # [ "$email" ] || git repo-config --get patch_email_address
Storing the default addressee in the config is a good idea,
since typically e-mail submissions are to a single address.
> [ $commits -gt 1 ] && opts=-n
You can always say -n if you want to do this; format-patch -n
with a single patch would not say [PATCH 1/1].
> for patch in $(git format-patch $opts $com2 $com1 | sed 's/^* //'); do
> patches="$patches $patch"
> done
This is the first script I saw that uses the standard output
from format-patch, and I do not think nobody else used it so
far. If the standard output from format-patch is useful like
this, I would like to drop the '* ' prefix from it, so that you
do not have to sed it out.
You would probably want to do "format-patch -o $tmpdir" at least
not to smudge the toplevel directory.
^ permalink raw reply
* Re: git-send-mail in sh
From: Fernando J. Pereda @ 2005-11-25 11:06 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Git Mailing List
In-Reply-To: <4386EE7B.7070604@op5.se>
[-- Attachment #1: Type: text/plain, Size: 567 bytes --]
On Fri, Nov 25, 2005 at 11:59:07AM +0100, Andreas Ericsson wrote:
| As for implementation, I don't think most "mail" programs have the
| functionality necessary to do so (dunno though since I didn't investigate).
You can always generate a 'valid' mail message and use the sendmail
binary directly. That way you can set proper Message-Id: and proper
References: and/or In-Reply-To: in the following mails.
Cheers,
Ferdy
--
Fernando J. Pereda Garcimartín
Gentoo Developer (Alpha,net-mail,mutt,git)
20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: git-send-mail in sh
From: Johannes Schindelin @ 2005-11-25 11:05 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Git Mailing List
In-Reply-To: <4386DD45.6030308@op5.se>
Hi,
On Fri, 25 Nov 2005, Andreas Ericsson wrote:
> It's worse than the perl version because;
> 1. It doesn't thread the patch-series (which I personally prefer anyway since
> it's easier to follow a thread on a particular patch that way).
I think you can do that easily by providing a Message-ID: and a
References: header. The id could be made up by "git-$commit_id" to be
reasonably unique.
> 2. The patches sent within the same second arrive in random order.
I have that all the time. Sometimes, I send emails to the git list
several minutes apart, and they come out in the wrong order. So it is no
problem.
> Sorry about the attachment btw. Thunderbird seems to wrap lines no
> matter what I tell it.
The hints in SubmittingPatches did not help?
> Thoughts? Comments?
I find it very cool. And easy to read. Just a few nits: You could use
git-sh-setup.sh to ensure that you're in a valid git repository. Also, you
could reuse the "die" function contained therein instead of a new
function, "abort".
Ciao,
Dscho
^ permalink raw reply
* Fix a warning about unused value.
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2005-11-25 10:03 UTC (permalink / raw)
To: junkio; +Cc: git, yoshfuji
Hello.
Fix a warning:
git.c:276: warning: value computed is not used
Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
diff --git a/git.c b/git.c
index bdd3f8d..0b10b6e 100644
--- a/git.c
+++ b/git.c
@@ -273,7 +273,7 @@ int main(int argc, char **argv, char **e
while (!strncmp(exec_path, "./", 2)) {
exec_path += 2;
while (*exec_path == '/')
- *exec_path++;
+ exec_path++;
}
snprintf(git_command + len, sizeof(git_command) - len,
"/%s", exec_path);
--
YOSHIFUJI Hideaki @ USAGI Project <yoshfuji@linux-ipv6.org>
GPG-FP : 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA
^ permalink raw reply related
* Re: git-send-mail in sh
From: Andreas Ericsson @ 2005-11-25 10:59 UTC (permalink / raw)
To: Nikolai Weibull; +Cc: Git Mailing List
In-Reply-To: <20051125101209.GA8868@puritan.petwork>
Nikolai Weibull wrote:
>>It's worse than the perl version because;
>>1. It doesn't thread the patch-series (which I personally prefer anyway
>>since it's easier to follow a thread on a particular patch that way).
>
>
> Not so great. Why is it so much more difficult to have one more level
> of nesting? It's annoying, but it's a lot less annoying than having 19
> separate threads that are all, in fact, related to each other.
>
I am of the opinion that nesting is bad because some patches get a few
comments while some others get them in droves. It's easy to miss those
with few if they're all nested. As for finding them, all the threads
should show up next to each other since there's practically no delay
between sending them.
As for implementation, I don't think most "mail" programs have the
functionality necessary to do so (dunno though since I didn't investigate).
>
>>2. The patches sent within the same second arrive in random order.
>
>
> Perhaps adding a 'sleep 1' would help? (The delay may be unacceptable
> to some people, though.)
>
I thought about that, but decided against it.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: files are disappearing in git
From: Nico -telmich- Schottelius @ 2005-11-25 10:30 UTC (permalink / raw)
To: Ryan Anderson; +Cc: Linus Torvalds, Git ML
In-Reply-To: <43866EDA.9050203@michonline.com>
[-- Attachment #1.1: Type: text/plain, Size: 2135 bytes --]
Ryan Anderson [Thu, Nov 24, 2005 at 08:54:34PM -0500]:
> Nico -telmich- Schottelius wrote:
> > Linus Torvalds [Wed, Nov 23, 2005 at 09:20:28AM -0800]:
> >>Is the tree public so that we can look at it and perhaps make a guess
> from
> >>what happened around it?
> >
> >
> > I am sorry it is not. Perhaps I can convince my boss to allow access to it for
> > some git developers, so someone could debug it. Thought, every information
> > found in the tree would have to be treated confidental.
> >
> > Do you have some other hints on how to debug that? Perhaps some conistency checking
> > tool?
> >
> > Or perhaps should I put that git directory under cvs? ;-)
>
> Is there anything in the directory structure that would be confidential?
The problem is that this is a project developed for a single company in
switzerland which uses it to manage elevators. We are right before to release
it and switch the customer away from MS Access to our program. It is currently
not clear, which license applies after the customer uses it, because he is interested
that some people should not use the software.
As soon as this is clearified the software may even become GPLed, but currently
I may not publish it public.
> Can you maybe provide the output of "git-whatchanged" (with no
> parameters) or maybe
>
> git-whatchanged $commit1..$commit2 path/
If I do it as you described, I get the usage of git-rev-list:
[11:01] srsyg01:walderlift% git-whatchanged 4cc7ff0cb20df228e4db467114c1c67b0933592a..cfd54ffd2aa8e44ff5c341030e9c5f22fbbc7f9f Code/Spikes/
usage: git-rev-list [OPTION] <commit-id>... [ -- paths... ]
I junh did git-whatchanged and stripped it manually. I included the initial
commit until the commit when it is gone. See attached file.
> If the output of one of those commands, which will be commit objects +
> tree differences, is less problematic, perhaps that would be easier to
> share?
I think this could be done.
Nico
--
Latest project: cinit-0.2.1 (http://linux.schottelius.org/cinit/)
Open Source nutures open minds and free, creative developers.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: git-log --]
[-- Type: text/plain; charset=utf-8, Size: 4470 bytes --]
diff-tree 056c65efea28066b7b241240f0d8421d3204b624 (from 7a9b0a3d72bc4f5417f3aecb9ca41c7dd5389ca9)
Author: Hansjörg Hassler <hhassler@srsyg03.(none)>
Date: Thu Nov 17 14:05:51 2005 +0100
Bug 195 - Tagesarbeitsplan: Nur eine Wartung pro Seite
Description: Opened: 2005-05-01 20:23
.. dies passiert manchmal. Wundi weiss angeblich warum.
------- Comment #1 From Daniel Wunderlin 2005-05-09 14:28 -------
Nicht reproduzierbar, aber lösbar: einfach Zeitbereich neu in
Monatsterminierung generieren lassen
------- Comment #2 From Fabian Hernandez 2005-11-01 14:06 -------
der bug ist plötzlich wieder aufgetreten.
1.0 - Beta(Build 29.10.2005 15:00:07)
lw26
------- Comment #3 From Sven Leser 2005-11-02 06:38 -------
*** Bug 348 has been marked as a duplicate of this bug. ***
------- Comment #4 From Hansjoerg Hassler 2005-11-17 13:02 -------
Dieses kahm durch verunreinigungen der DB bei Updatvorgängen der
Monatsterminierung.
Das ganze Anzeigen/Speichern der Daten wurde bei der Monatsterminierung neu
überarbeitet. nun werden Tagesdaten korrekt abgespeichert was eine
Voraussetzung ist damit beim Erstellen eines Tagesplanes die Darstellung stimmt
(Seitenumbrüche)
CGarbeitsplan: Nur eine Wartung pro Seite
:100644 100644 b876a90c52d4b48130450c0af5a11467b14d8410 175e435835deab5e36dc25c17c398f74c55dae9c M Code/Components/Utilities/LW1Calendar.pas
:100644 100644 ab01a0ad119927394e0a0d108251626480cffaba 5c0b5587aff550af0eb8c584826cf877e0e22738 M Code/lw1/Client/Terminierung/FeinTerminierungForm.pas
:100644 100644 b5e2bd6d55ae7a2d4a70c02c6d021d8d00b9db11 0b7551631f6c425b61daa60495803d35616844eb M Code/lw1/Client/Terminierung/FeinTerminierungForm.xfm
diff-tree dcd70e89dc7b2280260628fd699aa906c319c68f (from 10ad8267d77d78b615cf2560fb030dcc8b85c9ad)
Author: Peter Portmann <peterp@srsyg03.(none)>
Date: Thu Nov 17 10:24:56 2005 +0100
Bug 359 - Defektmeldungen ueberarbeiten
Das Suchen nach den Defektmeldungen ist nun eingebaut. Das Ändern des
Statuses ist noch nicht möglich. Zusätzlich wurden noch die neuen
Berechtigungen eingefügt.
:100644 100644 0b3b339507a4199f1484d4981bdf4ee31770ec4f 1e8a27a3dfbac681a842e4ac3b17caeba687cd28 M Code/lw1/Client/Constants.pas
:100644 100644 0047fba049e1fb4a40a0a6385c9acb7f4fb7afbb 7381ca88f1741441bb4f8c3012f1655a1e43b438 M Code/lw1/Client/DefektMeldung/DefektSearchForm.pas
:100644 100644 4a42ca39f4c74aedc32ac284240184284a05e8a0 d5234e556b2f7c671c79bb133c08b1f49ab1b93b M Code/lw1/Client/DefektMeldung/DefektSearchForm.xfm
:100644 100644 cb318c4231eb760ff0e6e8f0741b4eb0d68d46f3 0ae36dc7fc3d7740e798b41d72452bab99e450ae M Code/lw1/Client/MainForm.pas
:100644 100644 6d61131a11188762ac0f342afb820bc7aedb7079 e713a756a93da1d97face30ee7298a062b66e4a7 M Code/lw1/Client/MainForm.xfm
diff-tree 10ad8267d77d78b615cf2560fb030dcc8b85c9ad (from f1680a99ba34062c23060da1339898779f9a7a69)
Author: Peter Portmann <peterp@srsyg03.(none)>
Date: Thu Nov 17 10:20:41 2005 +0100
Datenbank auf lw29 umgestellt.
:100644 100644 fc46e27179ae8b3fb5b8c590988b7b5c905509e4 c3a5e848d4d43111f63ad86d5a6773ae81ca75e3 M Code/lw1/Client/MainDataModule.xfm
:100644 100644 f1018c16eea62a15b3166c193a63dd52bd7cc5d8 048f85089d3e924848a9a29a5ee4eb36afcaafa3 M Code/lw1/Client/lw1.conf
diff-tree f1680a99ba34062c23060da1339898779f9a7a69 (from 9e9b91166bfca448a8f1ddeb4580d73ac8ea0986)
Author: Peter Portmann <peterp@srsyg03.(none)>
Date: Thu Nov 17 10:19:25 2005 +0100
Neues Icon für lw1. Danke an Fabian Hernandez!
:000000 100644 0000000000000000000000000000000000000000 24f8254c06ea5efc89944a3a9f52d2c79c841c0b A Code/lw1/Client/Pics/icon/lw1-icon.png
diff-tree 9e9b91166bfca448a8f1ddeb4580d73ac8ea0986 (from b4d9c2fc8df035a340e675fa405ad942b032830b)
Author: Peter Portmann <peterp@srsyg03.(none)>
Date: Tue Nov 15 11:31:08 2005 +0100
Neuer Spike: Statistik fÃuer Auswertung.
:000000 100644 0000000000000000000000000000000000000000 5c8c47d855ee0f78a7fb81c4a49224b1607a88b7 A Code/Spikes/Statistik/Project.dpr
:000000 100644 0000000000000000000000000000000000000000 7bd2de9b7142999bc6bbadde06e73267d1b5ee0e A Code/Spikes/Statistik/Statistik.pas
:000000 100644 0000000000000000000000000000000000000000 a0fb45e2b906bdac7929cfd8174053015ab629b4 A Code/Spikes/Statistik/Statistik.xfm
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 827 bytes --]
^ permalink raw reply
* Re: git-send-mail in sh
From: Nikolai Weibull @ 2005-11-25 10:12 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <4386DD45.6030308@op5.se>
Andreas Ericsson wrote:
> Finally giving up on git-send-email (I won't install the 6 perl-modules
> it requires and I don't know perl enough to remove the need for them), I
> hacked up a replacement in sh. It's more aptly named as well. ;)
> It's better than the perl version because;
> 1. It doesn't have any requirements other than normal unix-commands and
> "mail" being in the path.
> 2. It can generate the patches on the fly, using git-format-patch.
Great!
> It's worse than the perl version because;
> 1. It doesn't thread the patch-series (which I personally prefer anyway
> since it's easier to follow a thread on a particular patch that way).
Not so great. Why is it so much more difficult to have one more level
of nesting? It's annoying, but it's a lot less annoying than having 19
separate threads that are all, in fact, related to each other.
> 2. The patches sent within the same second arrive in random order.
Perhaps adding a 'sleep 1' would help? (The delay may be unacceptable
to some people, though.)
nikolai
--
Nikolai Weibull: now available free of charge at http://bitwi.se/!
Born in Chicago, IL USA; currently residing in Gothenburg, Sweden.
main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}
^ permalink raw reply
* git-send-mail in sh
From: Andreas Ericsson @ 2005-11-25 9:45 UTC (permalink / raw)
To: Git Mailing List
[-- Attachment #1: Type: text/plain, Size: 1239 bytes --]
Finally giving up on git-send-email (I won't install the 6 perl-modules
it requires and I don't know perl enough to remove the need for them), I
hacked up a replacement in sh. It's more aptly named as well. ;)
It tries to be fairly newbie-friendly in what it accepts so that new
developers on a project easily can submit patches upstream in the
desired format.
This is just a draft. If anyone thinks it's a good idea then say so and
I'll write the man-page and re-submit it as a proper patch.
It's better than the perl version because;
1. It doesn't have any requirements other than normal unix-commands and
"mail" being in the path.
2. It can generate the patches on the fly, using git-format-patch.
It's worse than the perl version because;
1. It doesn't thread the patch-series (which I personally prefer anyway
since it's easier to follow a thread on a particular patch that way).
2. The patches sent within the same second arrive in random order.
Sorry about the attachment btw. Thunderbird seems to wrap lines no
matter what I tell it.
Thoughts? Comments?
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
[-- Attachment #2: git-send-patch.sh --]
[-- Type: application/x-shellscript, Size: 1524 bytes --]
^ permalink raw reply
* Re: Linux 2.6.15-rc2
From: Andreas Ericsson @ 2005-11-25 8:42 UTC (permalink / raw)
To: Ed Tomlinson
Cc: Nick Hengeveld, Linus Torvalds, Junio C Hamano, git,
Linux Kernel Mailing List
In-Reply-To: <200511242151.00162.tomlins@cam.org>
Ed Tomlinson wrote:
> On Thursday 24 November 2005 14:52, Nick Hengeveld wrote:
>
>>On Thu, Nov 24, 2005 at 10:37:15AM -0800, Linus Torvalds wrote:
>>
>>
>>>I just repacked and updated it now, so how http should work too, although
>>>inefficiently (because it will get a whole new pack - just one of the
>>>disadvantages of the non-native protocols).
>>
>>There's room to improve on that particular inefficiency. The http
>>commit walker could use Range: headers to fetch loose objects directly
>>from inside a pack if it didn't make sense to fetch the entire pack.
>>For this to work, pack fetches would need to be deferred until the
>>entire tree had been walked, and the commit walker could decide whether
>>to fetch the pack or loose objects based on the percentage of packed
>>objects it needed to fetch. It would also need to fetch all
>>tag/commit/tree objects using ranges to be able to fully walk the tree.
>
>
> Alternately, when creating a new archive the client could ask the server
> what protocols are active. It could then use the best one for the clone and
> update the .git/origin files with the optimal one for incremental pulls.
>
This would only work with the git protocol, and since that's the fastest
protocol (theoretically that is, Pasky seems to have gotten other
figures but I'm not sure I believe those) it should really only ever
return itself which wouldn't make much sense.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Linux 2.6.15-rc2
From: Ed Tomlinson @ 2005-11-25 2:50 UTC (permalink / raw)
To: Nick Hengeveld
Cc: Linus Torvalds, Junio C Hamano, git, Linux Kernel Mailing List
In-Reply-To: <20051124195256.GR3968@reactrix.com>
On Thursday 24 November 2005 14:52, Nick Hengeveld wrote:
> On Thu, Nov 24, 2005 at 10:37:15AM -0800, Linus Torvalds wrote:
>
> > I just repacked and updated it now, so how http should work too, although
> > inefficiently (because it will get a whole new pack - just one of the
> > disadvantages of the non-native protocols).
>
> There's room to improve on that particular inefficiency. The http
> commit walker could use Range: headers to fetch loose objects directly
> from inside a pack if it didn't make sense to fetch the entire pack.
> For this to work, pack fetches would need to be deferred until the
> entire tree had been walked, and the commit walker could decide whether
> to fetch the pack or loose objects based on the percentage of packed
> objects it needed to fetch. It would also need to fetch all
> tag/commit/tree objects using ranges to be able to fully walk the tree.
Alternately, when creating a new archive the client could ask the server
what protocols are active. It could then use the best one for the clone and
update the .git/origin files with the optimal one for incremental pulls.
Thoughts?
Ed Tomlinson
^ permalink raw reply
* Re: files are disappearing in git
From: Ryan Anderson @ 2005-11-25 1:54 UTC (permalink / raw)
To: Nico -telmich- Schottelius; +Cc: Linus Torvalds, Git ML
In-Reply-To: <20051124084633.GA3361@schottelius.org>
[-- Attachment #1: Type: text/plain, Size: 1108 bytes --]
Nico -telmich- Schottelius wrote:
> Linus Torvalds [Wed, Nov 23, 2005 at 09:20:28AM -0800]:
>>Is the tree public so that we can look at it and perhaps make a guess
from
>>what happened around it?
>
>
> I am sorry it is not. Perhaps I can convince my boss to allow access to it for
> some git developers, so someone could debug it. Thought, every information
> found in the tree would have to be treated confidental.
>
> Do you have some other hints on how to debug that? Perhaps some conistency checking
> tool?
>
> Or perhaps should I put that git directory under cvs? ;-)
Is there anything in the directory structure that would be confidential?
Can you maybe provide the output of "git-whatchanged" (with no
parameters) or maybe
git-whatchanged $commit1..$commit2 path/
Where $commit1 is a few commits before the problem, and $commit2 is a
few after it, and path/ is a path above the problem path?
You might add -m to that command line, too.
If the output of one of those commands, which will be commit objects +
tree differences, is less problematic, perhaps that would be easier to
share?
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]
^ permalink raw reply
* [PATCH] cvsimport: Don't let local settings hinder cvs user-migration.
From: Andreas Ericsson @ 2005-11-25 1:37 UTC (permalink / raw)
To: git
Avoid this by passing "--norc" to cvsps.
Signed-off-by: Andreas Ericsson <ae@op5.se>
---
git-cvsimport.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
applies-to: c183291c9f13912f9111ee0ab2e24ac47f3147ed
11f061ae28cca5071bfd7a344808b84c399bdbbe
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index efe1934..08a890c 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -502,7 +502,7 @@ unless($pid) {
if ($opt_P) {
exec("cat", $opt_P);
} else {
- exec("cvsps",@opt,"-u","-A",'--root',$opt_d,$cvs_tree);
+ exec("cvsps","--norc",@opt,"-u","-A",'--root',$opt_d,$cvs_tree);
die "Could not start cvsps: $!\n";
}
}
---
0.99.9.GIT
^ permalink raw reply related
* Re: Problem merging
From: Andreas Ericsson @ 2005-11-25 1:35 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <D8B7EF65-9D0C-4706-B248-4B7C118C16BF@hawaga.org.uk>
Ben Clifford wrote:
> hmm... pigeon-hole principle is just that there exists two files that
> have the same SHA-1 as each other... doesn't say anything about *all*
> SHA-1s, though?
>
It doesn't have to say that explicitly. It's universally applicable to
all static-size checksum algorithms given an infinite amount of inputs.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Problem merging
From: Johannes Schindelin @ 2005-11-25 1:13 UTC (permalink / raw)
To: Ben Clifford; +Cc: Git Mailing List
In-Reply-To: <D8B7EF65-9D0C-4706-B248-4B7C118C16BF@hawaga.org.uk>
Hi,
On Thu, 24 Nov 2005, Ben Clifford wrote:
> On 24 Nov 2005, at 00:49, Johannes Schindelin wrote:
>
> > I think nobody is. Since there are infinitely many files having the same
> > SHA1 (pigeon-hole principle),
>
> hmm... pigeon-hole principle is just that there exists two files that
> have the same SHA-1 as each other... doesn't say anything about *all*
> SHA-1s, though?
Okay, the second part of the truth is: It would be a lousy cryptographic
hash (which it isn't), if the SHA1s were not uniformly distributed over
the possible data.
You actually can be reasonably sure that given the SHA1s of all messages
of length up to N (N being an integer at least the number of bits of the
hash, i.e. 160 for SHA1), the counts of the different SHA1s should be
equal.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC 1/2] Use remote information in .git/config
From: Johannes Schindelin @ 2005-11-25 1:08 UTC (permalink / raw)
To: Ben Clifford; +Cc: Junio C Hamano, git
In-Reply-To: <41D1FCC0-E031-48FB-82A2-6CFDA2E03AC0@hawaga.org.uk>
Hi,
On Fri, 25 Nov 2005, Ben Clifford wrote:
> On 22 Nov 2005, at 05:29, Junio C Hamano wrote:
>
> > Personally I do not mind moving remotes/branches information
> > there, except that I suspect the git-config-set interface makes
> > it cumbersome to (1) find out what remotes I defined (i.e. an
> > equivalent of "ls .git/remotes")
>
> (1) is useful to be able to do in a very lightweight way when doing tab
> completion on remotes. Having heads, tags, remotes in nicely named separate
> files makes that pretty straightforward; I don't know if using a git-config-
> accessor would make this noticeably worse, though, as I haven't tried anything
> out there yet.
git-var -l | sed -n "s/^remote\.\([A-Za-z0-9]*\)\.url=.*$/\1/p"
Hth,
Dscho
^ permalink raw reply
* Re: [RFC 1/2] Use remote information in .git/config
From: Ben Clifford @ 2005-11-24 22:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7v4q65sst3.fsf@assigned-by-dhcp.cox.net>
On 22 Nov 2005, at 05:29, Junio C Hamano wrote:
>
> Personally I do not mind moving remotes/branches information
> there, except that I suspect the git-config-set interface makes
> it cumbersome to (1) find out what remotes I defined (i.e. an
> equivalent of "ls .git/remotes")
(1) is useful to be able to do in a very lightweight way when doing
tab completion on remotes. Having heads, tags, remotes in nicely
named separate files makes that pretty straightforward; I don't know
if using a git-config- accessor would make this noticeably worse,
though, as I haven't tried anything out there yet.
--
Ben • ベン • Бэн • 벤 • 班明
http://www.hawaga.org.uk/ben/
My email is high latency but best way to contact me. Alternatively,
SMS number(s) at above URL.
^ 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