Hi guys,
I'm looking for some feedback regarding an Android app I've released.
It's a simple idea of mine for a tool that may be useful to developers
when travelling or working on different locations.
So the idea was to combine the two (in my opinion) very complementary
paradigms - mobility and d
"git blame file" has always meant "find the origin of each line of
the file in the history leading to HEAD, oh by the way, blame the
lines that are modified locally to the working tree".
This teaches "git blame" that during a conflicted merge, some
uncommitted changes may have come from the other
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
We iterate through the list of children to cleanup, but do not keep
our "last" pointer up to date. As a result, we may end up cutting off
part of the list instead of removing a single element.
Iterate through children_to_clean using 'next' fields but with an
extra level of indirection. This allows
On 09/11/2012 09:52 PM, Junio C Hamano wrote:
> Stefano Lattarini writes:
>
>> On 09/11/2012 07:27 PM, Junio C Hamano wrote:
>>
>>> These two hunks suggest that you may be favoring spaces, but other
>>> places you seem to use tabs, so...
>>>
>> I can convert the new tabs to spaces if you prefer (
A maintenance release Git v1.7.11.6 is now available at the
usual places.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
f678531535643806733e8c7e87db77386c48738b git-1.7.11.6.tar.gz
e6ccf6cffa3b69dc5d658f43bb8a10ed70b176f2
Stefano Lattarini writes:
> On 09/11/2012 07:27 PM, Junio C Hamano wrote:
>> Stefano Lattarini writes:
>>
>>> Thanks to our 'GIT_CONF_SUBST' layer in configure.ac, a make variable 'VAR'
>>> can be defined to a value 'VAL' at ./configure runtime in our build system
>>> simply by using "GIT_CONF_
Jens Lehmann writes:
>> * jl/submodule-rm (2012-08-27) 1 commit
>> - Teach rm to remove submodules unless they contain a git directory
>>
>> "git rm submodule" cannot blindly remove a submodule directory as
>> its working tree may have local changes, and worse yet, it may even
>> have its repos
2012/9/7 Jonas Fonseca :
> On Fri, Sep 7, 2012 at 9:41 AM, Jean-Baptiste Quenot wrote:
>> Hi Jonas,
>
> Hello Jean-Baptiste
>
>> With tig 1.0 how to feed specific revisions to the main view?
>>
>> The following hack worked until tig 0.17:
>>
>> [alias]
>> tignowalk-helper = !git rev-list -
Currently using "git rm" on a submodule - populated or not - fails with
this error:
fatal: git rm: '': Is a directory
This made sense in the past as there was no way to remove a submodule
without possibly removing unpushed parts of the submodule's history
contained in its .git directory too
On 09/11/2012 07:27 PM, Junio C Hamano wrote:
> Stefano Lattarini writes:
>
>> Thanks to our 'GIT_CONF_SUBST' layer in configure.ac, a make variable 'VAR'
>> can be defined to a value 'VAL' at ./configure runtime in our build system
>> simply by using "GIT_CONF_SUBST([VAR], [VAL])" in configure.a
Junio C Hamano writes:
> Thanks; I picked up $gmane/204633 but forgot to queue.
... so this has been reduced to:
-- >8 --
From: Michael J Gruber
Date: Tue, 11 Sep 2012 13:58:30 +0200
Subject: [PATCH] completion: complete branch name for "branch
--set-upstream-to="
Signed-off-by: Michael J Gr
Jeff King writes:
> Thanks for the patch. Overall it looks good, but let me nit-pick your
> commit message a little (not because it is that horrible, but because
> you are so close to perfect that I want to fix the minor things and then
> encourage you to submit more patches :) ).
> ...
>
> Acked
Stefano Lattarini writes:
> Thanks to our 'GIT_CONF_SUBST' layer in configure.ac, a make variable 'VAR'
> can be defined to a value 'VAL' at ./configure runtime in our build system
> simply by using "GIT_CONF_SUBST([VAR], [VAL])" in configure.ac, rather than
> having both to call "AC_SUBST([VAR],
Michael J Gruber writes:
> Signed-off-by: Michael J Gruber
> ---
> Documentation/git-describe.txt | 16 +++-
> t/t6120-describe.sh| 7 +++
> 2 files changed, 22 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/git-describe.txt b/Documentation/git-describe
Thanks; I picked up $gmane/204633 but forgot to 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
On 11 September 2012 18:53, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
>> On Sat, Sep 1, 2012 at 6:12 PM, Andreas Schwab wrote:
>>> Ævar Arnfjörð Bjarmason writes:
>>>
I don't get what you mean, what committer info?
>>>
>>> GIT_COMMITTER_{NAME,EMAIL}. A tagger isn't really
Ævar Arnfjörð Bjarmason writes:
> On Sat, Sep 1, 2012 at 6:12 PM, Andreas Schwab wrote:
>> Ævar Arnfjörð Bjarmason writes:
>>
>>> I don't get what you mean, what committer info?
>>
>> GIT_COMMITTER_{NAME,EMAIL}. A tagger isn't really an author.
>
> Ah, am I the only one that finds that a bit c
> From: Junio C Hamano [mailto:gits...@pobox.com]
> Sent: Tuesday, September 11, 2012 6:06 PM
> To: Matthieu Moy
> Cc: Joachim Schmitz; git
> Subject: Re: How to update a cloned git repository
>
> Matthieu Moy writes:
>
> > [ Re-adding git@vger in Cc, I guess it was meant to be so ]
> >
> > "Joa
> -Original Message-
> From: Junio C Hamano [mailto:gits...@pobox.com]
> Sent: Tuesday, September 11, 2012 6:01 PM
> To: Joachim Schmitz
> Cc: 'Matthieu Moy'; git@vger.kernel.org
> Subject: Re: How to update a cloned git repository
>
> "Joachim Schmitz" writes:
>
> >> From: Matthieu Mo
Michael J Gruber writes:
> so that git-describe searches first-parent history only when looking for
Please make sure your first paragraph of the log message start with
a full sentence, not an incomplete tail part of a sentence as if the
title of the commit were repeated in front of it.
> a name
Michael J Gruber writes:
> The current behavior is probably as useful as it is confusing. In any
> case it is going to stay. So, document it.
>
> Signed-off-by: Michael J Gruber
> ---
> I would have written a test but don't really know where to stick it in.
> rev-list has many small tests where
Junio C Hamano writes:
> Matthieu Moy writes:
>
>> Anyway, you can easily get it from the commit that merges the branch
>> (it's the-merge-commit^1).
>
> I think it is the-merge-commit^2;
Right. I forgot that Git counted parents from 1, not 0.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
Michael J Gruber writes:
> While "git describe" behaves as documented, the notion of "most recent tag"
> is not really easy to grab, and it's not always the way you want to describe
> a commit.
>
> "--first-parent" is the option which answers the question: Which is the
> most recent tag on this b
Matthieu Moy writes:
> [ Re-adding git@vger in Cc, I guess it was meant to be so ]
>
> "Joachim Schmitz" writes:
>
>>> Then, work on the tip of the topic branch you depend on instead of pu.
>>> These are more stable, as they will be rewritten only if this particular
>>> topic branch changes.
>>
"Joachim Schmitz" writes:
>> From: Matthieu Moy [mailto:matthieu@grenoble-inp.fr]
>> ..
>> Short answer: don't work on pu. Work on master unless you have a good
>> reason not to.
>
> There are some changes in pu, that I need as the basis, namely my
> setitimer patch and my 2nd mkdir patch, wh
Thanks to our 'GIT_CONF_SUBST' layer in configure.ac, a make variable 'VAR'
can be defined to a value 'VAL' at ./configure runtime in our build system
simply by using "GIT_CONF_SUBST([VAR], [VAL])" in configure.ac, rather than
having both to call "AC_SUBST([VAR], [VAL])" in configure.ac and adding
Now, in configure.ac, a call like:
GIT_CONF_SUBST([FOO])
will be considered equivalent to:
GIT_CONF_SUBST([FOO], [$FOO])
This is mostly a preparatory refactoring in view of future changes.
No semantic change to the generated configure or config.mak.auto is
intended.
Signed-off-by: Stef
Roger Pau Monné writes:
> I understood this, it's just that I would prefer to avoid doing this
> kind if things, I would prefer to be able to work natively on my
> filesystem, but it seems like there's no other option.
If you are unwilling to keep both lowercase and uppercase separately
on your
Roger Pau Monné writes:
> Hello,
>
> I'm using git for all my projects, and I usually work under Mac OS X
> with the default filesystem (that's case-insensitive, but
> case-preserving). I'm currently working on a project that has several
> branches, and two of them are called origin/DHCPCD and or
Peter Krefting writes:
> I was thinking about using git cherry-pick with a list of commits,
> rebase is better at helping with conflicts and such.
Because the three-way merge done by rebase is exactly the same as
cherry-pick, I do not think I understand the reasoning behind this
statement at all
On Tue, Sep 11, 2012 at 4:32 PM, David Gould wrote:
> Iterate through children_to_clean using 'next' fields but with an
> extra level of indirection. This allows us to update the chain when
> we remove a child and saves us managing several variables around
> the loop mechanism.
> ---
> run-comman
On Tue, Sep 11, 2012 at 03:32:47PM +0100, David Gould wrote:
> Subject: Re: [PATCH] clear_child_for_cleanup must correctly manage
> children_to_clean
Thanks for the patch. Overall it looks good, but let me nit-pick your
commit message a little (not because it is that horrible, but because
you a
On Sat, Sep 1, 2012 at 6:12 PM, Andreas Schwab wrote:
> Ævar Arnfjörð Bjarmason writes:
>
>> I don't get what you mean, what committer info?
>
> GIT_COMMITTER_{NAME,EMAIL}. A tagger isn't really an author.
Ah, am I the only one that finds that a bit counterintuitive to the
point of wanting to s
The current behavior is probably as useful as it is confusing. In any
case it is going to stay. So, document it.
Signed-off-by: Michael J Gruber
---
I would have written a test but don't really know where to stick it in.
rev-list has many small tests where it doesn't fit.
Documentation/rev-list
Iterate through children_to_clean using 'next' fields but with an
extra level of indirection. This allows us to update the chain when
we remove a child and saves us managing several variables around
the loop mechanism.
---
run-command.c | 12 ++--
1 file changed, 6 insertions(+), 6 delet
On Tue, Sep 11, 2012 at 4:47 PM, Joachim Schmitz
wrote:
> Like this?
> git pull --rebase HEAD~42
>
> So far I create patches, wiped out the entire repository, cloned, forked and
> applied the changes, pretty painful.
I think a 'git pull --rebase' should usually work even for 'pu'.
But sometime
so that git-describe searches first-parent history only when looking for
a named commit. This is useful for describing commits by tags on their
"main" (first-parent) branch; for example, on git.git:
git describe 22ffc39
v1.7.2.3-223-g22ffc39
git describe --first-parent 22ffc39
v1.7.2-104-g22ffc39
Signed-off-by: Michael J Gruber
---
Documentation/git-describe.txt | 16 +++-
t/t6120-describe.sh| 7 +++
2 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-describe.txt b/Documentation/git-describe.txt
index 72d6bb6..9fb5c84 100644
---
While "git describe" behaves as documented, the notion of "most recent tag"
is not really easy to grab, and it's not always the way you want to describe
a commit.
"--first-parent" is the option which answers the question: Which is the
most recent tag on this branch which can be reached from this c
On Tue, Sep 11, 2012 at 2:40 PM, Matthieu Moy
wrote:
> [ Re-adding git@vger in Cc, I guess it was meant to be so ]
>
> "Joachim Schmitz" writes:
>
>>> Then, work on the tip of the topic branch you depend on instead of pu.
>>> These are more stable, as they will be rewritten only if this particula
> From: Matthieu Moy [mailto:matthieu@grenoble-inp.fr]
> Sent: Tuesday, September 11, 2012 2:41 PM
> To: Joachim Schmitz
> Cc: git
> Subject: Re: How to update a cloned git repository
>
> [ Re-adding git@vger in Cc, I guess it was meant to be so ]
Oops, yes it was meant to.
> "Joachim Schmi
[ Re-adding git@vger in Cc, I guess it was meant to be so ]
"Joachim Schmitz" writes:
>> Then, work on the tip of the topic branch you depend on instead of pu.
>> These are more stable, as they will be rewritten only if this particular
>> topic branch changes.
>
> These are not available from gi
Hello,
I am using git 1.7.10.4 from Debian. I just tried svn.pushmergeinfo and
it seems to have worked fine, great.
Now I am trying to understand what the doc says about this:
"Currently, this can only be done when dcommitting non-fast-forward
merges where all parents but the first have already b
Remove the deprecated --set-upstream from completion suggestions and add
the new --set-upstream-to=, offering all refs for completion like in
similar cases.
Signed-off-by: Michael J Gruber
---
contrib/completion/git-completion.bash | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff
Joachim Schmitz wrote:
If poll() is used as a milli-second sleep, like in help.c, by passing
a NULL in the 1st and a 0 in the 2nd arg, it exits with EFAULT.
As per Paolo Bonzini, the original author, this is a bug and to be
fixed like in this commit, which is not to exit if the 2nd arg is 0.
Si
Erik Faye-Lund writes:
> Yes, but being costly in terms of performance is IMO a lot better than
> corrupting refs, which is what we currently do.
I'm not saying nothing should be done, but I'm not sure packed-refs are
the right solution in the long term. We already have the foo Vs foo/bar
issue
"Joachim Schmitz" writes:
>> From: Matthieu Moy [mailto:matthieu@grenoble-inp.fr]
>>
>> Short answer: don't work on pu. Work on master unless you have a good
>> reason not to.
>
> There are some changes in pu, that I need as the basis, namely my
> setitimer patch and my 2nd mkdir patch, which
On Tue, Sep 11, 2012 at 12:28 PM, Matthieu Moy
wrote:
> Erik Faye-Lund writes:
>
>> I have stumbled upon a similar issue on Windows (which also has a
>> case-preserving filesystem), and I seem to remember the solution being
>> something to do with packed refs.
>
> Packed-refs use a format like th
> From: Matthieu Moy [mailto:matthieu@grenoble-inp.fr]
> Sent: Tuesday, September 11, 2012 1:06 PM
> To: Joachim Schmitz
> Cc: git@vger.kernel.org
> Subject: Re: How to update a cloned git repository
>
> "Joachim Schmitz" writes:
>
> > Hi folks
> >
> > Probably a beginner's question...
> >
>
"Joachim Schmitz" writes:
> Hi folks
>
> Probably a beginner's question...
>
> If I did a
>git clone git://guthub.com/git/git.git
> and worked on some own branches of pu
>git checkout pu;git checkout -p mybranch;
I guess you meant "git checkout -b mybranch" (not -p).
> hack;hack;...;git
Hi folks
Probably a beginner's question...
If I did a
git clone git://guthub.com/git/git.git
and worked on some own branches of pu
git checkout pu;git checkout -p mybranch;hack;hack;...;git commit -a -s
how to update my repository once the the one on github changed?
A plain
git pull
or
Erik Faye-Lund writes:
> I have stumbled upon a similar issue on Windows (which also has a
> case-preserving filesystem), and I seem to remember the solution being
> something to do with packed refs.
Packed-refs use a format like this:
$ tail -3 .git/packed-refs
e94214ce4b8acefce06d4ea37b76ac0d
On Tue, Sep 11, 2012 at 11:21 AM, Roger Pau Monné
wrote:
> Hello,
>
> I'm using git for all my projects, and I usually work under Mac OS X
> with the default filesystem (that's case-insensitive, but
> case-preserving). I'm currently working on a project that has several
> branches, and two of them
On Tue, Sep 11, 2012 at 10:36 AM, Tomas Carnecky
wrote:
> On Tue, Sep 11, 2012 at 9:30 AM, Roger Pau Monné
> wrote:
>> On Tue, Sep 11, 2012 at 10:24 AM, Tomas Carnecky
>> wrote:
>>> On Tue, 11 Sep 2012 10:21:16 +0100, Roger Pau Monné
>>> wrote:
Hello,
I'm using git for all my pr
On Tue, Sep 11, 2012 at 9:30 AM, Roger Pau Monné
wrote:
> On Tue, Sep 11, 2012 at 10:24 AM, Tomas Carnecky
> wrote:
>> On Tue, 11 Sep 2012 10:21:16 +0100, Roger Pau Monné
>> wrote:
>>> Hello,
>>>
>>> I'm using git for all my projects, and I usually work under Mac OS X
>>> with the default files
On Tue, Sep 11, 2012 at 10:24 AM, Tomas Carnecky
wrote:
> On Tue, 11 Sep 2012 10:21:16 +0100, Roger Pau Monné
> wrote:
>> Hello,
>>
>> I'm using git for all my projects, and I usually work under Mac OS X
>> with the default filesystem (that's case-insensitive, but
>> case-preserving). I'm curren
Hi guys,
Sorry for the delayed reply - what passes for my real life intruded
somewhat.
I'll get on to it today, but please be aware this will be my first-ever
patch for ANY project, so am likely to foul up the process.
I am reading the How To Submit Patches document even now
Cheers,
Da
58 matches
Mail list logo
