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 project
Jeff King p...@peff.net 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
Johannes Sixt j...@kdbg.org 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
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
-
Christian Couder christian.cou...@gmail.com writes:
On Tue, Mar 10, 2015 at 6:23 PM, Junio C Hamano gits...@pobox.com 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
Junio C Hamano gits...@pobox.com writes:
Johannes Sixt j...@kdbg.org 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
Kevin Daudt m...@ikke.info 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.
Am 10.03.2015 um 23:54 schrieb Junio C Hamano:
Michael Haggerty mhag...@alum.mit.edu 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:
On Wed, Mar 11, 2015 at 07:33:05PM +, Dan Langille (dalangil) wrote:
On Mar 10, 2015, at 6:29 PM, brian m. carlson sand...@crustytoothpaste.net
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
On Tue, Mar 10, 2015 at 04:12:18PM -0700, Junio C Hamano wrote:
Kevin Daudt m...@ikke.info 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
Peter Krefting pe...@softwolves.pp.se 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
Torsten Bögershausen tbo...@web.de writes:
On 03/10/2015 11:54 PM, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu 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.
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
Auto complete stashed modifications for gitk. This makes them easier to
discover and faster to view.
Signed-off-by: Sveinung Kvilhaugsvik sveinun...@users.sourceforge.net
---
contrib/completion/git-completion.bash | 2 ++
1 file changed, 2 insertions(+)
diff --git
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 *
On 12 March 2015 at 08:28, Junio C Hamano gits...@pobox.com 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
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
brian m. carlson sand...@crustytoothpaste.net 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
Previously, git-credential-store only supported storing credentials in a
single file: ~/.git-credentials. In order to support the XDG base
directory specification[1], git-credential-store needs to be able to
lookup and erase credentials from multiple files, as well as to pick the
appropriate file
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 does not exist.
* On the flip side, if the XDG file
The previous patch series can be found at [1].
[1] http://thread.gmane.org/gmane.comp.version-control.git/265042
The changes for git-credential-store: support multiple credential files are
as follows:
* store_credential(), instead of taking an index to the string_list for the
default filename,
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 new section FILES that lists out the credential
file paths
Add $XDG_CONFIG_HOME/git/credentials to the default credential search
path of git-credential-store. This allows git-credential-store to
support user-specific configuration files in accordance with the XDG
base directory specification[1].
[1]
Junio C Hamano venit, vidit, dixit 10.03.2015 18:06:
Michael J Gruber g...@drmicha.warpmail.net 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:
On Tue, Mar 10, 2015 at 10:11 PM, Junio C Hamano gits...@pobox.com wrote:
Shawn Pearce spea...@spearce.org writes:
We keep seeing reports of Gerrit Code Review users who incorrectly do
something like:
git clone URL foo
cd foo
git commit --amend -m My first change! -a
git push URL
On Wed, Mar 11, 2015 at 12:31 AM, Jeff King p...@peff.net 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 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 warning,
On Tue, Mar 10, 2015 at 11:00 PM, Shawn Pearce spea...@spearce.org wrote:
OK, replace that Gerrit-specific push syntax with:
git send-email
:)
Heh don't be too defensive; I was merely pulling your leg.
... But I am not sure what the definition of
unusual should be. In a non-Gerrit
On Wed, Mar 11, 2015 at 2:49 AM, Paul Tan pyoka...@gmail.com 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
On Wed, Mar 11, 2015 at 2:49 AM, Paul Tan pyoka...@gmail.com 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
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 and giving
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 9:11 PM, Torsten Bögershausen tbo...@web.de 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 pclo...@gmail.com
---
.. while I'm looking at config.txt. I think this is the preferred naming
convention for config keys.
I think
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 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,
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, losing
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.
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 amp; Clementine from the
local
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 sand...@crustytoothpaste.net
---
commit.c | 32
commit.h | 4 ++--
log-tree.c| 2 +-
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 included in
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
On Tue, Mar 10, 2015 at 6:23 PM, Junio C Hamano gits...@pobox.com wrote:
Christian Couder christian.cou...@gmail.com 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
Duy Nguyen pclo...@gmail.com writes:
On Wed, Mar 11, 2015 at 11:16 AM, Junio C Hamano gits...@pobox.com wrote:
Duy Nguyen pclo...@gmail.com writes:
... We may want to acknowledge review efforts as well, by
grepping Helped-by:, Reviewed-by:...
Agreed. Something along the lines of
$
Jeff King p...@peff.net 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
On Wed, Mar 11, 2015 at 11:16 AM, Junio C Hamano gits...@pobox.com wrote:
Duy Nguyen pclo...@gmail.com 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
45 matches
Mail list logo
