On Tue, Feb 25, 2014 at 06:43:24AM +0700, Duy Nguyen wrote:
> On Mon, Feb 24, 2014 at 11:21 PM, Kirill Smelkov wrote:
> > Hello up there.
> >
> > Here go combine-diff speedup patches in form of first reworking diff
> > tree-walker to work in general case - when a commit have several parents,
> >
Hi,
it seems git submodule supports --checkout, which is also mentioned
indirectly in the manpage. However, the option itself is not mentioned
in the synopsis or detailed option list.
Gr.
Matthijs
signature.asc
Description: Digital signature
--sort=version:refname (or --sort=v:refname for short) sorts tags as
if they are versions. --sort=-refname reverses the order (with or
without ":version").
versioncmp() is copied from string/strverscmp.c in glibc commit
ee9247c38a8def24a59eb5cfb7196a98bef8cfdc, reformatted to Git coding
style. The
Am 24.02.2014 17:21, schrieb Matthieu Moy:
$ git add foo.txt
$ git status
On branch master
Changes to be committed:
(use "git reset HEAD ..." to unstage)
modified: foo.txt
Maybe status should display a stash count if that count is > 0, as this
is part of the state of the repo.
Holger Hellmuth writes:
> Am 24.02.2014 17:21, schrieb Matthieu Moy:
>> $ git add foo.txt
>> $ git status
>> On branch master
>> Changes to be committed:
>>(use "git reset HEAD ..." to unstage)
>>
>> modified: foo.txt
>
> Maybe status should display a stash count if that count is >
Well, it's called `git stash` and not `git trash`... :-D
That's your own usage of it, but its main usage is different.
This is not a solution, but it's better than nothing and I second it.
On 25-02-14 13:33, Matthieu Moy wrote:
Holger Hellmuth writes:
Am 24.02.2014 17:21, schrieb Matthieu M
Brandon:
Please note that what I am asking for is not always dropping the stash,
but doing that *only* when the merge conflict is resolved. This is
simply getting the whole command to be consistent. If you do `git stash
pop` and it succeeds, the stash reference is dropped. If you do `git
stas
Omar Othman writes:
> Brandon:
Please, don't top-post on this list. Look how other people answer to
each other and follow the use.
> Please note that what I am asking for is not always dropping the
> stash, but doing that *only* when the merge conflict is resolved. This
> is simply getting the
Please note that what I am asking for is not always dropping the
stash, but doing that *only* when the merge conflict is resolved. This
is simply getting the whole command to be consistent. If you do `git
stash pop` and it succeeds, the stash reference is dropped. If you do
git stash pop` and it
On 02/24/2014 09:08 PM, Jonathan Nieder wrote:
> Michael Haggerty wrote:
>> [...] I've been documenting public functions in the
>> header files above the declaration, and private ones where they are
>> defined. [...]
>>
>> Let me know if you think I've made it less helpful.
>
> In the present st
Omar Othman writes:
> [omar_othman main (trunk|MERGING*)]$ git add path/to/file.txt
> [omar_othman main (trunk*)]$
>
> Note how the status message has changed to show that git is now happy.
> It is at that moment that the stash reference should be dropped
Dropping the stash on a "git add" operat
Sorry I'm going to go ahead and answer my own question:
$ git difftool $(git merge-base topic1 master) -- Path/SourceFile.cpp
I removed 'HEAD' from the command and now it picks up my changes and
compares to my working copy version (which is actually what I wanted).
I thought HEAD would point to m
I have a branch called topic1 that is based on 'master'. For a
particular file in my topic branch, I want to revert some changes by
using my diff tool. I do this by comparing the original revision of
the file with HEAD like so:
$ git difftool $(git merge-base topic1 master) HEAD -- Path/SourceFile
I'm pleased to announce that Git has been accepted to this year's Google
Summer of Code.
Student proposals will start coming in on March 22. In the meantime
students will be reading our Ideas page[1] and enquiring about the
program on the mailing list and on irc. There are many ways that
existing
Hi.
I was just going to write an email about that I would like to
participate in GSoC and contribute to Git project.
I don't have wide experience in C programming, but I could be start as a
"janitor". I found several tasks here
https://git.wiki.kernel.org/index.php/Janitor. For example "Refa
On 02/25/2014 04:41 PM, Jeff King wrote:
> I'm pleased to announce that Git has been accepted to this year's Google
> Summer of Code.
Cool! Thanks to Peff and Thomas and Vicent and whomever else was
involved in getting our application done! For those who don't know, the
application covers both G
Nguyễn Thái Ngọc Duy writes:
> versioncmp() is copied from string/strverscmp.c in glibc commit
> ee9247c38a8def24a59eb5cfb7196a98bef8cfdc, reformatted to Git coding
> style. The implementation is under LGPL-2.1 and according to [1] I can
> relicense it to GPLv2.
I'd propose this trivial change
David Kastrup writes:
> The region end can be looked up just like its beginning.
>
> Signed-off-by: David Kastrup
> ---
> builtin/blame.c | 9 +
> 1 file changed, 1 insertion(+), 8 deletions(-)
Yay, code reduction! Thanks.
> diff --git a/builtin/blame.c b/builtin/blame.c
> index e44a
Jens Lehmann writes:
> Am 24.02.2014 17:55, schrieb Junio C Hamano:
>> David Aguilar writes:
>>
>>> Modern versions of "git submodule" use .git-files to setup the
>>> submodule directory. When run in a "git submodule"-created
>>> repository "git difftool --dir-diff" dies with the following
>>>
Matthieu Moy writes:
> Holger Hellmuth writes:
>
>> Am 24.02.2014 17:21, schrieb Matthieu Moy:
>>> $ git add foo.txt
>>> $ git status
>>> On branch master
>>> Changes to be committed:
>>>(use "git reset HEAD ..." to unstage)
>>>
>>> modified: foo.txt
>>
>> Maybe status should disp
Joel Nothman writes:
> Git help --all had listed all git commands, but no configured aliases.
> This includes aliases as a separate listing, after commands in the main
> git directory and other $PATH directories.
... and why is this a good thing?
>
> Signed-off-by: Joel Nothman gmail.com>
> --
Am 25.02.2014 18:02, schrieb Junio C Hamano:
> Jens Lehmann writes:
>
>> Am 24.02.2014 17:55, schrieb Junio C Hamano:
>>> David Aguilar writes:
>>>
Modern versions of "git submodule" use .git-files to setup the
submodule directory. When run in a "git submodule"-created
repository
Matthieu Moy writes:
> Omar Othman writes:
>
>> [omar_othman main (trunk|MERGING*)]$ git add path/to/file.txt
>> [omar_othman main (trunk*)]$
>>
>> Note how the status message has changed to show that git is now happy.
>> It is at that moment that the stash reference should be dropped
>
> Droppi
Junio C Hamano writes:
> "status" is about reminding the user what changes are already in the
> index (i.e. what you would commit) and what changes are in the
> working tree, from which you could further update the index with
> (i.e. what you could commit).
I believe "status" should tell me ever
On 26 February 2014 06:15, Junio C Hamano wrote:
> Joel Nothman writes:
>
>> Git help --all had listed all git commands, but no configured aliases.
>> This includes aliases as a separate listing, after commands in the main
>> git directory and other $PATH directories.
>
> ... and why is this a go
Linus Torvalds writes:
> Thinking some more about the tag_name issue, I realize that the other
> patch ("Make request-pull able to take a refspec of form
> local:remote") broke another thing.
>
> The first patch pretty-printed the local branch-name, removing "refs/"
> and possibly "heads/" from t
Joel Nothman writes:
> arguments to git help. They are also like commands in that it is
> possible to forget their name, or whether they are defined on a
> particular workstation, and to hence want a listing.
I did envision that it would be useful for the last case, but then
the users would be h
Jens Lehmann writes:
>>> +test_expect_success PERL 'difftool properly honours gitlink and
>>> core.worktree' '
>>> + git submodule add ./. submod/ule &&
>>> + (
>>> + cd submod/ule &&
>>> + git difftool --tool=echo --dir-diff --cached
>>
>> In the context of this fix, f
Stephen Leake writes:
>> One _could_ argue that stashed changes are what could be reflected
>> to the working tree and form the source of the latter, but my gut
>> feeling is that it is a rather weak argument. At that point you are
>> talking about what you could potentially change in the workin
Stephen Leake writes:
>> Dropping the stash on a "git add" operation would be really, really
>> weird...
>
> Why? That is when the merge conflicts are resolved, which is what
> logically indicates that the stash is no longer needed,...
Not necessarily. Imagine a case where you used stash to qui
On 26 February 2014 08:51, Junio C Hamano wrote:
> Joel Nothman writes:
>
>> arguments to git help. They are also like commands in that it is
>> possible to forget their name, or whether they are defined on a
>> particular workstation, and to hence want a listing.
>
> I did envision that it would
Nguyễn Thái Ngọc Duy writes:
> git_path() soon understands the path given to it. Some paths "abc" may
> become "def" while other "ghi" may become "ijk". We don't want
> git_path() to interfere with .lock path construction. Concatenate
> ".lock" after the path has been resolved by git_path() so i
From: "Joel Nothman"
On 26 February 2014 06:15, Junio C Hamano wrote:
Joel Nothman writes:
Git help --all had listed all git commands, but no configured
aliases.
This includes aliases as a separate listing, after commands in the
main
git directory and other $PATH directories.
... and wh
Joel Nothman writes:
> Git help --all had listed all git commands, but no configured aliases.
> This includes aliases as a separate listing, after commands in the main
> git directory and other $PATH directories.
>
> Signed-off-by: Joel Nothman gmail.com>
> ---
Thanks.
> diff --git a/help.c b/
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 tip of 'next' has been rewound. There are healthy number of
topics in there that have been well-cooked during the 1.9.0
development cycle t
On Tue, Feb 25, 2014 at 01:33:56PM +0100, Matthieu Moy wrote:
> Holger Hellmuth writes:
> > Maybe status should display a stash count if that count is > 0, as
> > this is part of the state of the repo.
>
> Maybe it would help some users, but not me for example. My main use of
> "git stash" is a s
On Mon, Feb 24, 2014 at 05:21:40PM +0100, Matthieu Moy wrote:
> One easy thing to do OTOH would be to show a hint at the end of "git
> stash pop"'s output, like
I think that's a good idea. It makes it obvious that Git has kept
the stash and that the user should drop it when he's done - if he
wants
On Tue, Feb 18, 2014 at 8:39 AM, Nguyễn Thái Ngọc Duy wrote:
> This variable is intended to support multiple working directories
> attached to a repository. Such a repository may have a main working
> directory, created by either "git init" or "git clone" and one or more
> linked working directori
[omar_othman main (trunk|MERGING*)]$ git add path/to/file.txt
[omar_othman main (trunk*)]$
Note how the status message has changed to show that git is now happy.
It is at that moment that the stash reference should be dropped
Dropping the stash on a "git add" operation would be really, really
Am 24.02.2014 17:21, schrieb Matthieu Moy:
$ git add foo.txt
$ git status
On branch master
Changes to be committed:
(use "git reset HEAD ..." to unstage)
modified: foo.txt
Maybe status should display a stash count if that count is > 0, as
this is part of the state of the repo.
Matthieu Moy writes:
Holger Hellmuth writes:
Am 24.02.2014 17:21, schrieb Matthieu Moy:
$ git add foo.txt
$ git status
On branch master
Changes to be committed:
(use "git reset HEAD ..." to unstage)
modified: foo.txt
Maybe status should display a stash count if that coun
41 matches
Mail list logo
