On Wed, Aug 14, 2013 at 07:42:11AM +0200, Daniel Knittl-Frank wrote:
> > So would that be a bug? Or maybe a feature? I would like it that
> > when you do a rebase and select no commits, it will rebase ontop of
> > the commit you chose, and remove all the commits not shown in the
> > interactive li
On 08/14/2013 12:06 AM, Junio C Hamano wrote:
> * sb/parseopt-boolean-removal (2013-08-07) 9 commits
> (merged to 'next' on 2013-08-08 at b138a2d)
> + revert: use the OPT_CMDMODE for parsing, reducing code
> + checkout-index: fix negations of even numbers of -n
> + config parsing options: allo
On 08/14/2013 07:14 AM, Junio C Hamano wrote:
> Sitaram Chamarty writes:
>
>> # all reflog entries that are not on a branch, tag, or remote
>> d1 = !gitk --date-order $(git log -g --pretty=%H) --not --branches
>> --tags --remotes
>> # all dangling commits not on a branch, tag, or rem
On Wed, Aug 14, 2013 at 6:50 AM, Hugh Davenport wrote:
> Hey,
>
> Not sure if this is a bug or not. I commonly am finding myself wanting to
> remove some recent commits, either all or just a select few. So I use rebase
> in interactive mode for this. The problem I find is that when I do a rebase
>
Hey,
Not sure if this is a bug or not. I commonly am finding myself wanting
to
remove some recent commits, either all or just a select few. So I use
rebase
in interactive mode for this. The problem I find is that when I do a
rebase
and leave no commits to pick (where I would think that this wo
Sitaram Chamarty writes:
> # all reflog entries that are not on a branch, tag, or remote
> d1 = !gitk --date-order $(git log -g --pretty=%H) --not --branches --tags
> --remotes
> # all dangling commits not on a branch, tag, or remote
> d2 = !gitk --date-order $(git fsck | grep "d
On 08/13/2013 10:19 PM, Junio C Hamano wrote:
> Duy Nguyen writes:
>
>> On Mon, Aug 12, 2013 at 3:37 PM, David Jeske wrote:
>>> Is there currently any way to say "hey, git, show me what commits are
>>> dangling that might be lost in the reflog?"
>>
>> How do you define dangling commits? When you
A release candidate Git v1.8.4-rc3 is now available for testing at
the usual places.
Things have calmed down on the 'master' front; we will still need to
revert one commit that killed "git stash" in a large directory with
a lot of cruft before the final, but other than that, everything
else should
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 -rc3 has been tagged; we will need to revert a7365313 (git
stash: avoid data loss when "git stash save" kills a directory,
2013-06-28) that
René Scharfe writes:
>> It was lost in the follow-up discussion and I missed it.
>
> I had forgotten about it as well, until Felipe mentioned it again.
>
>> I assume that this is signed-off by you as a forwarder? I'd prefer
>> to even mark it Reviewed-by: you.
>
> Right, I did review the patch a
[administrivia: people on the original thread added back on CC]
Junio C Hamano writes:
> Anders Darander writes:
>
Do anyone have any better idea on how to approach this?
>>>
>>>Teaching "ls-files" to leave early once it seens even a single
>>>output is probably a possibility.
>>
>> Would
Am 13.08.2013 23:12, schrieb Junio C Hamano:
René Scharfe writes:
From: Felipe Contreras
Before overwriting the destination index, first let's discard its
contents.
Signed-off-by: Felipe Contreras
Tested-by: Лежанкин Иван wrote:
---
Felipe sent this patch as part of multiple series in Jun
René Scharfe writes:
> From: Felipe Contreras
>
> Before overwriting the destination index, first let's discard its
> contents.
>
> Signed-off-by: Felipe Contreras
> Tested-by: Лежанкин Иван wrote:
> ---
> Felipe sent this patch as part of multiple series in June, but it can
> stand on its own
Eric Sunshine writes:
> git-contacts invokes git-blame once for each patch hunk it encounters.
> No attempt is made to consolidate invocations for multiple hunks
> referencing the same file at the same revision. This can become
> expensive quickly.
>
> Reduce the number of git-blame invocations b
This is the beginning of the rewrite of the repacking.
Signed-off-by: Stefan Beller
---
Makefile | 2 +-
builtin.h | 1 +
builtin/repack.c | 313 +
contrib/examples/git-repack.sh | 194 ++
Hello,
a few days ago, I asked how I would proceed if I'd want to rewrite git-repack.
The general consensus (Duy, Junio and Matthieu) was to not touch
git-pack-objects, but rather translate the shell version of the git-repack
to C.
I'll send a very rough patch, which still contains 2 todos, so it
Dear Git Mailing List,
I have force added a file we usually like to ignore (but keep in the
repository). That was a change a while ago, and cannot be undone without
serious pain. I would like to re-ignore the file though, as we dont want
to track changes to it. Some of the options I came acros
From: Felipe Contreras
Before overwriting the destination index, first let's discard its
contents.
Signed-off-by: Felipe Contreras
Tested-by: Лежанкин Иван wrote:
---
Felipe sent this patch as part of multiple series in June, but it can
stand on its own. This version is trivially rebased agai
Dear winner,
Microsoft organization is glad to pronounce your email ID as the lucky winner
of £1,000,000'00 send us the following details to claims award.Do note that no
ticket was sold nor ballot paper,it was conducted via random selection of so
many emails and your email emerge as a beneficia
Tvangeste writes:
> Brice Lambson live.com> writes:
>> +1, this is a significant issue downstream in Git for Windows:
>>
>> https://github.com/msysgit/git/issues/57
>>
>> Effectively this renders .gitattributes useless for the scenario of
>> enforcing normalized line ending characters.
>
> +1
Anders Darander writes:
>>> Do anyone have any better idea on how to approach this?
>>
>>Teaching "ls-files" to leave early once it seens even a single
>>output is probably a possibility.
>
> Would that mean that we're able to fail early?
Heh, good point. "Leave once you find one path" does not
Brice Lambson live.com> writes:
> +1, this is a significant issue downstream in Git for Windows:
>
> https://github.com/msysgit/git/issues/57
>
> Effectively this renders .gitattributes useless for the scenario of
> enforcing normalized line ending characters.
+100
Folks, the problem is still
Jiang Xin writes:
> Haven't seen new languages support for git l10n for over 1 year.
> Here comes French translation.
Nice.
Pulled, and will be part of -rc3.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More maj
(I'm resending this as Gmail added some html parts...)
Junio C Hamano wrote:
>Anders Darander writes:
>
>> diff --git a/git-stash.sh b/git-stash.sh
>> index 85c9e2c..e5a2043 100755
>> --- a/git-stash.sh
>> +++ b/git-stash.sh
>> @@ -263,7 +263,7 @@ save_stash () {
>> exit 0
>>
Junio C Hamano writes:
> David Jeske writes:
>
>>> When you do "git commit --amend",
>>> the current commit will become dangling (in the sense that it's not
>>> referred by any ref, but the commit exists) and those are just noise
>>> in my opinion.
>>
>> This is *exactly* my point.
>>
>> There i
Anders Darander writes:
> diff --git a/git-stash.sh b/git-stash.sh
> index 85c9e2c..e5a2043 100755
> --- a/git-stash.sh
> +++ b/git-stash.sh
> @@ -263,7 +263,7 @@ save_stash () {
> exit 0
> fi
> if test -z "$untracked$force" &&
> - test -n "$(git ls-files
David Jeske writes:
>> When you do "git commit --amend",
>> the current commit will become dangling (in the sense that it's not
>> referred by any ref, but the commit exists) and those are just noise
>> in my opinion.
>
> This is *exactly* my point.
>
> There is no way to distinguish a commit whi
Duy Nguyen writes:
> On Mon, Aug 12, 2013 at 3:37 PM, David Jeske wrote:
>> Is there currently any way to say "hey, git, show me what commits are
>> dangling that might be lost in the reflog?"
>
> How do you define dangling commits? When you do "git commit --amend",
> the current commit will bec
Duy Nguyen writes:
> transport_get() actually sets thin option to 1 by default.
Yeah, I missed your message in the nearby thread. It indeed does.
--
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:
Jeff King writes:
> I guess we could do something like:
>
> [include "repo:...your regex here..."]
> path = .gitconfig-only-for-some-repos
> [include "env:USE_MY_MAGIC_CONFIG"]
> path = .gitconfig-only-when-magic-env-set
I am not sure if "env" is very useful, but there certainly are
Jeff King writes:
> diff --git a/config.c b/config.c
> index e13a7b6..a31dc85 100644
> --- a/config.c
> +++ b/config.c
> @@ -119,10 +119,45 @@ int git_config_include(const char *var, const char
> *value, void *data)
> return ret;
> }
>
> +static NORETURN void die_bad_regex(int err, rege
Matthieu Moy writes:
> Junio C Hamano writes:
>
>> +changes. You can emulate `git log` with a trivial script that pipes
>
> I'd say "You can emulate `git log` and `git log -p`" here, but I'm fine
> with your version too.
By `git log`, I meant "`git log` with its various options", as it
felt un
John Keeping writes:
> Hmm, I hadn't realised that specifying "-p" would disable the "--raw".
> I still find the last sentence of the original patch slightly awkward
> though. How about
>
> New users are encouraged to use linkgit:git-log[1] instead. The
> `whatchanged` command is essent
On Tue, Aug 13, 2013 at 10:52:34PM +1000, Andrew Ardill wrote:
> > The only downside I can think of is that we might want to use the
> > subsection in "include.SUBSECTION.*" for some other limiting conditions
> > (e.g., "only include this config when running version >= X.Y", or even
> > "include o
On Aug 12, 2013 11:06 PM, "Duy Nguyen" wrote:
>
> On Mon, Aug 12, 2013 at 3:37 PM, David Jeske wrote:
> > Is there currently any way to say "hey, git, show me what commits are
> > dangling that might be lost in the reflog?"
>
> How do you define dangling commits?
Any commit which I did not expl
On Tue, Aug 13, 2013 at 9:44 PM, David Jeske wrote:
> On Aug 12, 2013 11:06 PM, "Duy Nguyen" wrote:
>>
>> On Mon, Aug 12, 2013 at 3:37 PM, David Jeske wrote:
>> > Is there currently any way to say "hey, git, show me what commits are
>> > dangling that might be lost in the reflog?"
>>
>> How do y
Signed-off-by: Matthieu Moy
---
contrib/mw-to-git/.gitignore | 1 +
1 file changed, 1 insertion(+)
diff --git a/contrib/mw-to-git/.gitignore b/contrib/mw-to-git/.gitignore
index b919655..ae545b0 100644
--- a/contrib/mw-to-git/.gitignore
+++ b/contrib/mw-to-git/.gitignore
@@ -1 +1,2 @@
git-remot
Git-mediawiki's "dumb push" sends the local revisions to the remote wiki,
but does not update the local metadata to reflect the push (hence, the
next pull will have to re-import the exported revisions).
The previous implementation was simply omitting the update to the private
ref after a dumb push
On 13 August 2013 21:46, Jeff King wrote:
> Like I said, I do not have a particular use for it, but I don't think it
> would hurt anybody who does not use it. If you want to polish it up into
> a real patch with docs and tests, I don't mind.
I'll have a go at this.
> The only downside I can thi
On Tue, Aug 13, 2013 at 07:46:35AM -0400, Jeff King wrote:
> The only downside I can think of is that we might want to use the
> subsection in "include.SUBSECTION.*" for some other limiting conditions
> (e.g., "only include this config when running version >= X.Y", or even
> "include only when env
On Tue, Aug 13, 2013 at 09:05:40PM +1000, Andrew Ardill wrote:
> I applied this on top of latest next (1da3ebde8999d07), and it worked
> perfectly for my use case.
>
> For what it's worth, it also passed the test suite!
>
> Would be great to see this, or something on the same theme, get into
> m
On Mon, Aug 12, 2013 at 11:01:03PM +1000, Andrew Ardill wrote:
>On 12 August 2013 22:39, Jeff King wrote:
>> We could do something like the patch below, which allows:
>>
>> $ git config --global include./magic/.path .gitconfig-magic
>>
>> to read ~/.gitconfig-magic only when we are in a reposito
Josh Triplett joshtriplett.org> writes:
> [CCing folks involved in the recent "stash-refuse-to-kill" merge.]
>
> I keep portions of my home directory in git. I tried to "git stash"
> some local changes, and it ran for several minutes with no progress. ps
> showed that it was running "git ls-fil
Matthieu Moy dixit:
>An opt-in auto-detection would be cool for people who really work in a
>controlled environment, so that the sysadmin could enable it from
Sounds like a plan ;-)
I think with several people chiming in on this, while that proposal
would affect a majority of people, it would do
Felipe Contreras writes:
> This is how to implement that:
>
> From f1feaa05ce3772d8006078c4aeabcbd55b52d58e Mon Sep 17 00:00:00 2001
> From: Felipe Contreras 2nd
> Date: Tue, 13 Nov 2012 07:33:12 +0100
> Subject: [PATCH] ident: don't allow implicit email addresses
>
> Signed-off-by: Felipe Contr
Jonathan Nieder writes:
> Hi Thorsten,
>
> Thorsten Glaser wrote[1]:
>
>> git config user.email SHOULD NOT default to $(id -un)@$(hostname -f)
>> because just too many cow-orkers seem to be unable to follow basic
>> instructions
>
> Heh.
>
> Can you say a little more about your setup? In a unive
Junio C Hamano writes:
> (2) configure "include.path" to point at "~/.git-profile/open" at
> the very end
I'd rather have it ~/.config/git/profile/ (or
$XDG_CONFIG_HOME/git/profile if $XDG_CONFIG_HOME is set), but the
proposal makes sense.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
Junio C Hamano writes:
> +changes. You can emulate `git log` with a trivial script that pipes
I'd say "You can emulate `git log` and `git log -p`" here, but I'm fine
with your version too.
> -[NOTE]
> -Most likely, you are not directly using the core
> -Git Plumbing commands, but using Porcela
48 matches
Mail list logo