* Re: current git kernel has strange problems during bisect
From: Daniel Barkalow @ 2009-01-11 22:27 UTC (permalink / raw)
To: Christian Borntraeger
Cc: Linus Torvalds, Sam Ravnborg, Johannes Schindelin, git,
Linux Kernel Mailing List
In-Reply-To: <200901112239.20306.borntraeger@de.ibm.com>
On Sun, 11 Jan 2009, Christian Borntraeger wrote:
> Am Sonntag 11 Januar 2009 schrieb Linus Torvalds:
> > Well, you don't actually have to mark that semi-random one as good either.
> > What you can do is to just mark anything that _only_ contains fs/btrfs as
> > good. IOW, you don't have to know the magic number - you just have to be
> > told that "oh, if you only have btrfs files, and you're not actively
> > bisecting a btrfs bug, just do 'git bisect good' and continue".
>
> That should work.
>
> <rant>
> Still, I am a bit frustrated. During this weekend I reported 2 regressions
> (wlan and ata) and I still try to find out why suspend/resume stopped
> working. In the meantime I have identified 2 patches (one was already known,
> I reported the 2nd to the usb maintainers) after 2.6.28 that caused suspend
> to ram regressions. In rc1 S2R was broken again. So I tried bisecting the
> third patch - which finally brought me to the btrfs bisect problem.
>
> For me, this was the most annoying merge window ever.
>
> In my opinion we should really avoid subtree merges in the future as a curtesy
> to people who do the uncool work of testing, problem tracking and bisecting.
> </rant>
I think hitting a version without the actual kernel source in it should
actually make bisecting easier, not harder; you can say without even
building the kernel that that version doesn't have the problem you're
trying to find, because it doesn't have anything in it.
The alternative to having that part of the tree empty would be to stick in
some kernel version there (probably 2.6.28), and then you'd build and test
2.6.28 again, completely wasting a bunch of time.
Probably the bisect documentation or messages need to make it clear what
you should do when you land on this sort of commit.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] Cleanup of unused symcache variable inside diff-lib.c
From: Junio C Hamano @ 2009-01-11 22:25 UTC (permalink / raw)
To: Kjetil Barvik; +Cc: Johannes Schindelin, git
In-Reply-To: <86ab9x8t4a.fsf@broadpark.no>
Kjetil Barvik <barvik@broadpark.no> writes:
> And the 'a' and the 'd' in the DCO I do agree with in this particular
> situation, so I added a '--signoff' to the patches.
I think Dscho's suggestion was to sign-off when you commit, not when you
format-patch. It won't make any difference either way to me nor other
people who reads the list, because nobody can tell which way you used by
looking at your e-mail, but it is a good habit to get into if you work on
git or the kernel.
^ permalink raw reply
* Re: [PATCH] Cleanup of unused symcache variable inside diff-lib.c
From: Junio C Hamano @ 2009-01-11 22:23 UTC (permalink / raw)
To: Kjetil Barvik; +Cc: Johannes Schindelin, git
In-Reply-To: <86eiz98v0s.fsf@broadpark.no>
Kjetil Barvik <barvik@broadpark.no> writes:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> <snipp>
>> My question was more: why do you do additional work and put a git diff
>> --raw between the commit message and the diffstat when that information is
>> in the patch already?
>
> Ok, I see. I (re)used the 'git format-patch' command from previous
> run, and this time it was (without the line-breaks):
>
> git format-patch --stat --patch-with-raw -1 --signoff -M -C
> --summary --full-index --subject-prefix="PATCH"
> --output-directory ../diff_lib_c_symcache_cleanup_v1/
Please drop --patch-with-raw and --full-index. They are distracting.
I do not think using --subject-prefix=PATCH to repeat what is default adds
any value either.
^ permalink raw reply
* Re: [PATCH v3 2/4] word diff: customizable word splits
From: Junio C Hamano @ 2009-01-11 22:20 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Johannes Schindelin, Teemu Likonen
In-Reply-To: <529cd830908f018f796dbc46d3b055c1f8ba9c1b.1231669012.git.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> Allows for user-configurable word splits when using --color-words.
> This can make the diff more readable if the regex is configured
> according to the language of the file.
>
> Each non-overlapping match of the regex is a word; everything in
> between is whitespace.
What happens if the input "language" does not have any inter-word spacing
but its words can still be expressed by regexp patterns?
ImagineALanguageThatAllowsYouToWriteSomethingLikeThis. Does the mechanism
help users who want to do word-diff files written in such a language by
outputting:
ImagineALanguage<red>That</red><green>Which</green>AllowsYou...
when '[A-Z][a-z]*' is given by the word pattern?
> We disallow matching the empty string (because
> it results in an endless loop) or a newline (breaks color escapes and
> interacts badly with the input coming from the usual line diff). To
> help the user, we set REG_NEWLINE so that [^...] and . do not match
> newlines.
AndImagineALanguageWhoseWordStruc
tureDoesNotCareAboutLineBreak
Can you help users with such payload?
Side note. Yes, I am coming from Japanese background.
Side note 2. No, I am not saying your code must support both of
the above to be acceptable. I am just gauging the design
assumptions and limitations.
> Insertion of spaces is somewhat subtle. We echo a "context" space
> twice (once on each side of the diff) if it follows directly after a
> word. While this loses a tiny bit of accuracy, it runs together long
> sequences of changed word into one removed and one added block, making
> the diff much more readable.
I guess this part can be later enhanced to be more precise, so that it
keeps the original context space more faithfully (i.e. does not lose two
consecutive spaces in the original occidental script, and does not insert
any extra space to the oriental script), if we were to support the second
example I gave above in the future as a follow-up patch.
> +--color-words[=<regex>]::
> + Show colored word diff, i.e., color words which have changed.
> + By default, a new word only starts at whitespace, so that a
> + 'word' is defined as a maximal sequence of non-whitespace
> + characters. The optional argument <regex> can be used to
> + configure this.
> ++
> +The <regex> must be an (extended) regular expression. When set, every
> +non-overlapping match of the <regex> is considered a word. (Regular
> +expression semantics ensure that quantifiers grab a maximal sequence
> +of characters.) Anything between these matches is considered
> +whitespace and ignored for the purposes of finding differences. You
> +may want to append `|\S` to your regular expression to make sure that
> +it matches all non-whitespace characters.
Whose regexp library do we assume here? Traditionally we limited
ourselves to POSIX BRE, and I do not think anybody minds using POSIX ERE
here, but we need to be clear. In either case \S is a pcre outside
POSIX.
The rest I only skimmed but did not spot anything glaringly wrong; thanks.
^ permalink raw reply
* Re: [PATCH v3 1/4] word diff: comments, preparations for regex customization
From: Junio C Hamano @ 2009-01-11 22:19 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Johannes Schindelin, Teemu Likonen
In-Reply-To: <4aea85caafd38a058145c5769fe8a30ffdbd4d13.1231669012.git.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> +/* unused right now */
> +enum diff_word_boundaries {
> + DIFF_WORD_UNDEF,
> + DIFF_WORD_BODY,
> + DIFF_WORD_END,
> + DIFF_WORD_SPACE,
> + DIFF_WORD_SKIP
> +};
Don't do this. Please introduce them when you start using them.
> struct diff_words_buffer {
> mmfile_t text;
> long alloc;
> long current; /* output pointer */
> int suppressed_newline;
> + enum diff_word_boundaries *boundaries;
> };
Likewise. Especially because this raises eyebrows "Huh, a pointer to an
enum, or perhaps he allocates an array of enums?" without allowing the
reader to figure it out much later when the field is actually used.
> static void diff_words_append(char *line, unsigned long len,
> @@ -339,16 +349,23 @@ static void diff_words_append(char *line, unsigned long len,
> struct diff_words_data {
> struct diff_words_buffer minus, plus;
> FILE *file;
> + regex_t *word_regex; /* currently unused */
> };
I see having this here and keeping it NULL in this patch makes the later
patch to diff_words_show() more readable, so this probably should stay
here.
> -static void print_word(FILE *file, struct diff_words_buffer *buffer, int len, int color,
> +/*
> + * Print 'len' characters from the "real" diff data in 'buffer'. Also
> + * returns how many characters were printed (currently always 'len').
> + * With 'suppress_newline', we remember a final newline instead of
> + * printing it.
> + */
"... Even in such a case, 'len' that is returned counts the suppressed
newline", or something like that? If you can concisely describe why the
caller wants the returned count not match the number of actually printed
chars (i.e. it includes the suppressed newline), it would help the reader
understand the logic. I am _guessing_ it is because this is called to
print matching words from the preimage buffer, and the return value is
used to skip over the same part in the postimage buffer, and by definition
they have to be of the same length (otherwise they won't be matching).
> +static int print_word(FILE *file, struct diff_words_buffer *buffer, int len, int color,
> int suppress_newline)
> {
> const char *ptr;
> int eol = 0;
>
> if (len == 0)
> - return;
> + return len;
>
> ptr = buffer->text.ptr + buffer->current;
> buffer->current += len;
> @@ -368,18 +385,30 @@ static void print_word(FILE *file, struct diff_words_buffer *buffer, int len, in
> else
> putc('\n', file);
> }
> +
> + /* we need to return how many chars to skip on the other side,
> + * so account for the (held off) \n */
Multi-line comment style? I won't repeat this but you have many...
> + return len+eol;
> }
>
> +/*
> + * Callback for word diff output
> + */
Without saying "to do what", the comment adds more noise than signal.
"Called to parse diff between pre- and post- image files converted into
one-word-per-line format and concatenate them to into lines by dropping
some of the end-of-lines but keeping some others", or something like that?
Thanks.
^ permalink raw reply
* Re: [PATCH] Allow cloning to an existing empty directory
From: Junio C Hamano @ 2009-01-11 22:19 UTC (permalink / raw)
To: Alexander Potashev; +Cc: Git Mailing List
In-Reply-To: <1231676352-16082-1-git-send-email-aspotashev@gmail.com>
Thanks; will queue both with minor style fix-ups and a trivial test.
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2009, #02; Sun, 11)
From: Junio C Hamano @ 2009-01-11 22:19 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3ljthzzdq.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> writes:
>> ----------------------------------------------------------------
>> [Actively cooking]
>>
>> * sc/gitweb-category (Fri Dec 12 00:45:12 2008 +0100) 3 commits
>> - gitweb: Optional grouping of projects by category
>> - gitweb: Split git_project_list_body in two functions
>> - gitweb: Modularized git_get_project_description to be more generic
>
> This I think needs some further cooking. I guess with addition of one
> more patch to series categories could be sorted together with projects
> they contain, and not always have to be in fixed ordering.
These should be moved to the Stalled category; nobody seems to be
discussing improvements and sending updates to the series as far as I
recall.
>> * gb/gitweb-patch (Thu Dec 18 08:13:19 2008 +0100) 4 commits
>> - gitweb: link to patch(es) view in commit(diff) and (short)log view
>> - gitweb: add patches view
>> - gitweb: change call pattern for git_commitdiff
>> - gitweb: add patch view
>
> If I remember correctly the only point of discussion is calling
> convention for git_commitdiff, and whether 'patches' view should
> (re)use git_commitdiff or use its own subroutine.
Thanks; I take it that it is basically usable, useful and can be
incrementally improved in 'next'?
^ permalink raw reply
* Re: current git kernel has strange problems during bisect
From: Alexey Zaytsev @ 2009-01-11 22:17 UTC (permalink / raw)
To: Linus Torvalds
Cc: Sam Ravnborg, Christian Borntraeger, Johannes Schindelin, git,
Linux Kernel Mailing List
In-Reply-To: <alpine.LFD.2.00.0901111200330.6528@localhost.localdomain>
On Sun, Jan 11, 2009 at 23:04, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
>
> On Sun, 11 Jan 2009, Sam Ravnborg wrote:
>>
>> The cost of moving this piece of history from one git tree to another
>> git tree is that we make it harder to debug the kernel for the advanced user
>> that knows how to do bisect.
>>
>> It is not like this history would be lost - one just had to look
>> somewhere else to find it.
>>
>> That may be a bad pain/benefit ratio - time will tell.
>
> Umm. No.
>
> Time is exactly what makes it useful. It will make all the downsides
> shrink, and the advantages stay.
>
>> There should be a way to avoid such pain when bisecting without
>> having to mark a semi-random (for the average person) commit as good.
>
> Well, you don't actually have to mark that semi-random one as good either.
> What you can do is to just mark anything that _only_ contains fs/btrfs as
> good. IOW, you don't have to know the magic number - you just have to be
> told that "oh, if you only have btrfs files, and you're not actively
> bisecting a btrfs bug, just do 'git bisect good' and continue".
>
> Yeah, you'll hit it a few times, but you don't even have to compile things
> or boot anything, so it's not actually going to be all that much slower
> than just knowing about the magic point either.
But would not such bug avoid being bisected if you blindly
mark btrfs commits as good?
v2.6.29 <-- bad
...
...
...
btrfs stuff <-- mark as good
...
the-real-bug
...
v2.6.28 <-- good
So you hit the btrfs commit, mark it as good, leaving the real bug below,
and the bisection continues, with both sides being actually bad.
Am I missing something?
^ permalink raw reply
* Re: git-svn: File was not found in commit
From: Björn Steinbrink @ 2009-01-11 21:55 UTC (permalink / raw)
To: Morgan Christiansson; +Cc: git
In-Reply-To: <49678705.4040506@mog.se>
On 2009.01.09 18:19:01 +0100, Morgan Christiansson wrote:
> Hi, i'm trying to "git svn fetch" my repository from a local file:///
> repo and i'm running into this problem:
>
> $ git svn init -t tags -b branches -T trunk file:///path/to/svn/repo
> $ git svn fetch
> branches/rails/rails/vendor/plugins/acts_as_xapian/.git/refs/heads/master
> was not found in commit a643e882c557593f36bb9fd0966490010b9dba61 (r10576)
>
>
> I found another report that seems to describe the same error:
> http://marc.info/?l=git&m=121537767308135&w=2
> Investigating the the history it's committed in r10577 and it's looking
> for it in r10576, so it seems to be off by one revision number. Exactly
> like the other report.
> I've tried the latest git version of git-svn.perl and the problem is not
> fixed there.
>
>
> $ svn log file:///path/to/repo -r10576:10577 -v
> ------------------------------------------------------------------------
> r10576 | morgan | 2008-11-28 14:35:53 +0000 (Fri, 28 Nov 2008) | 3 lines
> Changed paths:
> A /branches/rails/rails/app/controllers/browse_sheetmusic_controller.rb
> M /branches/rails/rails/app/controllers/scores_controller.rb
> M /branches/rails/rails/app/models/composer.rb
> M /branches/rails/rails/app/models/score.rb
> M /branches/rails/rails/config/routes.rb
>
> Commit message.
>
> ------------------------------------------------------------------------
> r10577 | morgan | 2008-11-28 18:31:00 +0000 (Fri, 28 Nov 2008) | 3 lines
> Changed paths:
> A /branches/rails/rails/vendor/plugins/acts_as_xapian/.git/FETCH_HEAD
> M /branches/rails/rails/vendor/plugins/acts_as_xapian/.git/config
> M /branches/rails/rails/vendor/plugins/acts_as_xapian/.git/index
> M /branches/rails/rails/vendor/plugins/acts_as_xapian/.git/logs/HEAD
> M
> /branches/rails/rails/vendor/plugins/acts_as_xapian/.git/logs/refs/heads/master
>
>
> # <-- THIS FILE
Unless I totally misread that line, SVN reports that the file was
_modified_, not added. For the file to be modified, it seems reasonable
to expect that it existed in the previous commit.
Is there anything "special" about how that file came into existence in
that branch? Without further knowledge, that looks like a svn bug, but
hey, it's svn, it might do funny stuff on purpose ;-)
Maybe you could provide a small test case/repo?
Björn
^ permalink raw reply
* Re: current git kernel has strange problems during bisect
From: Sam Ravnborg @ 2009-01-11 21:54 UTC (permalink / raw)
To: Linus Torvalds
Cc: Christian Borntraeger, Johannes Schindelin, git,
Linux Kernel Mailing List
In-Reply-To: <alpine.LFD.2.00.0901111200330.6528@localhost.localdomain>
On Sun, Jan 11, 2009 at 12:04:12PM -0800, Linus Torvalds wrote:
>
>
> On Sun, 11 Jan 2009, Sam Ravnborg wrote:
> >
> > The cost of moving this piece of history from one git tree to another
> > git tree is that we make it harder to debug the kernel for the advanced user
> > that knows how to do bisect.
> >
> > It is not like this history would be lost - one just had to look
> > somewhere else to find it.
> >
> > That may be a bad pain/benefit ratio - time will tell.
>
> Umm. No.
>
> Time is exactly what makes it useful. It will make all the downsides
> shrink, and the advantages stay.
>
> > There should be a way to avoid such pain when bisecting without
> > having to mark a semi-random (for the average person) commit as good.
>
> Well, you don't actually have to mark that semi-random one as good either.
> What you can do is to just mark anything that _only_ contains fs/btrfs as
> good. IOW, you don't have to know the magic number - you just have to be
> told that "oh, if you only have btrfs files, and you're not actively
> bisecting a btrfs bug, just do 'git bisect good' and continue".
And we lost 24 hours due to timezone differences etc. and maybe
a few testers.
Thats my point.
There are other obvious ways to do this where we keep history in kernel
but do not impact bisect.
And we have one frustrated tester already - so this is not a made up example.
Sam
^ permalink raw reply
* Re: [PATCH 0/4] refactor the --color-words to make it more hackable
From: Thomas Rast @ 2009-01-11 21:53 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0901112057300.3586@pacific.mpi-cbg.de>
[-- Attachment #1: Type: text/plain, Size: 695 bytes --]
Johannes Schindelin wrote:
>
> But at least _I_ think it is easy to follow, and it actually makes the code
> more readable/hackable. Correct me if I'm wrong.
It indeed seems a sane approach. However, the final result segfaults
and/or prints garbage (on apparently every commit except very small
changes) when using the regex '\S+', which IMHO should give exactly
the same result as not using a regex at all. In git.git:
$ ./git-show --color-words='\S+' 7eb5bbdb645
Segmentation fault
$ ./git-show --color-words='\S+' d3240d935c4
[...garbled output...]
Segmentation fault
Plain --color-words is not affected.
--
Thomas Rast
trast@{inf,student}.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: current git kernel has strange problems during bisect
From: Christian Borntraeger @ 2009-01-11 21:39 UTC (permalink / raw)
To: Linus Torvalds
Cc: Sam Ravnborg, Johannes Schindelin, git, Linux Kernel Mailing List
In-Reply-To: <alpine.LFD.2.00.0901111200330.6528@localhost.localdomain>
Am Sonntag 11 Januar 2009 schrieb Linus Torvalds:
> Well, you don't actually have to mark that semi-random one as good either.
> What you can do is to just mark anything that _only_ contains fs/btrfs as
> good. IOW, you don't have to know the magic number - you just have to be
> told that "oh, if you only have btrfs files, and you're not actively
> bisecting a btrfs bug, just do 'git bisect good' and continue".
That should work.
<rant>
Still, I am a bit frustrated. During this weekend I reported 2 regressions
(wlan and ata) and I still try to find out why suspend/resume stopped
working. In the meantime I have identified 2 patches (one was already known,
I reported the 2nd to the usb maintainers) after 2.6.28 that caused suspend
to ram regressions. In rc1 S2R was broken again. So I tried bisecting the
third patch - which finally brought me to the btrfs bisect problem.
For me, this was the most annoying merge window ever.
In my opinion we should really avoid subtree merges in the future as a curtesy
to people who do the uncool work of testing, problem tracking and bisecting.
</rant>
Christian
^ permalink raw reply
* Re: [PATCH 4/4] pager: do wait_for_pager on signal death
From: Junio C Hamano @ 2009-01-11 21:13 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Sixt, Johannes Schindelin, git
In-Reply-To: <20090111113649.GD29791@coredump.intra.peff.net>
Thanks; I agree with you that I do not see a good reason _not_ to be
handling those other signals at some of the "just handle SIGINT" sites,
and I like the direction in whcih this series is taking us very much.
^ permalink raw reply
* Re: Lightweight tag ?
From: Junio C Hamano @ 2009-01-11 21:04 UTC (permalink / raw)
To: Francis Moreau; +Cc: git
In-Reply-To: <38b2ab8a0901111044x5db21d74i25ff7a26bb702a5d@mail.gmail.com>
"Francis Moreau" <francis.moro@gmail.com> writes:
> My problem is that I don't see their point !
>
> They behave the same way like the annotated tags: when pushing to a
> repo the lightweight tags are pushed as well, and pulling from a repo
> with lightweight tags give the same results (all of this with the
> --tags switch).
Don't use explicit --tags blindly. It says "no matter what kind of tag,
transfer everything under refs/tags". Otherwise you won't see a
difference.
^ permalink raw reply
* Re: [PATCH] filter-branch: add git_commit_non_empty_tree and --prune-empty.
From: Johannes Schindelin @ 2009-01-11 20:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Pierre Habouzit, Jay Soffian, git, pasky, srabbelier
In-Reply-To: <7vab9xsgzf.fsf@gitster.siamese.dyndns.org>
Hi,
On Sun, 11 Jan 2009, Junio C Hamano wrote:
> Pierre Habouzit <madcoder@debian.org> writes:
>
> > On Sun, Jan 11, 2009 at 01:35:15PM +0000, Johannes Schindelin wrote:
> > ...
> >> And I suggested to merge the tests with Sverre's patch. That
> >> suggestion also went unaddressed.
> >
> > I can't find any mails from Sverre in the same thread, but maybe I'm
> > not searching in the proper place...
>
> This is in 'master' already; if there was anything missing in your
> patch, please fill in with updates.
I _think_ that I asked for test cases to use that workflow, so that we can
be sure that what's in the man page actually works.
Ciao,
Dscho
^ permalink raw reply
* Re: stopping patches from just floating by
From: jidanni @ 2009-01-11 20:53 UTC (permalink / raw)
To: barkalow; +Cc: git
In-Reply-To: <alpine.LNX.1.00.0901111524110.19665@iabervon.org>
I see. Say, for my forthcoming 40 minor grammar fixes that affect 20
files in Documentation/*, I just couldn't bear spamming this list with
more that one or two [PATCH] mails. OK one long mail it will be then,
with several commits encompassing many diffs. Hope that will be OK.
(Then another long mail next month, when I finish looking at the second
half of the man pages.)
^ permalink raw reply
* Re: [PATCH] filter-branch: add git_commit_non_empty_tree and --prune-empty.
From: Junio C Hamano @ 2009-01-11 20:52 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Johannes Schindelin, Jay Soffian, git, pasky, srabbelier
In-Reply-To: <20090111142732.GA18484@artemis.corp>
Pierre Habouzit <madcoder@debian.org> writes:
> On Sun, Jan 11, 2009 at 01:35:15PM +0000, Johannes Schindelin wrote:
> ...
>> And I suggested to merge the tests with Sverre's patch. That suggestion
>> also went unaddressed.
>
> I can't find any mails from Sverre in the same thread, but maybe I'm not
> searching in the proper place...
This is in 'master' already; if there was anything missing in your patch,
please fill in with updates.
^ permalink raw reply
* Re: current git kernel has strange problems during bisect
From: Johannes Schindelin @ 2009-01-11 20:51 UTC (permalink / raw)
To: Andi Kleen
Cc: Linus Torvalds, Christian Borntraeger, git,
Linux Kernel Mailing List
In-Reply-To: <87tz85fuxr.fsf@basil.nowhere.org>
Hi,
On Sun, 11 Jan 2009, Andi Kleen wrote:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
> >
> > For bisect purposes, if you know you're not chasing down a btrfs issue,
> > you can do
> >
> > git bisect good 34353029534a08e41cfb8be647d734b9ce9ebff8
>
> Could you perhaps add some standard tag for that commit? That
> would make it easier than to always find the exact btrfs commit.
>
> Just an idea.
Well, AFAICT what Linus hinted at is that you do not need such a standard
tag. Indeed, you would only clutter the history with such tags, when it
usually is just a matter of saying "git bisect good" whenever you _know_
you are hitting known-good history.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Cleanup of unused symcache variable inside diff-lib.c
From: Kjetil Barvik @ 2009-01-11 20:50 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano
In-Reply-To: <alpine.DEB.1.00.0901112112540.3586@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
<snipp>
>> --signoff
>
> If you had signed off on your commits already, not necessary. (FWIW I
> keep a sign off as a marker that I actually think this is good to be
> submitted, or at least close.)
From the Documentation/SubmittingPatches file, for me I think that the
'-signoff' is supposed to mean:
[....]
- if you want your work included in git.git, add a "Signed-off-by:
Your Name <you@example.com>" line to the commit message (or just
use the option "-s" when committing) to confirm that you agree to
the Developer's Certificate of Origin
[....]
The sign-off is a simple line at the end of the explanation for the
patch, which certifies that you wrote it or otherwise have the right
to pass it on as a open-source patch. The rules are pretty simple: if
you can certify the below:
Developer's Certificate of Origin 1.1
By making a contribution to this project, I certify that:
[....]
then you just add a line saying
Signed-off-by: Random J Developer <random@developer.example.org>
This line can be automatically added by git if you run the git-commit
command with the -s option.
[....]
And the 'a' and the 'd' in the DCO I do agree with in this particular
situation, so I added a '--signoff' to the patches.
-- kjetil
^ permalink raw reply
* Re: stopping patches from just floating by
From: Daniel Barkalow @ 2009-01-11 20:37 UTC (permalink / raw)
To: jidanni; +Cc: git
In-Reply-To: <87y6xhkb2f.fsf@jidanni.org>
On Mon, 12 Jan 2009, jidanni@jidanni.org wrote:
> I notice lots of "Merge branch qq/bla". And think, hmmm, Mr. QQ must
> be using Documentation/everyday.txt's [[Individual Developer
> (Participant)]] git-push methods, for a more efficient way of getting
> his patches included by the maintainer.
Nope, that would lead to "Merge git://qq.org/git bla". In fact, Junio is
getting the patches by email, and then using that workflow in his own tree
to manage the maintence process. That is, he creates a branch for each
patch series that someone sends that looks ready for more exposure, by
starting with some plausible commit and applying the series of patches,
and then he can merge than branch into pu, next, master, or maint as
needed. This is particularly useful for pu, where he redoes all the merges
frequently; if he worked by just applying the patches, every time he
wanted to drop a series that he'd applied before some other series, he'd
have to pick out the conflict resolutions from the original author's
changes.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: current git kernel has strange problems during bisect
From: Andi Kleen @ 2009-01-11 20:29 UTC (permalink / raw)
To: Linus Torvalds
Cc: Christian Borntraeger, Johannes Schindelin, git,
Linux Kernel Mailing List
In-Reply-To: <alpine.LFD.2.00.0901111113150.6528@localhost.localdomain>
Linus Torvalds <torvalds@linux-foundation.org> writes:
>
> For bisect purposes, if you know you're not chasing down a btrfs issue,
> you can do
>
> git bisect good 34353029534a08e41cfb8be647d734b9ce9ebff8
Could you perhaps add some standard tag for that commit? That
would make it easier than to always find the exact btrfs commit.
Just an idea.
-Andi
--
ak@linux.intel.com
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2009, #02; Sun, 11)
From: Junio C Hamano @ 2009-01-11 20:24 UTC (permalink / raw)
To: Alexander Potashev; +Cc: git
In-Reply-To: <20090111122128.GA16108@myhost>
Alexander Potashev <aspotashev@gmail.com> writes:
>> * jc/maint-format-patch (Sat Jan 10 12:41:33 2009 -0800) 1 commit
>> + format-patch: show patch text for the root commit
>
> My testcases ([PATCH] Add new testcases for format-patch root commits)
> for this don't satisfy the target behaviour.
I thought I squashed the test case from your original to it and they seem
to pass for me, but maybe you are talking about some other tests? If you
know of breakages please send in incremental updates.
>> * ap/clone-into-empty (Fri Jan 9 02:24:23 2009 +0300) 2 commits
>> - Use is_pseudo_dir_name everywhere
>> - Allow cloning to an existing empty directory
>
> As far as I understood from your message, you don't think that cloning
> into empty directories is necessary. So, I thought, the best solution for
> yesterday was "[PATCH] add is_dot_or_dotdot inline function" (to make you
> happy ;)).
I merely said "I am not particularly interested in it." That's quite
different from "I oppose and reject".
As long as the new feature is maintainability-wise low-impact and does not
hurt users who do _not_ use it, I am not opposed to have a new feature
even when I see it is only narrowly useful.
If a topic brings in a large change that helps to support only one
particular workflow better, while making it cumbersome to update the
resulting code to support some other workflow later, even if the change is
useful for users of that one particular workflow, I may oppose it. It
would be high-impact from the maintainability point of view [*1*].
But I do not think your "clone here" falls into that category.
It is really up to you to follow through with it, and people with similar
needs to cheer you on. I thought you took a good strategy to first get
dot-or-dotdot in (which is generally useful), hoping to bring up the
"clone here" topic again by building on top of it later.
> Btw, I've sent some worthwhile patches, I but haven't got any reply from you:
> [PATCH] use || instead of | in logical expressions
> [PATCH] Replace deprecated dashed git commands in usage
> [PATCH] remove unnecessary 'if'
> It's better if you say "No" than nothing.
I do not recall the last one.
The first one I thought was a trivial janitor patch that (1) didn't matter
very deeply but made things somewhat easier to read, and more importantly
(2) you had "oops" reply to yourself.
I often clean up trivial "oops" in a patch that fixes bugs or adds
features to avoid extra round trip with the contributor, but that is only
when bugfix and enhancements are worthwhile by itself.
The purpose of a clean-up patch is to clean things up. If it itself has
"oops" in it, that fails its own criteria of goodness. Please don't
expect/force me to spend time cleaning up "oops" in a clean-up patch, but
submit a replacement I can apply straight out of my mailbox.
The second one I was expecting to hear from people who were involved in
the discussion back when we standardized on dashless form to show hands as
I recall these messages were deliberately left with dashed form for some
reason (perhaps to help avoiding "man git foo" vs "man git-foo"
confusion).
[Footnote]
*1* Such a change probably needs to be justified either by showing any
other workflow does not make sense (so supporting that one true workflow
well is sufficient) or by demonstrating that support for some other
equally valid workflows can be included trivially, or both.
^ permalink raw reply
* [JGIT] Blame functionality for jgit
From: Manuel Woelker @ 2009-01-11 20:23 UTC (permalink / raw)
To: spearce, Robin Rosenberg; +Cc: git
Hello there,
Over the weekend I have been hacking the jgit sources a little to see
if I can add blame/praise/annotate functionality to it. The results
can be found at http://github.com/manuel-woelker/egit/tree/blame . All
work is in the blame branch in org.spearce.jgit.blame package.
I largely ported the cgit blame algorithm described here
https://kerneltrap.org/mailarchive/git/2006/10/12/224187 , the
relevant file is builtin-blame.c cf.
http://repo.or.cz/w/git.git?a=blob;f=builtin-blame.c;hb=HEAD
The structure has been kept largely intact, but I have tried to
translate the concepts to idiomatic java, with the bulk of the logic
now in the Scoreboard class
The blame algorithm needs to use a diff algorithm to find common parts
in files. AFAICT there is no diff implementation in jgit at the
moment. I used the incava java-diff library, (see
http://www.incava.org/projects/java/java-diff ), but I introduced an
interface that should make it possible to swap implementations with a
minimum of effort. To compile I just create a new eclipse project with
the java-diff sources.
Currently renames, copies etc. are not supported, so only files with
the same name can receive the blame. Unmodified renames and copies
should be fairly simple to implement. Modified renames and copies
might prove to be a little bit harder, so that would have to wait
until jgit can follow history across renames/copies.
There are some simple unit tests to check the basic functionality. I
also "blamed" SUBMITTING_PATCHES in the egit repo, and got the same
results as cgit. I am certain that there a some bugs lurking in the
code, but overall it looks quite promising.
I would like to hear your thoughts on a couple of topics:
- Merge/patch/diff/blame functionality needs a diff implementation,
what are our options within technical and license constraints?
- What is the roadmap for these features?
- Can you see this blame effort getting integrated upstream?
I would love to contribute more effort to egit and the blame
functionality in particular. To me, "blame" is one of the killer
features of modern SCMs.
Last no least, kudos to the git and egit teams for their hard work on
making git such a great piece of software.
- Manuel Woelker
^ permalink raw reply
* Re: [RFC PATCH 0/3] Support for importing in builtin-fetch
From: Johannes Schindelin @ 2009-01-11 20:20 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git, Junio C Hamano
In-Reply-To: <alpine.LNX.1.00.0901110318530.19665@iabervon.org>
Hi,
On Sun, 11 Jan 2009, Daniel Barkalow wrote:
> This series is an attempt to standardize importers and exporters for
> non-git upstream repositories, and to allow the normal git programs to
> use them transparently when configured to do so.
Cute!
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Cleanup of unused symcache variable inside diff-lib.c
From: Johannes Schindelin @ 2009-01-11 20:17 UTC (permalink / raw)
To: Kjetil Barvik; +Cc: git, Junio C Hamano
In-Reply-To: <86eiz98v0s.fsf@broadpark.no>
Hi,
On Sun, 11 Jan 2009, Kjetil Barvik wrote:
> git format-patch
Necessary.
> --stat
Not necessary.
> --patch-with-raw
As I showed you, also not necessary.
> -1
Necessary.
> --signoff
If you had signed off on your commits already, not necessary. (FWIW I
keep a sign off as a marker that I actually think this is good to be
submitted, or at least close.)
> -M -C
Usualy not necessary, unless you rename some file, or introduce a huge
code
duplication.
> --summary
Dunno. I think it's not really necessary, you see that from the diff.
> --full-index
I find it makes the patch hard to read, as the index line will always
wrap. And it's not necessary, as it is so highly unlikely that the hash
is unique in your repository, but not mine.
> --subject-prefix="PATCH"
Not necessary.
> --output-directory ../diff_lib_c_symcache_cleanup_v1/
If you insist...
Sure, you can make it complicated, but I usually prefer something like
$ git format-patch -3 --cover-letter
Nice 'n easy.
Ciao,
Dscho
^ 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