On 25/05/14 15:50, Jeremiah Mahler wrote:
> Some minor wording fixes in the user manual and glossary.
>
> Signed-off-by: Jeremiah Mahler
> ---
> Documentation/glossary-content.txt | 2 +-
> Documentation/user-manual.txt | 8
> 2 files changed, 5 insertions(+), 5 deletions(-)
>
> d
gt; the new major version is larger. This is done for both the place that
> caused the reported bug and another spot where the git version is tested
> for another feature.
>
> Reported-by: Chris Packham
> Reported-by: Yann Dirson
> Helped-by: Pat Thoyts
> Signed-off-by: Je
ne for both the place
> that caused the reported bug and another spot where the git version is
> tested for another feature.
>
> Reported-by: Chris Packham
> Reported-by: Yann Dirson
> Signed-off-by: Jens Lehmann
> ---
Looks good to me (refer to previous comment about being ru
Hi,
On 13/05/14 11:45, Yann Dirson wrote:
> In 2.0rc2, git-gui is unable to work inside submodules, where 1.9.2
> did not show such a problem:
>
>
> yann@home:~$ cd /tmp/
> yann@home:tmp$ mkdir foo
> yann@home:tmp$ cd foo/
> yann@home:foo$ git init
> Initialized empty Git repository in /tmp/foo/
On 08/05/14 18:54, Jianyu Zhan wrote:
> Usually, a trivial change(like coding style fix) may bury a
> original change of the code, and thus git blame is of less
> help. And to address this situation, I have to do like this:
>
>git blame -s REF^ > temp
>
> to dig into the history recursively
Hi,
On 06/05/14 11:50, Junio C Hamano wrote:
> John Keeping writes:
>
>> On Tue, Apr 29, 2014 at 03:38:07PM -0700, Junio C Hamano wrote:
>>> * fc/remote-helpers-hg-bzr-graduation (2014-04-29) 11 commits
>>> ...
>>> Move remote-hg and remote-bzr out of contrib/. There were some
>>> suggestion
On 07/05/14 19:28, Chris Packham wrote:
> On 07/05/14 00:10, Pat Thoyts wrote:
>> Chris Packham writes:
>>
>>> On Tue, Apr 29, 2014 at 2:56 PM, Chris Packham
>>> wrote:
>>>> Hi Pat,
>>>>
>>>> I'm running git 2.0.0-rc0 (ha
On 07/05/14 00:10, Pat Thoyts wrote:
> Chris Packham writes:
>
>> On Tue, Apr 29, 2014 at 2:56 PM, Chris Packham
>> wrote:
>>> Hi Pat,
>>>
>>> I'm running git 2.0.0-rc0 (haven't got round to pulling down rc1 yet)
>>> which includ
Hi,
I know there are a few people on this list that do git training in
various forms. At $dayjob I've been asked to run a few training
sessions in house. The initial audience is SW developers so they are
fairly clued up on VCS concepts and most have some experience
(although some not positive) wit
ubmodule's $GIT_DIR. Unfortunately vsatisfies doesn't handle versions
like v2.0.0.rc0 so the fall-back logic is triggered.
Given the fact that git 1.7.0 was released over 4 years ago rather than
fixing the fall-back logic it seems reasonable to drop the version
check.
Signed-off-by: Chris Pac
On Tue, Apr 29, 2014 at 2:56 PM, Chris Packham wrote:
> Hi Pat,
>
> I'm running git 2.0.0-rc0 (haven't got round to pulling down rc1 yet)
> which includes gitgui-0.19.0 and I'm getting a new error when I run
> 'git gui' in a repository with a .git file (c
Hi Pat,
I'm running git 2.0.0-rc0 (haven't got round to pulling down rc1 yet)
which includes gitgui-0.19.0 and I'm getting a new error when I run
'git gui' in a repository with a .git file (created by git submodule).
I can send you a screencap of the error message off list if you want
but the tex
---
On 17/03/14 20:35, Chris Packham wrote:> On 17/03/14 19:39, Junio C Hamano
wrote:
>> Chris Packham writes:
>>
>>> Ping?
>>
>> Hasn't it been already cooking in 'next' for a few days?
>>
>
> Indeed I think I missed a "
On 17/03/14 19:39, Junio C Hamano wrote:
> Chris Packham writes:
>
>> Ping?
>
> Hasn't it been already cooking in 'next' for a few days?
>
Indeed I think I missed a "What's cooking". Do you want me to submit a
fixup for the spelling mista
On 11/03/14 16:51, Chris Packham wrote:
> The --patch-format option has been supported for a while but it is not
> mentioned in the man page and the short help cannot tell the user what
> the supported formats are. Add the option to the man page along with the
> supported options.
>
The --patch-format option has been supported for a while but it is not
mentioned in the man page and the short help cannot tell the user what
the supported formats are. Add the option to the man page along with the
supported options.
Signed-off-by: Chris Packham
---
I've not bothered to act
On 05/03/14 16:22, Phillip Susi wrote:
> On 03/04/2014 10:08 PM, Chris Packham wrote:
>> Could you provide a few more details such as your git version (git
>> --version) and an example of the failure. I've tried to reproduce
>> the problem based on the description pro
Hi,
On 05/03/14 15:49, Phillip Susi wrote:
> I applied a patch with git am that adds a new source file to a new
> directory, and later noticed that file was missing from the commit.
> It seems that git am fails to add the new file/directory to the index.
>
Could you provide a few more details su
Hi,
I don't know if this really counts as a bug but it is a little
annoying from a user experience point of view.
We're using an applypatch-msg hook to check that certain things
(reviewer, bug entry etc) are recorded correctly in commit messages.
My expectation is that if our applypatch-msg hook
On 27/02/14 04:54, Robert Dailey wrote:
> On Wed, Feb 26, 2014 at 3:26 AM, Jeff King wrote:
>> On Mon, Feb 24, 2014 at 01:34:34PM -0600, Robert Dailey wrote:
>>
>>> So I set GIT_PAGER to 'echo custom pager' as you instructed, and I
>>> noticed that wasn't being printed when I ran my git log alias.
On 24/02/14 09:33, Robert Dailey wrote:
> On Sat, Feb 22, 2014 at 1:39 AM, Chris Packham
> wrote:
>> On 22/02/14 18:18, Robert Dailey wrote:
>>> So it seems that the pager doesn't work by default when running `git
>>> log` from Cygwin like it does in msysgi
On 22/02/14 18:18, Robert Dailey wrote:
> So it seems that the pager doesn't work by default when running `git
> log` from Cygwin like it does in msysgit for Windows.
>
> I know I can pipe to `less` but that requires the additional typing
> obviously. Does anyone know how I can get the pager to wo
On 13/02/14 10:55, Robert Dailey wrote:
> I have the following alias defined:
> sync = "!f() { cbr=$(git rev-parse --abbrev-ref HEAD); git co $1 &&
> git pull && git co $cbr && git rebase $1; }; f"
>
> The goal is to basically update a local branch which tracks a branch
> on a remote, and then reb
Hi,
On 12/02/14 14:57, Stefan Zager wrote:
> From b4796d9d99c03b0b7cddd50808a41413e45f1129 Mon Sep 17 00:00:00 2001
> From: Stefan Zager
> Date: Mon, 10 Feb 2014 16:55:12 -0800
> Subject: [PATCH] Make the global packed_git variable static to sha1_file.c.
>
> This is a first step in making the co
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,
On 19/11/13 06:11, Matthieu Moy wrote:
> I was wondering whether others had similar (or not) experience. In
> particular, as a teacher, I'm wondering whether I should push my
> students towards the GUI in the IDE, or advise them to keep using the
> command-line (we teach them git with the command-l
On 18/09/13 22:22, Tay Ray Chuan wrote:
> Hi Chris,
>
> I think you mentioned usability issues with git-submodule before on
> the git mailing list, so I thought you might be interested in taking a
> look at this patch. It's attached below, you can also view it at
>
>
> http://thread.gmane.org/
On Tue, Sep 10, 2013 at 11:04 PM, Matthieu Moy
wrote:
> Chris Packham writes:
>
>> On 10/09/13 21:19, Matthieu Moy wrote:
>>> Hi,
>>>
>>> I just noticed that the template COMMIT_EDITMSG was containing status
>>> hints, and that they were not part
On 10/09/13 21:19, Matthieu Moy wrote:
> Hi,
>
> I just noticed that the template COMMIT_EDITMSG was containing status
> hints, and that they were not particularty helpfull _during_ a commit. I
> think it would be sensible to ignore advice.statusHints and disable
> hints unconditionally when writt
Hi,
At $dayjob we have some simple "code quality" checks that we run to
make sure that things are heading in the right direction. These are
usually run as part of our automated builds but people occasionally
run them when merging updates from other teams or preparing to merge
to the integration br
Hi Ron,
On 28/08/13 03:10, Ron Tregaskis - NOAA Federal wrote:
> Does git work with Eclipse?
>
> Ron
> --
Eclipse does have git integration courtesy of the EGit plugin. At
$dayjob most of us are running eclipse 3.7 a.k.a "Indigo". When we
started with an earlier eclipse version we had to instal
Hi Brian,
Sorry for the delay.
On 20/08/13 12:26, brian m. carlson wrote:
> When git submodule summary is run and there is a deleted submodule, there is
> an
> warning from git rev-parse:
>
> fatal: Not a git repository: '.vim/pathogen/.git'
>
> Silence this warning, since it is fully expect
Hi Brian,
On 19/08/13 05:31, brian m. carlson wrote:
> When git submodule summary is run and there is a deleted submodule, there is
> an
> warning from git rev-parse:
>
> fatal: Not a git repository: '.vim/pathogen/.git'
>
> Silence this warning, since it is fully expected that a deleted submo
ng able
to intercept the submodule update process may prove useful for
integrating with or extensions to other tools.
Signed-off-by: Chris Packham
---
v4 adds a couple of simple tests - an equivalent of update=checkout and a test
to make sure we detect a failure reported by the update command.
On 03/07/13 19:54, Chris Packham wrote:
> On a related note should I be updating Documentation/config.txt as well?
> Even if it's a statement that this feature exists refer to
> git-submodule(1) for details.
>
Answering my own question. While 'update' is mentioned i
On 03/07/13 18:55, Jens Lehmann wrote:
> Am 03.07.2013 01:26, schrieb Chris Packham:
>> On Wed, Jul 3, 2013 at 4:56 AM, Jens Lehmann wrote:
>>> Am 02.07.2013 12:12, schrieb Chris Packham:
>>>> --- a/Documentation/git-submodule.txt
>>>> +++ b/Documentati
On Wed, Jul 3, 2013 at 4:56 AM, Jens Lehmann wrote:
> Am 02.07.2013 12:12, schrieb Chris Packham:
>> --- a/Documentation/git-submodule.txt
>> +++ b/Documentation/git-submodule.txt
>> @@ -159,7 +159,9 @@ update::
>> This will make the submodules HEAD be de
ng able
to intercept the submodule update process may prove useful for
integrating or extending other tools.
Signed-off-by: Chris Packham
---
v3 updated as per Junio's review.
Still needs tests. Any suggestions? I've been manually testing by setting
submodule.$name.update to '!echo
On 02/07/13 04:48, Junio C Hamano wrote:
> Chris Packham writes:
>
>> +!*)
>> +command="$(expr "$update_module" : '!\(.*\)')"
>
> command=${command#!}
>
Thanks, expr was my attem
ng able
to intercept the submodule update process may prove useful for
integrating or extending other tools.
Signed-off-by: Chris Packham
---
On 01/07/13 03:30, Jens Lehmann wrote:
>
> Hmm, if we go that route, why not do the same we do for aliases? If
> the submodule.*.update setting is
On 01/07/13 03:30, Jens Lehmann wrote:
> Am 29.06.2013 11:11, schrieb Chris Packham:
>> On 28/06/13 22:42, Fredrik Gustafsson wrote:
>>> technically it looks fine to me (except for the lack of tests) but I'm
>>> not sure I follow the use case.
>>>
>
On 28/06/13 22:42, Fredrik Gustafsson wrote:
> Hi,
>
> On Fri, Jun 28, 2013 at 09:53:10PM +1200, Chris Packham wrote:
>> This allows the user some finer grained control over how the update is
>> done. The primary motivation for this was interoperability with stgit
>
This allows the user some finer grained control over how the update is
done. The primary motivation for this was interoperability with stgit
however being able to intercept the submodule update process may prove
useful for integrating or extending other tools.
Signed-off-by: Chris Packham
--
Hi
On 07/05/13 07:16, Jens Lehmann wrote:
> Am 06.05.2013 02:19, schrieb Chris Packham:
>> This did get me thinking. Why does an uninitialized submodule need to
>> have an empty directory? If it didn't the maintainer in question
>> probably would have realized that he ne
Hi,
[Jens, sorry for the re-send - trying to convince gmail to send plain text.]
Just ran into a submodules usability situation at $dayjob that might
be worth looking at.
An internal maintainer was going to pull changes in from a project
team into our repository which is arranged into submodules
Hi Jens,
(sorry for the dup. gmail insists on sending html)
I know I saw a few threads regarding support for moving submodules but I
lost track of the discussion.
At $dayjob we were discussing a potential re-org of our super-projects
to introduce a bit of hierarchy to the submodules (at the mome
Minor typo
On 12/29/2012 05:20 AM, Eric S. Raymond wrote:
> The parsecvs code has been neglected for a long time, and the only
> public version does not even build correctly. I have been handed
> control of the project and intend to fix this, but until I do it
> cannot be recommended.
>
> Also,
On 09/12/2012 09:48 PM, Junio C Hamano wrote:
> Chris Packham writes:
>
>> Our default MUA has an annoying habit of using a non RFC822 date format when
>> saving an email as plaintext. This means the first 12 days of every month we
>> run into the ambiguous date problem
--
This testcase is only good for the next couple of months. For a longer term
test the current time would need to be set in the test setup.
---
t/t4255-am-author-date.sh | 85 +
1 file changed, 85 insertions(+)
create mode 100755 t/t4255-am-author-d
Hi,
I think this has come up before [1],[2] but we ran into this at $dayjob today.
Our default MUA has an annoying habit of using a non RFC822 date format when
saving an email as plaintext. This means the first 12 days of every month we
run into the ambiguous date problem (our date convention is d
first. Even better the tab completion works!
> On Aug 9, 2012 5:44 PM, "Chris Packham" wrote:
>>
>> Hi,
>>
>> At $dayjob we have backups setup for developers using a post-commit
>> hook that rsyncs the local .git directory to a backup server. The
>>
Hi,
At $dayjob we have backups setup for developers using a post-commit
hook that rsyncs the local .git directory to a backup server. The
advantage we get of using rsync instead of git push is that we also
backup the things that git push doesn't touch (e.g. config, hooks,
metadata from other tools
101 - 152 of 152 matches
Mail list logo
