* Re: Fix signal handler
From: Shawn O. Pearce @ 2010-02-03 15:52 UTC (permalink / raw)
To: Markus Elfring; +Cc: Thomas Rast, Jeff King, git
In-Reply-To: <4B699A45.7000905@web.de>
Markus Elfring <Markus.Elfring@web.de> wrote:
> >
> > So why don't you post patches (either fixes or testcases exhibiting
> > the issue) instead of more mails containing the same points?
> >
>
> I try to get a feeling about acceptance for update suggestions before
> they can be expressed in the target programming language.
We've been burned too many times by people who drive-by and demand
we fix X, without showing proof that X is a problem, or offering
a patch to resolve whatever X they claim is an issue. Each such
time burns existing well-known contributor time.
We've also been burned too many times by well-known contributors
posting "Hey, we should do Y" and then never actually writing the
code themselves. I know, I've done it.
Pie-in-the-sky discussions serve no purpose, and just waste
everyone's time.
If its worthwhile, write the damn code, and share it. If its not
worth your time to write the code in order to propose the idea,
its not worth our time to listen.
I've never kill-filed _ANYONE_ on this mailing list before. You are
>.< this close to making me go figure out how to setup a kill file
on my domain just so I can stop receving all emails from you.
--
Shawn.
^ permalink raw reply
* Re: Fix signal handler
From: Andreas Ericsson @ 2010-02-03 15:53 UTC (permalink / raw)
To: Markus Elfring; +Cc: Thomas Rast, Jeff King, git
In-Reply-To: <4B699A45.7000905@web.de>
On 02/03/2010 04:46 PM, Markus Elfring wrote:
>
>>
>> So why don't you post patches (either fixes or testcases exhibiting
>> the issue) instead of more mails containing the same points?
>>
>
> I try to get a feeling about acceptance for update suggestions before
> they can be expressed in the target programming language.
The general feeling on this list is that patches are listened to, no
matter how foul they are, and you will get a (hopefully) polite
rejection if it is considered useless because it addresses a problem
that doesn't exist.
Suggestions that others do a lot of work is generally not listened
to.
> The "correct" wording in the source code might become more work than you
> might agree with.
>
Since you're the only one really interested in this, you'll be the
one doing the work. If you do that work well and submit your patch(es)
by the git patch submission standards, screening them for useless
code churn is but a moments work.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
^ permalink raw reply
* Re: aborting rebase -i right at the start, was Re: [BUG] - "git commit --amend" commits, when exiting the editor with no changes written
From: Eugene Sajine @ 2010-02-03 16:02 UTC (permalink / raw)
To: SZEDER Gábor
Cc: Johannes Schindelin, Matthieu Moy, kusmabite, Wincent Colaiuta,
Avery Pennarun, Jacob Helwig, git
In-Reply-To: <20100203094144.GM15202@neumann>
2010/2/3 SZEDER Gábor <szeder@ira.uka.de>:
> On Wed, Feb 03, 2010 at 10:08:50AM +0100, Johannes Schindelin wrote:
>> Hi,
>>
>> On Wed, 3 Feb 2010, Matthieu Moy wrote:
>>
>> > Strictly speaking, an empty [rebase -i] todolist should mean to drop all
>> > the patches (like a todolist with just one line would mean to drop all
>> > the others). But a user never wants to do that (otherwise, "git reset"
>> > would be the right command), so "git rebase -i" considers it as a
>> > special case.
>>
>> Actually, it is a design bug, but it was the only sane way I could think
>> of aborting the rebase.
>>
>> Note that there _are_ users who want to do that ("let me see what commits
>> I have, ah, oh, okay, I want none of them"). I am one of those.
>
> I regularly mess up the todo file so badly that I don't want to bother
> with undo but rather start over from the beginning.
>
>
> Best,
> Gábor
>
>
I already described the solution which i think should be implemented
in old thread I will just repeat it here for easier tracking:
The solution should be as Avery proposed - to monitor file
modification timestamp as well as the content.
Timestamp should be remembered by git when editor is fired up and then
checked when you're exiting the editor. If it is the same - it means
that user canceled the whole operation by *not* confirming the file
content by save. If the timestamp is bigger than the saved one and the
message is not empty - we can proceed.
I.e. in case of rebase -i you will be able to abort the operation by
simply exiting the editor without save in any state at any moment and
start from the beginning.
Thanks,
Eugene
^ permalink raw reply
* Re: Fix signal handler
From: Markus Elfring @ 2010-02-03 16:04 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20100203151709.GA28477@coredump.intra.peff.net>
>
> If your patch is not too intrusive, and especially if you can demonstrate
> that it is a problem on a real-world system, then I think your patch would
> be considered for inclusion upstream.
>
I have got the feeling that my corresponding update suggestion (in
source code form) would become intrusive to some degree. If I do not get
an indication that issues from word-tearing in signal handlers is a
mentionable problem here, I assume that your acceptance is low for
potential fixes from every software developer (including me).
Regards,
Markus
^ permalink raw reply
* Re: Fix signal handler
From: Markus Elfring @ 2010-02-03 16:24 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Thomas Rast, Jeff King, git
In-Reply-To: <4B699C08.50400@op5.se>
>
> The general feeling on this list is that patches are listened to, no
> matter how foul they are, and you will get a (hopefully) polite
> rejection if it is considered useless because it addresses a problem
> that doesn't exist.
>
I hope that a healthy balance will be found between correct software
design, development and quick "hacking". There might also be more
efforts if too many patches will be rejected just because the suggested
and planned changes were not discussed before.
Would you like to get an acknowledgement for signal handler problems
from people in other discussion groups like "comp.programming.threads"?
Regards,
Markus
^ permalink raw reply
* Re: Fix signal handler
From: Bill Lear @ 2010-02-03 16:26 UTC (permalink / raw)
To: Markus Elfring; +Cc: Jeff King, git
In-Reply-To: <4B699E7C.1030007@web.de>
On Wednesday, February 3, 2010 at 17:04:12 (+0100) Markus Elfring writes:
>> If your patch is not too intrusive, and especially if you can demonstrate
>> that it is a problem on a real-world system, then I think your patch would
>> be considered for inclusion upstream.
>>
>I have got the feeling that my corresponding update suggestion (in
>source code form) would become intrusive to some degree. If I do not get
>an indication that issues from word-tearing in signal handlers is a
>mentionable problem here, I assume that your acceptance is low for
>potential fixes from every software developer (including me).
Do the words "insufferable !@#$!%%$" mean anything to you? I mean,
seriously, you are WELCOME TO SUBMIT A PATCH FOR THIS. Do it! Go
ahead, write it! We would love to see it. Fix things, make things
better! Don't continue to whine and waste people's time. ALL PATCHES
ARE INTRUSIVE. JUST SUBMIT A PATCH!
Bill
^ permalink raw reply
* Re: [RFC/PATCH 1/6] revert: libify cherry-pick and revert functionnality
From: Stephen Boyd @ 2010-02-03 16:40 UTC (permalink / raw)
To: Christian Couder
Cc: Junio C Hamano, git, Linus Torvalds, Johannes Schindelin,
Stephan Beyer, Daniel Barkalow
In-Reply-To: <20100201075542.3929.38404.chriscool@tuxfamily.org>
On 01/31/2010 11:55 PM, Christian Couder wrote:
> + if (flags& PICK_REVERSE) {
> + char *oneline_body = strchr(oneline, ' ');
> +
> + base = commit;
> + next = parent;
> + strbuf_addstr(msg, "Revert \"");
> + strbuf_addstr(msg, oneline_body + 1);
>
Why not do the oneline_body + 1 during the strchr()? Seems like
oneline_body is pointing to before the actual string we want.
> + for (i = 0; i< active_nr;) {
> + struct cache_entry *ce = active_cache[i++];
> + if (ce_stage(ce)) {
> + strbuf_addstr(msg, "\t");
> + strbuf_addstr(msg, ce->name);
> + strbuf_addstr(msg, "\n");
>
use strbuf_addch() for characters.
--->8----
diff --git a/pick.c b/pick.c
index bb04c68..1e1628a 100644
--- a/pick.c
+++ b/pick.c
@@ -145,12 +145,12 @@ int pick_commit(struct commit *pick_commit, int mainline,
oneline = get_oneline(message);
if (flags& PICK_REVERSE) {
- char *oneline_body = strchr(oneline, ' ');
+ char *oneline_body = strchr(oneline, ' ') + 1;
base = commit;
next = parent;
strbuf_addstr(msg, "Revert \"");
- strbuf_addstr(msg, oneline_body + 1);
+ strbuf_addstr(msg, oneline_body);
strbuf_addstr(msg, "\"\n\nThis reverts commit ");
strbuf_addstr(msg, sha1_to_hex(commit->object.sha1));
@@ -196,9 +196,9 @@ int pick_commit(struct commit *pick_commit, int mainline, in
for (i = 0; i< active_nr;) {
struct cache_entry *ce = active_cache[i++];
if (ce_stage(ce)) {
- strbuf_addstr(msg, "\t");
+ strbuf_addch(msg, '\t');
strbuf_addstr(msg, ce->name);
- strbuf_addstr(msg, "\n");
+ strbuf_addch(msg, '\n');
while (i< active_nr&& !strcmp(ce->name,
active_cache[i]->name))
i++;
^ permalink raw reply related
* extra headers in commit objects
From: Shawn O. Pearce @ 2010-02-03 17:40 UTC (permalink / raw)
To: git
Am I correct that core C developers are still under the opinion
that extra headers in a commit object aren't encouraged?
That is, we shouldn't see something like this made-up example:
$ git cat-file commit HEAD
tree e0fb24d872e2daa1507ea5879e1cdce5c0da9902
parent ec0865178ad6d8dab9ccd82b07bc3f3dae20542a
parent 89d61592bddda4dfcb90314be9e06479f712bb7f
author Junio C Hamano <gitster@pobox.com> 1265176189 -0800
committer Junio C Hamano <gitster@pobox.com> 1265176189 -0800
bug 18389
url http://example.com/some/mailing/list/post
message-id <gitster-182819131@gitster.computer>
Merge git://repo.or.cz/git-gui into next
(Sorry Junio for picking on your latest next merge...)
Today I came across this "bug fix" [1,2] in Dulwich, which is
claiming to be a pure-Python implementation of Git.
[1] http://git.samba.org/?p=jelmer/dulwich.git;a=commit;h=bc8d73f1146afba8828a7dadbb4320f592cddcab
[2] http://git.samba.org/?p=jelmer/dulwich.git;a=commitdiff;h=bc8d73f1146afba8828a7dadbb4320f592cddcab;hp=4e50426fb72e6c9259feecbba5bfcf053af62335
I haven't spoken with Jelmer Vernooij directly about it, but after
some indirect email through a 3rd party, it seems he might be under
the impression that this really is a bug in Dulwich, because "other
git implementations do it".
Uhm.
I thought the canonical reference implementation was C Git
(aka git-core), as maintained by Junio Hamano, and the object
formats, core data structures, and network protocols were
fairly well documented between the Git Community Book and the
Documentation/technical/ directory.
The only other widely used Git implementation that I know of is JGit.
It sure as hell doesn't do this, and it sure as hell isn't what I
would call the reference implementation for Git... and that project
is my own baby.
Yes, there are many other Git implementations. But I thought nearly
all of them were toys, and none of them were even close to serving
the kind of production volume that JGit serves, and JGit isn't even
considered a production library by most. Yet JGit always tries to
conform to whatever standard is set by the C implementation.
Basically, aside from having a pretty horrible morning thus far,
and being in a really bad mood, I'm starting to get a bit worried
about the proliferation of Git implementations, and what the notion
of the standard network protocol and file formats is.
We're starting to see a fork in the basic protocols happen. Hell,
Dulwich 0.4.1 isn't even capable of speaking over the network to
C Git, but it does talk to itself, so its valid, right? :-(
$ PYTHONPATH=`pwd` ./bin/dul-daemon . &
$ git clone git://localhost/.git
Initialized empty Git repository in /usr/local/google/users/sop/tmp/localhost/.git/
fetch-pack: protocol error: bad band #78
fatal: early EOF
fatal: index-pack failed
Fortunately a friend of mine is spending some time trying to patch
it up... trying to get it back in compliance with the C reference
implementation.
At the end of the day, is it a bug that C git doesn't support
working with extra commit headers? IMHO, no, because, we've
rejected these in the past, and its not part of the Git standard.
And other implementations shouldn't be trying to sell it that way.
</rather-pissed-off-rant>
--
Shawn.
^ permalink raw reply
* Re: How to tell if a file was renamed between two commits
From: Ron Garret @ 2010-02-03 17:48 UTC (permalink / raw)
To: git
In-Reply-To: <20100203025347.GB13092@spearce.org>
In article <20100203025347.GB13092@spearce.org>,
"Shawn O. Pearce" <spearce@spearce.org> wrote:
> Ron Garret <ron1@flownet.com> wrote:
> > In article <20100203023219.GA13092@spearce.org>,
> > "Shawn O. Pearce" <spearce@spearce.org> wrote:
> > > > So... is there an easy way to work around this? Is there a way to get,
> > > > say, rev-list to tell me when the file it is tracking changed names?
> > >
> > > Maybe use the -M flag to git log, or the --follow flag to
> > > log/rev-list?
> >
> > Nope. git log --follow will follow through a name change but won't
> > actually say when the name changed happened or what the previous name of
> > the file was.
> >
> > And actually playing around with it some more, it appears that git
> > rev-list doesn't actually track file renames, or at least it doesn't do
> > it all the time. Weird. I'm going to have to play around with this
> > some more.
>
> Use:
>
> git log --format=%H -M --name-status --follow -- path
>
> I just tried it:
>
> $ git log --format=%H -M --name-status --follow
> gerrit-prettify/src/main/resources/com/google/gerrit/prettify/client/prettify.
> js
> 8db22c85c49814b99639b2e6346583e9be4c289f
>
> R100
> gerrit-patch-gwtexpui/src/main/java/com/google/gwtexpui/safehtml/client/
> 544546fcd680f82a88df3e9eba7df8acfadf1e46
>
> M
> gerrit-patch-gwtexpui/src/main/java/com/google/gwtexpui/safehtml/client/
> d83ac11a52c1b6d4acae932a8495daf1e9129fdf
>
> R100
> gerrit-patch-gwtexpui/src/main/java/com/google/gwtexpui/safehtml/public/
> 44671f5c6929a8f05223dd359182610286ceb98a
>
> R100 src/main/java/com/google/gerrit/public/prettify20090521/prettify.js
>
> 56fc9e3d951b0886c4781a5c8623dbc3da824f30
>
> A src/main/java/com/google/gerrit/public/prettify20090521/prettify.js
>
>
> Yay, its been renamed 3 times in its life here. :-)
Cool! Thanks!
rg
^ permalink raw reply
* Re: [BUG] - "git commit --amend" commits, when exiting the editor with no changes written
From: Jonathan Nieder @ 2010-02-03 17:51 UTC (permalink / raw)
To: Eugene Sajine
Cc: Matthieu Moy, kusmabite, Johannes Schindelin, Wincent Colaiuta,
Avery Pennarun, Jacob Helwig, git
In-Reply-To: <76c5b8581002030745g634d6ec1hb9e87b687e58e521@mail.gmail.com>
Eugene Sajine wrote:
> On Wed, Feb 3, 2010 at 2:31 AM, Matthieu Moy
>> Just try:
>>
>> Create a file.
>> 1) Launch emacs, save and quit.
>> 2) Launch emacs, don't save, and quit.
>>
>> From outside, it's EXACTLY the same thing. In the first case, emacs
>> will just tell you "no change need to be saved" and quit, in the
>> second, it'll quit. Try deleting the file in the meantime, it won't
>> change the behavior.
> Please, do not assume i don't understand that file opened in editor
> and saved with no changes will be the same as not saved.
>
> Please, do not assume i don't understand that current implementation
> does not allow to correctly abort by simply quiting the editor,
> because it uses the file content only to verify if it can proceed.
I’ll bite. Please reread Mattheiu’s message. Pay particular attention
to the lines
In the first case, emacs
will just tell you "no change need to be saved" and quit, in the
second, it'll quit.
and
Try deleting the file in the meantime, it won't
change the behavior.
and consider what this means about what is happening and the resulting
stat() information.
It is a bit frustrating to read this thread because Mattheiu was not the
first thing to say this (and many have mentioned other problems, too,
such as people’s muscle memory), but you do not seem to respond to them.
Instead, you keep repeating the same thing...
Hope that helps,
Jonathan
^ permalink raw reply
* Re: [BUG] - "git commit --amend" commits, when exiting the editor with no changes written
From: Jonathan Nieder @ 2010-02-03 17:53 UTC (permalink / raw)
To: Eugene Sajine
Cc: Matthieu Moy, kusmabite, Johannes Schindelin, Wincent Colaiuta,
Avery Pennarun, Jacob Helwig, git
In-Reply-To: <20100203175118.GA2982@progeny.tock>
Jonathan Nieder wrote:
> It is a bit frustrating to read this thread because Mattheiu was not the
> first thing to say this
s/thing/person/
Sorry, Mattheiu. ;-)
Kind regards,
Jonathan
^ permalink raw reply
* Re: extra headers in commit objects
From: Nicolas Pitre @ 2010-02-03 18:15 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20100203174041.GC14799@spearce.org>
On Wed, 3 Feb 2010, Shawn O. Pearce wrote:
> Am I correct that core C developers are still under the opinion
> that extra headers in a commit object aren't encouraged?
I would say so.
[...]
> At the end of the day, is it a bug that C git doesn't support
> working with extra commit headers? IMHO, no, because, we've
> rejected these in the past, and its not part of the Git standard.
> And other implementations shouldn't be trying to sell it that way.
Agreed. And this was discussed in great length on this list on few
occasions already (probably more than a year back).
Nicolas
^ permalink raw reply
* Re: [BUG] - "git commit --amend" commits, when exiting the editor with no changes written
From: Avery Pennarun @ 2010-02-03 18:19 UTC (permalink / raw)
To: Jeff King; +Cc: Eugene Sajine, Larry D'Anna, git
In-Reply-To: <20100203093150.GA23956@coredump.intra.peff.net>
On Wed, Feb 3, 2010 at 4:31 AM, Jeff King <peff@peff.net> wrote:
> On Wed, Feb 03, 2010 at 01:15:35AM -0500, Larry D'Anna wrote:
>> * Avery Pennarun (apenwarr@gmail.com) [100202 18:41]:
>> > You can however add *new* stuff. That's why I suggested adding an
>> > option. You could even make it a config option so you only have to
>> > set it once (just like setting your preferred editor).
>>
>> Or, he can set his $EDITOR to a script that checks the mtime.
Nice.
> Do note, though, that there is a subtle race condition in using the
> mtime. If you make a change and save within a second of the editor
> starting, it will be ignored. To be thorough, you would probably want to
> check the size and inode, as well.
Or just the file contents.
Avery
^ permalink raw reply
* Re: [PATCH] gitweb: Simplify (and fix) chop_str
From: J.H. @ 2010-02-03 18:25 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, John 'Warthog9' Hawley
In-Reply-To: <201002031228.31324.jnareb@gmail.com>
This looks good to me.
- John 'Warthog9' Hawley
On 02/03/2010 03:28 AM, Jakub Narebski wrote:
> From: John 'Warthog9' Hawley <warthog9@kernel.org>
>
> The chop_str subroutine is meant to be used on strings (such as commit
> description / title) *before* HTML escaping, which means before
> applying esc_html or equivalent.
>
> Therefore get rid of the failed attempt to always remove full HTML
> entities (like e.g. & or ). It is not necessary (HTML
> entities gets added later), and it can cause chop_str to chop a string
> incorrectly.
>
> Specifically:
>
> API & protocol: support option to force written data immediately to disk
>
> from http://git.kernel.org/?p=daemon/distsrv/chunkd.git;a=commit;h=3b02f749df2cb1288f345a689d85e7061f507e54
>
> The short version of the title gets chopped to
>
> API ...
>
> where it should be
>
> API & protocol: support option to force written data...
>
> Noticed-by: John 'Warthog9' Hawley <warthog9@kernel.org>
> Signed-off-by: John 'Warthog9' Hawley <warthog9@kernel.org>
> Signed-off-by: Jakub Narebski <jnareb@gmail.com>
> ---
> I have retained J.H. authorship of this patch. I have rewritten
> commit message, added signoffs, and removed all instances of failed
> attempt of removing HTML entities whole, even though only one of them
> is used.
>
> gitweb/gitweb.perl | 4 ----
> 1 files changed, 0 insertions(+), 4 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index d0c3ff2..1f6978a 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -1330,7 +1330,6 @@ sub chop_str {
> $str =~ m/^(.*?)($begre)$/;
> my ($lead, $body) = ($1, $2);
> if (length($lead) > 4) {
> - $body =~ s/^[^;]*;// if ($lead =~ m/&[^;]*$/);
> $lead = " ...";
> }
> return "$lead$body";
> @@ -1341,8 +1340,6 @@ sub chop_str {
> $str =~ m/^(.*?)($begre)$/;
> my ($mid, $right) = ($1, $2);
> if (length($mid) > 5) {
> - $left =~ s/&[^;]*$//;
> - $right =~ s/^[^;]*;// if ($mid =~ m/&[^;]*$/);
> $mid = " ... ";
> }
> return "$left$mid$right";
> @@ -1352,7 +1349,6 @@ sub chop_str {
> my $body = $1;
> my $tail = $2;
> if (length($tail) > 4) {
> - $body =~ s/&[^;]*$//;
> $tail = "... ";
> }
> return "$body$tail";
^ permalink raw reply
* [PATCH] grep: simplify assignment of ->fixed
From: René Scharfe @ 2010-02-03 18:16 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano
After 885d211e, the value of the ->fixed pattern option only depends on
the grep option of the same name. Regex flags don't matter any more,
because fixed mode and regex mode are strictly separated. Thus we can
simply copy the value from struct grep_opt to struct grep_pat, as we do
already for ->word_regexp and ->ignore_case.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
grep.c | 5 +----
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/grep.c b/grep.c
index 60cce46..a0864f1 100644
--- a/grep.c
+++ b/grep.c
@@ -57,11 +57,8 @@ static void compile_regexp(struct grep_pat *p, struct grep_opt *opt)
p->word_regexp = opt->word_regexp;
p->ignore_case = opt->ignore_case;
+ p->fixed = opt->fixed;
- if (opt->fixed)
- p->fixed = 1;
- if (opt->regflags & REG_ICASE)
- p->fixed = 0;
if (p->fixed)
return;
--
1.7.0.rc1
^ permalink raw reply related
* git-mv redux: there must be something else going on
From: Ron Garret @ 2010-02-03 18:25 UTC (permalink / raw)
To: git
Based on my current understanding of git there should be no difference
between a git mv and a git rm followed by a git add. But empirically
there is a difference. git log --M --follow is able to track files
through git mvs even if their content changes completely. Likewise, it
does *not* track files through rm/add combinations even if the content
didn't change at all. (See experiment transcript below.)
So something in my understanding of how git works must be wrong. Git
must be keeping a separate record of file renames somewhere. But where?
Just for the record, I'm not complaining about this behavior. In fact,
what git does is exactly what I want. I just want to understand how it
works.
Thanks,
rg
---
[ron@mickey:~/devel/gittest]$ cat>file1
1
2
3
4
5
[ron@mickey:~/devel/gittest]$ cat>file2
a
b
c
d
e
[ron@mickey:~/devel/gittest]$ git init
Initialized empty Git repository in /Users/ron/devel/gittest/.git/
[ron@mickey:~/devel/gittest]$ git add file1
[ron@mickey:~/devel/gittest]$ git commit -m 'Add numbers'
[master (root-commit) 54c2e4a] Add numbers
1 files changed, 5 insertions(+), 0 deletions(-)
create mode 100644 file1
[ron@mickey:~/devel/gittest]$ git rm file1
rm 'file1'
[ron@mickey:~/devel/gittest]$ git add file2
[ron@mickey:~/devel/gittest]$ git commit -m 'numbers->letters'
[master fe05d12] numbers->letters
2 files changed, 5 insertions(+), 5 deletions(-)
delete mode 100644 file1
create mode 100644 file2
[ron@mickey:~/devel/gittest]$ git log --name-status -M --follow file2
commit fe05d1233be1bb11f4ed0e8496e4191795d515a0
Author: rongarret <ron@mickey>
Date: Wed Feb 3 10:13:38 2010 -0800
numbers->letters
A file2
[ron@mickey:~/devel/gittest]$ ls
file2 git/
[ron@mickey:~/devel/gittest]$ cat>file2
6
7
8
9
10
[ron@mickey:~/devel/gittest]$ git mv file2 file3
[ron@mickey:~/devel/gittest]$ git commit -m 'letters->numbers'
[master ae3f6d4] letters->numbers
1 files changed, 0 insertions(+), 0 deletions(-)
rename file2 => file3 (100%)
[ron@mickey:~/devel/gittest]$ git log --name-status -M --follow file3
commit ae3f6d440483fa41cf08819237e87d567ac3a31d
Author: rongarret <ron@mickey>
Date: Wed Feb 3 10:15:00 2010 -0800
letters->numbers
R100 file2 file3
commit fe05d1233be1bb11f4ed0e8496e4191795d515a0
Author: rongarret <ron@mickey>
Date: Wed Feb 3 10:13:38 2010 -0800
numbers->letters
A file2
[ron@mickey:~/devel/gittest]$ ls
file3 git/
[ron@mickey:~/devel/gittest]$ mv file3 file4
[ron@mickey:~/devel/gittest]$ git rm file3
rm 'file3'
[ron@mickey:~/devel/gittest]$ git add file4
[ron@mickey:~/devel/gittest]$ git commit -m 'rm/add identical content'
[master a3d7227] rm/add identical content
2 files changed, 5 insertions(+), 5 deletions(-)
delete mode 100644 file3
create mode 100644 file4
[ron@mickey:~/devel/gittest]$ git log --name-status -M --follow file4
commit a3d7227fc2edca75fff8894acd5b077d1788bb36
Author: rongarret <ron@mickey>
Date: Wed Feb 3 10:17:23 2010 -0800
rm/add identical content
A file4
[ron@mickey:~/devel/gittest]$
^ permalink raw reply
* Re: master^ is not a local branch -- huh?!?
From: J. Bruce Fields @ 2010-02-03 18:27 UTC (permalink / raw)
To: Ron Garret; +Cc: git
In-Reply-To: <ron1-9204BD.14042202022010@news.gmane.org>
On Tue, Feb 02, 2010 at 02:04:22PM -0800, Ron Garret wrote:
> In article <20100202191942.GB9628@fieldses.org>,
> "J. Bruce Fields" <bfields@fieldses.org> wrote:
>
> > My memory is that I'd seen the word "branch" used for both meanings (a
> > linear piece of history, and a ref under ref/heads/), so figured we
> > needed terms for both.
> >
> > But then I didn't really use that distinction anywhere. On a quick skim
> > the only instance I can see of the first sense is in
> > http://kernel.org/pub/software/scm/git-core/docs/user-manual.html#counting-com
> > mits-on-a-branch,
> > which could probably be reworded.
> >
> > It still may be worth acknowledging the confusion; e.g., something like:
> >
> > In the above diagram, "A", "B", and "master" are all references
> > to a point in history. We call all three "branches".
> >
> > Informally, the word "branch" is sometimes also used to the
> > entire line of development leading up to one of these points,
> > or, more generally, to any individual line of development. But
> > when speaking about git, a "branch" (or "branch head") will
> > always be a reference to a point in history, and in particular a
> > reference which may be advanced to new commits by future
> > development.
> >
> > Eh, I don't know if that's helpful; maybe that section could just be
> > deleted. Or replaced by a more general discusion of the ref/ namespace.
>
> FWIW, I find the above verbiage to to be very clear, much better than
> what is there now. You might also add that branches are almost exactly
> the same as tags. The only difference (AFAIK) is that tags get dragged
> along by commits and resets and tags don't.
Might also be worth considering whether this:
http://kernel.org/pub/software/scm/git-core/docs/user-manual.html#how-git-stores-references
or some other general introduction to refs, should be moved to appear
earlier in the manual.
Apologies, though, I can't volunteer for now; if you'd like any of this
to happen, I'd recommend sending Junio patches. (I'll try to read them
if you cc: me.)
--b.
^ permalink raw reply
* [PATCH] grep: simple test for operation in a bare repository
From: René Scharfe @ 2010-02-03 18:16 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
t/t7002-grep.sh | 17 +++++++++++++++++
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/t/t7002-grep.sh b/t/t7002-grep.sh
index bf4d4dc..8cf958d 100755
--- a/t/t7002-grep.sh
+++ b/t/t7002-grep.sh
@@ -45,6 +45,23 @@ test_expect_success 'grep should not segfault with a bad input' '
test_must_fail git grep "("
'
+bare_repo=.git/bare_test_repo
+test_expect_success 'setup bare repo' '
+ git clone --bare . $bare_repo
+'
+
+test_expect_success "grep HEAD (t-1), bare repo" '(
+ cd $bare_repo &&
+ echo "HEAD:t/t:1:test" >expected &&
+ git grep -n -e test HEAD >actual &&
+ diff expected actual
+)'
+
+test_expect_success "grep (t-1), bare repo, must fail" '(
+ cd $bare_repo &&
+ test_must_fail git grep -n -e test
+)'
+
for H in HEAD ''
do
case "$H" in
--
1.7.0.rc1
^ permalink raw reply related
* Re: [BUG] - "git commit --amend" commits, when exiting the editor with no changes written
From: Matthieu Moy @ 2010-02-03 18:47 UTC (permalink / raw)
To: Eugene Sajine
Cc: kusmabite, Johannes Schindelin, Wincent Colaiuta, Avery Pennarun,
Jacob Helwig, git
In-Reply-To: <76c5b8581002030745g634d6ec1hb9e87b687e58e521@mail.gmail.com>
Eugene Sajine <euguess@gmail.com> writes:
> Tell me you're not serious, please;) I'm working with computers for
> more than 20 years and I do understand how editors are opening files.
> If you are serious though...:
I'm damned serious. If you've been working for 20 years with
computers, you probably understand what "no change need to be saved"
mean.
> The solution should be as Avery proposed - to monitor file
> modification timestamp as well as the content.
Try it. I do mean "try it". I don't think anyone will be able to
explain you better than it has already been done, but ... it doesn't
work.
So, again, stop arguing, try it, and see by yourself. I promise public
apologies if you prove me wrong with an actually working piece of
code.
> Timestamp should be remembered by git when editor is fired up and then
> checked when you're exiting the editor.
Which doesn't work reliable, as you would have noticed by reading my
message.
(and yes, I'm tired and angry after a long day of work ;-) ).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: git-mv redux: there must be something else going on
From: Avery Pennarun @ 2010-02-03 18:48 UTC (permalink / raw)
To: Ron Garret; +Cc: git
In-Reply-To: <ron1-32BD5F.10255403022010@news.gmane.org>
On Wed, Feb 3, 2010 at 1:25 PM, Ron Garret <ron1@flownet.com> wrote:
> So something in my understanding of how git works must be wrong. Git
> must be keeping a separate record of file renames somewhere. But where?
It doesn't. Your experiment is wrong.
> [ron@mickey:~/devel/gittest]$ cat>file2
> 6
> 7
> 8
> 9
> 10
> [ron@mickey:~/devel/gittest]$ git mv file2 file3
> [ron@mickey:~/devel/gittest]$ git commit -m 'letters->numbers'
> [master ae3f6d4] letters->numbers
> 1 files changed, 0 insertions(+), 0 deletions(-)
> rename file2 => file3 (100%)
Whoops. You didn't 'git add file2' (before the mv) or 'git add file3'
(after the mv), or use commit -a, so what you've committed is the
*old* content of file2 under the name file3. The *new* content of
file2 is still uncommitted in your work tree under the name file3.
This is why git can detect the move. (The 100% is a good clue: it
means the old and new files are 100% identical.)
Artificial tests like this are useless anyway. If you renamed file2
to file3 *and* changed all the contents, did you *really* rename it?
If so, who cares? What good does it do you to know this? If someone
else tries to patch the old file2 and you merge it into a (totally
different) file3 vs a (now missing) file2, how is that any better?
On the other hand, if one guy moves file2 to file3 and changes a few
lines, you want the other guy's patch to go into file3, whether the
first guy used 'git mv' or add+rm or anything else.
As long as only a few lines changed, git does the right thing. If
most/all of the lines have changed, then there is no right thing,
because you'll get a nasty merge conflict either way.
Have fun,
Avery
^ permalink raw reply
* Re: [BUG] - "git commit --amend" commits, when exiting the editor with no changes written
From: Eugene Sajine @ 2010-02-03 18:49 UTC (permalink / raw)
To: Wincent Colaiuta
Cc: Matthieu Moy, kusmabite, Johannes Schindelin, Avery Pennarun,
Jacob Helwig, git
In-Reply-To: <1088CD70-9D6E-4B97-9A46-BDDE1535B703@wincent.com>
On Wed, Feb 3, 2010 at 1:21 PM, Wincent Colaiuta <win@wincent.com> wrote:
> El 03/02/2010, a las 16:45, Eugene Sajine escribió:
>
>> On Wed, Feb 3, 2010 at 2:31 AM, Matthieu Moy
>> <Matthieu.Moy@grenoble-inp.fr> wrote:
>>>
>>> Eugene Sajine <euguess@gmail.com> writes:
>>>
>>>> Thank you, but I'm not wrong, as i described the exact same thing
>>>> somewhere in my second or third message, without even knowing the
>>>> implementation details. I understand the reason WHY it is like it is,
>>>> i just don't like it as it is inconsistent and IMHO incorrect.
>>>
>>> Just try:
>>>
>>> Create a file.
>>> 1) Launch emacs, save and quit.
>>> 2) Launch emacs, don't save, and quit.
>>>
>>> From outside, it's EXACTLY the same thing. In the first case, emacs
>>> will just tell you "no change need to be saved" and quit, in the
>>> second, it'll quit. Try deleting the file in the meantime, it won't
>>> change the behavior.
>>>
>>> Now, what would you do about this? Ignore Emacs and force people to
>>> use vi?
>>>
>>> People have been spending a whole thread to explain you that it's not
>>> going to work. I think it'll either be time to acknowledge that, or to
>>> learn C and write a patch. Or perhaps try to write it in Java to
>>> understand why it doesn't work.
>>>
>>> --
>>> Matthieu Moy
>>> http://www-verimag.imag.fr/~moy/
>>>
>>
>> Tell me you're not serious, please;) I'm working with computers for
>> more than 20 years and I do understand how editors are opening files.
>> If you are serious though...:
>>
>> Please, do not assume i don't understand that file opened in editor
>> and saved with no changes will be the same as not saved.
>>
>> Please, do not assume i don't understand that current implementation
>> does not allow to correctly abort by simply quiting the editor,
>> because it uses the file content only to verify if it can proceed.
>>
>>
>> I will stop trying to explain the problem here, but the solution, that
>> i think should work:
>>
>> The solution should be as Avery proposed - to monitor file
>> modification timestamp as well as the content.
>> Timestamp should be remembered by git when editor is fired up and then
>> checked when you're exiting the editor. If it is the same - it means
>> that user canceled the whole operation by not confirming the file
>> content by save. If the timestamp is bigger than the saved one and the
>> message is not empty - we can proceed. Something like that.
>>
>> And finally:
>>
>> I DO highly appreciate everybody's time spent on every discussion and
>> particularly this one. I ask you to excuse me if i was failing to
>> properly express my thoughts or if i was too emotional at times.
>
> Perhaps you could invest a little time actually reading what people have
> written. Your proposal won't work because in the case where the user wants
> to keep the commit message without any modifications many editors won't
> touch the file even if people explicitly save it.
>
> Wincent
>
>
Thank you for clarifying that.
OK. I admit I got confused with the fact that some editors (vi,
kwrite, gedit - i just tested them to be 100% sure) do allow you to
hit save right after the file was opened and the timestamp will be
changed, while emacs or open office writer or some others do not, if
no changes has been made. Therefore there is no way to actually change
the timestamp on the file from editors like emacs without actually
changing something.
I'm very sorry for confusion, so, please, accept my apologies for
being stubborn.
I hope it is clear that my only intention is to try to make git better
and provide useful feedback and I'm sorry i didn't succeed this time.
Thanks,
Eugene
^ permalink raw reply
* Re: [BUG] - "git commit --amend" commits, when exiting the editor with no changes written
From: Wincent Colaiuta @ 2010-02-03 18:21 UTC (permalink / raw)
To: Eugene Sajine
Cc: Matthieu Moy, kusmabite, Johannes Schindelin, Avery Pennarun,
Jacob Helwig, git
In-Reply-To: <76c5b8581002030745g634d6ec1hb9e87b687e58e521@mail.gmail.com>
El 03/02/2010, a las 16:45, Eugene Sajine escribió:
> On Wed, Feb 3, 2010 at 2:31 AM, Matthieu Moy
> <Matthieu.Moy@grenoble-inp.fr> wrote:
>> Eugene Sajine <euguess@gmail.com> writes:
>>
>>> Thank you, but I'm not wrong, as i described the exact same thing
>>> somewhere in my second or third message, without even knowing the
>>> implementation details. I understand the reason WHY it is like it
>>> is,
>>> i just don't like it as it is inconsistent and IMHO incorrect.
>>
>> Just try:
>>
>> Create a file.
>> 1) Launch emacs, save and quit.
>> 2) Launch emacs, don't save, and quit.
>>
>> From outside, it's EXACTLY the same thing. In the first case, emacs
>> will just tell you "no change need to be saved" and quit, in the
>> second, it'll quit. Try deleting the file in the meantime, it won't
>> change the behavior.
>>
>> Now, what would you do about this? Ignore Emacs and force people to
>> use vi?
>>
>> People have been spending a whole thread to explain you that it's not
>> going to work. I think it'll either be time to acknowledge that, or
>> to
>> learn C and write a patch. Or perhaps try to write it in Java to
>> understand why it doesn't work.
>>
>> --
>> Matthieu Moy
>> http://www-verimag.imag.fr/~moy/
>>
>
> Tell me you're not serious, please;) I'm working with computers for
> more than 20 years and I do understand how editors are opening files.
> If you are serious though...:
>
> Please, do not assume i don't understand that file opened in editor
> and saved with no changes will be the same as not saved.
>
> Please, do not assume i don't understand that current implementation
> does not allow to correctly abort by simply quiting the editor,
> because it uses the file content only to verify if it can proceed.
>
>
> I will stop trying to explain the problem here, but the solution, that
> i think should work:
>
> The solution should be as Avery proposed - to monitor file
> modification timestamp as well as the content.
> Timestamp should be remembered by git when editor is fired up and then
> checked when you're exiting the editor. If it is the same - it means
> that user canceled the whole operation by not confirming the file
> content by save. If the timestamp is bigger than the saved one and the
> message is not empty - we can proceed. Something like that.
>
> And finally:
>
> I DO highly appreciate everybody's time spent on every discussion and
> particularly this one. I ask you to excuse me if i was failing to
> properly express my thoughts or if i was too emotional at times.
Perhaps you could invest a little time actually reading what people
have written. Your proposal won't work because in the case where the
user wants to keep the commit message without any modifications many
editors won't touch the file even if people explicitly save it.
Wincent
^ permalink raw reply
* Re: [BUG] - "git commit --amend" commits, when exiting the editor with no changes written
From: Avery Pennarun @ 2010-02-03 18:57 UTC (permalink / raw)
To: Eugene Sajine
Cc: Wincent Colaiuta, Matthieu Moy, kusmabite, Johannes Schindelin,
Jacob Helwig, git
In-Reply-To: <76c5b8581002031049t5558a700qe2e05bb70d175305@mail.gmail.com>
On Wed, Feb 3, 2010 at 1:49 PM, Eugene Sajine <euguess@gmail.com> wrote:
> OK. I admit I got confused with the fact that some editors (vi,
> kwrite, gedit - i just tested them to be 100% sure) do allow you to
> hit save right after the file was opened and the timestamp will be
> changed, while emacs or open office writer or some others do not, if
> no changes has been made. Therefore there is no way to actually change
> the timestamp on the file from editors like emacs without actually
> changing something.
Of course, in such editors you could just hit "space; backspace" and
then save. Sounds annoying? Well, so does deleting all the lines in
the commit message just to make it *not* amend.
To reiterate what I said earlier: the mtime idea isn't even
automatically a bad one. It's about as good as what currently exists,
and the resulting rule (file content or mtime must be modified) is
just as consistent as the current rule (file must be nonempty). It's
also arguably easier for new users to understand.
But you can't just blindly change the system to always work in a
different way. People depend on the current behaviour. Jeff King's
script is a pretty cute solution that lets you have it your way with
no changes to git, though.
Of course, this does open up the question of how to do any global UI
design at all if a decision made once gets locked in forever. The
reason git is hard for new users is that its UI is crazy and
confusing, but a major reason it keeps gaining in popularity is that
once you learn git, you stick with it, because you don't have to
relearn it with every new version.
Have fun,
Avery
^ permalink raw reply
* Re: extra headers in commit objects
From: demerphq @ 2010-02-03 19:01 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Shawn O. Pearce, git
In-Reply-To: <alpine.LFD.2.00.1002031311010.1681@xanadu.home>
On 3 February 2010 19:15, Nicolas Pitre <nico@fluxnic.net> wrote:
> On Wed, 3 Feb 2010, Shawn O. Pearce wrote:
>
>> Am I correct that core C developers are still under the opinion
>> that extra headers in a commit object aren't encouraged?
>
> I would say so.
>
> [...]
>> At the end of the day, is it a bug that C git doesn't support
>> working with extra commit headers? IMHO, no, because, we've
>> rejected these in the past, and its not part of the Git standard.
>> And other implementations shouldn't be trying to sell it that way.
>
> Agreed. And this was discussed in great length on this list on few
> occasions already (probably more than a year back).
One problem, is that if you take the approach you say then you
basically guarantee that a new git that DOES add new headers will
break an old git that doesnt know about the headers, and actually
doesnt care about them either.
So it would essentially mean that if you ever have to change the
commit format you will be in a position where new git commits will be
incompatible by design with old git commits.
Maybe I misunderstand, but this doesnt seem to accord with my reading
of the original design objectives and philosophy of git.
Shouldn't an old git just ignore headers from a new git?
I mean, forget about the fact that somebody is doing something naughty
with the git protocol, ask youself if you want this rule to basically
prevent any backwards compatible changes with older gits.
As a lurker here I understand completely if you ignore this mail
entirely. But this seems to me to be a decision that could bite you
later.
cheers,
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
^ permalink raw reply
* Re: git-mv redux: there must be something else going on
From: Ron Garret @ 2010-02-03 19:23 UTC (permalink / raw)
To: git
In-Reply-To: <32541b131002031048i26d166d9w3567a60515235c34@mail.gmail.com>
In article
<32541b131002031048i26d166d9w3567a60515235c34@mail.gmail.com>,
Avery Pennarun <apenwarr@gmail.com> wrote:
> On Wed, Feb 3, 2010 at 1:25 PM, Ron Garret <ron1@flownet.com> wrote:
> > So something in my understanding of how git works must be wrong. Git
> > must be keeping a separate record of file renames somewhere. But where?
>
> It doesn't. Your experiment is wrong.
>
> > [ron@mickey:~/devel/gittest]$ cat>file2
> > 6
> > 7
> > 8
> > 9
> > 10
> > [ron@mickey:~/devel/gittest]$ git mv file2 file3
> > [ron@mickey:~/devel/gittest]$ git commit -m 'letters->numbers'
> > [master ae3f6d4] letters->numbers
> > 1 files changed, 0 insertions(+), 0 deletions(-)
> > rename file2 => file3 (100%)
>
> Whoops. You didn't 'git add file2' (before the mv) or 'git add file3'
> (after the mv), or use commit -a, so what you've committed is the
> *old* content of file2 under the name file3. The *new* content of
> file2 is still uncommitted in your work tree under the name file3.
> This is why git can detect the move. (The 100% is a good clue: it
> means the old and new files are 100% identical.)
Ah. That explains everything. Thanks. (I thought git mv was
equivalent to git rm followed by git add. But it's not.)
> Artificial tests like this are useless anyway.
Yes, I know. This was not intended to be a real-world example. I was
just trying to understand the heuristics that git uses to track filename
changes, and in particular, how much a file could change before git
decided it was a different file. When I got to zero shared lines
between old and new it was clear that I was missing something
fundamental :-)
So... how *does* git decide when two blobs are different blobs and when
they are the same blob with mods? I asked this question before and was
pointed to the diffcore docs, but that didn't really clear things up.
That just describes all the different ways git can do diffs, not the
actual heuristics that git uses to track content.
rg
^ 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