* Re: [PATCH (GIT-GUI BUG)] git-gui: use of undeclared variable in handle_empty_diff
From: Johannes Schindelin @ 2009-04-05 21:35 UTC (permalink / raw)
To: Joerg Bornemann; +Cc: git
In-Reply-To: <0337ff5648e5e0dc583e255a44573dbf@mb8-2.1blu.de>
Hi,
On Sun, 5 Apr 2009, Joerg Bornemann wrote:
> Commit 584fa9cc ("git-gui: Avoid an infinite rescan loop in
> handle_empty_diff.") introduced the global variable diff_empty_count,
> which is used in diff.tcl. But this variable isn't declared anywhere
> which results in an ugly error message box instead of the intended
> informative message. This patch fixes this and removes the unnecessary
> second initialization of current_diff_path.
Under which circumstances does this bug trigger? I never saw it happen.
Ciao,
Dscho
^ permalink raw reply
* Running 'git pull' from an unnamed branch
From: Reece Dunn @ 2009-04-05 21:33 UTC (permalink / raw)
To: Git List
Hi,
Here is something I have just recently tripped up on.
$ git pull
You asked me to pull without telling me which branch you
want to merge with, and 'branch..merge' in
your configuration file does not tell me either. Please
name which branch you want to merge on the command line and
try again (e.g. 'git pull <repository> <refspec>').
See git-pull(1) for details on the refspec.
If you often merge with the same branch, you may want to
configure the following variables in your configuration
file:
branch..remote = <nickname>
branch..merge = <remote-ref>
remote.<nickname>.url = <url>
remote.<nickname>.fetch = <refspec>
See git-config(1) for details.
$ git branch
* (no branch)
master
Running `git checkout master && git pull` fixed the above issue. The
patch below improves the error message for users that are in this
state.
Also, is "branch..remote" valid? Should this be "branch.remote"?
- Reece
>From c3933ba95f705dae1a41cb2ee6a282f3be0a6ab0 Mon Sep 17 00:00:00 2001
From: Reece Dunn <msclrhd@gmail.com>
Date: Sun, 5 Apr 2009 22:27:10 +0100
Subject: [PATCH] Improve the message when pulling to a headless branch.
---
git-pull.sh | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/git-pull.sh b/git-pull.sh
index 8a26763..00a72dd 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -97,6 +97,10 @@ error_on_no_merge_candidates () {
echo "try again (e.g. 'git pull <repository> <refspec>')."
echo "See git-pull(1) for details on the refspec."
echo
+ echo "You may not be on a branch. In this case, you need to move"
+ echo "onto the branch you want to pull to (usually master):"
+ echo " git checkout <branch>"
+ echo
echo "If you often merge with the same branch, you may want to"
echo "configure the following variables in your configuration"
echo "file:"
--
1.6.0.4
^ permalink raw reply related
* Re: Performance issue: initial git clone causes massive repack
From: Sverre Rabbelier @ 2009-04-05 21:36 UTC (permalink / raw)
To: david, Junio C Hamano
Cc: Nicolas Sebrecht, Robin H. Johnson, Git Mailing List
In-Reply-To: <alpine.DEB.1.10.0904051419490.6245@asgard.lang.hm>
Heya,
On Sun, Apr 5, 2009 at 23:28, <david@lang.hm> wrote:
> Guys, back off a little on telling the gentoo people to change.
I agree here, we should either say "look, we don't really support big
repositories because [explanation here], unless you [workarounds
here]" OR we should work to improve the support we do have. Of course,
the latter option does not magically create developer time to work on
that, but if we do go that way we should at least tell people that we
are aware of the problems and that it's on the global TODO list (not
necessarily on anyone's personal TODO list though).
Of course, the problem can sometimes be solved by splitting the
repository, but I think it is important to have an official policy
here, do we want Git to support huge repositories, or do we not?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: Running 'git pull' from an unnamed branch
From: Sverre Rabbelier @ 2009-04-05 21:37 UTC (permalink / raw)
To: Reece Dunn; +Cc: Git List
In-Reply-To: <3f4fd2640904051433u199587c3wc9bf080d138944e7@mail.gmail.com>
Heya,
On Sun, Apr 5, 2009 at 23:33, Reece Dunn <msclrhd@googlemail.com> wrote:
> + echo "You may not be on a branch. In this case, you need to move"
> + echo "onto the branch you want to pull to (usually master):"
> + echo " git checkout <branch>"
> + echo
Please, there's already 17 lines of spam each time I type 'git pull',
let's not embed the entire user manual!
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [EGIT PATCH 5/5] Cache resolved ids in quickdiff document for faster update
From: Robin Rosenberg @ 2009-04-05 21:40 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20090405203604.GP23521@spearce.org>
söndag 05 april 2009 22:36:04 skrev "Shawn O. Pearce" <spearce@spearce.org>:
> Arrrgh. We're still using Commit/Tree/TreeEntry to read file paths?
>
> I'm applying this as-is, but we really need to start to transition
> away from them. I wanted to start deleting the mapCommit and its
> friends from the Repository class.
Yeah, but the new API is more awkward and error-prone to use. The old
API is quite straightforward. I will try harder next time.
-- robin
^ permalink raw reply
* Re: [EGIT PATCH 2/5] quickdiff - Don't add GitDocument as repository listener more than once
From: Robin Rosenberg @ 2009-04-05 21:41 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20090405202400.GO23521@spearce.org>
söndag 05 april 2009 22:24:00 skrev "Shawn O. Pearce" <spearce@spearce.org>:
> Robin Rosenberg <robin.rosenberg@dewire.com> wrote:
> > Doing so was very costly and led to sessions being locked
> > for a long time while refreshing the reference document used
> > by Eclipse's quickdiff feature.
> ...
> > --- a/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java
> > +++ b/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java
> > @@ -1132,6 +1132,7 @@ public File getWorkDir() {
> > * @param l
> > */
> > public void addRepositoryChangedListener(final RepositoryListener l) {
> > + assert !listeners.contains(l);
> > listeners.add(l);
> > }
> >
> > @@ -1150,6 +1151,7 @@ public void removeRepositoryChangedListener(final RepositoryListener l) {
> > * @param l
> > */
> > public static void addAnyRepositoryChangedListener(final RepositoryListener l) {
> > + assert !allListeners.contains(l);
> > allListeners.add(l);
> > }
>
> That's a race condition. The two collections are Vectors so another
> thread can add the listener between your assertion point and the
> add call.
That would be another programming error, to add the same listener from different threads. Hopefully it would be caught on the next run. Adding synchronized might be too much since I cannot disable it by disabling assert.
> Also, if this really is considered to be very bad behavior on the
> part of the application, maybe these should be real tests with
> exceptions thrown, so they can't be disabled when assertions are
> turned off in the JRE?
It's usually not terribly bad, but what happens isn't well defined. If it happens it's a programming error. Especially now that the API bans it.
Asserts are for detecting programming errors during program test. If the tests are good enough there will never be a reason for this assert to fail and so it won't be necessary in deployed code. We could probably have lots more of these
declarations of assumptions, most of which would be less obvious than this simple test.
In particular asserts are for detecting bad conditions the programmer controls (or should control). Anything that can be the result of user actions or depending on the runtime environment should have non assert tests.
-- robin
^ permalink raw reply
* Re: Running 'git pull' from an unnamed branch
From: Markus Heidelberg @ 2009-04-05 21:42 UTC (permalink / raw)
To: Reece Dunn; +Cc: Git List
In-Reply-To: <3f4fd2640904051433u199587c3wc9bf080d138944e7@mail.gmail.com>
Reece Dunn, 05.04.2009:
> Hi,
>
> Here is something I have just recently tripped up on.
>
> $ git pull
>
> [..]
>
> $ git branch
> * (no branch)
> master
>
> Running `git checkout master && git pull` fixed the above issue. The
> patch below improves the error message for users that are in this
> state.
>
> Also, is "branch..remote" valid? Should this be "branch.remote"?
The current branch has no name, so there is nothing between the two
dots. For clarification: branch.(no branch).remote
> + echo "You may not be on a branch. In this case, you need to move"
> + echo "onto the branch you want to pull to (usually master):"
> + echo " git checkout <branch>"
> + echo
Not being on a branch is not the general case when you receive this
message. Maybe determining if you are not on a branch and adjusting the
message acordingly is an option.
Markus
^ permalink raw reply
* Re: [EGIT PATCH 5/5] Cache resolved ids in quickdiff document for faster update
From: Shawn O. Pearce @ 2009-04-05 21:43 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <200904052340.01864.robin.rosenberg.lists@dewire.com>
Robin Rosenberg <robin.rosenberg.lists@dewire.com> wrote:
> s?ndag 05 april 2009 22:36:04 skrev "Shawn O. Pearce" <spearce@spearce.org>:
> > Arrrgh. We're still using Commit/Tree/TreeEntry to read file paths?
> >
> > I'm applying this as-is, but we really need to start to transition
> > away from them. I wanted to start deleting the mapCommit and its
> > friends from the Repository class.
>
> Yeah, but the new API is more awkward and error-prone to use. The old
> API is quite straightforward.
I see. Then I failed.
What can we do to reduce that?
> I will try harder next time.
Shouldn't be necessary. :-)
--
Shawn.
^ permalink raw reply
* Re: [RFC/PATCH 0/2] New 'stage' command
From: Markus Heidelberg @ 2009-04-05 21:58 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git, Junio C Hamano
In-Reply-To: <1238939331-10152-1-git-send-email-felipe.contreras@gmail.com>
Felipe Contreras, 05.04.2009:
> For example 'git stage diff' is more natural (at least to me) than 'git diff
> --cached', same goes for 'git stage rm foo.c' vs 'git rm --cached foo.c'.
Not for me. If I want to GET a diff, I want to use a command "diff", so
"git diff" is more obvious.
The next step is to say WHAT exactly to diff. Therefor options to the
"diff" command are more logically to me from a hierarchic POV. And here
I don't think options like "--cached" or "sha1..sha2", despite having
different style, make any difference.
Markus
^ permalink raw reply
* Re: [RFC/PATCH 0/2] New 'stage' command
From: Felipe Contreras @ 2009-04-05 22:06 UTC (permalink / raw)
To: Jay Soffian; +Cc: Junio C Hamano, git
In-Reply-To: <76718490904051355p2f92d445j860c56638118a604@mail.gmail.com>
On Sun, Apr 5, 2009 at 11:55 PM, Jay Soffian <jaysoffian@gmail.com> wrote:
> On Sun, Apr 5, 2009 at 4:41 PM, Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
>> == stage ==
>>
>> The word "stage" is used widely in the English language, and it
>> immediately evokes a theatrical stage. Generally, it means a different
>> (upper) level.
>>
>> In git it is barely used, mostly on the "documentation industry"
>> probably because it's easier to understand for most people (even
>> non-native-English speakers).
>
> Would an index by any other name smell as sweet?
Yeap, almost. Do you have in mind any other word that would fit?
--
Felipe Contreras
^ permalink raw reply
* Re: Running 'git pull' from an unnamed branch
From: Björn Steinbrink @ 2009-04-05 22:08 UTC (permalink / raw)
To: Reece Dunn; +Cc: Git List
In-Reply-To: <3f4fd2640904051433u199587c3wc9bf080d138944e7@mail.gmail.com>
On 2009.04.05 22:33:57 +0100, Reece Dunn wrote:
> $ git pull
> You asked me to pull without telling me which branch you
> want to merge with, and 'branch..merge' in
> your configuration file does not tell me either. Please
> name which branch you want to merge on the command line and
> try again (e.g. 'git pull <repository> <refspec>').
> See git-pull(1) for details on the refspec.
>
> If you often merge with the same branch, you may want to
> configure the following variables in your configuration
> file:
>
> branch..remote = <nickname>
> branch..merge = <remote-ref>
> remote.<nickname>.url = <url>
> remote.<nickname>.fetch = <refspec>
>
> See git-config(1) for details.
>
> $ git branch
> * (no branch)
> master
>
> Running `git checkout master && git pull` fixed the above issue. The
> patch below improves the error message for users that are in this
> state.
It doesn't "fix" anything, you're simply doing something different.
"git pull" while on a detached HEAD can't work, there are no defaults
that could be used. But e.g. "git pull origin master" would do, fetching
"master" from "origin" and merging it to the commit you have checked
out.
Your "git checkout master && git pull" does something else. It uses the
configured pull defaults for "master" to fetch something and merge it to
"master".
> Also, is "branch..remote" valid? Should this be "branch.remote"?
That's a bug, but it should not be branch.remote. The config setting is
branch.<name>.remote. As you were on a detached HEAD, there is no
"<name>", and the code that generates the error message doesn't handle
that correctly. I'd even say that in this case, the whole "If you often
merge ..." part makes no sense at all, you simply can't setup pull
defaults for a detached HEAD.
> + echo "You may not be on a branch. In this case, you need to move"
> + echo "onto the branch you want to pull to (usually master):"
Hm? Neither do you really need to move to a branch, nor is "master"
really _that_ special that it is warranted to recommend checking it
out... IMHO.
Björn
^ permalink raw reply
* Re: git-{diff,merge} refactor round 2
From: Markus Heidelberg @ 2009-04-05 22:15 UTC (permalink / raw)
To: David Aguilar; +Cc: Junio C Hamano, Johannes.Schindelin, charles, git, msysgit
In-Reply-To: <20090405211533.GA1393@gmail.com>
David Aguilar, 05.04.2009:
> On 0, Junio C Hamano <gitster@pobox.com> wrote:
> > David Aguilar <davvid@gmail.com> writes:
> >
> > I'll try to queue all the outstanding da/difftool patches tonight, but I
> > think the patches in the series are getting to the point of needing a
> > fresh redoing. Patches like "oops, these non-user scripts should have
> > been named with double-dash" can and should disappear.
> >
> > Currently they are:
> >
> > $ git log --oneline next..da/difftool
> > [..]
>
> It goes back even farther...
>
> d3b8cec difftool: move 'git-difftool' out of contrib
>
> d3db8cec is currently sitting in 'next' and is where the
> "oops, I should have used double-dash" lack of foresight
> began.
> 1. Base it on the current master, completely throwing away
> the existing da/difftool branch. That would include throwing
> away the commit that's in next if we really want to be clean
> about the history. In the process, move Markus' mergetool
> fixes for windows to the top so that they can be applied
> independently if necessary. This series would then depend
> on them.
This is my favourite, too.
Additionally, what about basing these on master as well? They also are
unrelated to the refactoring:
def88c8 mergetool-lib: specialize opendiff options when in diff mode
2a83022 mergetool-lib: add diffuse as merge and diff tool
73c59d9 mergetool-lib: specialize xxdiff options when in diff mode
273e7a2 mergetool-lib: specialize kdiff3 options when in diff mode
And start refactoring on top of these?
Then these could go into master or next, since they are mostly bugfixes
and the refactoring can start in pu.
> This would probably mean a merge conflict with next at some
> point.
Revert "d3b8cec difftool: move 'git-difftool' out of contrib" from next?
> Regardless of which it's based on, it's obvious that there'll
> be some squashing going on. Tentatively,
>
> Will be squashed:
> 588954e difftool: use valid_tool from git-mergetool-lib
> 8af4556 mergetool: use valid_tool from git-mergetool-lib
>
> Will be squashed:
> 72286b5 difftool: use get_mergetool_path from git-mergetool-lib
> d03b97f mergetool: use get_mergetool_path from git-mergetool-lib
> c6afc72 Add a mergetool-lib scriptlet for holding common merge tool functions
>
> Will be squashed:
> 99511d8 mergetool: use run_mergetool from git-mergetool-lib
> 37c48c7 difftool: use run_mergetool from git-mergetool-lib
> 4e314b5 mergetool-lib: introduce run_mergetool
>
> Will be squashed:
> def88c8 mergetool-lib: specialize opendiff options when in diff mode
> 73c59d9 mergetool-lib: specialize xxdiff options when in diff mode
> 273e7a2 mergetool-lib: specialize kdiff3 options when in diff mode
Yes, some squashing would be nice. Similar commit messages are confusing
when reading the history.
Markus
^ permalink raw reply
* Re: Running 'git pull' from an unnamed branch
From: Reece Dunn @ 2009-04-05 22:15 UTC (permalink / raw)
To: markus.heidelberg; +Cc: Git List
In-Reply-To: <200904052342.44856.markus.heidelberg@web.de>
2009/4/5 Markus Heidelberg <markus.heidelberg@web.de>:
> Reece Dunn, 05.04.2009:
>> Hi,
>>
>> Here is something I have just recently tripped up on.
>>
>> $ git pull
>>
>> [..]
>>
>> $ git branch
>> * (no branch)
>> master
>>
>> Running `git checkout master && git pull` fixed the above issue. The
>> patch below improves the error message for users that are in this
>> state.
>>
>> Also, is "branch..remote" valid? Should this be "branch.remote"?
>
> The current branch has no name, so there is nothing between the two
> dots. For clarification: branch.(no branch).remote
Ok. I see now.
>> + echo "You may not be on a branch. In this case, you need to move"
>> + echo "onto the branch you want to pull to (usually master):"
>> + echo " git checkout <branch>"
>> + echo
>
> Not being on a branch is not the general case when you receive this
> message. Maybe determining if you are not on a branch and adjusting the
> message acordingly is an option.
So, something like:
From 59e8b71be1585a3a6c8c1233811c19ef0022b3e5 Mon Sep 17 00:00:00 2001
From: Reece Dunn <msclrhd@gmail.com>
Date: Sun, 5 Apr 2009 23:15:03 +0100
Subject: [PATCH] Improve the message when pulling to a headless branch.
---
git-pull.sh | 40 +++++++++++++++++++++++-----------------
1 files changed, 23 insertions(+), 17 deletions(-)
diff --git a/git-pull.sh b/git-pull.sh
index 8a26763..f263c04 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -90,23 +90,29 @@ error_on_no_merge_candidates () {
curr_branch=${curr_branch#refs/heads/}
- echo "You asked me to pull without telling me which branch you"
- echo "want to merge with, and 'branch.${curr_branch}.merge' in"
- echo "your configuration file does not tell me either. Please"
- echo "name which branch you want to merge on the command line and"
- echo "try again (e.g. 'git pull <repository> <refspec>')."
- echo "See git-pull(1) for details on the refspec."
- echo
- echo "If you often merge with the same branch, you may want to"
- echo "configure the following variables in your configuration"
- echo "file:"
- echo
- echo " branch.${curr_branch}.remote = <nickname>"
- echo " branch.${curr_branch}.merge = <remote-ref>"
- echo " remote.<nickname>.url = <url>"
- echo " remote.<nickname>.fetch = <refspec>"
- echo
- echo "See git-config(1) for details."
+ if [ -n "$curr_branch" ]; then
+ echo "You asked me to pull without telling me which branch you"
+ echo "want to merge with, and 'branch.${curr_branch}.merge' in"
+ echo "your configuration file does not tell me either. Please"
+ echo "name which branch you want to merge on the command line"
+ echo "and try again (e.g. 'git pull <repository> <refspec>')."
+ echo "See git-pull(1) for details on the refspec."
+ echo
+ echo "If you often merge with the same branch, you may want to"
+ echo "configure the following variables in your configuration"
+ echo "file:"
+ echo
+ echo " branch.${curr_branch}.remote = <nickname>"
+ echo " branch.${curr_branch}.merge = <remote-ref>"
+ echo " remote.<nickname>.url = <url>"
+ echo " remote.<nickname>.fetch = <refspec>"
+ echo
+ echo "See git-config(1) for details."
+ else
+ echo "You may not be on a branch. In this case, you need to"
+ echo "move to the branch you want to pull to (usually master):"
+ echo " git checkout <branch>"
+ fi
exit 1
}
--
1.6.2.2.414.g81aa.dirty
^ permalink raw reply related
* Re: Running 'git pull' from an unnamed branch
From: Markus Heidelberg @ 2009-04-05 22:28 UTC (permalink / raw)
To: Reece Dunn; +Cc: Git List
In-Reply-To: <3f4fd2640904051515x797e10b5ia20543f207084a60@mail.gmail.com>
Reece Dunn, 06.04.2009:
> 2009/4/5 Markus Heidelberg <markus.heidelberg@web.de>:
> > Reece Dunn, 05.04.2009:
> >> + echo "You may not be on a branch. In this case, you need to move"
> >> + echo "onto the branch you want to pull to (usually master):"
> >> + echo " git checkout <branch>"
> >> + echo
> >
> > Not being on a branch is not the general case when you receive this
> > message. Maybe determining if you are not on a branch and adjusting the
> > message acordingly is an option.
>
> So, something like:
> git-pull.sh | 40 +++++++++++++++++++++++-----------------
> 1 files changed, 23 insertions(+), 17 deletions(-)
>
> diff --git a/git-pull.sh b/git-pull.sh
> index 8a26763..f263c04 100755
> --- a/git-pull.sh
> +++ b/git-pull.sh
> @@ -90,23 +90,29 @@ error_on_no_merge_candidates () {
>
> curr_branch=${curr_branch#refs/heads/}
>
> - echo "You asked me to pull without telling me which branch you"
> - echo "want to merge with, and 'branch.${curr_branch}.merge' in"
> - echo "your configuration file does not tell me either. Please"
> - echo "name which branch you want to merge on the command line and"
> - echo "try again (e.g. 'git pull <repository> <refspec>')."
> - echo "See git-pull(1) for details on the refspec."
> - echo
> - echo "If you often merge with the same branch, you may want to"
> - echo "configure the following variables in your configuration"
> - echo "file:"
> - echo
> - echo " branch.${curr_branch}.remote = <nickname>"
> - echo " branch.${curr_branch}.merge = <remote-ref>"
> - echo " remote.<nickname>.url = <url>"
> - echo " remote.<nickname>.fetch = <refspec>"
> - echo
> - echo "See git-config(1) for details."
> + if [ -n "$curr_branch" ]; then
> + echo "You asked me to pull without telling me which branch you"
> + echo "want to merge with, and 'branch.${curr_branch}.merge' in"
> + echo "your configuration file does not tell me either. Please"
> + echo "name which branch you want to merge on the command line"
> + echo "and try again (e.g. 'git pull <repository> <refspec>')."
> + echo "See git-pull(1) for details on the refspec."
> + echo
> + echo "If you often merge with the same branch, you may want to"
> + echo "configure the following variables in your configuration"
> + echo "file:"
> + echo
> + echo " branch.${curr_branch}.remote = <nickname>"
> + echo " branch.${curr_branch}.merge = <remote-ref>"
> + echo " remote.<nickname>.url = <url>"
> + echo " remote.<nickname>.fetch = <refspec>"
> + echo
> + echo "See git-config(1) for details."
> + else
> + echo "You may not be on a branch. In this case, you need to"
> + echo "move to the branch you want to pull to (usually master):"
> + echo " git checkout <branch>"
> + fi
> exit 1
> }
>
Yes, on something like this I thought, but the proposed solution is not
the right thing to do, see the response from Björn.
Maybe something like "You are not on a branch, so there cannot be a
configuration for git-pull. You have to explicitly tell the repository
and refspec." or so.
Markus
^ permalink raw reply
* Re: Running 'git pull' from an unnamed branch
From: Reece Dunn @ 2009-04-05 22:29 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Git List
In-Reply-To: <20090405220855.GA20356@atjola.homenet>
2009/4/5 Björn Steinbrink <B.Steinbrink@gmx.de>:
> On 2009.04.05 22:33:57 +0100, Reece Dunn wrote:
>> Running `git checkout master && git pull` fixed the above issue. The
>> patch below improves the error message for users that are in this
>> state.
>
> It doesn't "fix" anything, you're simply doing something different.
>
> "git pull" while on a detached HEAD can't work, there are no defaults
> that could be used. But e.g. "git pull origin master" would do, fetching
> "master" from "origin" and merging it to the commit you have checked
> out.
Sure.
> Your "git checkout master && git pull" does something else. It uses the
> configured pull defaults for "master" to fetch something and merge it to
> "master".
The two cases depend on if you want to stay with the detached HEAD or not.
>> Also, is "branch..remote" valid? Should this be "branch.remote"?
>
> That's a bug, but it should not be branch.remote. The config setting is
> branch.<name>.remote. As you were on a detached HEAD, there is no
> "<name>", and the code that generates the error message doesn't handle
> that correctly. I'd even say that in this case, the whole "If you often
> merge ..." part makes no sense at all, you simply can't setup pull
> defaults for a detached HEAD.
Yup. In my revised patch, I have it displaying a different message
(the one I added) instead of the default one you get at the moment.
>> + echo "You may not be on a branch. In this case, you need to move"
>> + echo "onto the branch you want to pull to (usually master):"
>
> Hm? Neither do you really need to move to a branch, nor is "master"
> really _that_ special that it is warranted to recommend checking it
> out... IMHO.
I said "usually master" to give a hint to the casual/newbie user. The
exact wording that is outputted in this case can be figured out. It
can also mention the case you highlighted.
- Reece
^ permalink raw reply
* Re: [RFC/PATCH 0/2] New 'stage' command
From: Felipe Contreras @ 2009-04-05 22:35 UTC (permalink / raw)
To: markus.heidelberg; +Cc: git, Junio C Hamano
In-Reply-To: <200904052358.53028.markus.heidelberg@web.de>
On Mon, Apr 6, 2009 at 12:58 AM, Markus Heidelberg
<markus.heidelberg@web.de> wrote:
> Felipe Contreras, 05.04.2009:
>> For example 'git stage diff' is more natural (at least to me) than 'git diff
>> --cached', same goes for 'git stage rm foo.c' vs 'git rm --cached foo.c'.
>
> Not for me. If I want to GET a diff, I want to use a command "diff", so
> "git diff" is more obvious.
> The next step is to say WHAT exactly to diff. Therefor options to the
> "diff" command are more logically to me from a hierarchic POV. And here
> I don't think options like "--cached" or "sha1..sha2", despite having
> different style, make any difference.
Well, it's a matter of preference, and you would not loose the option
to do it the way you like. But actually, "git diff --cached" is a
different action; you can't do "git diff --cached HEAD^.." for
example.
Consider "git rm foo.c" vs "git rm --cached foo.c"... both commands
are removing a file, the only difference is that one is removing from
the staging area while the other is removing it from the working
directory. Now think about "git branch -d bar", following the "first I
specify the action, and then the object" thinking, would it make sense
to have "git rm --branch bar"? Probably not; if you want to do stuff
with branches, you use "git branch", similarly, if you want to do
stuff with the staging area, why not use "git stage"?
--
Felipe Contreras
^ permalink raw reply
* Re: Performance issue: initial git clone causes massive repack
From: Nicolas Sebrecht @ 2009-04-05 22:59 UTC (permalink / raw)
To: david; +Cc: Nicolas Sebrecht, Robin H. Johnson, Git Mailing List
In-Reply-To: <alpine.DEB.1.10.0904051419490.6245@asgard.lang.hm>
On Sun, Apr 05, 2009 at 02:28:35PM -0700, david@lang.hm wrote:
> guys, back off a little on telling the gentoo people to change.
Don't blame Git people, please. I currently am the only one here to
discuss that way and see a painful work coming at Gentoo.
Git people didn't discuss around thoses issues.
> the
> kernel developers don't split th kernel into 'core' 'drivers' etc pieces
> just because some people only work on one area.
And you might notice that they don't provide a CVS access and actually
don't work around an unique shared repo. Also, you might notice that
keeping the history clean to assure the work on the kernel easier is not
an elementary issue.
> just because some people only work on one area. I see the gentoo desire
> to keep things in one repo as being something very similar.
That's why I think the gentoo desire is not very clean (don't be
affected). What I see is that in one hand you want a DSCM and on the
other hand you want to keep a central shared repo.
> the problem here is a real one, if you have a large repo, git send-pack
> will always generate a new pack, even if it doesn't need to (with the
> extreme case being the the repo is fully packed)
What about the rsync solution given in this thread?
--
Nicolas Sebrecht
^ permalink raw reply
* Re: Performance issue: initial git clone causes massive repack
From: Robin H. Johnson @ 2009-04-05 23:02 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <20090405191703.GJ23521@spearce.org>
[-- Attachment #1: Type: text/plain, Size: 2851 bytes --]
On Sun, Apr 05, 2009 at 12:17:03PM -0700, Shawn O. Pearce wrote:
> Another option is to use rsync:// for initial clones.
> git clone rsync://git.gentoo.org/tree.git
> rsync should be more efficient at dragging 1.6GiB over the network,
> as its only streaming the files. But it may fall over if the server
> has a lot of loose objects; many more small files to create.
I just tried this, and ran into a segfault.
Original command:
# git clone rsync://git.overlays.gentoo.org/vcs-public-gitroot/exp/gentoo-x86.git
It looks at a glance like the linked list has a null value it hits during the
internal while loop, not checking 'list' before using 'list->next'.
gdb> bt
#0 strcmp () at ../sysdeps/x86_64/strcmp.S:30
#1 0x000000000049474c in get_refs_via_rsync (transport=<value optimized out>, for_push=<value optimized out>) at transport.c:123
#2 0x000000000049234c in transport_get_remote_refs (transport=0x725fc9) at transport.c:1045
#3 0x000000000041620a in cmd_clone (argc=<value optimized out>, argv=0x7fff908c8550, prefix=<value optimized out>) at builtin-clone.c:487
#4 0x0000000000404f59 in handle_internal_command (argc=0x2, argv=0x7fff908c8550) at git.c:244
#5 0x0000000000405167 in main (argc=0x2, argv=0x7fff908c8550) at git.c:434
gdb> up
#1 0x000000000049474c in get_refs_via_rsync (transport=<value optimized out>, for_push=<value optimized out>) at transport.c:123
123 (cmp = strcmp(buffer + 41,
gdb> print list
$1 = {nr = 0x0, alloc = 0x0, name = 0x0}
If I go into the repo thereafter and manually run git-fetch again, it does work
fine.
> One way around that would be to use two repositories on the server;
> a historical repository that is fully packed and contains the full
> history, and a bleeding edge repository that users would normally
> work against:
Yup, we've been considering similar. We do have one specific need with that
however: to prevent resource abuse, we would like to DENY the ability to do the
initial clone with git:// then - just so that nobody tries to DoS our servers
by doing a couple of hungry initial clones at once.
> That caching GSoC project may help, but didn't I see earlier in
> this thread that you have >4.8 million objects in your repository?
> Any proposals on that project would still have Git malloc()'ing
> data per object; its ~80 bytes per object needed so that's a data
> segment of 384+ MiB, per concurrent clone client.
384MiB or even 512MiB I can cover. It's the 200+ wallclock minutes of cpu burn
with no download that aren't acceptable.
P.S.
The -v output of the rsync-mode git-fetch is very devoid of output. Can we
maybe pipe the rsync progress back?
--
Robin Hugh Johnson
Gentoo Linux Developer & Infra Guy
E-Mail : robbat2@gentoo.org
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
[-- Attachment #2: Type: application/pgp-signature, Size: 330 bytes --]
^ permalink raw reply
* Re: [RFC/PATCH 0/2] New 'stage' command
From: Björn Steinbrink @ 2009-04-05 23:06 UTC (permalink / raw)
To: Felipe Contreras; +Cc: markus.heidelberg, git, Junio C Hamano
In-Reply-To: <94a0d4530904051535v8bd901fsedecdf61bc4acb33@mail.gmail.com>
On 2009.04.06 01:35:24 +0300, Felipe Contreras wrote:
> On Mon, Apr 6, 2009 at 12:58 AM, Markus Heidelberg
> <markus.heidelberg@web.de> wrote:
> > Felipe Contreras, 05.04.2009:
> >> For example 'git stage diff' is more natural (at least to me) than 'git diff
> >> --cached', same goes for 'git stage rm foo.c' vs 'git rm --cached foo.c'.
> >
> > Not for me. If I want to GET a diff, I want to use a command "diff", so
> > "git diff" is more obvious.
> > The next step is to say WHAT exactly to diff. Therefor options to the
> > "diff" command are more logically to me from a hierarchic POV. And here
> > I don't think options like "--cached" or "sha1..sha2", despite having
> > different style, make any difference.
>
> Well, it's a matter of preference, and you would not loose the option
> to do it the way you like. But actually, "git diff --cached" is a
> different action; you can't do "git diff --cached HEAD^.." for
> example.
Sure you can. It diffs the index against HEAD^
> Consider "git rm foo.c" vs "git rm --cached foo.c"... both commands
> are removing a file, the only difference is that one is removing from
> the staging area while the other is removing it from the working
> directory.
The working tree _and_ the index. To delete it only from the working
tree you need "rm", not "git rm".
> Now think about "git branch -d bar", following the "first I
> specify the action, and then the object" thinking, would it make sense
> to have "git rm --branch bar"? Probably not; if you want to do stuff
> with branches, you use "git branch", similarly, if you want to do
> stuff with the staging area, why not use "git stage"?
If you're going that way, you'll also need "clone create", "working-tree
grep", "repo/remote fetch/pull/push", etc.
"git branch", "git tag", "git remote" and maybe "git status" are the
"outsiders", in that the commands (in some forms) end up as "git
<object> <action>" form. The rest is "git <action> <object>".
So "git stage <action>" would extend the minority, and not lead to
unification.
Björn
^ permalink raw reply
* Re: [RFC/PATCH 0/2] New 'stage' command
From: Markus Heidelberg @ 2009-04-05 23:17 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git, Junio C Hamano
In-Reply-To: <94a0d4530904051535v8bd901fsedecdf61bc4acb33@mail.gmail.com>
Felipe Contreras, 06.04.2009:
> On Mon, Apr 6, 2009 at 12:58 AM, Markus Heidelberg
> <markus.heidelberg@web.de> wrote:
> > Felipe Contreras, 05.04.2009:
> >> For example 'git stage diff' is more natural (at least to me) than 'git diff
> >> --cached', same goes for 'git stage rm foo.c' vs 'git rm --cached foo.c'.
> >
> > Not for me. If I want to GET a diff, I want to use a command "diff", so
> > "git diff" is more obvious.
> > The next step is to say WHAT exactly to diff. Therefor options to the
> > "diff" command are more logically to me from a hierarchic POV. And here
> > I don't think options like "--cached" or "sha1..sha2", despite having
> > different style, make any difference.
>
> Well, it's a matter of preference, and you would not loose the option
> to do it the way you like.
I know, but that's not the topic.
> But actually, "git diff --cached" is a
> different action; you can't do "git diff --cached HEAD^.." for
> example.
And I neither could I do "git stage diff HEAD^.."
> Consider "git rm foo.c" vs "git rm --cached foo.c"... both commands
> are removing a file, the only difference is that one is removing from
> the staging area while the other is removing it from the working
> directory. Now think about "git branch -d bar", following the "first I
> specify the action, and then the object" thinking, would it make sense
> to have "git rm --branch bar"? Probably not;
Right, the argumentation with first the action doesn't fly any more.
I guess it has to be considered what makes sense to have as command.
"rm" (not git-rm) is such a well-known tool for deleting files so it
probably doesn't make sense to have a command git-rm-files instead.
> if you want to do stuff
> with branches, you use "git branch", similarly, if you want to do
> stuff with the staging area, why not use "git stage"?
So git-diff for working with diffs, git-branch for working with
branches and git-rm/git-add for working on file level makes sense for
me. Whether the a command can work with both the working tree and the
index doesn't seem to make a difference for me.
Markus
^ permalink raw reply
* Re: Performance issue: initial git clone causes massive repack
From: david @ 2009-04-05 23:20 UTC (permalink / raw)
To: Nicolas Sebrecht; +Cc: Robin H. Johnson, Git Mailing List
In-Reply-To: <20090405225954.GA18730@vidovic>
On Mon, 6 Apr 2009, Nicolas Sebrecht wrote:
> On Sun, Apr 05, 2009 at 02:28:35PM -0700, david@lang.hm wrote:
>
>> guys, back off a little on telling the gentoo people to change.
>
> Don't blame Git people, please. I currently am the only one here to
> discuss that way and see a painful work coming at Gentoo.
> Git people didn't discuss around thoses issues.
>
>> the
>> kernel developers don't split th kernel into 'core' 'drivers' etc pieces
>> just because some people only work on one area.
>
> And you might notice that they don't provide a CVS access and actually
> don't work around an unique shared repo. Also, you might notice that
> keeping the history clean to assure the work on the kernel easier is not
> an elementary issue.
these issues are completely seperate from the issue that the initial
poster asked about, which is that when someone tries to do a clone of the
repository the system wastes a lot of time creating a new pack.
the kernel has a central public repo, they could run the cvs server on
that and still keep the rest of the kernel development exactly the way it
is.
if they are currently planning for one central repo with everyone pushing
to it, I expect that they will change their workflow as they get used to
git, but that isn't going to address the problem in the tool.
>> just because some people only work on one area. I see the gentoo desire
>> to keep things in one repo as being something very similar.
>
> That's why I think the gentoo desire is not very clean (don't be
> affected). What I see is that in one hand you want a DSCM and on the
> other hand you want to keep a central shared repo.
don't worry about this part of things, worry about why the server wastes
so many resources.
if this is really what's happening, other projects will suffer as well
(including the kernel, which has a very distributed workflow)
>> the problem here is a real one, if you have a large repo, git send-pack
>> will always generate a new pack, even if it doesn't need to (with the
>> extreme case being the the repo is fully packed)
>
> What about the rsync solution given in this thread?
that may be a work-around for a situation where git just doesn't work, but
how do they prevent users from killing their server by trying to do a
normal git clone?
Daivd Lang
^ permalink raw reply
* Re: [RFC/PATCH 0/2] New 'stage' command
From: Sverre Rabbelier @ 2009-04-05 23:22 UTC (permalink / raw)
To: markus.heidelberg; +Cc: Felipe Contreras, git, Junio C Hamano
In-Reply-To: <200904060117.24810.markus.heidelberg@web.de>
Heya,
On Mon, Apr 6, 2009 at 01:17, Markus Heidelberg
<markus.heidelberg@web.de> wrote:
> Felipe Contreras, 06.04.2009:
>> But actually, "git diff --cached" is a
>> different action; you can't do "git diff --cached HEAD^.." for
>> example.
>
> And I neither could I do "git stage diff HEAD^.."
I rest my case ;). That's the whole point Felipe is trying to make here.
$ git diff --cached
$ git diff HEAD^..
That's two different modes of operation with the only difference being
a switch ('--cached'), which changes what is, and what is not valid
after that.
Whereas with
$ git stage diff
There is no confusion that 'HEAD^..' is not a valid argument, as there
is no command in 'git stage diff' to which it _is_ a valid argument.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [RFC/PATCH 0/2] New 'stage' command
From: Markus Heidelberg @ 2009-04-05 23:23 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Felipe Contreras, git, Junio C Hamano
In-Reply-To: <20090405230655.GB20356@atjola.homenet>
Björn Steinbrink, 06.04.2009:
> On 2009.04.06 01:35:24 +0300, Felipe Contreras wrote:
> > Well, it's a matter of preference, and you would not loose the option
> > to do it the way you like. But actually, "git diff --cached" is a
> > different action; you can't do "git diff --cached HEAD^.." for
> > example.
>
> Sure you can. It diffs the index against HEAD^
No, note the ".."
Markus
^ permalink raw reply
* Re: Performance issue: initial git clone causes massive repack
From: Robin Rosenberg @ 2009-04-05 23:28 UTC (permalink / raw)
To: david; +Cc: Nicolas Sebrecht, Robin H. Johnson, Git Mailing List
In-Reply-To: <alpine.DEB.1.10.0904051613420.6245@asgard.lang.hm>
måndag 06 april 2009 01:20:07 skrev david@lang.hm:
> >> the problem here is a real one, if you have a large repo, git send-pack
> >> will always generate a new pack, even if it doesn't need to (with the
> >> extreme case being the the repo is fully packed)
> >
> > What about the rsync solution given in this thread?
>
> that may be a work-around for a situation where git just doesn't work, but
> how do they prevent users from killing their server by trying to do a
> normal git clone?
Is there no way of telling git not work so hard on packing?
If not, you could try JGit and compare. It's still too stupid to pack much, so it shouldn't spend much CPU time (for that reason at least). I haven't tried JGit's deamon for large amounts of data yet.
-- robin
^ permalink raw reply
* Re: Performance issue: initial git clone causes massive repack
From: Robin H. Johnson @ 2009-04-05 23:38 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <20090405195714.GA4716@coredump.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 4561 bytes --]
On Sun, Apr 05, 2009 at 03:57:14PM -0400, Jeff King wrote:
> > During an initial clone, I see that git-upload-pack invokes
> > pack-objects, despite the ENTIRE repository already being packed - no
> > loose objects whatsoever. git-upload-pack then seems to buffer in
> > memory.
> We need to run pack-objects even if the repo is fully packed because we
> don't know what's _in_ the existing pack (or packs). In particular we
> want to:
> - combine multiple packs into a single pack; this is more efficient on
> the network, because you can find more deltas, and I believe is
> required because the protocol sends only a single pack.
>
> - cull any objects which are not actually part of the reachability
> chain from the refs we are sending
>
> If no work needs to be done for either case, then pack-objects should
> basically just figure that out and then send the existing pack (the
> expensive bit is doing deltas, and we don't consider objects in the same
> pack for deltas, as we know we have already considered that during the
> last repack). It does mmap the whole pack, so you will see your virtual
> memory jump, but nothing should require the whole pack being in memory
> at once.
While my current pack setup has multiple packs of not more than 100MiB
each, that was simply for ease of resume with rsync+http tests. Even
when I already had a single pack, with every object reachable,
pack-objects was redoing the packing.
> pack-objects streams the output to upload-pack, which should only ever
> have an 8K buffer of it in memory at any given time.
>
> At least that is how it is all supposed to work, according to my
> understanding. So if you are seeing very high memory usage, I wonder if
> there is a bug in pack-objects or upload-pack that can be fixed.
>
> Maybe somebody more knowledgeable than me about packing can comment.
Looking at the source, I agree that it should be buffering, however top and ps
seem to disagree. 3GiB VSZ and 2.5GiB RSS here now.
%CPU %MEM VSZ RSS STAT START TIME COMMAND
0.0 0.0 140932 1040 Ss 16:09 0:00 \_ git-upload-pack /code/gentoo/gentoo-git/gentoo-x86.git
32.2 0.0 0 0 Z 16:09 1:50 \_ [git-upload-pack] <defunct>
80.8 44.2 3018484 2545700 Sl 16:09 4:36 \_ git pack-objects --stdout --progress --delta-base-offset
Also, I did another trace, using some other hardware, in a LAN setting, and
noticed that git-upload-pack/pack-objects only seems to start output to the
network after it reaches 100% in 'remote: Compressing objects:'.
Relatedly, throwing more RAM (6GiB total, vs. the previous 2GiB) at the server
in this case cut the 200 wallclock minutes before any sending too place down to
5 minutes.
> > During 'remote: Counting objects: 4886949, done.', git-upload-pack peaks at
> > 2474216KB VSZ and 1143048KB RSS.
> > Shortly thereafter, we get 'remote: Compressing objects: 0%
> > (1328/1994284)', git-pack-objects with ~2.8GB VSZ and ~1.8GB RSS. Here,
> > the CPU burn also starts. On our test server machine (w/ git 1.6.0.6),
> > it takes about 200 minutes walltime to finish the pack, IFF the OOM
> > doesn't kick in.
> Have you tried with a more recent git to see if it is any better? There
> have been a number of changes since 1.6.0.6, although it looks like
> mostly dealing with better recovery from corrupted packs.
Testing right now, the above on the LAN setup was w/ current git HEAD.
> > For the initial clone, can the git-upload-pack algorithm please send
> > existing packs, and only generate a pack containing the non-packed
> > items?
>
> I believe that would require a change to the protocol to allow multiple
> packs. However, it may be possible to munge the pack header in such a
> way that you basically concatenate multiple packs. You would still want
> to peek in the big pack to try deltas from the non-packed items, though.
>
> I think all of this falls into the realm of the GSOC pack caching project.
> There have been other discussions on the list, so you might want to look
> through those for something useful.
Yes, both changing the protocol, and recognizing that existing packs may be
suitable to send could be considered as part of the caching project, as they
fall under the aegis of making good use of what's stored in the cache already
to send.
--
Robin Hugh Johnson
Gentoo Linux Developer & Infra Guy
E-Mail : robbat2@gentoo.org
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
[-- Attachment #2: Type: application/pgp-signature, Size: 330 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox