"Joachim Schmitz" writes:
>> I think it is the-merge-commit^2; contrib/git-resurrect.sh might be
>> of interest, too.
>
> Sorry you lost me, this is greek to me...
A commit is an object that contain pointers to its parents. The root
commit has no parent. For ordinary commits, there is one parent
Jeff King writes:
> On Sat, Sep 08, 2012 at 09:40:39PM -0700, Junio C Hamano wrote:
>
>> The built-in "binary" attribute macro expands to "-diff -text", so
>> that textual diff is not produced, and the contents will not go
>> through any CR/LF conversion ever. During a merge, it should also
>> c
Junio C Hamano writes:
> Junio C Hamano writes:
>
>> "Eric S. Raymond" writes:
>>
>>> ---
>>
>> A forgotten Sign-off?
>
> Ping? Just telling us that this is Signed-off is fine.
Ping again.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@
Junio C Hamano writes:
> I've applied these two, on top of Paul's master branch at
>
> git://ozlabs.org/~paulus/gitk.git
>
> and tentatively queued in 'pu', but I would prefer to see it
> eyeballed by and queued in his tree first.
>
> Thanks.
Pinging Paul...
The following changes since comm
Hi,
I think this has come up before [1],[2] but we ran into this at $dayjob today.
Our default MUA has an annoying habit of using a non RFC822 date format when
saving an email as plaintext. This means the first 12 days of every month we
run into the ambiguous date problem (our date convention is d
--
This testcase is only good for the next couple of months. For a longer term
test the current time would need to be set in the test setup.
---
t/t4255-am-author-date.sh | 85 +
1 file changed, 85 insertions(+)
create mode 100755 t/t4255-am-author-d
Chris Packham writes:
> Our default MUA has an annoying habit of using a non RFC822 date format when
> saving an email as plaintext. This means the first 12 days of every month we
> run into the ambiguous date problem (our date convention is dd/mm/yy).
>
> I see code in date.c for refusing a date
While looking to use the git SHA1 code, I've found some small oddities.
Please find little cosmetics fixes for them.
The patches are against 'next' and can be merged in one single patch
if needed.
Yann Droneaud (3):
sha1: update pointer and remaining length after subfunction call
sha1: clean
There's no need to update the pointer and remaining length before
leaving or calling the SHA1 sub function.
Additionnaly, the partial block code could be looking more like
the full block handling branch.
Signed-off-by: Yann Droneaud
---
block-sha1/sha1.c | 4 ++--
1 file changed, 2 insertions(+
On 09/12/2012 09:48 PM, Junio C Hamano wrote:
> Chris Packham writes:
>
>> Our default MUA has an annoying habit of using a non RFC822 date format when
>> saving an email as plaintext. This means the first 12 days of every month we
>> run into the ambiguous date problem (our date convention is dd
Junio C Hamano venit, vidit, dixit 11.09.2012 19:13:
> Thanks; I picked up $gmane/204633 but forgot to queue.
I missed that one, thanks for reducing appropriately.
Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More
The SHA context is holding a temporary buffer for partial block.
This block must 64 bytes long. It is currently described as
an array of 16 integers.
Signed-off-by: Yann Droneaud
---
block-sha1/sha1.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/block-sha1/sha1.h b/block-
One memcpy() argument is computed from a pointer added to an integer:
eg. int + pointer. It's unusal.
Let's write it in the correct order: pointer + offset.
Signed-off-by: Yann Droneaud
---
block-sha1/sha1.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/block-sha1/sha1.c b/
Recent versions of Linux libc (later than 5.4.23) and glibc (2.x)
include a malloc() implementation which is tunable via environment
variables. When MALLOC_CHECK_ is set, a special (less efficient)
implementation is used which is designed to be tolerant against
simple errors, such as double calls o
On Wed, Sep 12, 2012 at 02:25:28AM -0700, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > I've applied these two, on top of Paul's master branch at
> >
> > git://ozlabs.org/~paulus/gitk.git
> >
> > and tentatively queued in 'pu', but I would prefer to see it
> > eyeballed by and queued i
- Original Message -
> From: "Junio C Hamano"
> Sent: Wednesday, September 12, 2012 4:55:53 AM
> Subject: Re: [PATCH 2/2] attr: "binary" attribute should choose built-in
> "binary" merge driver
>
> Jeff King writes:
>
> > On Sat, Sep 08, 2012 at 09:40:39PM -0700, Junio C Hamano wrote:
On 09/11/2012 12:33 AM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> +`string_list_split`, `string_list_split_in_place`::
>> +
>> +Split a string into substrings on a delimiter character and
>> +append the substrings to a `string_list`. If `maxsplit` is
>> +non-negative, the
On Wed, Sep 12, 2012 at 01:55:53AM -0700, Junio C Hamano wrote:
> > Yeah, that seems like the obviously correct thing to do. In practice,
> > most files would end up in the first few lines of ll_xdl_merge checking
> > buffer_is_binary anyway, so I think this would really only make a
> > difference
On 09/10/2012 11:56 PM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> diff --git a/string-list.c b/string-list.c
>> index d9810ab..5594b7d 100644
>> --- a/string-list.c
>> +++ b/string-list.c
>> @@ -148,13 +148,23 @@ void print_string_list(const struct string_list *p,
>> const char *text
Junio C Hamano venit, vidit, dixit 11.09.2012 18:22:
> Michael J Gruber writes:
>
>> The current behavior is probably as useful as it is confusing. In any
>> case it is going to stay. So, document it.
>>
>> Signed-off-by: Michael J Gruber
>> ---
>> I would have written a test but don't really kn
Ping.. what happens to this patch? Do you want to support other
encodings as well via iconv()? I can't test that though.
On Tue, Sep 4, 2012 at 5:39 PM, Nguyễn Thái Ngọc Duy wrote:
> fetch does printf("%-*s", width, "foo") where "foo" can be a utf-8
> string, but width is in bytes, not columns. F
Version 3 of a patch series that adds some functions to the
string_list API. This patch series applies to current master. Thanks
for Junio for lots of great feedback.
The patch series "Clean up how fetch_pack() handles the heads list"
v3, which requires some of the new string_list functionality,
Add two new functions, string_list_split() and
string_list_split_in_place(). These split a string into a string_list
on a separator character. The first makes copies of the substrings
(leaving the input string untouched) and the second splits the
original string in place, overwriting the separato
Add a new function that appends a string to a string_list without
copying it. This can be used to pass ownership of an already-copied
string to a string_list that has strdup_strings set.
Signed-off-by: Michael Haggerty
---
Documentation/technical/api-string-list.txt | 17 ++---
stri
This function allows entries that don't match a specified criterion to
be discarded from a string_list while preserving the order of the
remaining entries.
Signed-off-by: Michael Haggerty
---
Documentation/technical/api-string-list.txt | 11 +++
string-list.c |
Add a function that finds the longest string from a string_list that
is a prefix of a given string.
Signed-off-by: Michael Haggerty
---
Documentation/technical/api-string-list.txt | 8
string-list.c | 20 +++
string-list.h
Add a function that deletes duplicate entries from a sorted
string_list.
Signed-off-by: Michael Haggerty
---
Documentation/technical/api-string-list.txt | 9 +
string-list.c | 17 +
string-list.h | 7 +++
t
In the demo code blurb, show how to initialize the string_list using
STRING_LIST_INIT_NODUP rather than memset().
Signed-off-by: Michael Haggerty
---
Documentation/technical/api-string-list.txt | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/Documentation/technical/api-stri
Should I interpret the silence as "I don't care, if you want it, go
for it" or "not acceptable, but no reasons given"? I'd like some form
of it in. Reverting the i18n diffstat patch is the last resort that I
really don't want to do.
On Sun, Aug 26, 2012 at 2:26 AM, Nguyễn Thái Ngọc Duy wrote:
> T
I am pleased to announce that version 2.7 of GNU patch has been
released. The following significant changes have happened since the
last stable release in December 2009:
* Support for most features of the "diff --git" format, including renames and
copies, permission changes, and symlink diffs.
Signed-off-by: Peter Jones
---
git-am.sh | 46 ++
1 file changed, 46 insertions(+)
diff --git a/git-am.sh b/git-am.sh
index c682d34..ebcbff7 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -216,6 +216,21 @@ check_patch_format () {
read l2
(this version with fixed tabs)
Signed-off-by: Peter Jones
---
git-am.sh | 45 +
1 file changed, 45 insertions(+)
diff --git a/git-am.sh b/git-am.sh
index c682d34..4a1a768 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -216,6 +216,21 @@ check_patch_format (
> Subject: Re: [PATCH] Handle "git show" output correctly.
No final period please.
This does not say which part of git is made to handle "git show". What
about
[PATCH] am: handle "git show" output correctly
Peter Jones writes:
This lacks a proper commit message, i.e. an answer to the "why is
Peter Jones writes:
> (this version with fixed tabs)
This will end up being the commit message. If you add text here, then
the maintainer will have to manually fix it when applying (or reject
your patch). Please, be nice with him and put your comments below the
--- :
> Signed-off-by: Peter Jone
(this version with fixed tabs and the comment fixed to be actual English)
Signed-off-by: Peter Jones
---
git-am.sh | 45 +
1 file changed, 45 insertions(+)
diff --git a/git-am.sh b/git-am.sh
index c682d34..cfd7b09 100755
--- a/git-am.sh
+++ b/git-am.s
This patch adds the ability for "git am" to accept patches in the format
generated by "git show". Some people erroneously use "git show" instead
of "git format-patch", and it's nice as a maintainer to be able to
easily take their patch rather than going back and forth with them to
get a "correctly
Peter Jones writes:
> Subject: [PATCH] [git-am] Handle "git show" output correctly
The convention in Git is ": " (i.e. no
brackets around git-am, just am: and no capital for Handle).
My other concerns (name of stgit, multi-lines subject lines and lack of
documentation) still hold.
--
Matthieu
Chris Packham writes:
> Consistent as long as you save as the default .txt. Some people have
> trained themselves to use the save as .eml option which uses RFC822
> style output.
Yuck.
> Could this be done in a applypatch-msg
> hook?
Isn't the hook about fixing up the log message? Also I do n
On 09/11/2012 02:32 AM, Peter Krefting wrote:
Now, to my question. Is there an easy way to run interactive rebase on
the upstream branch with this recipe? The best we have come up with so
far is
git checkout master # the upstream branch
git rebase -i HEAD~
and then just append everything
Stephen Bash writes:
>> Perhaps something like this makes it better.
>
> Patch didn't apply on top of the previous two for me,...
Look at 'pu' and see how it applies.
> ... The only remaining
> question for me is should -Xtheirs resolve "deleted by them"
> conflicts?
I do not know, and I do n
Michael J Gruber writes:
> It was introduced in 0ab7befa with a clear meaning (AND everything),
> then the general logic (without --all-match) was modified in 80235ba7
> (to take headermatch AND (all greps ORed)), and 5aaeb733 finally made
> multiple authors resp. committers get ORed among each o
Junio C Hamano writes:
> This is what I used to use when adding these generalized grep
> boolean expressions.
>
> With this applied,...
And this is the "this" X-<.
grep.c | 90 +-
1 file changed, 89 insertions(+), 1 deletion(-)
d
Matthieu Moy writes:
> Peter Jones writes:
>
>> Subject: [PATCH] [git-am] Handle "git show" output correctly
>
> The convention in Git is ": " (i.e. no
> brackets around git-am, just am: and no capital for Handle).
>
> My other concerns (name of stgit, multi-lines subject lines and lack of
> doc
- Original Message -
> From: "Junio C Hamano"
> Sent: Wednesday, September 12, 2012 1:01:30 PM
> Subject: Re: [PATCH 2/2] attr: "binary" attribute should choose built-in
> "binary" merge driver
>
> >> Perhaps something like this makes it better.
> >
> > Patch didn't apply on top of the p
Elia Pinto writes:
> Recent versions of Linux libc (later than 5.4.23) and glibc (2.x)
> include a malloc() implementation which is tunable via environment
> variables. When MALLOC_CHECK_ is set, a special (less efficient)
> implementation is used which is designed to be tolerant against
> simple
Michael Haggerty writes:
> On 09/11/2012 12:33 AM, Junio C Hamano wrote:
>> Michael Haggerty writes:
>>
>>> +`string_list_split`, `string_list_split_in_place`::
>>> +
>>> + Split a string into substrings on a delimiter character and
>>> + append the substrings to a `string_list`. If `maxsp
On Wed, 2012-09-12 at 17:40 +0200, Matthieu Moy wrote:
>
> How does this react to multi-line subject, e.g
>
> This should be the
> subject line.
>
> And this is the body.
>
> ?
>
> git format-patch will merge the lines in a single Subject: header, and
> your version seems to take only the firs
Nguyen Thai Ngoc Duy writes:
> Ping.. what happens to this patch? Do you want to support other
> encodings as well via iconv()? I can't test that though.
I thought I refuted a potential blocker, which was an implied
objection from Torsten, in $gmane/204912 already. As long as we
make it clear t
On Wed, 2012-09-12 at 10:32 -0700, Junio C Hamano wrote:
> We do not want to apply "git show" output that munges the log
> message, period.
>
> If you want to give patches to somebody (or to yourself) via e-mail
> or via sneaker-net, "git format-patch" is there for you. Do not
> butcher "am" to a
This patch adds the ability for "git am" to accept patches in the format
generated by "git show". Some people erroneously use "git show" instead
of "git format-patch", and it's nice as a maintainer to be able to
easily take their patch rather than going back and forth with them to
get a "correctly
Nguyen Thai Ngoc Duy writes:
> Should I interpret the silence as "I don't care, if you want it, go
> for it" or "not acceptable, but no reasons given"?
I do not speak for the others, but the reason I didn't respond is
none of the above. It is somewhere between "Meh" and "Anything that
says 'loca
Yann Droneaud writes:
> There's no need to update the pointer and remaining length before
> leaving or calling the SHA1 sub function.
>
> Additionnaly, the partial block code could be looking more like
> the full block handling branch.
>
> Signed-off-by: Yann Droneaud
> ---
> block-sha1/sha1.c
Yann Droneaud writes:
> One memcpy() argument is computed from a pointer added to an integer:
> eg. int + pointer. It's unusal.
> Let's write it in the correct order: pointer + offset.
Meh.
Both are correct. Aren't ctx->w[lenW] and lenW[ctx-w] both correct,
even?
>
> Signed-off-by: Yann Dron
On Wed, Sep 12, 2012 at 12:30:45PM +0200, Yann Droneaud wrote:
> The SHA context is holding a temporary buffer for partial block.
>
> This block must 64 bytes long. It is currently described as
> an array of 16 integers.
>
> Signed-off-by: Yann Droneaud
> ---
> block-sha1/sha1.h | 2 +-
> 1 fi
Yann Droneaud writes:
> The SHA context is holding a temporary buffer for partial block.
>
> This block must 64 bytes long. It is currently described as
> an array of 16 integers.
>
> Signed-off-by: Yann Droneaud
> ---
As we do not work with 16-bit integers anyway, 16 integers occupy 64
bytes a
Peter Jones writes:
> Let me put it a different way - if you won't accept git-am handling "git
> show" output because "git show" has output that wasn't designed to be
> parsed ever, would you be opposed to a patch that switches the "git
> show" output to be something usable?
The output from the
Am 11.09.2012 21:41, schrieb Junio C Hamano:
> Thanks. I wish all others paid attention to "What's cooking" like
> you did here.
>
> And if it is hard to do so for whatever reason, suggest a better way
> for me to publish "What's cooking" or an equivalent (I am interested
> in finding the least b
Am 11.09.2012 21:41, schrieb Junio C Hamano:
> Lilewise. It may make sense to introduce a helper function to tell
> if it is a submodule on our side by checking only the stage #2 entry
> when you see a nagetive pos returned from cache_name_pos() and call
> it "is_ours_submodule?()" or something.
On Wed, Sep 12, 2012 at 09:21:46PM +0200, Jens Lehmann wrote:
> Am 11.09.2012 21:41, schrieb Junio C Hamano:
> > Thanks. I wish all others paid attention to "What's cooking" like
> > you did here.
> >
> > And if it is hard to do so for whatever reason, suggest a better way
> > for me to publish
In case 'git cherry-pick -s ' failed, the user had to use 'git
commit -s' (i.e. state the -s option again), which is easy to forget
about. Instead, write the signed-off-by line early, so plain 'git
commit' will have the same result.
Signed-off-by: Miklos Vajna
---
Hi,
See
http://article.gmane.
Peter Jones writes:
> This patch adds the ability for "git am" to accept patches in the format
> generated by "git show". Some people erroneously use "git show" instead
> of "git format-patch", and it's nice as a maintainer to be able to
> easily take their patch rather than going back and forth
On Wed, Sep 12, 2012 at 3:21 PM, Jens Lehmann wrote:
> Am 11.09.2012 21:41, schrieb Junio C Hamano:
>> Thanks. I wish all others paid attention to "What's cooking" like
>> you did here.
>>
>> And if it is hard to do so for whatever reason, suggest a better way
>> for me to publish "What's cooking
On 12.09.12 20:02, Junio C Hamano wrote:
> Nguyen Thai Ngoc Duy writes:
>
>> Ping.. what happens to this patch? Do you want to support other
>> encodings as well via iconv()? I can't test that though.
>
> I thought I refuted a potential blocker, which was an implied
> objection from Torsten, in
Le mercredi 12 septembre 2012 à 11:42 -0700, Junio C Hamano a écrit :
> Yann Droneaud writes:
>
> > The SHA context is holding a temporary buffer for partial block.
> >
> > This block must 64 bytes long. It is currently described as
> > an array of 16 integers.
> >
> > Signed-off-by: Yann Droneau
On Wed, 2012-09-12 at 13:06 -0700, Junio C Hamano wrote:
> Peter Jones writes:
>
> > This patch adds the ability for "git am" to accept patches in the format
> > generated by "git show". Some people erroneously use "git show" instead
> > of "git format-patch", and it's nice as a maintainer to be
Le mercredi 12 septembre 2012 à 11:37 -0700, Junio C Hamano a écrit :
> Yann Droneaud writes:
>
> > One memcpy() argument is computed from a pointer added to an integer:
> > eg. int + pointer. It's unusal.
> > Let's write it in the correct order: pointer + offset.
>
> Meh.
>
> Both are correct.
Le mercredi 12 septembre 2012 à 14:38 -0400, Jeff King a écrit :
> On Wed, Sep 12, 2012 at 12:30:45PM +0200, Yann Droneaud wrote:
>
> > The SHA context is holding a temporary buffer for partial block.
> >
> > This block must 64 bytes long. It is currently described as
> > an array of 16 integers.
This patch adds the ability for "git am" to accept patches in the format
generated by "git show". Some people erroneously use "git show" instead
of "git format-patch", and it's nice as a maintainer to be able to
easily take their patch rather than going back and forth with them to
get a "correctly
On Wed, Sep 12, 2012 at 10:37:10PM +0200, Yann Droneaud wrote:
> > > diff --git a/block-sha1/sha1.h b/block-sha1/sha1.h
> > > index b864df6..d29ff6a 100644
> > > --- a/block-sha1/sha1.h
> > > +++ b/block-sha1/sha1.h
> > > @@ -9,7 +9,7 @@
> > > typedef struct {
> > > unsigned long long size;
> >
Peter Jones writes:
> Well, if that happens, maybe we could regexp match on
> "[[:alnum:]_-]+: /someexprthatlookslikeanemailaddress/" ?
I doubt that would be even reliably done.
> But we could
> also just wait to cross that bridge until we get to it?
Not really. If we start encouraging people
On Wed, Sep 12, 2012 at 1:50 PM, Yann Droneaud wrote:
>> Both are correct. Aren't ctx->w[lenW] and lenW[ctx-w] both correct,
>> even?
>>
>
> "correct" in my commit log message should be read as "the way it's used
> by most C developer".
>
> It's again a cosmetic fix.
It's a maintenance fix. The
On Wed, Sep 12, 2012 at 5:18 PM, Junio C Hamano wrote:
> Peter Jones writes:
>
>> Well, if that happens, maybe we could regexp match on
>> "[[:alnum:]_-]+: /someexprthatlookslikeanemailaddress/" ?
>
> I doubt that would be even reliably done.
>
>> But we could
>> also just wait to cross that brid
Dan Johnson writes:
> I was thinking about this earlier. I wondered if it might even be
> worth it just to CC the authors of all topics whose status has changed
> since the last what's cooking, to make sure that they see updates
> pertinent to them. I know that I at least have filters which catch
Dan Johnson writes:
>> Not really. If we start encouraging people to use "git show" output
>> as a kosher input to "am", we would have to support such use
>> forever, and we end up painting ourselves in a corner we cannot get
>> out of easily.
>
> If git am emitted a warning when accepting "git
On Wed, Sep 12, 2012 at 6:19 PM, Junio C Hamano wrote:
> Dan Johnson writes:
>
>>> Not really. If we start encouraging people to use "git show" output
>>> as a kosher input to "am", we would have to support such use
>>> forever, and we end up painting ourselves in a corner we cannot get
>>> out
Miklos Vajna writes:
> In case 'git cherry-pick -s ' failed, the user had to use 'git
> commit -s' (i.e. state the -s option again), which is easy to forget
> about. Instead, write the signed-off-by line early, so plain 'git
> commit' will have the same result.
>
> Signed-off-by: Miklos Vajna
>
Hi Junio,
The following changes since commit 16d26b168b371b2f4f86b1adb61470c6b08b27b9:
Latter half of the second batch for 1.8.0 (2012-08-29 15:00:30 -0700)
are available in the git repository at:
git://github.com/git-l10n/git-po master
for you to fetch changes up to 9a4f34bb6d11ab47d532f7
On 09/13/2012 12:19 AM, Junio C Hamano wrote:
> Dan Johnson writes:
>
>>> Not really. If we start encouraging people to use "git show" output
>>> as a kosher input to "am", we would have to support such use
>>> forever, and we end up painting ourselves in a corner we cannot get
>>> out of easily
Junio C Hamano writes:
> I think we had a separate topic around cherry-pick that needs the
> footer thing accessible from cherry-pick recently ($gmane/204755).
>
> I think the code movement in this patch is a good one.
>
> Thanks.
Having said that, the behaviour after this patch is applied is no
From: "Jens Lehmann"
Sent: Wednesday, September 12, 2012 8:21 PM
Am 11.09.2012 21:41, schrieb Junio C Hamano:
Thanks. I wish all others paid attention to "What's cooking" like
you did here.
And if it is hard to do so for whatever reason, suggest a better way
for me to publish "What's cooking"
Dan Johnson writes:
> I was assuming Peter would accept the patch, and reply with a "in the
> future, please submit the output of format-patch", thus correcting the
> submitter's behavior. This warning would serve someone who did not
> know that they wanted the output of format-patch, and hopeful
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
(sorry about double replying - html sub-part creeped in!)
On 13 September 2012 08:49, Philip Oakley wrote:
>
> From: "Jens Lehmann"
> Sent: Wednesday, September 12, 2012 8:21 PM
>
>> Am 11.09.2012 21:41, schrieb Junio C Hamano:
>>>
>>> Thanks. I wish all others paid attention to "What's cooking"
Le mercredi 12 septembre 2012 à 17:04 -0400, Jeff King a écrit :
> > > Wouldn't this break all of the code that is planning to index "W" by
> > > 32-bit words (see the definitions of setW in block-sha1/sha1.c)?
> > >
> > That's not the same "W" ... This part of the code is indeed unclear.
>
> So
"git repack" started giving the above warning, and I am guessing
that the recent 11e50b2 (attr: warn on inaccessible attribute files,
2012-08-21) exposed a bug where we ask stat(2) not lstat(2) by
mistake before deciding to append .gitattributes to see if that
directory has a per-directory attribut
85 matches
Mail list logo
