On Tue, Aug 13, 2013 at 1:27 AM, Ari Entlich wrote:
> Hello all!
>
> At my current workplace, I have a git-svn repository which has an extremely
> large working directory. I did not use the --stdlayout option in this clone,
> so I have a number of branches in my working directory which duplicate
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 become dangling (in the sense tha
On 08/12/2013 12:05 PM, Phil Hord wrote:
On Mon, Aug 12, 2013 at 1:29 AM, Luke San Antonio
wrote:
On 08/08/20130 04:54 PM, Phil Hord wrote:
Luke,
I think the issue is that your working directory receives your cached
file when you say 'git stash --keep-index'. When you restore the
stash, your
Command "git branch -vv" will report tracking branches, but invalid
tracking branches are also reported. This is because the function
stat_tracking_info() can not distinguish whether the upstream branch
does not exist, or nothing is changed between one branch and its
upstream.
This patch changes t
In order to see what the current branch is tracking, one way is using
"git branch -v -v", but branches other than the current are also
reported. Another way is using "git status", such as:
$ git status
# On branch master
# Your branch is ahead of 'origin/master' by 1 commit.
...
B
2013/8/12 Junio C Hamano :
> Jiang Xin writes:
>
>> 2013/8/10 Junio C Hamano :
>>> Jiang Xin writes:
>>>
So always show the remote tracking branch in the output of "git status"
and other commands will help users to see where the current branch
will push to and pull from. E.g.
If a user is working on master, and has merged in their feature branch, but now
has to "git pull" because master moved, with pull.rebase their feature branch
will be flattened into master.
This is because "git pull" currently does not know about rebase's preserve
merges flag, which would avoid thi
On Mon, Aug 12, 2013 at 3:44 AM, Junio C Hamano wrote:
> Subject: .mailmap: update long-lost friends with multiple defunct addresses
>
> A handful of past contributors are recorded with multiple e-mail
> addresses, all of which are undeliberable. With a lot of help from
s/undeliberable/undeliver
On Mon, Aug 12, 2013 at 10:24 AM, Junio C Hamano wrote:
> Don't we already do that?
>
> Warning: you are leaving N commits behind, not connected to
> any of your branches:
>
> ... list of commits to be lost ...
This only shows on checkout... not reset, not submodule-update, nor
an
On Mon, Aug 12, 2013 at 6:23 AM, Duy Nguyen wrote:
> That would annoy me as I often work on top of detached HEAD on purpose
> and only create a branch when I want to save something. If the warning
> is to be moved, it should warn at the next checkout.
Yes, you're absolutely right ...
My point ab
Hello all!
At my current workplace, I have a git-svn repository which has an extremely
large working directory. I did not use the --stdlayout option in this clone, so
I have a number of branches in my working directory which duplicate large
amounts of trunk. There is a particularly large subdir
Duy Nguyen writes:
> On Mon, Aug 12, 2013 at 7:14 PM, David Jeske wrote:
>> IMO, the current warning during checkout of a detached-head is
>> misplaced. It should be removed, and instead there should only be a
>> warning after detached-head commit, since this is the only time there
>> is a dange
David Jeske writes:
> @Junio - to put the issue in the context of your previous comments on
> the topic... way back when you made a comment about warnings during
> commits to detached heads..
>
> http://git.661346.n2.nabble.com/RFC-Detached-HEAD-reminder-on-commit-td834710.html#a834959
>
>> If we
Stefan Beller writes:
> On 08/12/2013 07:46 AM, Junio C Hamano wrote:
>> I think that is an overall improvement, especially if we also update
>> the checks of {one,two}->mode made for the block that deals with
>> submodules to use DIFF_FILE_VALID().
>>
>> Thanks.
>>
>
> So, do I understand your
Pete Wyckoff writes:
> You should send the patch to junio for inclusion in pu/ for the
> next release, with:
>
> Acked-by: Pete Wyckoff
Thanks; I'll queue this then.
-- >8 --
From: Alexandru Juncu
Date: Thu, 8 Aug 2013 16:17:38 +0300
Subject: [PATCH] git-p4: Fix occasional truncation of symli
> How should this interact with 949e0d8e (pull: require choice between
> rebase/merge on non-fast-forward pull, 2013-06-27)
I believe there should not be any conflicts in functionality, other
than just tweaking the docs to mention --rebase=preserve as an option.
Personally, I would assert that,
Duy Nguyen writes:
> That would annoy me as I often work on top of detached HEAD on purpose
> and only create a branch when I want to save something. If the warning
> is to be moved, it should warn at the next checkout.
$ git checkout master
Warning: you are leaving 1 commit behind, not connecte
Hi Junio,
> "-r", even though it happens to be accepted, is not a good idea
> here, as there are other --r* commands that are not --rebase.
>
> [--[no-]rebase|--rebase=preserve]
Cool, I will change that.
> You would want "bool or string" helper function to parse it
> correctly, something
On Mon, Aug 12, 2013 at 02:54:13PM +0200, Michael Haggerty wrote:
> We could satisfy a whole class of wishes by supporting
> user-wide/system-wide git hooks like
>
> ~/.githooks/{pre,post}-clone /etc/githooks/{pre,post}-clone
> ~/.githooks/{pre,post}-init /etc/githooks/{pre,post}
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 r
- From the beginning of push.c in 755225d, 2006-04-29, "thin" option
was enabled by default but could be turned off with --no-thin.
- Then Shawn changed the default to 0 in favor of saving server
resources in a4503a1, 2007-09-09. --no-thin worked great.
- One day later, in 9b28851 Daniel extr
On 12 August 2013 15:38, Pete Wyckoff wrote:
> al...@rosedu.org wrote on Mon, 12 Aug 2013 10:46 +0300:
>> On 11 August 2013 14:57, Pete Wyckoff wrote:
>> > al...@rosedu.org wrote on Thu, 08 Aug 2013 16:17 +0300:
>> >> Symlink contents in p4 print sometimes have a trailing
>> >> new line character
On Mon, Aug 12, 2013 at 7:14 PM, David Jeske wrote:
> IMO, the current warning during checkout of a detached-head is
> misplaced. It should be removed, and instead there should only be a
> warning after detached-head commit, since this is the only time there
> is a danger of losing something.
Tha
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 repository with a
> directory component "/magic/".
Thanks, this looks great!
On 08/12/2013 02:39 PM, Jeff King wrote:
> On Mon, Aug 12, 2013 at 09:52:45PM +1000, Andrew Ardill wrote:
>
>> On 11 August 2013 02:58, Junio C Hamano wrote:
>>> Perhaps we need a lighter-weight mechanism
>>>
>>> git init --profile=open
>>> git clone --profile=open git://git.kerne
Jeff King writes:
> On Sat, Aug 10, 2013 at 11:59:21AM +0200, Michael Haggerty wrote:
>
>> I intentionally don't set user.email in my ~/.gitconfig because I use
>> different identities (on the same machine) depending on what project I
>> am committing to (open-source vs. work). After I clone a
On Mon, Aug 12, 2013 at 09:52:45PM +1000, Andrew Ardill wrote:
> On 11 August 2013 02:58, Junio C Hamano wrote:
> > Perhaps we need a lighter-weight mechanism
> >
> > git init --profile=open
> > git clone --profile=open git://git.kernel.org/git.git
>
> This is something I would d
al...@rosedu.org wrote on Mon, 12 Aug 2013 10:46 +0300:
> On 11 August 2013 14:57, Pete Wyckoff wrote:
> > al...@rosedu.org wrote on Thu, 08 Aug 2013 16:17 +0300:
> >> Symlink contents in p4 print sometimes have a trailing
> >> new line character, but sometimes it doesn't. git-p4
> >> should only
@Junio - to put the issue in the context of your previous comments on
the topic... way back when you made a comment about warnings during
commits to detached heads..
http://git.661346.n2.nabble.com/RFC-Detached-HEAD-reminder-on-commit-td834710.html#a834959
> If we _really_ don't want newbies to s
On 11 August 2013 02:58, Junio C Hamano wrote:
> Perhaps we need a lighter-weight mechanism
>
> git init --profile=open
> git clone --profile=open git://git.kernel.org/git.git
This is something I would definitely use.
All of my work git directories are in a separate folder to my
On Mon, Aug 12, 2013 at 12:59 PM, Junio C Hamano wrote:
>> @@ -15,7 +15,7 @@ static const char * const push_usage[] = {
>> NULL,
>> };
>>
>> -static int thin;
>> +static int thin = 1;
>> static int deleterefs;
>> static const char *receivepack;
>> static int verbosity;
>> @@ -313,8 +313,
On Mon, Aug 12, 2013 at 5:04 AM, Лежанкин Иван wrote:
> Thank you, it works very well!
> Will this patch go to upstream?
Ask Junio.
> Also, there is still some unexpected memory consumption - about 2Gb
> per ~200 commits, but it's bearable.
> I will do a futher investigation.
Can you post some
On Mon, Aug 12, 2013 at 5:04 AM, Лежанкин Иван wrote:
> Thank you, it works very well!
> Will this patch go to upstream?
Ask Junio.
> Also, there is still some unexpected memory consumption - about 2Gb
> per ~200 commits, but it's bearable.
> I will do a futher investigation.
Can you post some
Thank you, it works very well!
Will this patch go to upstream?
Also, there is still some unexpected memory consumption - about 2Gb
per ~200 commits, but it's bearable.
I will do a futher investigation.
Felipe, should I exclude you from my futher reports on possible memory leaks?
On 10 August 201
On 08/12/2013 10:32 AM, Stefan Beller wrote:
>
> diff --git a/diff.c b/diff.c
> index e53ddad..de21971 100644
> --- a/diff.c
> +++ b/diff.c
> @@ -2254,8 +2254,11 @@ static void builtin_diff(const char *name_a,
> (!two->mode || S_ISGITLINK(two->mode))) {
> const
> Would the temporary branch created by checking out a random commit be
> automatically deleted when checking out another branch, or would it be
> garbage-collected at some
> point later?
Yes, as I stated in my example, the ephemeral branch created from
checking out a random commit would be aut
On 08/12/2013 07:46 AM, Junio C Hamano wrote:
> Jeff King writes:
>
>> On Thu, Aug 08, 2013 at 08:31:44PM +0200, Stefan Beller wrote:
>>
>>> The next occurrences are at:
>>> /* Never use a non-valid filename anywhere if at all possible */
>>> name_a = DIFF_FILE_VALID(one) ? name_a : name_
Stefan Beller writes:
>> +# The 2 following authors are probably the same person,
>> +# but both emails bounce.
>
> You seemed to be sure about Nanako Shiraishi for example,
> but here you're uncertain, whether he is one person
> or 2 persons having the same name?
Nanako did 70+ patches, and
Signed-off-by: Stefan Beller
---
.mailmap | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/.mailmap b/.mailmap
index f7cc21e..1236b3a 100644
--- a/.mailmap
+++ b/.mailmap
@@ -19,9 +19,11 @@ Anders Kaseorg
Anders Kaseorg
Aneesh Kumar K.V
Ben Walton
+Benoit Sigoure
On 08/12/2013 09:58 AM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> I'd suggest using the lavabit address unless we hear the preferred
>> address from her, as the lavabit address was used in 5bf46841
>> (git-gui: update Japanese translation, 2010-02-02), while the last
>> use of the blueb
Hi Duy,
> OK. Mathijs, do you want make a patch for it?
I'm willing, but:
- I don't understand the code and all of your comments well enough yet
to start coding right away (though I haven't actually invested enough
time in this yet, either).
- I'll be on vacation for the next two weeks.
W
Junio C Hamano writes:
> I'd suggest using the lavabit address unless we hear the preferred
> address from her, as the lavabit address was used in 5bf46841
> (git-gui: update Japanese translation, 2010-02-02), while the last
> use of the bluebottle address was in 6762079a (Cloning from a repo
> w
David Jeske writes:
> I'm asking about (and proposing) this mechanism, because it would
> prevent refs from ever being "accidentally lost", such as occurs in
> the following scenerios..
>
> 1) forgetting to branch a detached head before checkin
> 2) forgetting a head is detached before moving awa
On Fri, Aug 09, 2013 at 01:57:19PM -0700, Junio C Hamano wrote:
> John Keeping writes:
>
> >> +New users are encouraged to use linkgit:git-log[1] instead. The
> >> +`whatchanged` command is essentially the same as linkgit:git-log[1]
> >> +run with different defaults that shows a --raw diff outpu
On 11 August 2013 14:57, Pete Wyckoff wrote:
> al...@rosedu.org wrote on Thu, 08 Aug 2013 16:17 +0300:
>> Symlink contents in p4 print sometimes have a trailing
>> new line character, but sometimes it doesn't. git-p4
>> should only remove the last character if that character
>> is '\n'.
>
> Your p
Junio C Hamano writes:
> I'd suggest using the lavabit address unless we hear the preferred
> address from her, as the lavabit address was used in 5bf46841
> (git-gui: update Japanese translation, 2010-02-02), while the last
> use of the bluebottle address was in 6762079a (Cloning from a repo
> w
On Mon, Aug 12, 2013 at 2:31 AM, Junio C Hamano wrote:
> Eric Sunshine writes:
>
>> The 'todo' sheet for interactive rebase shows abbreviated SHA-1's and
>> then performs its operations upon those shortened values. This can lead
>> to an abort if the SHA-1 of a reworded or edited commit is no lon
David Jeske wrote:
> Ephemeral branch names would be
> local-only and would never be pushed.
That's how normal branch names behave (local branch names and remote
branch names live in different namespaces). How would the proposed
detached HEAD replacement compare
Hi, Junio
Haven't seen new languages support for git l10n for over 1 year.
Here comes French translation.
Please pull the following updates from Jean-Noel Avila.
The following changes since commit 96cb27a9d2db3c01b8e296a0fbc1da1da09d1412:
Merge branch 'maint' (2013-08-09 15:49:55 -0700)
are
On Mon, Aug 12, 2013 at 2:28 AM, Junio C Hamano wrote:
> Eric Sunshine writes:
>
>> At start of script, t3404 installs a specialized test-editor ($EDITOR)
>> upon which many of the interactive rebase tests depend. Late in t3404,
>> test "rebase -i respects core.commentchar" installs its own cust
Has there ever been any any discussion of creating an ephemeral-branch
name mechanism, instead of using detached HEADs?
By ephemeral, I mean that a branch-name could be created which would
live only so long as it is the only named way to reach a ref or the
ref is in the working directory. Ephemera
INVESTMENT PROJECT ( SEE ATTACHED FOR DETAIL ).doc
Description: MS-Word document
Junio C Hamano writes:
> Andres Perera writes:
>
>> i just realized that there are ambiguities:
>>
>> pull -r (true|false|preserve) foo
>>
>> there are 2 ways to interpret this:
>>
>> pull --rebase=(true|false|preserve) foo # pull from remote named foo
>>
>> pull --rebase (true|false|preserve) f
53 matches
Mail list logo
