Jeff King writes:
> I spent many years as a "type C" contributor, and I remember how nice it
> was to see my name mentioned occasionally as a useful person.
I guess that everybody is different ;-)
After throwing a small patch at ROCKbox (git.rockbox.org) back when
they were still hosted on Subv
Duy Nguyen writes:
> On Wed, Mar 11, 2015 at 11:16 AM, Junio C Hamano wrote:
>> Duy Nguyen writes:
>>
>>> ... We may want to acknowledge review efforts as well, by
>>> grepping Helped-by:, Reviewed-by:...
>>
>> Agreed. Something along the lines of
>>
>> $ git shortlog --no-merges -s -n -t H
On Wed, Mar 11, 2015 at 11:16 AM, Junio C Hamano wrote:
> Duy Nguyen writes:
>
>> ... We may want to acknowledge review efforts as well, by
>> grepping Helped-by:, Reviewed-by:...
>
> Agreed. Something along the lines of
>
> $ git shortlog --no-merges -s -n -t Helped-by -t Reviewed-by v2.3.0.
Rip and transfer Blu-ray films to Galaxy Note Pro 12.2
Want to put Blu-ray onto Galaxy Note Pro 12.2 for watching on the go, but
don't know what to do? Get the solution below to rip Blu-ray to Note Pro
native video.
I have some Blu-ray discs like Amour and Ernest & Clementine from the
local libr
The first two messages in this thread were dropped by the vger mailing
list for some unknown reason.
In an attempt to make the mailing list archives of this thread
complete, the original two messages in this thread are included below.
-Kyle
BEGIN FIRST MESSAGE
From: Kyle J. McKay
Auto complete stashed modifications for gitk. This makes them easier to
discover and faster to view.
Signed-off-by: Sveinung Kvilhaugsvik
---
contrib/completion/git-completion.bash | 2 ++
1 file changed, 2 insertions(+)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
It is becoming clear that the upcoming release will be a usual
incremental improvements and not an earth shattering one. Let's
decide to name it
"brian m. carlson" writes:
> Michael Haggerty recommended that I call the structure element sha1
> instead of oid in case we want to turn this into a union if we decide to
> go the additional hash route.
I'd advise against it.
As I wrote in $gmane/265337 in response to Michael:
> 4. We con
On 12 March 2015 at 08:28, Junio C Hamano wrote:
> OK, I've updated the Announce script on the 'todo' branch. The
> announcement for 2.3.2 I sent out earlier as $gmane/264975 would
> have looked like this.
I think the changes are excellent, and think they add a lot of value
regardless of any oth
On Wed, Mar 11, 2015 at 03:20:08PM +0100, Michael Haggerty wrote:
On 03/08/2015 12:23 AM, brian m. carlson wrote:
struct directory {
struct directory *up;
- unsigned char sha1[20];
+ unsigned char sha1[GIT_SHA1_RAWSZ];
This is a local struct, and I think it is only a three
On Tue, Mar 10, 2015 at 07:38:42PM -0700, Kyle J. McKay wrote:
GIT_SHA1_HEXSZ will always be exactly 2 * GIT_SHA1_RAWSZ, right? In
fact, if it's not things will almost certainly break, yes?
Does it make more sense then to reflect this requirement by using:
#define GIT_SHA1_HEXSZ (2 * GIT_SHA1
On Wed, Mar 11, 2015 at 07:33:05PM +, Dan Langille (dalangil) wrote:
On Mar 10, 2015, at 6:29 PM, brian m. carlson
wrote:
Does it work with a ticket if you specify a username, as in the
following URL?
https://b...@git.crustytoothpaste.net/git/bmc/homedir.git
Yes, that does work. Our proj
Junio C Hamano writes:
> Johannes Sixt writes:
>
>> Isn't it more like: Here we are interested in the "eol" attribute of
>> this file named "a.foo". And the lookup would find the first line that
>> says "eol=crlf". Elsewhere, we are interested in the "binary"
>> attribute of the file named "a.fo
Johannes Sixt writes:
>> I would say former. You find out what attributes apply to a path
>> and then consider the collective effect of these attributes that
>> survived.
>>
>> So the second "No it is not text" which is overruled by the "oops,
>> no that is text" later should not get in the pict
Jeff King writes:
> Or something along those lines. The wording and indentation of the
> message could probably use tweaking. And there is a bash-ism in the
> script. :)
OK, I've updated the Announce script on the 'todo' branch. The
announcement for 2.3.2 I sent out earlier as $gmane/264975 wou
Christian Couder writes:
> On Tue, Mar 10, 2015 at 6:23 PM, Junio C Hamano wrote:
>>
>> I would suspect that those who agree with you would appreciate if
>> you or somebody volunteered to act as our CKDO (chief kudos
>> distribution officer). I do not think I have enough time to do that
>> well
On Wed, Mar 11, 2015 at 07:20:18PM +0700, Nguyễn Thái Ngọc Duy wrote:
> This should improve readability. Compare "thislongname" and
> "thisLongName". The following keys are left in unchanged. We can
> decide what to do with them later.
>
> - am.keepcr
> - core.autocrlf .safecrlf .trustctime
> -
Am 10.03.2015 um 23:54 schrieb Junio C Hamano:
Michael Haggerty writes:
Well, that's true, but the "eol" attribute can regain its effect if
"binary" is followed by "text" or "text=auto". So I guess the simplest
question is as follows. Suppose I have the following .gitattributes:
a.foo eo
Kevin Daudt writes:
> On Tue, Mar 10, 2015 at 04:12:18PM -0700, Junio C Hamano wrote:
>
>> What does such a command line _mean_? It tells us this:
>>
>> Define a set by having the "bad" ref as a positive end, and
>> having all the "good" refs as negative (uninteresting) boundary.
>>
>>
On Tue, Mar 10, 2015 at 04:12:18PM -0700, Junio C Hamano wrote:
> Kevin Daudt writes:
>
> > git log --bisect seems to do something different then git rev-list
> > --bisect
> >
> > From git-log(1):
> >
> > Pretend as if the bad bisection ref refs/bisect/bad was listed and
> > as if it was
Torsten Bögershausen writes:
> On 03/10/2015 11:54 PM, Junio C Hamano wrote:
>> Michael Haggerty writes:
>>
>>> Well, that's true, but the "eol" attribute can regain its effect if
>>> "binary" is followed by "text" or "text=auto". So I guess the simplest
>>> question is as follows. Suppose I hav
Peter Krefting writes:
> For commit --amend, I would say it would refuse to amend if the commit
> you are trying to amend
>
> 1. was not authored by yourself (and --reset-author was not given), or
> 2. is reachable (or is the tip?) from an upstream branch.
I agree that 2. is a safe check witho
On 03/08/2015 12:23 AM, brian m. carlson wrote:
> This is a patch series to convert some of the relevant uses of unsigned
> char [20] to struct object_id.
>
> The goal of this series to improve type-checking in the codebase and to
> make it easier to move to a different hash function if the projec
On 03/08/2015 12:24 AM, brian m. carlson wrote:
> Convert struct commit_graft and necessary local parts of commit.c.
>
> Signed-off-by: brian m. carlson
> ---
> commit.c | 32
> commit.h | 4 ++--
> log-tree.c| 2 +-
> send-pack.c | 2 +-
> sha
On Tue, Mar 10, 2015 at 6:23 PM, Junio C Hamano wrote:
> Christian Couder writes:
>
>> I don't want to write again about each of these points now. I am more
>> interested in discussing a good strategy to try to revert the sad
>> trend of Git developers being promoted less and less, because I thin
On 03/08/2015 12:23 AM, brian m. carlson wrote:
> There are several utility functions (hashcmp and friends) that are used
> for comparing object IDs (SHA-1 values). Using these functions, which
> take pointers to unsigned char, with struct object_id requires tiresome
> access to the sha1 member, w
Junio C Hamano venit, vidit, dixit 10.03.2015 21:20:
> JFF stands for just for fun.
>
> This is not meant to give out a model answer and is known to be
> incomplete, but I was wondering if it would be a better direction to
> allow "-" as a stand-in for "@{-1}" everywhere we allow a branch
> name,
This should improve readability. Compare "thislongname" and
"thisLongName". The following keys are left in unchanged. We can
decide what to do with them later.
- am.keepcr
- core.autocrlf .safecrlf .trustctime
- diff.dirstat .noprefix
- gitcvs.usecrlfattr
- gui.blamehistoryctx .trustmtime
-
On Tue, Mar 10, 2015 at 9:11 PM, Torsten Bögershausen wrote:
> On 10.03.15 11:39, Nguyễn Thái Ngọc Duy wrote:
>> Signed-off-by: Nguyễn Thái Ngọc Duy
>> ---
>> .. while I'm looking at config.txt. I think this is the preferred naming
>> convention for config keys.
>
> I think the default is unix-
On Wed, Mar 11, 2015 at 2:49 AM, Paul Tan wrote:
> t0302 now tests git-credential-store's support for the XDG user-specific
> configuration file $XDG_CONFIG_HOME/git/credentials. Specifically:
>
> * Ensure that the XDG file is strictly opt-in. It should not be created
> by git at all times if it
On Tue, Mar 10, 2015 at 11:18:45PM -0700, Junio C Hamano wrote:
> One thing we already do is to give an extra "Author: " line in the
> comment when the user edits the log message, so that it is clear
> that what is being edited is not their own work but hers. We obviously
> can add the extra warnin
Junio C Hamano:
Having said that, disabling --amend and forcing to use --force or
something when it is clear that the user is attempting something
unusual is a good idea. But I am not sure what the definition of
unusual should be.
For commit --amend, I would say it would refuse to amend if
On Tue, Mar 10, 2015 at 11:18:45PM -0700, Junio C Hamano wrote:
> Even though we cannot prevent the user from rewriting what _he_
> already pushed out to refs/for/master (as we do not have the record
> of what the last thing we pushed there and its history via a reflog),
> we could at least detect
Junio C Hamano venit, vidit, dixit 10.03.2015 18:06:
> Michael J Gruber writes:
>
>> So it didn't take too long to convince me after all :)
>>
>> Here comes Junio's version, preceded by a cleanup of the color
>> setting and resetting for decorations.
>>
>> Junio C Hamano (1):
>> log: decorate H
On Wed, Mar 11, 2015 at 12:38:21AM -0700, Junio C Hamano wrote:
> >> I can add "shortlog --no-merges -s -n v2.3.0..v2.4.0" at the end of
> >> the e-mail when the release notes is sent out. That might be a good
> >> enough balance between the usefulness of the release notes to its
> >> customers an
On Wed, Mar 11, 2015 at 2:49 AM, Paul Tan wrote:
> git-credential-store now supports an additional default credential file
> at $XDG_CONFIG_HOME/git/credentials. However, ~/.git-credentials takes
> precedence over it for backwards compatibility. To make the precedence
> ordering explicit, add a ne
On Wed, Mar 11, 2015 at 12:31 AM, Jeff King wrote:
> On Tue, Mar 10, 2015 at 07:36:34PM -0700, Junio C Hamano wrote:
>
>> > Or if that would make the release notes too cumbersome to review, what
>> > about using systemd's method? systemd's release notes include a
>> > "contributions from" section
On Tue, Mar 10, 2015 at 07:36:34PM -0700, Junio C Hamano wrote:
> > Or if that would make the release notes too cumbersome to review, what
> > about using systemd's method? systemd's release notes include a
> > "contributions from" section at the very end that lists everyone with
> > a patch inclu
38 matches
Mail list logo
