Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
Over the time the default value for --thin has been switched between
on and off. As of now it's always on, even if --no-thin is given.
Correct the code to respect --no-thin.
receive-pack learns about --no-thin only for testing purposes, hence
Jiang Xin worldhello@gmail.com writes:
2013/8/10 Junio C Hamano gits...@pobox.com:
Jiang Xin worldhello@gmail.com 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
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 this
Eric Sunshine sunsh...@sunshineco.com 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 longer
unique within the abbreviated SHA-1
Stephen Haberman step...@exigencecorp.com writes:
I assume I'm doing the right thing by just posting another version of
this patch to the git list; let me know if I'm missing something.
Thanks. Writing the story so far... summary like you did after
the three-dash line was very helpful.
diff
Junio C Hamano gits...@pobox.com writes:
Andres Perera andre...@zoho.com 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
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.
On Mon, Aug 12, 2013 at 2:28 AM, Junio C Hamano gits...@pobox.com wrote:
Eric Sunshine sunsh...@sunshineco.com 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
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
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
On Mon, Aug 12, 2013 at 2:31 AM, Junio C Hamano gits...@pobox.com wrote:
Eric Sunshine sunsh...@sunshineco.com 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
On 11 August 2013 14:57, Pete Wyckoff p...@padd.com 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'.
On Fri, Aug 09, 2013 at 01:57:19PM -0700, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk 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
David Jeske dav...@gmail.com 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
Junio C Hamano gits...@pobox.com 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
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.
On 08/12/2013 09:58 AM, Junio C Hamano wrote:
Junio C Hamano gits...@pobox.com 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
Stefan Beller stefanbel...@googlemail.com 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
On 08/12/2013 07:46 AM, Junio C Hamano wrote:
Jeff King p...@peff.net 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 :
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
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 char *del
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
On Mon, Aug 12, 2013 at 5:04 AM, Лежанкин Иван abys...@gmail.com 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
On Mon, Aug 12, 2013 at 5:04 AM, Лежанкин Иван abys...@gmail.com 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
On Mon, Aug 12, 2013 at 12:59 PM, Junio C Hamano gits...@pobox.com 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,7
On 11 August 2013 02:58, Junio C Hamano gits...@pobox.com 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
@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
al...@rosedu.org wrote on Mon, 12 Aug 2013 10:46 +0300:
On 11 August 2013 14:57, Pete Wyckoff p...@padd.com 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
On Mon, Aug 12, 2013 at 09:52:45PM +1000, Andrew Ardill wrote:
On 11 August 2013 02:58, Junio C Hamano gits...@pobox.com 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
Jeff King p...@peff.net 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
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 gits...@pobox.com wrote:
Perhaps we need a lighter-weight mechanism
git init --profile=open
git clone --profile=open
On 12 August 2013 22:39, Jeff King p...@peff.net 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
On Mon, Aug 12, 2013 at 7:14 PM, David Jeske dav...@gmail.com 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
On 12 August 2013 15:38, Pete Wyckoff p...@padd.com wrote:
al...@rosedu.org wrote on Mon, 12 Aug 2013 10:46 +0300:
On 11 August 2013 14:57, Pete Wyckoff p...@padd.com wrote:
al...@rosedu.org wrote on Thu, 08 Aug 2013 16:17 +0300:
Symlink contents in p4 print sometimes have a trailing
new
- 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
On Mon, Aug 12, 2013 at 11:01:03PM +1000, Andrew Ardill wrote:
On 12 August 2013 22:39, Jeff King p...@peff.net 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
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
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 like:
Duy Nguyen pclo...@gmail.com 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
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,
Pete Wyckoff p...@padd.com writes:
You should send the patch to junio for inclusion in pu/ for the
next release, with:
Acked-by: Pete Wyckoff p...@padd.com
Thanks; I'll queue this then.
-- 8 --
From: Alexandru Juncu al...@rosedu.org
Date: Thu, 8 Aug 2013 16:17:38 +0300
Subject: [PATCH]
Stefan Beller stefanbel...@googlemail.com 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
David Jeske dav...@gmail.com 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..
Duy Nguyen pclo...@gmail.com writes:
On Mon, Aug 12, 2013 at 7:14 PM, David Jeske dav...@gmail.com 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
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
On Mon, Aug 12, 2013 at 6:23 AM, Duy Nguyen pclo...@gmail.com 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
On Mon, Aug 12, 2013 at 10:24 AM, Junio C Hamano gits...@pobox.com 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
On Mon, Aug 12, 2013 at 3:44 AM, Junio C Hamano gits...@pobox.com 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
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 this
2013/8/12 Junio C Hamano gits...@pobox.com:
Jiang Xin worldhello@gmail.com writes:
2013/8/10 Junio C Hamano gits...@pobox.com:
Jiang Xin worldhello@gmail.com writes:
So always show the remote tracking branch in the output of git status
and other commands will help users to see where
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.
...
But
On 08/12/2013 12:05 PM, Phil Hord wrote:
On Mon, Aug 12, 2013 at 1:29 AM, Luke San Antonio
lukesananto...@gmail.com 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
52 matches
Mail list logo
