Am 10/16/2013 1:57, schrieb Jonathan Nieder:
> Junio C Hamano wrote:
>
>> You just made these two that the user clearly meant to express two
>> different things indistinguishable.
>>
>> opt.sh -S
>> opt.sh -S ''
> [...]
>> And that is exactly why gitcli.txt tells users to use the 'stick
On Tue, Oct 15, 2013 at 10:55:07PM -0500, Felipe Contreras wrote:
> John Szakmeister wrote:
> >
> > I like the idea that we could kick git into a mode that applies the
> > behaviors we're talking about having in 2.0, but I'm concerned about
> > one aspect of it. Not having these behaviors until 2
From: Alexander Hirsch <1ze...@gmail.com>
git status -bs (--branch --short) does not seem to allow customization of the
colors for the local and remote branch.
This patch adds these via the color.status.local and color.status.remote
config variables.
Given the trivial nature of this patch I did n
I was recently presented with a repository with a corrupted packfile,
and was asked if the data was recoverable. This post-mortem describes
the steps I took to investigate and fix the problem. I thought others
might find the process interesting, and it might help somebody in the
same situation.
I
On Wed, Oct 16, 2013 at 09:04:32AM +0200, Johannes Sixt wrote:
> > Yes, another possibility in that vein would be to teach rev-parse
> > --parseopt an OPTIONS_LONG_STICKED output format, and then parse with
>
> Aren't you people trying to solve something that can't besolved? What does
>
> git
On Wed, Oct 16, 2013 at 3:34 PM, Jeff King wrote:
> I was recently presented with a repository with a corrupted packfile,
> and was asked if the data was recoverable. This post-mortem describes
> the steps I took to investigate and fix the problem. I thought others
> might find the process interes
Hello Junio, Keshav
Thank you very much for your detailed reviewing.
I just tried to update the patch and posted as "[PATCH v6]".
---
Tsuneo Yoshioka (吉岡 恒夫)
yoshiokatsu...@gmail.com
On Oct 16, 2013, at 1:54 AM, Junio C Hamano wrote:
> Yoshioka Tsuneo writes:
>
>> "git diff -M --stat" can
"git diff -M --stat" can detect rename and show renamed file name like
"foofoofoo => barbarbar".
Before this commit, this output is shortened always by omitting left most
part like "...foo => barbarbar". So, if the destination filename is too long,
source filename putting left or arrow can be tota
On Tue, Oct 15, 2013 at 11:55 PM, Felipe Contreras
wrote:
[snip]
> We cannot change the behavior of push.default = simple already, so at least
> that option is not in question.
True.
> Presumably you are worried about the other options that can't be enabled in
> any
> way.
Yes.
> But think ab
On Wed, 16 Oct 2013, Johannes Sixt wrote:
> Am 10/16/2013 1:57, schrieb Jonathan Nieder:
> > Junio C Hamano wrote:
> >
> >> You just made these two that the user clearly meant to express two
> >> different things indistinguishable.
> >>
> >>opt.sh -S
> >> opt.sh -S ''
> > [...]
> >> And
- Don't start tests with 'test $? = 0' ;)
- Move writing the bogus patch and the expected output into the
appropriate test_expect_success blocks.
- Use the test_must_fail helper instead of manually checking for
non-zero exit code.
- Use the debug-friendly test_path_is_file helper instead of 'te
On Tue, 15 Oct 2013, Jonathan Nieder wrote:
> Junio C Hamano wrote:
>
> > You just made these two that the user clearly meant to express two
> > different things indistinguishable.
> >
> > opt.sh -S
> > opt.sh -S ''
> [...]
> > And that is exactly why gitcli.txt tells users to use the '
On Wed, Oct 16, 2013 at 6:54 AM, John Szakmeister wrote:
[snip]
> "probably a minority" -- I guess that's the part I disagree with. I'm
> not sure what a minority means here, but I don't think it'll be a
> handful of people. How big does that number get before we get
> concerned about backlash f
On Wednesday, October 16, 2013 02:34:01 am Jeff King wrote:
> I was recently presented with a repository with a
> corrupted packfile, and was asked if the data was
> recoverable. This post-mortem describes the steps I took
> to investigate and fix the problem. I thought others
> might find the proc
Am 15.10.2013 22:05, schrieb Jonathan Nieder:
> Jens Lehmann wrote:
>> Am 15.10.2013 21:16, schrieb Jonathan Nieder:
>
>>> So I suspect this will fix more scripts than it breaks, though it may
>>> still break some. :/
>>
>> Hmm, I'm really not sure if we should do this or not.
>
> What convinced
On Sun, Sep 08, 2013 at 04:03:11AM -0400, Jeff King wrote:
> > I have some free time to come, and would like to work on that feature.
> > Does the offer still hold ?
> > If it does, I would be interested in your patches.
>
> I'm sorry I have taken so long to get back to you on this. I was hoping
On Wed, Oct 16, 2013 at 7:56 PM, Jeff King wrote:
> On Sun, Sep 08, 2013 at 04:03:11AM -0400, Jeff King wrote:
>
>> > I have some free time to come, and would like to work on that feature.
>> > Does the offer still hold ?
>> > If it does, I would be interested in your patches.
>>
>> I'm sorry I ha
Commit 15a147e (rebase: use @{upstream} if no upstream specified,
2011-02-09) says:
Make it default to 'git rebase @{upstream}'. That is also what
'git pull [--rebase]' defaults to, so it only makes sense that
'git rebase' defaults to the same thing.
but that isn't actuall
Hi,
John Keeping wrote:
>Since commit d44e712 (pull: support
> rebased upstream + fetch + pull --rebase, 2009-07-19), pull has actually
> chosen the most recent reflog entry which is an ancestor of the current
> branch if it can find one.
>
> Change rebase so t
Krzysztof Mazur wrote:
> On Tue, Oct 15, 2013 at 11:03:26PM -0500, Felipe Contreras wrote:
> > > not some "next" behavior that may change in future.
> >
> > But I'm suggesting to add a core.addremove option as well, like you
> > suggested,
> > am I not?
>
> Yes, I think we both agreed on adding
Krzysztof Mazur wrote:
> On Tue, Oct 15, 2013 at 10:55:07PM -0500, Felipe Contreras wrote:
> > John Szakmeister wrote:
> > >
> > > I like the idea that we could kick git into a mode that applies the
> > > behaviors we're talking about having in 2.0, but I'm concerned about
> > > one aspect of it.
On Wed, Oct 16, 2013 at 12:24:13PM -0700, Jonathan Nieder wrote:
> John Keeping wrote:
>
> >Since commit d44e712 (pull: support
> > rebased upstream + fetch + pull --rebase, 2009-07-19), pull has actually
> > chosen the most recent reflog entry which is an ances
When I use the `--progress` flag with the push command, I get transfer-speed
statistics like this:
$ git push -progress origin master 2>&1 | tee /tmp/push
Counting objects: 30, done.
Compressing objects: 100% (20/20), done.
Writing objects: 100% (30/30), 9.02 MiB | 206.00 KiB/s, d
John Szakmeister wrote:
> On Tue, Oct 15, 2013 at 11:55 PM, Felipe Contreras
> wrote:
> [snip]
> > We cannot change the behavior of push.default = simple already, so at least
> > that option is not in question.
>
> True.
>
> > Presumably you are worried about the other options that can't be enab
John Szakmeister wrote:
> On Wed, Oct 16, 2013 at 6:54 AM, John Szakmeister
> wrote:
> [snip]
> > "probably a minority" -- I guess that's the part I disagree with. I'm
> > not sure what a minority means here, but I don't think it'll be a
> > handful of people. How big does that number get befor
In Git, one can set up a repository with a "detached worktree", where
the .git directory is not a subdirectory of the top directory of the
work tree.
In general, Git commands on a repository with a detached worktree can
be executed by cd'ing into the directory containing the .git
directory, and ex
On Wed, Oct 16, 2013 at 03:50:51PM -0400, Jacobs, Todd wrote:
> When I use the `--progress` flag with the push command, I get transfer-speed
> statistics like this:
>
> $ git push -progress origin master 2>&1 | tee /tmp/push
> Counting objects: 30, done.
> Compressing objects: 100% (2
> Does it make a difference how you invoke "git fetch"? From a quick look at
> the code, "git fetch" with no remote or refspec should display progress data,
> but if you specify "--all" or a remote and refspec then it won't.
Thanks for your prompt response. However, it doesn't make any
differenc
Felipe Contreras writes:
> So replace 'git-foo' with 'git foo'.
>
> Signed-off-by: Felipe Contreras
> ---
> Documentation/git-checkout.txt | 4 ++--
> Documentation/git-commit.txt | 4 ++--
> Documentation/git-rebase.txt | 4 ++--
> Documentation/git-status.txt | 4 ++--
> 4 files changed
Felipe Contreras writes:
> Saying this patch is from me is not really accurate, it's based on a patch by
> me, or it was reported by me, but it's not really from me.
OK, will reword.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord..
Jonathan Nieder writes:
> Matthieu Moy wrote:
>
>> This file isn't really harmful, but isn't useful either, and can create
>> minor annoyance for the user:
>
> Would something like the following make sense, to ensure the gc.pid file is
> always removed on normal exit?
Has anything further happen
Matthieu Moy writes:
> Duy Nguyen writes:
>
>> has_dash_dash is calculated as (argc > 1) && !strcmp(argv[1], "--"),
>> so when argc == 1, the has_dash_dash must be zero, the "&&
>> !has_dash_dash" is redundant.
>
> Yes, but I'd rather not have to read the detailed definition of
> has_dash_dash t
Matthew Cline writes:
> When I try to a plain old "git add ." when files have been
> deleted/moved, I get the warning
>
>> You ran 'git add' with neither '-A (--all)' or '--ignore-removal'
>
> There should be some way to put something in ~/.gitconfig to tell git to
> always choose one or another.
Brandon Casey writes:
> On 10/15/2013 3:40 PM, Junio C Hamano wrote:
>> This seems to post-date what Jonathan has kept in his 'pu'; is this
>> the latest (I have a huge backlog to wade through, so I'd rather
>> skip it if another reroll is coming and move on to other topics).
>>
>> Thanks.
>
> T
Jeff King writes:
> ... But what is the normalized form for an
> optional argument? It either needs to be consistently "sticked" or
> "unsticked", either:
>
> set -- -S '' -- ;# default
> set -- -S 'foo' -- ;# not default
>
> or
>
> set -- -S --;# default
> set -- -Sfoo -- ;# not
Sitaram Chamarty writes:
> - describe when it is still applicable
> - tell people where to go for most normal cases
>
> Signed-off-by: Sitaram Chamarty
> ---
>
> ref: http://thread.gmane.org/gmane.comp.version-control.git/159633. Yes
> it's very old but better late than never.
>
> Document
Alexander 'z33ky' Hirsch <1ze...@gmail.com> writes:
> From: Alexander Hirsch <1ze...@gmail.com>
>
> git status -bs (--branch --short) does not seem to allow customization of the
> colors for the local and remote branch.
wt-status can use the following colors:
WT_STATUS_CHANGED
WT_STATUS_
wor...@alum.mit.edu (Dale R. Worley) writes:
> In general, Git commands on a repository with a detached worktree can
> be executed by cd'ing into the directory containing the .git
> directory, ...
Eh? News to me; it might happened to have appeared to work by
accident, but that is not by design.
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
I think I correctly inherited all the topics Jonathan kept track of
during my absence (big thanks to Jonathan); if a topic that has been
in his
On Wed, Oct 16, 2013 at 02:40:07PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > ... But what is the normalized form for an
> > optional argument? It either needs to be consistently "sticked" or
> > "unsticked", either:
> >
> > set -- -S '' -- ;# default
> > set -- -S 'foo' --
There has been plenty of comments lately about how certain features
will be released in 2.0
Have these features been tied together anywhere yet?
If not, when might such an integration branch be created? Would be
very interested in seeing how Git 2.0 plays, even in these early days.
Regards,
And
From: "Felipe Contreras"
John Szakmeister wrote:
On Tue, Oct 15, 2013 at 11:55 PM, Felipe Contreras
wrote:
[snip]
Similarly, if a user does core.mode = next, the user is expecting to
enable all
future behaviors, because that's what core.mode = next does, if he
doesn't want
to do that, then
Hi Andrew,
Andrew Ardill wrote:
> There has been plenty of comments lately about how certain features
> will be released in 2.0
>
> Have these features been tied together anywhere yet?
They're in Junio's "jch" branch:
https://github.com/gitster/git/commits/jch
> If not, when might such an integ
On 16 October 2013 15:11, Jonathan Nieder wrote:
>> There has been plenty of comments lately about how certain features
>> will be released in 2.0
>>
>> Have these features been tied together anywhere yet?
>
> They're in Junio's "jch" branch:
> https://github.com/gitster/git/commits/jch
Thanks! I
Nicolas Vigier wrote:
> I'm thinking about a patch to add the following two options to rev-parse :
>
> --sticked-opt-args::
> Only meaningful in --parseopt mode. Tells the options parser to
> output options with optional arguments in sticked form. The
> default is to output them
From: "Junio C Hamano"
wor...@alum.mit.edu (Dale R. Worley) writes:
In general, Git commands on a repository with a detached worktree can
be executed by cd'ing into the directory containing the .git
directory, ...
Eh? News to me; it might happened to have appeared to work by
accident, but t
Philip Oakley wrote:
> Would this be a good time to suggest a specific wording should be
> proposed (or a reminder of what was proposed repeated) for the
> documentation of this option. It will be the documentation that
> users will refer to when they need to know, rather than the list
> discussio
"Philip Oakley" writes:
> ... and the detection process for 'toplevel' may not work
> properly when in a separated work-tree environment.
Without GIT_WORK_TREE exported to point at the top-level, there is
nothing that lets us "detect" it, as the working tree does not have
".git" directory to tel
This file isn't really harmful, but isn't useful either, and can create
minor annoyance for the user:
* It's confusing, as the presence of a *.pid file often implies that a
process is currently running. A user running "ls .git/" and finding
this file may incorrectly guess that a "git gc" is cu
On Wed, Oct 16, 2013 at 09:41:16AM -0600, Martin Fick wrote:
> I have nightmares about this sort of thing every now and
> then, and we even experience some corruption here and there
> that needs to be fixed (mainly missing objects when we toy
> with different git repack arguments). I cannot he
Junio C Hamano wrote:
> Matthew Cline writes:
>
> > When I try to a plain old "git add ." when files have been
> > deleted/moved, I get the warning
> >
> >> You ran 'git add' with neither '-A (--all)' or '--ignore-removal'
> >
> > There should be some way to put something in ~/.gitconfig to tell
On Wed, Oct 16, 2013 at 10:41 PM, Martin Fick wrote:
>> and then running "git index-pack tmp.pack" in the
>> debugger (stop at unpack_raw_entry). Doing this, I found
>> that there were 3 bytes of header (and the header itself
>> had a sane type and size). So I stripped those off with:
>>
>> dd i
On Wed, Oct 16, 2013 at 02:38:27PM -0700, Junio C Hamano wrote:
> > Documentation/git-checkout.txt | 4 ++--
> [...]
> I recall that I wanted to see this change happen myself long time
> ago, and suspect that there may have been some reason that prevented
> us from doing so. I might have found th
>From bdbefc100ceba66a70f540dfe2b1b09b0869f7ab Mon Sep 17 00:00:00 2001
From: Hemmo Nieminen
Date: Wed, 16 Oct 2013 11:28:50 +0300
Subject: [PATCH] graph: Fix log's graph's colors when merging branches.
The log's graph's colors were off sometimes when merging several
branches. For example in the
54 matches
Mail list logo
