On 5 Dec 2013, at 11:52, Junio C Hamano wrote:
> Nick Townsend writes:
>
>> Interplay between paths specified in three ways now tested:
>> * After a : in the tree-ish,
>> * As a pathspec in the command,
>> * By virtue of the current working directory
>>
>> Note that these tests are based on t
Hi
I came across this issue the other day while trying to optimise a fetch to a
repo with release branches named release-X.X.X. I wanted to just fetch just
those branches but because of the trailing slash rule I couldn't. The following
StackOverflow post has details of the issue:
http://stack
John Keeping wrote:
> Since commit d96855f (merge-base: teach "--fork-point" mode, 2013-10-23)
> we can replace a shell loop in git-pull with a single call to
> git-merge-base. So let's do so.
>
> Signed-off-by: John Keeping
> ---
> git-pull.sh | 10 +-
> 1 file changed, 1 insertion(+),
Heiko Voigt writes:
> On Fri, Dec 06, 2013 at 02:40:15PM -0500, Martin Langhoff wrote:
>> On Fri, Dec 6, 2013 at 3:48 AM, Jens Lehmann wrote:
>> > Right you are, we need tutorials for the most prominent use cases.
>>
>> In the meantime, are there any hints? Emails on this list showing a
>> curr
Karsten Blees wrote:
> (Besides, __attribute__((aligned)) / __declspec(align) can only
> _increase_ the alignment, so aligned(1) would have no effect).
Good catch.
> Googling some more, I believe the most protable way to achieve this
> via 'compiler settings' is
>
> #pragma pack(push)
> #pragm
Heiko Voigt writes:
> This notion has changed in a way that only the url (by that the name)
> should be copied on init. The default for everything else should come
> from .gitmodules or gits own default.
I think you need to be a bit careful here. I do not think
everything should blindly default
Heiko Voigt writes:
> This submodule configuration cache allows us to lazily read .gitmodules
> configurations by commit into a runtime cache which can then be used to
> easily lookup values from it. Currently only the values for path or name
> are stored but it can be extended for any value need
I had not previously noticed commit --fixup, so that is something
useful I have learned from this thread, thanks.
The workflow here can be summarized as "I have an initial commit and
subsequent, review-generated commits, that I'd like to share on a
review-branch with proper commit-log comments, bu
Am 09.12.2013 21:08, schrieb Jonathan Nieder:
> Karsten Blees wrote:
>
>> GCC supports __packed__ as of 2.3 (1992), so any other compilers
>> that copied the __attribute__ feature probably won't complain.
>
> Alas, it looks like HP C doesn't support __packed__ (not that I
> care much about HP C):
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
On Fri, Dec 06, 2013 at 02:40:15PM -0500, Martin Langhoff wrote:
> On Fri, Dec 6, 2013 at 3:48 AM, Jens Lehmann wrote:
> > Right you are, we need tutorials for the most prominent use cases.
>
> In the meantime, are there any hints? Emails on this list showing a
> current "smart" workflow? Blog po
Jeff King writes:
> On Sat, Dec 07, 2013 at 06:03:22PM +0100, Thomas Rast wrote:
>
>> Junio C Hamano writes:
>>
>> > * jk/pack-bitmap (2013-11-18) 22 commits
>> [...]
>> Peff can decide if he wants to reroll with my nits or not; either way
>> I'm all for moving it forward and aiming for one of
On Fri, Dec 06, 2013 at 03:48:46PM +, Charlie Dyson wrote:
> gitmodules(5) states that submodule.$name.update should be defined in
> .gitmodules. However in cmd_update() in git-submodule.sh, git config
> is used with "-f .gitmodules". Consequently this flag is only
> respected in .git/config
>
On Sat, Dec 07, 2013 at 06:03:22PM +0100, Thomas Rast wrote:
> Junio C Hamano writes:
>
> > * jk/pack-bitmap (2013-11-18) 22 commits
> [...]
> Peff can decide if he wants to reroll with my nits or not; either way
> I'm all for moving it forward and aiming for one of the next releases.
I'm going
Jens Lehmann writes:
> I didn't check each site in detail, but I suspect each ignore option
> was added on purpose to fix a problem. That means we still need "all"
> (at least when diffing rev<->index). Unfortunately that area is not
> covered well in our tests, I only got breakage from the filte
Torsten Bögershausen writes:
> The old log-line looked like this:
> + 9d498b0...8598732 master -> master (forced update)
> And the new one like this:
>9d498b0..8598732 master -> master
>
> - Loosen the grep pattern by not demanding "(forced update)"
Hmm, what is the reason for the change t
On Fri, Dec 06, 2013 at 03:10:31PM -0800, Junio C Hamano wrote:
> Heiko Voigt writes:
> > diff --git a/builtin/add.c b/builtin/add.c
> > index 2d0d2ef..d6cab7f 100644
> > --- a/builtin/add.c
> > +++ b/builtin/add.c
> > @@ -550,6 +569,7 @@ int cmd_add(int argc, const char **argv, const char
> > *p
On Thu, Dec 05, 2013 at 09:51:31PM +0100, Jens Lehmann wrote:
> Am 05.12.2013 00:19, schrieb Heiko Voigt:
> > On Wed, Dec 04, 2013 at 02:32:46PM -0800, Junio C Hamano wrote:
> > This series tries to achieve the following goals for the
> > submodule..ignore=all configuration or the --ignore-submodul
On Fri, Dec 6, 2013 at 5:07 PM, Jeff King wrote:
> When rev-parse looks at whether an argument like "foo..bar"
> or "foobar^@" is a difference or parent-shorthand, it
> internally munges the arguments so that it can pass the
> individual rev arguments to get_sha1. However, we do not
> consistently
Felipe Contreras writes:
> There's no mention of the 'origin' default, or the fact that the
> upstream tracking branch remote is used.
>
> Signed-off-by: Felipe Contreras
> ---
> Documentation/git-fetch.txt | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/Documentation/git-fetch.txt
Felipe Contreras writes:
> Signed-off-by: Felipe Contreras
> ---
> abspath.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/abspath.c b/abspath.c
> index e390994..8b3385a 100644
> --- a/abspath.c
> +++ b/abspath.c
> @@ -143,7 +143,7 @@ static const char *real_path_inte
Thanks, will queue.
--
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
Felipe Contreras writes:
> Commit 66713ef (pull: allow pull to preserve merges when rebasing)
> didn't include an update so 'git remote status' parses
> branch..rebase=preserve
> correctly, let's do that.
>
> Signed-off-by: Felipe Contreras
> ---
> builtin/remote.c | 9 +++--
> 1 file chan
Eric Sunshine writes:
> On Mon, Dec 9, 2013 at 3:40 PM, Thomas Gummerer wrote:
>> git diff --no-index ... currently reads the index, during setup, when
>> calling gitmodules_config(). This results in worse performance when
>> the index is not actually needed. This patch avoids calling
>> gitmo
[Sorry for not seeing this before sending out v2.]
Junio C Hamano writes:
> Thomas Gummerer writes:
>
>> git diff --no-index ... currently reads the index, during setup, when
>> calling gitmodules_config(). In the usual case this gives us some
>> performance drawbacks, but it's especially ann
Junio C Hamano writes:
> A refspec consists of one or more elements, each of which has
> right and left hand side separated by a colon, i.e. RHS:LHS, and
>
> 1) is determined by the RHS
> 2-a) is determined by the LHS
> 2-b) is determined by the correspondence between RHS-to-LHS.
Heh, I got m
Jonathan Nieder writes:
>> But if we cook it for a while, I suspect that we will find more and
>> more breakages of expectations in the existing scripts in and out of
>> the tree;
>
> Alas, probably no, because nobody has "HEAD~3..HEAD" in their working
> directory. That's exactly the problem --
Will re-queue these 6 for now. 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
Felipe Contreras writes:
> Junio C Hamano wrote:
>> Junio C Hamano writes:
>> > Felipe Contreras writes:
>
>> But it does not have to stay that way. In order to move things
>> forward in that direction, this new configuration has to be
>> distinguishable from the traditional "refspec", as it e
Felipe Contreras writes:
> To take hostage the whole patch series because of the name
> --refspec (which is perfectly fine) is just an excuse to not fix
> the issues already present.
I actually was wondering why you are taking the fixes to the hostage
to force a wrong option name.
--
To unsubscr
On Mon, Dec 9, 2013 at 3:40 PM, Thomas Gummerer wrote:
> git diff --no-index ... currently reads the index, during setup, when
> calling gitmodules_config(). This results in worse performance when
> the index is not actually needed. This patch avoids calling
> gitmodules_config() when the --no-i
Junio C Hamano wrote:
> I do not share the "with --verify is better hence no problem"
> reasoning. My "not so much worth worrying about" comes solely from
> a hunch that nobody has "HEAD~3..HEAD" in their working directory,
That's what makes it a problem. This change makes it very easy to
make
This submodule configuration cache allows us to lazily read .gitmodules
configurations by commit into a runtime cache which can then be used to
easily lookup values from it. Currently only the values for path or name
are stored but it can be extended for any value needed.
This cache can be used fo
On 2013-12-09 21.40, Thomas Gummerer wrote:
>
> +test_expect_success 'git diff --no-index with broken index' '
> + cd repo &&
> + echo broken >.git/index &&
> + git diff --no-index a ../non/git/a &&
^^
I'm confused: Does this work with the tr
Hi,
Dominik Vogt wrote:
>Now,
> when I switch to one of the other branches, said file is not
> identical anymore and stamped with the _current_ time during
> checkout. Although branch b and c have not changed at all, they
> will now be
Jonathan Nieder writes:
> Junio C Hamano wrote:
>
>>> So maybe we are doing a favor by
>>> calling out the problem; if they want a rev, they should be using
>>> "--verify" (or "--").
>>
>> I tend to agree with the reasoning in the last sentence. Let's cook
>>
git diff --no-index ... currently reads the index, during setup, when
calling gitmodules_config(). This results in worse performance when
the index is not actually needed. This patch avoids calling
gitmodules_config() when the --no-index option is given. The times for
executing "git diff --no-in
On Mon, Dec 09, 2013 at 12:11:50PM -0800, Junio C Hamano wrote:
> John Keeping writes:
>
> > Last time this came up [1], there was some discussion about moving the
> > added block of code to affect upstreams given on the command line as
> > well as when the upstream is discovered from the config.
Dominik Vogt writes:
> Me and some colleagues work on gcc in lots of different branches.
> For each branch there is a separate build directory for each
> branch, e.g. build-a, build-b and build-c. Let's assume that all
> branches are identical at the moment. If a file in branch a is
> changed t
Thomas Gummerer writes:
> git diff --no-index ... currently reads the index, during setup, when
> calling gitmodules_config(). In the usual case this gives us some
> performance drawbacks, but it's especially annoying if there is a broken
> index file.
>
> Avoid calling the unnecessary gitmodule
Johannes Sixt writes:
> Am 12/9/2013 3:23, schrieb Brett Randall:
>> * fixup! or squash! on it's own would default to fixing-up the
>> previous commit (or result of previous step of rebase if that was a
>> squash/fixup).
>
> Why would you want that? To fixup the previous commit, just use 'git
> c
John Keeping writes:
> Last time this came up [1], there was some discussion about moving the
> added block of code to affect upstreams given on the command line as
> well as when the upstream is discovered from the config. Having tried
> that, it has some more fallout on the test suite than I l
Karsten Blees wrote:
> GCC supports __packed__ as of 2.3 (1992), so any other compilers
> that copied the __attribute__ feature probably won't complain.
Alas, it looks like HP C doesn't support __packed__ (not that I
care much about HP C):
http://h21007.www2.hp.com/portal/download/files/unprot
The old log-line looked like this:
+ 9d498b0...8598732 master -> master (forced update)
And the new one like this:
9d498b0..8598732 master -> master
- Loosen the grep pattern by not demanding "(forced update)"
- Improve the grep pattern and check the new SHA id
Signed-off-by: Torsten Bögersh
Nguyễn Thái Ngọc Duy writes:
> I've got this with Vietnamese translation
>
> $ git status
> HEAD được tách rời từorigin/master
>
> One does not need to understand Vietnamese to see that a space is
> missing before "origin/master"...
Not really. Only if one guesses (or knows) that Vietn
Samuel Bronson writes:
>> If somebody has diff.orderfile configuration that points at a custom
>> ordering, and wants to send out a patch (or show a diff) with the
>> standard order, how would the "overriding" command line look like?
>> Would it be "git diff -O/dev/null"?
>
> It looks like that w
Jonathan Nieder wrote:
> Isn't this essentially breaking a contract
To clarify, if there were some strong motivation --- e.g. if this
were resolving some security problem --- then I would be all for
breaking compatibility in this way. What's confusing to me is that I
just don't see the motivati
Thomas Gummerer wrote:
> For example I would take one
> version, use test-dump-cache-tree to dump the cache tree to a file,
> change the format slightly, use test-dump-cache-tree again, and check
> the difference with "git diff --no-index".
Makes a lot of
Jonathan Nieder writes:
> Thomas Gummerer wrote:
>
>> git diff --no-index ... currently reads the index, during setup, when
>> calling gitmodules_config(). In the usual case this gives us some
>> performance drawbacks,
>
> Makes sense.
>
>>but it's especially annoying if
Junio C Hamano wrote:
>> So maybe we are doing a favor by
>> calling out the problem; if they want a rev, they should be using
>> "--verify" (or "--").
>
> I tend to agree with the reasoning in the last sentence. Let's cook
> it for a while and see what happens
Jens Lehmann wrote:
> Am 09.12.2013 16:16, schrieb Jonathan Nieder:
>> Thomas Gummerer wrote:
>>> git diff --no-index ... currently reads the index, during setup, when
>>> calling gitmodules_config(). In the usual case this gives us some
>>> performance drawbacks,
>>
>> Makes sense.
>
> Hmm, but
Jeff King writes:
> Is it better for "rev-parse" to be more careful, and to behave more like
> the rest of git? Or is better to be historically compatible?
>
> One thing to note is that "git rev-parse HEAD" is slightly broken there
> already. Because "git rev-parse $some_branch" may do very diffe
John Szakmeister writes:
> Signed-off-by: John Szakmeister
> ---
> The gnome-keyring credential backend had a number of coding style
> violations. I believe this fixes all of them.
>
> .../gnome-keyring/git-credential-gnome-keyring.c | 55
> ++
> 1 file changed, 25 inser
Am 09.12.2013 11:59, schrieb George Papanikolaou:
> I was just playing with the new features of 'git mv' in 1.8.5 and
> realized that both rm
> and mv don't change the .git/config file. Is that on purpuse?
Yes. Only the "path" entry in .gitmodules needs to be updated
when a submodule is moved. Its
Karsten Blees writes:
>> * kb/fast-hashmap (2013-11-18) 14 commits
>> (merged to 'next' on 2013-12-06 at f90be3d)
>
> Damn, a day too late :-) I found these two glitches today...is a
> fixup patch OK or should I do a reroll (or separate patch on top)?
A separate patch on top would be the most
Karsten Blees writes:
> Am 07.12.2013 00:52, schrieb Junio C Hamano:
>
>> * kb/doc-exclude-directory-semantics (2013-11-07) 1 commit
>> - gitignore.txt: clarify recursive nature of excluded directories
>>
>> Originally merged to 'next' on 2013-11-13
>>
>> Kicked back to 'pu' to replace with
Am 09.12.2013 16:16, schrieb Jonathan Nieder:
> Thomas Gummerer wrote:
>
>> git diff --no-index ... currently reads the index, during setup, when
>> calling gitmodules_config(). In the usual case this gives us some
>> performance drawbacks,
>
> Makes sense.
Hmm, but this will disable the submod
Thomas Gummerer wrote:
> git diff --no-index ... currently reads the index, during setup, when
> calling gitmodules_config(). In the usual case this gives us some
> performance drawbacks,
Makes sense.
>but it's especially annoying if there is a broken
> index file.
Is t
Am 08.12.2013 11:20, schrieb Thomas Rast:
> Karsten Blees writes:
>
>> Am 07.12.2013 23:23, schrieb Thomas Rast:
>>> Karsten Blees writes:
>>>
Extending 'struct hashmap_entry' with an int-sized member shouldn't waste
memory on 64-bit systems. This is already documented in api-hashmap.t
git diff --no-index ... currently reads the index, during setup, when
calling gitmodules_config(). In the usual case this gives us some
performance drawbacks, but it's especially annoying if there is a broken
index file.
Avoid calling the unnecessary gitmodules_config() when the --no-index
option
Me and some colleagues work on gcc in lots of different branches.
For each branch there is a separate build directory for each
branch, e.g. build-a, build-b and build-c. Let's assume that all
branches are identical at the moment. If a file in branch a is
changed that triggers a complete rebuild o
Hi list,
I was just playing with the new features of 'git mv' in 1.8.5 and
realized that both rm
and mv don't change the .git/config file. Is that on purpuse?
Also after mv you need to run 'submodule update' and I think this should be
documented somewhere.
Thanks..
--
George 'papanikge' Papanik
Thomas Gummerer writes:
> Hi,
>
> previous rounds (without api) are at $gmane/202752, $gmane/202923,
> $gmane/203088 and $gmane/203517, the previous rounds with api were at
> $gmane/229732, $gmane/230210 and $gmane/232488. Thanks to Duy for
> reviewing the the last round and Junio, Ramsay and Er
This aims to support code-review workflows of teams that prefer rebase
over merge, when committing a new peer-reviewed feature.
* Developer starts with commit OM, commits A.
* During testing, the developer may make further changes, either
through --amend or new commits, but either way, all work is
> >> * fixup! or squash! on it's own would default to fixing-up the
> >> previous commit (or result of previous step of rebase if that was a
> >> squash/fixup).
> >
> > Why would you want that? To fixup the previous commit, just use 'git
> > commit --amend'. What am I missing?
>
> In the past I've
On 09/12/13 19:51, Johannes Sixt wrote:
> Am 12/9/2013 3:23, schrieb Brett Randall:
>> * fixup! or squash! on it's own would default to fixing-up the
>> previous commit (or result of previous step of rebase if that was a
>> squash/fixup).
>
> Why would you want that? To fixup the previous commit,
66 matches
Mail list logo
