Am 20.02.2015 um 00:52 schrieb Mike Hommey:
Hi,
I was trying to use --color-words with a regex to check a diff, and it appears
it displays things out of order. Am I misunderstanding what my regexp should be
doing or is there a bug?
$ git diff -U3 HEAD^ dom/base/nsDOMFileReader.cpp
diff --git a/
On Fri, Feb 20, 2015 at 06:35:09AM +0100, Michael Haggerty wrote:
> On 02/18/2015 08:14 PM, Jeff King wrote:
> > The response to my previous email was not overwhelming, but people did
> > express some interest in Git doing GSoC this year. So I've started on
> > the application, using last year's v
On Fri, Feb 20, 2015 at 10:26:15AM +0700, Duy Nguyen wrote:
> On Thu, Feb 19, 2015 at 2:14 AM, Jeff King wrote:
> > and the list of microprojects:
> >
> > http://git.github.io/SoC-2015-Microprojects.html
> >
>
> There is debian bug 777690 [1] that's basically about making tag's
> version sort
On Feb 19, 2015 5:42 PM, David Turner wrote:
>
> On Fri, 2015-02-20 at 06:38 +0700, Duy Nguyen wrote:
> > > * 'git push'?
> >
> > This one is not affected by how deep your repo's history is, or how
> > wide your tree is, so should be quick..
> >
> > Ah the number of refs may affect both g
On 02/18/2015 08:14 PM, Jeff King wrote:
> The response to my previous email was not overwhelming, but people did
> express some interest in Git doing GSoC this year. So I've started on
> the application, using last year's version as a template.
Regretfully, I can't in good conscience volunteer to
On Thu, Feb 19, 2015 at 02:21:11PM +0100, Michael J Gruber wrote:
> > It passes NO_ICONV through to the test suite, sets up a prerequisite,
> > disables some test scripts which are purely about i18n (e.g.,
> > t3900-i18n-commit), and marks some of the scripts with one-off tests
> > using the ICONV
On Thu, Feb 19, 2015 at 10:02:12AM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > Yeah, I think this is a good fix. I had a vague feeling that we may have
> > done this on purpose to let the decoration color "inherit" from the
> > existing colors for backwards compatibility, but I don't
On Thu, Feb 19, 2015 at 2:14 AM, Jeff King wrote:
> and the list of microprojects:
>
> http://git.github.io/SoC-2015-Microprojects.html
>
There is debian bug 777690 [1] that's basically about making tag's
version sort aware about -rc, -pre suffixes. I imagine it would touch
versioncmp.c and bui
On Thu, Feb 19, 2015 at 11:32:46AM +0100, Matthieu Moy wrote:
> > I do need somebody to volunteer as backup admin. This doesn't need
> > to involve any specific commitment, but is mostly about what to do if I
> > get hit by a bus.
>
> If you promise me to try hard not to be hit by a bus and no on
Once we know the number of objects in the input pack, we allocate an
array of nr_objects of struct delta_entry. On x86-64, this struct is
32 bytes long. The union delta_base, which is part of struct
delta_entry, provides enough space to store either ofs-delta (8 bytes)
or ref-delta (20 bytes).
Not
For each object in the input pack, we need one struct object_entry. On
x86-64, this struct is 64 bytes long. Although:
- The 8 bytes for delta_depth and base_object_no are only useful when
show_stat is set. And it's never set unless someone is debugging.
- The three fields hdr_size, type and
Compared to 'pu', the first patch is unchanged, except the commit
message. The second patch has __attribute((packed)) removed because it
causes problems on some ARM systems. x86 people who want to save more
memory just have to put it back by themselves.
Nguyễn Thái Ngọc Duy (2):
index-pack: redu
On Fri, 2015-02-20 at 06:38 +0700, Duy Nguyen wrote:
> >* 'git push'?
>
> This one is not affected by how deep your repo's history is, or how
> wide your tree is, so should be quick..
>
> Ah the number of refs may affect both git-push and git-pull. I think
> Stefan knows better than I in this
On Fri, Feb 20, 2015 at 6:29 AM, Ævar Arnfjörð Bjarmason
wrote:
> Anecdotally I work on a repo at work (where I'm mostly "the Git guy") that's:
>
> * Around 500k commits
> * Around 100k tags
> * Around 5k branches
> * Around 500 commits/day, almost entirely to the same branch
> * 1.5 GB .git
On Thu, Feb 19, 2015 at 04:26:58PM -0500, Stephen Morton wrote:
> I posted this to comp.version-control.git.user and didn't get any response. I
> think the question is plumbing-related enough that I can ask it here.
>
> I'm evaluating the feasibility of moving my team from SVN to git. We have a
>
Hi,
I was trying to use --color-words with a regex to check a diff, and it appears
it displays things out of order. Am I misunderstanding what my regexp should be
doing or is there a bug?
$ git diff -U3 HEAD^ dom/base/nsDOMFileReader.cpp
diff --git a/dom/base/nsDOMFileReader.cpp b/dom/base/nsDOM
On Feb 19, 2015, at 09:49, Junio C Hamano wrote:
"Kyle J. McKay" writes:
What about a shortcut to "reset-and-apply" as well?
I have often been frustrated when "git stash apply" refuses to work
because I have changes that would be stepped on and there's no --
force
option like git checkout h
On Fri, Feb 20, 2015 at 4:26 AM, Stephen Morton
wrote:
> By 'performance', I guess I mean speed of day to day operations for devs.
>
>* (Obviously, trivially, a (non-local) clone will be slow with a large
> repo.)
>* Will a few simultaneous clones from the central server also slow down
>
On Thu, Feb 19, 2015 at 10:26 PM, Stephen Morton
wrote:
> I posted this to comp.version-control.git.user and didn't get any response. I
> think the question is plumbing-related enough that I can ask it here.
>
> I'm evaluating the feasibility of moving my team from SVN to git. We have a
> very
>
On Thu, Feb 19, 2015 at 3:06 PM, Stephen Morton
wrote:
>
> I think I addressed most of this in my original post with the paragraph
>
> "Assume ridiculous numbers. Let me exaggerate: say 1 million commits,
> 15 GB repo,
> 50k tags, 1,000 branches. (Due to historical code fixups, another
> 5,000
On Thu, Feb 19, 2015 at 5:21 PM, Stefan Beller wrote:
> On Thu, Feb 19, 2015 at 1:26 PM, Stephen Morton
> wrote:
>> I posted this to comp.version-control.git.user and didn't get any response. I
>> think the question is plumbing-related enough that I can ask it here.
>>
>> I'm evaluating the feasi
On Thu, Feb 19, 2015 at 1:26 PM, Stephen Morton
wrote:
> I posted this to comp.version-control.git.user and didn't get any response. I
> think the question is plumbing-related enough that I can ask it here.
>
> I'm evaluating the feasibility of moving my team from SVN to git. We have a
> very
> l
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
The second and third batch of topics have been merged to 'master'.
I am tempted to start discarding topics in the Stalled category that
haven't
I posted this to comp.version-control.git.user and didn't get any response. I
think the question is plumbing-related enough that I can ask it here.
I'm evaluating the feasibility of moving my team from SVN to git. We have a very
large repo. [1] We will have a central repo using GitLab (or similar)
On Wed, Feb 18, 2015 at 04:17:46PM +, Dan Langille (dalangil) wrote:
> I just built from ‘master’, on FreeBSD 9.3:
>
> cd ~/src
> git clone https://github.com/git/git.git
> cd git
> gmake
>
> Then tried ~/src/git/git clone https://OUR_REPO
>
> It cores too, and I see: git-remote-https.core
On Tue, Feb 17, 2015 at 09:51:38AM +0100, Matthieu Moy wrote:
> This should be fixable from Git itself, by replacing the calls to
> "unlink" with something like
>
> int unlink_or_chmod(...) {
> if (unlink(...)) {
> chmod(...); // give user write permission
> retur
On Thu, Feb 19, 2015 at 09:54:52AM -0800, Junio C Hamano wrote:
I can see that you do not agree with the "If we accept it" part
(where "it" refers to "allowing [...] was a bug.")---past acceptance
was not a bug for you.
Brian is for that "If we accept it", and sees it as a bug.
So let's see wha
On Thu, 19 Feb 2015 14:21:11 +0100, Michael J Gruber
wrote:
> Jeff, you got it wrong. You should do the hard part and leave the easy
> part to us!
>
> Thanks anyways, I'll add this to my HP_UX branch.
I did not mention this in earlier mails. When using the HP C-ANSI-C
compiler, MAX_INT is not s
The documentation of 'git submodule update' has several problems:
1) It mentions that value 'none' of submodule.$name.update can be
overridden by --checkout, but other combinations of configuration
values and command line options are not mentioned.
2) The documentation of submodule.$name.up
Michael J Gruber writes:
> Randall S. Becker venit, vidit, dixit 19.02.2015 14:32:
>> git symbolic-ref --short HEAD
>
> That errors out when HEAD is detached.
Isn't that what you would want to happen anyway?
if current=$(that command)
then
you know $current is ch
Jeff King writes:
> Yeah, I think this is a good fix. I had a vague feeling that we may have
> done this on purpose to let the decoration color "inherit" from the
> existing colors for backwards compatibility, but I don't think that
> could ever have worked (since color.decorate.* never defaulted
Torsten Bögershausen writes:
> On 02/18/2015 07:40 PM, Junio C Hamano wrote:
>> "brian m. carlson" writes:
>>
>>> I understand that this used to work, but it probably shouldn't have
>>> ever been accepted. It's nonstandard, and if we accept it for ssh,
>>> people will want it to work for https,
On Thu, Feb 19 2015, Junio C Hamano wrote:
> Michal Sojka writes:
>
>> The documentation of 'git submodule update' has several problems:
>>
>> 1) It says that submodule.$name.update can be overridden by --checkout
>>only if its value is `none`.
>
> Hmm, I do not read the existing sentence that
"Kyle J. McKay" writes:
> What about a shortcut to "reset-and-apply" as well?
>
> I have often been frustrated when "git stash apply" refuses to work
> because I have changes that would be stepped on and there's no --force
> option like git checkout has. I end up doing a reset just so I can
> ru
On 02/18/2015 07:40 PM, Junio C Hamano wrote:
> "brian m. carlson" writes:
>
>> On Thu, Jan 22, 2015 at 11:05:29PM +0100, Torsten Bögershausen wrote:
>>> We want to support ssh://bmc@2001:470:1f05:79::1/git/bmc/homedir.git/
>>> because e.g. the Git shipped with Debian (1.7.10.4) (and a lot of
>>
Randall S. Becker venit, vidit, dixit 19.02.2015 14:32:
> git symbolic-ref --short HEAD
That errors out when HEAD is detached.
git rev-parse --symbolic-full-name [--abbrev-ref] HEAD
returns the branch name or HEAD. Though it's a bit difficult to discover.
I guess git 3.0 will have "git branch"
I have a (fsck-clean) git tree in which for 2 commits A and B:
* "git merge-base --is-ancestor A B" returns 0
* "git log B..A" returns a non-empty set of commits
I get this behaviour with 2.3.0 as well as with 2.1.3 and 1.7.12.
Is that a real bug or am I just misinterpreting something ?
--
To un
Hi Folks,
I encounter unexpected behavior in the following case:
file content:
line1
line2
line3
line4
This is what I get as console output (on Windows):
> git blame -s file.txt
7db36436 1) line1
line3436 2) line2
7db36436 3) line4
This is the real content:
> git blame -s file.txt > blame.tx
On Feb 19, 2015, at 04:34, Michael J Gruber wrote:
"git stash save" performs the steps "create-store-reset". Often,
users try to use "stash save" as a way to to save their current state
(index, worktree) before an operation like "checkout/reset --patch"
they
don't feel confident about, and are
Hi Martin,
I use:
git symbolic-ref --short HEAD
in scripts. Not sure it's the best way, but it works 100% for me.
Regards,
Randall
-Original Message-
From: git-ow...@vger.kernel.org [mailto:git-ow...@vger.kernel.org] On Behalf Of
mdc...@seznam.cz
Sent: February 19, 2015 8:15 AM
To: gi
Jeff King venit, vidit, dixit 19.02.2015 13:54:
> On Thu, Feb 19, 2015 at 12:20:02PM +0100, Michael J Gruber wrote:
>
>> OK, so we should use NO_ICONV on HP_UX then.
>>
Failing so many tests with NO_ICONV is certainly not ideal, but I'm not
sure we should care to protect so many tests wi
Hello,
To start with, I did not find an official way to submit feature request so
hopefully this is the right way to do so - if not then my apologize &
appreciate if somebody could re-submit to the proper place.
I'd like to request adding a parameter to 'git branch' that would only show the
cu
On Thu, Feb 19, 2015 at 12:20:02PM +0100, Michael J Gruber wrote:
> OK, so we should use NO_ICONV on HP_UX then.
>
> >> Failing so many tests with NO_ICONV is certainly not ideal, but I'm not
> >> sure we should care to protect so many tests with a prerequisite.
> >
> > How feasible is it to iso
"git stash save" performs the steps "create-store-reset". Often,
users try to use "stash save" as a way to to save their current state
(index, worktree) before an operation like "checkout/reset --patch" they
don't feel confident about, and are forced to do "git stash save && git
stash apply".
Prov
H.Merijn Brand venit, vidit, dixit 19.02.2015 12:14:
> On Thu, 19 Feb 2015 11:33:01 +0100, Michael J Gruber
> wrote:
>
>> Jeff King venit, vidit, dixit 18.02.2015 19:57:
>>> On Wed, Feb 18, 2015 at 10:47:16AM -0800, Junio C Hamano wrote:
>>>
> It seems like we could use
>
> (cd src
On Thu, 19 Feb 2015 11:33:01 +0100, Michael J Gruber
wrote:
> Jeff King venit, vidit, dixit 18.02.2015 19:57:
> > On Wed, Feb 18, 2015 at 10:47:16AM -0800, Junio C Hamano wrote:
> >
> >>> It seems like we could use
> >>>
> >>> (cd src && tar cf - .) | (cd dst && tar xf -)
> >>>
> >>> here as a
On Wed, Feb 18, 2015 at 5:07 PM, Junio C Hamano wrote:
> Julien's "HEAD=master, other" vs "HEAD, master, other" may be
> subdued enough to be undistracting, I would guess. I do not think
> the distinction between "HEAD = master" and "HEAD -> master" would
> be useful, on the other hand.
Just to
Kyle J. McKay venit, vidit, dixit 19.02.2015 02:17:
> On Feb 18, 2015, at 01:46, Michael J Gruber wrote:
>> Armin Ronacher venit, vidit, dixit 16.02.2015 14:29:
>>> Hi,
>>>
>>> On 16/02/15 13:09, Ævar Arnfjörð Bjarmason wrote:
We should definitely make recovery like this harder, but is there a
Jeff King venit, vidit, dixit 18.02.2015 19:57:
> On Wed, Feb 18, 2015 at 10:47:16AM -0800, Junio C Hamano wrote:
>
>>> It seems like we could use
>>>
>>> (cd src && tar cf - .) | (cd dst && tar xf -)
>>>
>>> here as a more portable alternative. I don't think we can rely on rsync
>>> being every
Jeff King writes:
> I do need somebody to volunteer as backup admin. This doesn't need
> to involve any specific commitment, but is mostly about what to do if I
> get hit by a bus.
If you promise me to try hard not to be hit by a bus and no one else
steps in, I can be the backup admin.
> Where
On 02/18/2015 07:28 PM, Duy Nguyen wrote:> On Wed, Feb 18, 2015 at 7:50
> Use what sha1_object_info() uses behind the scene. Loose object
> encodes object type as a string, you could just print that string and
> skip the enum object_type conversion. You probably need special
> treatment for packe
Junio C Hamano venit, vidit, dixit 18.02.2015 20:49:
> Michael J Gruber writes:
>
>> Yep, it very well is. Also, that approach would tell you which branch is
>> checked out, though I don't consider that git log's business.
>>
>> OTOH, it's "backwards" in the sense that it marks the "ordinary" cas
52 matches
Mail list logo
