* reflog by default?, was Re: What's in git.git (stable)
From: Johannes Schindelin @ 2006-12-14 14:03 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Carl Worth, Andy Parkins, git
In-Reply-To: <20061214120518.GL1747@spearce.org>
Hi,
On Thu, 14 Dec 2006, Shawn Pearce wrote:
> * Normal working repository (wants reflogs);
> * Bare private (backup) repository (wants reflogs);
> * Bare shared repository (probably doesn't want reflogs);
> * Import generated repository (probably doesn't want reflogs);
In contrast, I think that reflogs make lots of sense for shared repos,
and less sense for bare (non-shared) ones...
So, I'd say: enable reflog by default, unless it is bare _and_ not shared.
But then, cmd_init_db() no longer knows if it was called with "--bare" or
not.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Avoid accessing a slow working copy during diffcore operations.
From: Johannes Schindelin @ 2006-12-14 14:12 UTC (permalink / raw)
To: Alex Riesen; +Cc: Shawn O. Pearce, Junio C Hamano, git
In-Reply-To: <81b0412b0612140557u225ca00du5b15823d05fda4b9@mail.gmail.com>
Hi,
On Thu, 14 Dec 2006, Alex Riesen wrote:
> On 12/14/06, Shawn O. Pearce <spearce@spearce.org> wrote:
> > If Git is compiled with NO_FAST_WORKING_DIRECTORY set then we will
> > avoid looking at the working directory when the blob in question
> > is available within a packfile and the caller doesn't need the data
> > unpacked into a temporary file.
>
> Why can't it be useful in generic code? What are the downsides?
It is usually cheaper to just read the file, especially if it is still
cached, because the alternative means unpacking the loose object, or
worse, unpacking the packed object _along_ with the objects in its delta
chain.
Not every OS sucks cache-wise, and you should not make others suffer for
Redmond's shortcomings.
Ciao,
Dscho
^ permalink raw reply
* Re: git-fetching from a big repository is slow
From: Johannes Schindelin @ 2006-12-14 14:14 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Andy Parkins, git
In-Reply-To: <4581573E.40803@op5.se>
Hi,
On Thu, 14 Dec 2006, Andreas Ericsson wrote:
> Andy Parkins wrote:
> > Hello,
> >
> > I've got a big repository. I've got two computers. One has the repository
> > up-to-date (164M after repack); one is behind (30M ish).
> >
> > I used git-fetch to try and update; and the sync took HOURS. I zipped the
> > .git directory and transferred that and it took about 15 minutes to
> > transfer.
> >
> > Am I doing something wrong? The git-fetch was done with a git+ssh:// URL.
> > The zip transfer with scp (so ssh shouldn't be a factor).
> >
>
> This seems to happen if your repository consists of many large binary files,
> especially many large binary files of several versions that do not deltify
> well against each other. Perhaps it's worth adding gzip compression detecion
> to git? I imagine more people than me are tracking gzipped/bzip2'ed content
> that pretty much never deltifies well against anything else.
Or we add something like the heuristics we discovered in another thread,
where rename detection (which is related to delta candidate searching) is
not started if the sizes differ drastically.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] merge-recursive: add/add really is modify/modify with an empty base
From: Catalin Marinas @ 2006-12-14 14:15 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0612141436170.3635@wbgn013.biozentrum.uni-wuerzburg.de>
On 14/12/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Thu, 14 Dec 2006, Catalin Marinas wrote:
> > What it the relation between git-merge-recursive and "git-read-tree
> > -m" (if any)?
>
> git-merge-recursive internally calls the equivalent of 'git-read-tree -m'
> (it does not fork() and exec(), but rather calls the C functions
> directly) and does nothing more if the 'git-write-tree' succeeds. At least
> that's the theory...
OK, thanks (I imagined it might work like this).
> > One nice addition to git-merge-recursive (probably only useful to
> > StGIT) would be more meaningful labeling of the conflict regions,
> > passed via a command line similar to the "diff3 -L" option. StGIT
> > generates "patched", "current" and "ancestor" labels with diff3.
>
> This is possible. However, it is not _that_ horrible to see "HEAD" and
> some SHA1 which is obviously non-HEAD. Added to that, a quite common case
> are the intermediate merges which make merge-recursive so powerful, and
> they are rightly called "Temporary branch 1" and "... 2".
From the StGIT perspective, it only does a three-way merge and passes
commit id to git-merge-recursive, hence the complicated naming.
However, it wouldn't be hard to modify StGIT to actually replace the
hashes in the file with meaningful names.
> > Yet another nice feature would be the ancestor region (which diff3
> > doesn't add either but it gets added by emacs'
> > ediff-merge-files-with-ancestor function if you use the interactive
> > merge with StGIT).
>
> Is this really that nice? I never needed it... Besides, it can get really
> crappy when the conflicting regions are too large.
I think I only used the ancestor region for a mental representation of
what xdl_merge already produces :-) since emacs (nor diff3) wasn't
able to show the real differences. Probably no longer needed now.
Thanks for the explanations.
--
^ permalink raw reply
* Re: More Perl fun: man and System directories
From: Brian Gernhardt @ 2006-12-14 14:15 UTC (permalink / raw)
To: Sebasitan Harl; +Cc: git
In-Reply-To: <4F093D53-CFC7-44F1-9460-22DAD35DBAC8@silverinsanity.com>
Sorry about the delay. My subscription e-mail to the list got
delayed somewhere along the way, so I missed your message until I
decided to poke at the web archive.
On Dec 13, 2006, at 1:14 PM, Sebastian Harl wrote:
> On Wed, Dec 13, 2006 at 08:07:19AM -0500, Brian Gernhardt wrote:
> > 1) Perl is creating man files in the wrong place. My system expects
> > them to be in /usr/local/share/man, but Perl is installing them in /
> > usr/local/man. Currently I'm just moving them by hand every time I
> > pull-make-install, which is less than optimal.
>
> Try "perl Makefile.PL INSTALLDIRS=vendor".
That doesn't seem to change anything at all, and checking "man
ExtUtils::MakeMaker" and "perl -V:install.*", that still seems to
install man files in /usr/local/man instead of /usr/local/share/man.
And still generates /usr/local/System/...
I ran:
cd perl; perl Makefile.PL INSTALLDIRS=vendor; cd ..; make; sudo make
install
Maybe I need to tweak Perl's variables somewhere instead. Or my
MANPATH. The latter is probably easier.
^ permalink raw reply
* Re: [PATCH] Avoid accessing a slow working copy during diffcore operations.
From: Alex Riesen @ 2006-12-14 14:49 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Shawn O. Pearce, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0612141511110.3635@wbgn013.biozentrum.uni-wuerzburg.de>
On 12/14/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > If Git is compiled with NO_FAST_WORKING_DIRECTORY set then we will
> > > avoid looking at the working directory when the blob in question
> > > is available within a packfile and the caller doesn't need the data
> > > unpacked into a temporary file.
> >
> > Why can't it be useful in generic code? What are the downsides?
>
> It is usually cheaper to just read the file, especially if it is still
> cached, because the alternative means unpacking the loose object, or
> worse, unpacking the packed object _along_ with the objects in its delta
> chain.
But you have to read less, and even that could be in cache as well
and unpacking in userspace could be faster than open/write temporary/
read temporary/close/unlink temporary file on a normal system
> Not every OS sucks cache-wise, and you should not make others suffer for
> Redmond's shortcomings.
I'm just do not understand why avoiding temporary file wouldn't help
^ permalink raw reply
* Re: git-fetching from a big repository is slow
From: Andreas Ericsson @ 2006-12-14 15:06 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Andy Parkins, git
In-Reply-To: <Pine.LNX.4.63.0612141513130.3635@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> Hi,
>
> On Thu, 14 Dec 2006, Andreas Ericsson wrote:
>
>> Andy Parkins wrote:
>>> Hello,
>>>
>>> I've got a big repository. I've got two computers. One has the repository
>>> up-to-date (164M after repack); one is behind (30M ish).
>>>
>>> I used git-fetch to try and update; and the sync took HOURS. I zipped the
>>> .git directory and transferred that and it took about 15 minutes to
>>> transfer.
>>>
>>> Am I doing something wrong? The git-fetch was done with a git+ssh:// URL.
>>> The zip transfer with scp (so ssh shouldn't be a factor).
>>>
>> This seems to happen if your repository consists of many large binary files,
>> especially many large binary files of several versions that do not deltify
>> well against each other. Perhaps it's worth adding gzip compression detecion
>> to git? I imagine more people than me are tracking gzipped/bzip2'ed content
>> that pretty much never deltifies well against anything else.
>
> Or we add something like the heuristics we discovered in another thread,
> where rename detection (which is related to delta candidate searching) is
> not started if the sizes differ drastically.
>
It wouldn't work for this particular case though. In our distribution
repository we have ~300 bzip2 compressed tarballs with an average size
of 3MiB. 240 of those are between 2.5 and 4 MiB, so they don't
drastically differ, but neither do they delta well.
One option would be to add some sort of config option to skip attempting
deltas of files with a certain suffix. That way we could just tell it to
ignore *.gz,*.tgz,*.bz2 and everything would work just as it does today,
but a lot faster.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply
* Re: svn versus git
From: Nguyen Thai Ngoc Duy @ 2006-12-14 15:08 UTC (permalink / raw)
To: git
In-Reply-To: <7vodq695ha.fsf@assigned-by-dhcp.cox.net>
On 12/14/06, Junio C Hamano <junkio@cox.net> wrote:
> If a Porcelain level "ls" is needed (and I am doubtful about
> usefulness of "svn list -r538" like command), that is the
> command you would want to teach about using ls-files and ls-tree
> depending on what the end users want in their workflow.
+1. Any chance git-ls can go to 1.5.0?
--
^ permalink raw reply
* Re: git-fetching from a big repository is slow
From: Andy Parkins @ 2006-12-14 15:18 UTC (permalink / raw)
To: git
In-Reply-To: <4581573E.40803@op5.se>
On Thursday 2006 December 14 13:53, Andreas Ericsson wrote:
> This seems to happen if your repository consists of many large binary
> files, especially many large binary files of several versions that do
> not deltify well against each other. Perhaps it's worth adding gzip
It's actually just every released patch to the linux kernel ever issued.
Almost entirely ASCII and every revision (save the first) created by patching
the previous.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply
* [PATCH] "master" should be treated no differently from any other branch
From: Andy Parkins @ 2006-12-14 15:19 UTC (permalink / raw)
To: git
This patch makes all merge log messages of the form:
Merge branch XXXX into YYYY
Regardless of whether YYYY is master or not.
"master" shouldn't get special treatment; making different log messages
based on the name of the branch is bad form. What if a user likes
"my/master" or "my/head" as their master branch?
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
builtin-fmt-merge-msg.c | 5 +----
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/builtin-fmt-merge-msg.c b/builtin-fmt-merge-msg.c
index 87d3d63..99edb75 100644
--- a/builtin-fmt-merge-msg.c
+++ b/builtin-fmt-merge-msg.c
@@ -331,10 +331,7 @@ int cmd_fmt_merge_msg(int argc, const char **argv, const char *prefix)
printf(" of %s", srcs.list[i]);
}
- if (!strcmp("master", current_branch))
- putchar('\n');
- else
- printf(" into %s\n", current_branch);
+ printf(" into %s\n", current_branch);
if (merge_summary) {
struct commit *head;
--
1.4.4.1.g3ece-dirty
^ permalink raw reply related
* [PATCH] git-status always says what branch it's on
From: Andy Parkins @ 2006-12-14 15:25 UTC (permalink / raw)
To: git
If the current branch was "master" then git-status wouldn't say
# On branch XXXX
In its output. This patch makes it so that this message is always
output; regardless of branch name.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
wt-status.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/wt-status.c b/wt-status.c
index de1be5b..9a78dac 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -271,7 +271,7 @@ static void wt_status_print_verbose(struct wt_status *s)
void wt_status_print(struct wt_status *s)
{
- if (s->branch && strcmp(s->branch, "refs/heads/master"))
+ if (s->branch)
color_printf_ln(color(WT_STATUS_HEADER),
"# On branch %s", s->branch);
--
1.4.4.1.g3ece-dirty
^ permalink raw reply related
* Re: [PATCH] "master" should be treated no differently from any other branch
From: Johannes Schindelin @ 2006-12-14 15:29 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200612141519.44294.andyparkins@gmail.com>
Hi,
On Thu, 14 Dec 2006, Andy Parkins wrote:
> "master" shouldn't get special treatment; making different log messages
> based on the name of the branch is bad form. What if a user likes
> "my/master" or "my/head" as their master branch?
I do not agree. There is usually a principal branch, where you collect the
topics, and you do want to treat that special. As for the name: better
have a convention here than configurability. You would not want "git" to
be called "guitar" for some users, just because they happen to like that
name more, either, right?
Ciao,
Dscho
^ permalink raw reply
* Re: svn versus git
From: Johannes Schindelin @ 2006-12-14 15:31 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <fcaeb9bf0612140708w6bc691f6k2e08fbab2a651421@mail.gmail.com>
Hi,
On Thu, 14 Dec 2006, Nguyen Thai Ngoc Duy wrote:
> On 12/14/06, Junio C Hamano <junkio@cox.net> wrote:
> > If a Porcelain level "ls" is needed (and I am doubtful about
> > usefulness of "svn list -r538" like command), that is the
> > command you would want to teach about using ls-files and ls-tree
> > depending on what the end users want in their workflow.
>
> +1. Any chance git-ls can go to 1.5.0?
Two questions arise naturally:
- what do you need it for?
- have you seen the patch for git-show today, which would include this
functionality?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Avoid accessing a slow working copy during diffcore operations.
From: Johannes Schindelin @ 2006-12-14 15:37 UTC (permalink / raw)
To: Alex Riesen; +Cc: Shawn O. Pearce, Junio C Hamano, git
In-Reply-To: <81b0412b0612140649i71643aaar847460ca9e4cea48@mail.gmail.com>
Hi,
On Thu, 14 Dec 2006, Alex Riesen wrote:
> On 12/14/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> >
> > It is usually cheaper to just read the file, especially if it is still
> > cached, because the alternative means unpacking the loose object, or
> > worse, unpacking the packed object _along_ with the objects in its
> > delta chain.
>
> But you have to read less, and even that could be in cache as well and
> unpacking in userspace could be faster than open/write temporary/ read
> temporary/close/unlink temporary file on a normal system
You have to unpack anyway, since even the loose objects are packed. But to
reconstruct a deltified object, you have to reconstruct possibly many
objects.
So yes, if you have it in the working directory (unpacked), it should be
faster to just read it, especially if it is still in the filesystem cache.
> > Not every OS sucks cache-wise, and you should not make others suffer
> > for Redmond's shortcomings.
>
> I'm just do not understand why avoiding temporary file wouldn't help all
> OSes, even if they do not suck cache-wise.
Ah! But it is not temporary! It is the "working copy", which means the
file you have in the working directory. IOW it is an unpacked blob, which
happens to be already unpacked anyway.
Ciao,
Dscho
^ permalink raw reply
* git fetch slow as molasses due to tag downloading
From: Han-Wen Nienhuys @ 2006-12-14 15:40 UTC (permalink / raw)
To: git
Hello,
just upgraded our autobuilder from 1.4.3 to 1.4.4.2.
Now, our standard download command comes to a complete halt. Judging
from the "ps -ef" apparently, it does
git-show-ref --verify --quiet -- [TAG]
This is done for every one of the 1500 tags that are in my repository.
At approx 20 tags per second this takes an awful lot of time.
1. Is this necessary?
2. Is this efficient? Wouldn't doing all tags in a single git-show-ref
invocation be potentially quicker?
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* Re: git-fetching from a big repository is slow
From: Han-Wen Nienhuys @ 2006-12-14 15:45 UTC (permalink / raw)
To: git
In-Reply-To: <200612141518.05770.andyparkins@gmail.com>
Andy Parkins escreveu:
> On Thursday 2006 December 14 13:53, Andreas Ericsson wrote:
>
>> This seems to happen if your repository consists of many large binary
>> files, especially many large binary files of several versions that do
>> not deltify well against each other. Perhaps it's worth adding gzip
>
> It's actually just every released patch to the linux kernel ever issued.
> Almost entirely ASCII and every revision (save the first) created by patching
> the previous.
I just noticed that git-fetch now runs git-show-ref --verify on every
tag it encounters. This seems to slow down fetch over here.
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* Re: [PATCH] "master" should be treated no differently from any other branch
From: Han-Wen Nienhuys @ 2006-12-14 15:47 UTC (permalink / raw)
To: git; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0612141627090.3635@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin escreveu:
> Hi,
>
> On Thu, 14 Dec 2006, Andy Parkins wrote:
>
>> "master" shouldn't get special treatment; making different log messages
>> based on the name of the branch is bad form. What if a user likes
>> "my/master" or "my/head" as their master branch?
>
> I do not agree. There is usually a principal branch, where you collect the
> topics, and you do want to treat that special. As for the name: better
> have a convention here than configurability. You would not want "git" to
> be called "guitar" for some users, just because they happen to like that
> name more, either, right?
Disagree: I have two principal branches, master and stable/2.10. I don't see
why the latter should get different commit messages.
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* Re: [PATCH] git-status always says what branch it's on
From: Andreas Ericsson @ 2006-12-14 15:54 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200612141525.23671.andyparkins@gmail.com>
Andy Parkins wrote:
> If the current branch was "master" then git-status wouldn't say
>
> # On branch XXXX
>
> In its output. This patch makes it so that this message is always
> output; regardless of branch name.
>
I like it. I know that it's quiet when I'm on 'master', but I still need
to spend an extra cycle to remember that fact. Uniformity is a good
thing in program behaviour.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply
* Re: svn versus git
From: Seth Falcon @ 2006-12-14 15:55 UTC (permalink / raw)
To: git
In-Reply-To: <20061213225627.GC32568@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> Andy Parkins <andyparkins@gmail.com> wrote:
>> svn cat::
>> Output the contents of specified files or URLs. Optionally at a
>> specific revision.
>> git cat-file -p $(git-ls-tree $REV $file | cut -d " " -f 3 | cut -f 1)::
>
> better:
>
> git cat-file -p $REV:$file
FWIW, after some amount of git experience, I had a need for git
cat-file and I found it hard to use. Why? Because following the
pattern of some other commands, I really expected the following to work:
git cat-file -p HEAD^2 $file
Since that is similar to
git diff HEAD^^ $file
git checkout HEAD $file
Where else uses the colon syntax?
My $0.02.
^ permalink raw reply
* Re: [PATCH] "master" should be treated no differently from any other branch
From: Johannes Schindelin @ 2006-12-14 15:57 UTC (permalink / raw)
To: Han-Wen Nienhuys; +Cc: git
In-Reply-To: <4581721B.4050102@xs4all.nl>
Hi,
On Thu, 14 Dec 2006, Han-Wen Nienhuys wrote:
> Johannes Schindelin escreveu:
> > Hi,
> >
> > On Thu, 14 Dec 2006, Andy Parkins wrote:
> >
> >> "master" shouldn't get special treatment; making different log messages
> >> based on the name of the branch is bad form. What if a user likes
> >> "my/master" or "my/head" as their master branch?
> >
> > I do not agree. There is usually a principal branch, where you collect the
> > topics, and you do want to treat that special. As for the name: better
> > have a convention here than configurability. You would not want "git" to
> > be called "guitar" for some users, just because they happen to like that
> > name more, either, right?
>
> Disagree: I have two principal branches, master and stable/2.10. I
> don't see why the latter should get different commit messages.
Well, in your case I would even more strongly argue that "Merging into
master" bears no more information than "Merging", since "master" is too
generic a name. Since "stable/2.10" is more specific, the same reasoning
does not apply here.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] "master" should be treated no differently from any other branch
From: Han-Wen Nienhuys @ 2006-12-14 15:59 UTC (permalink / raw)
To: hanwen; +Cc: git
In-Reply-To: <4581721B.4050102@xs4all.nl>
Han-Wen Nienhuys escreveu:
> Johannes Schindelin escreveu:
>> Hi,
>>
>> On Thu, 14 Dec 2006, Andy Parkins wrote:
>>
>>> "master" shouldn't get special treatment; making different log messages
>>> based on the name of the branch is bad form. What if a user likes
>>> "my/master" or "my/head" as their master branch?
>> I do not agree. There is usually a principal branch, where you collect the
>> topics, and you do want to treat that special. As for the name: better
>> have a convention here than configurability. You would not want "git" to
>> be called "guitar" for some users, just because they happen to like that
>> name more, either, right?
>
> Disagree: I have two principal branches, master and stable/2.10. I don't see
> why the latter should get different commit messages.
Note that this also confused my codeveloper (who is rather enamoured bzr), who
was wondering what the other branch was in case of
Merge branch 'master' of ssh+git://git.sv.gnu.org/srv/git/lilypond
Wouldn't it be better to mention the id of the local repository too?
Merge branch 'master' of ssh+git://git.sv.gnu.org/srv/git/lilypond into
'master' of 'hanwen@xs4all.nl'
this would give more information when these commit messages get pushed to
someone else.
--
^ permalink raw reply
* Re: git fetch slow as molasses due to tag downloading
From: Johannes Schindelin @ 2006-12-14 16:05 UTC (permalink / raw)
To: Han-Wen Nienhuys; +Cc: git
In-Reply-To: <elrr8j$a02$1@sea.gmane.org>
Hi,
On Thu, 14 Dec 2006, Han-Wen Nienhuys wrote:
> just upgraded our autobuilder from 1.4.3 to 1.4.4.2.
>
> Now, our standard download command comes to a complete halt. Judging
> >from the "ps -ef" apparently, it does
>
> git-show-ref --verify --quiet -- [TAG]
>
> This is done for every one of the 1500 tags that are in my repository.
> At approx 20 tags per second this takes an awful lot of time.
>
> 1. Is this necessary?
Yes. The purpose is to check which tags have not yet been fetched.
> 2. Is this efficient? Wouldn't doing all tags in a single git-show-ref
> invocation be potentially quicker?
It is not efficient. But it cannot be solved like you propose, since it is
inside a loop, and a "continue" is executed when the tag exists already.
IMHO this should be solved as a filter: "git-show-ref --stdin
--show-invalid". Thus, git does not have to traverse _every_ ref for
_every_ incoming tag.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] "master" should be treated no differently from any other branch
From: Johannes Schindelin @ 2006-12-14 16:14 UTC (permalink / raw)
To: Han-Wen Nienhuys; +Cc: git
In-Reply-To: <458174C9.2050401@xs4all.nl>
Hi,
On Thu, 14 Dec 2006, Han-Wen Nienhuys wrote:
> Wouldn't it be better to mention the id of the local repository too?
>
> Merge branch 'master' of ssh+git://git.sv.gnu.org/srv/git/lilypond into
> 'master' of 'hanwen@xs4all.nl'
>
> this would give more information when these commit messages get pushed
> to someone else.
And why not put your address and birthday in there, too?
Frankly, it does not matter. In my private git repository I see that I
often merged from this machine to that machine, criss-crossing often. It
does not buy me anything to even know _where_ I got it from.
Besides, the information you are most likely looking for is the committer,
which is recorded anyway.
The single most useful information in the Merge message is the name of the
branch I merged, since it is more often than not a topic branch, which is
aptly named.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] "master" should be treated no differently from any other branch
From: Jerome Lovy @ 2006-12-14 16:20 UTC (permalink / raw)
To: git; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0612141627090.3635@wbgn013.biozentrum.uni-wuerzburg.de>
Hi,
Johannes Schindelin wrote:
> On Thu, 14 Dec 2006, Andy Parkins wrote:
>
>> "master" shouldn't get special treatment; making different log messages
>> based on the name of the branch is bad form. What if a user likes
>> "my/master" or "my/head" as their master branch?
>
> I do not agree. There is usually a principal branch, where you collect the
> topics, and you do want to treat that special. As for the name: better
> have a convention here than configurability. You would not want "git" to
> be called "guitar" for some users, just because they happen to like that
> name more, either, right?
because I like the pattern framework described in the book "Software
Configuration Management Patterns", I like to use "mainline" instead of
"master", for example.
Jérôme
^ permalink raw reply
* Re: git-fetching from a big repository is slow
From: Andy Parkins @ 2006-12-14 16:20 UTC (permalink / raw)
To: git, hanwen
In-Reply-To: <458171B7.1020702@xs4all.nl>
On Thursday 2006 December 14 15:45, Han-Wen Nienhuys wrote:
> I just noticed that git-fetch now runs git-show-ref --verify on every
> tag it encounters. This seems to slow down fetch over here.
There aren't any tags in this repository :-)
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ 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