* Re: [PATCH v4 1/2] filter-branch: stop special-casing $filter_subdir argument
From: Junio C Hamano @ 2009-11-11 18:00 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Thomas Rast, git, Junio C Hamano
In-Reply-To: <4AFA7624.5040400@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> In the snippet above, dashdash will always be set to "--" because a mere
> '+' in the variable expansion only tests whether the variable ('nonrevs')
> is unset, but it is always set. Even ${nonrevs:+"--"} is wrong, and your
> earlier 'test -z' invocation was the correct way to set dashdash.
I do not mind "test -z", so this is just for information, but you could
use variable substitution with a colon, i.e. ${nonrevs:+"--"}.
IIRC, the colon-form ("do this if unset or empty") wasn't understood by
ancient BSDs but these days it is safe to use.
^ permalink raw reply
* Re: [PATCH v5 2/2] filter-branch: nearest-ancestor rewriting outside subdir filter
From: Junio C Hamano @ 2009-11-11 18:22 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Thomas Rast, git, Junio C Hamano
In-Reply-To: <4AFA7C1E.1050606@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> However, that rewriting strategy is also a useful building block in
> other tasks. For example, if you want to split out a subset of files
> from your history, you would typically call
>
> git filter-branch -- <refs> -- <files>
>
> But this fails for all refs that do not point directly to a commit
> that affects <files>, because their referenced commit will not be
> rewritten and the ref remains untouched.
>
> The code was already there for the --subdirectory-filter case, so just
> introduce an option that enables it independently.
>
> Signed-off-by: Thomas Rast <trast@student.ethz.ch>
> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Up to this point, nothing mentions the name of the new option. Please
write your log for a person who needs to write the release notes by
looking at "git shortlog" output ;-)
I am wondering if this even needs an option to trigger. Shouldn't you
want this behaviour always when you give any pathspec?
What are the sane reasons to leave the rewritten ref to point at the old
commit, essentially making the rewritten history unreachable?
^ permalink raw reply
* Re: [PATCH v5 2/2] filter-branch: nearest-ancestor rewriting outside subdir filter
From: Thomas Rast @ 2009-11-11 18:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, git
In-Reply-To: <7vocn8q5v2.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
>
> Up to this point, nothing mentions the name of the new option. Please
> write your log for a person who needs to write the release notes by
> looking at "git shortlog" output ;-)
>
> I am wondering if this even needs an option to trigger. Shouldn't you
> want this behaviour always when you give any pathspec?
>
> What are the sane reasons to leave the rewritten ref to point at the old
> commit, essentially making the rewritten history unreachable?
Fear of hysterical raisins, nothing else. I cannot really see a
use-case of the original behaviour, and since it does not change the
behaviour in the case of an unfiltered rewrite, it should be safe to
always be enabled.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: excerpts from tomorrow's "What's cooking" draft
From: Nicolas Sebrecht @ 2009-11-11 18:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Nicolas Sebrecht
In-Reply-To: <7vbpj9s8vk.fsf@alter.siamese.dyndns.org>
The 11/11/09, Junio C Hamano wrote:
> I'll do the full-list at the end of my git Wednesday, but here are the
> current highlights I am sending out to hear opinions from people.
A bit OT, I've noticed the following output today:
% git clone git://repo.or.cz/girocco.git
Initialized empty Git repository in /home/nicolas/dev/official_packages/girocco/.git/
remote: Counting objects: 3017, done.
g objects: 100% (994/994), done.
remote: Total 3017 (delta 1911), reused 2988 (delta 1896)
Receiving objects: 100% (3017/3017), 403.99 KiB | 309 KiB/s, done.
Resolving deltas: 100% (1911/1911), done.
%
Notice the "g " at the begining at the 3th line. This is reproducible.
% git --version
git version 1.6.5.2.352.g8b8744
I can provide more test or bissect it if wanted.
--
Nicolas Sebrecht
^ permalink raw reply
* Re: excerpts from tomorrow's "What's cooking" draft
From: Daniel Barkalow @ 2009-11-11 18:45 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Junio C Hamano, git
In-Reply-To: <fabb9a1e0911110957k599ac3dfmd1a44a0499c72b2d@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 5088 bytes --]
On Wed, 11 Nov 2009, Sverre Rabbelier wrote:
> Heya,
>
> On Wed, Nov 11, 2009 at 10:34, Junio C Hamano <junio@pobox.com> wrote:
> > * sr/gfi-options (2009-09-06) 6 commits.
> > - fast-import: test the new option command
> > - ...
> > - fast-import: put option parsing code in separate functions
> >
> > It seemed to be moving again soon, but nothing has happened yet...
>
> I ran out of git time due to the start of my uni's next quarter, this
> is next on my to-do list though, as my remote helper depends on it.
>
> > * sr/vcs-helper (2009-11-06) 12 commits
> > - Add Python support library for remote helpers
> > - ...
> > - Fix memory leak in helper method for disconnect
> >
> > Re-rolled series that contains Daniel's and Johan's.
> > Any comments? Is everybody happy?
>
> Daniel, are you going to send a follow-up to the memory-leaking patch?
> If not, this needs to stay out of next until I have time to do so. My
> gitdir patch might need to be evicted as it is connected to
> sr/gfi-options which is not yet done. Also, we need to update the
> documentation, but I think we can at least start cooking it in next
> without these documentation updates?
Okay, finally got to it just now. This is entirely untested (because I
don't have anything that uses it), but it compiles and should be correct.
It would be nice to get a clean bill of health on it from valgrind.
If it works, please squash it into my other patch, keep that commit
message, and add my sign-off.
commit 5fdebd88a8e5c2714470c86a2c13ee2c795210cb
Author: Daniel Barkalow <barkalow@iabervon.org>
Date: Wed Nov 11 13:36:36 2009 -0500
Free memory used by remote helper importing refspecs, document
"Allow helper to map private ref names into normal names" was just an
RFD which turned out to be surprisingly correct. This adds the necessary
memory-management and documentation, and generally makes it a suitable
patch.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
diff --git a/Documentation/git-remote-helpers.txt b/Documentation/git-remote-helpers.txt
index 2c5130f..f4b6a5a 100644
--- a/Documentation/git-remote-helpers.txt
+++ b/Documentation/git-remote-helpers.txt
@@ -46,7 +46,11 @@ Supported if the helper has the "fetch" capability.
'import' <name>::
Produces a fast-import stream which imports the current value
of the named ref. It may additionally import other refs as
- needed to construct the history efficiently.
+ needed to construct the history efficiently. The script writes
+ to a helper-specific private namespace. The value of the named
+ ref should be written to a location in this namespace derived
+ by applying the refspecs from the "refspec" capability to the
+ name of the ref.
+
Supported if the helper has the "import" capability.
@@ -67,6 +71,16 @@ CAPABILITIES
'import'::
This helper supports the 'import' command.
+'refspec' 'spec'::
+ When using the import command, expect the source ref to have
+ been written to the destination ref. The earliest applicable
+ refspec takes precedence. For example
+ "refs/heads/*:refs/svn/origin/branches/*" means that, after an
+ "import refs/heads/name", the script has written to
+ refs/svn/origin/branches/name. If this capability is used at
+ all, it must cover all refs reported by the list command; if
+ it is not used, it is effectively "*:*"
+
REF LIST ATTRIBUTES
-------------------
diff --git a/remote.c b/remote.c
index 09e14a8..1f7870d 100644
--- a/remote.c
+++ b/remote.c
@@ -673,6 +673,16 @@ static struct refspec *parse_push_refspec(int nr_refspec, const char **refspec)
return parse_refspec_internal(nr_refspec, refspec, 0, 0);
}
+void free_refspec(int nr_refspec, struct refspec *refspec)
+{
+ int i;
+ for (i = 0; i < nr_refspec; i++) {
+ free(refspec[i].src);
+ free(refspec[i].dst);
+ }
+ free(refspec);
+}
+
static int valid_remote_nick(const char *name)
{
if (!name[0] || is_dot_or_dotdot(name))
diff --git a/remote.h b/remote.h
index c2f920b..f89cb0e 100644
--- a/remote.h
+++ b/remote.h
@@ -91,6 +91,8 @@ void ref_remove_duplicates(struct ref *ref_map);
int valid_fetch_refspec(const char *refspec);
struct refspec *parse_fetch_refspec(int nr_refspec, const char **refspec);
+void free_refspec(int nr_refspec, struct refspec *refspecs);
+
char *apply_refspecs(struct refspec *refspecs, int nr_refspec,
const char *name);
diff --git a/transport-helper.c b/transport-helper.c
index 7ea76fd..cea646c 100644
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -72,8 +72,13 @@ static struct child_process *get_helper(struct transport *transport)
}
}
if (refspecs) {
+ int i;
data->refspec_nr = refspec_nr;
data->refspecs = parse_fetch_refspec(refspec_nr, refspecs);
+ for (i = 0; i < refspec_nr; i++) {
+ free((char *)refspecs[i]);
+ }
+ free(refspecs);
}
return data->helper;
}
@@ -90,6 +95,8 @@ static int disconnect_helper(struct transport *transport)
free(data->helper);
data->helper = NULL;
}
+ free_refspec(data->refspec_nr, data->refspecs);
+ data->refspecs = NULL;
return 0;
}
^ permalink raw reply related
* Re: excerpts from tomorrow's "What's cooking" draft
From: Jakub Narebski @ 2009-11-11 18:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Petr Baudis
In-Reply-To: <7vbpj9s8vk.fsf@alter.siamese.dyndns.org>
Junio C Hamano <junio@pobox.com> writes:
> I'll do the full-list at the end of my git Wednesday, but here are the
> current highlights I am sending out to hear opinions from people.
>
> Please note that I haven't caught up with the patches from past 12 hours
> or so.
>
> ----------------------------------------------------------------
> * jn/gitweb-blame (2009-09-01) 5 commits.
> - gitweb: Minify gitweb.js if JSMIN is defined
> - gitweb: Create links leading to 'blame_incremental' using JavaScript
> (merged to 'next' on 2009-10-11 at 73c4a83)
> + gitweb: Colorize 'blame_incremental' view during processing
> + ...
>
> Ajax-y blame. Any progress or RFH?
I have reordered two top commits (those that are only in 'pu'), but I
didn't improve "Create links..." commit. Current version works, but
is suboptimal.
I wonder if Packy has any comments about 'blame_incremental' series...
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Unhelpful "branch.master.remote = <nickname>" advice?
From: Tomas Carnecky @ 2009-11-11 19:10 UTC (permalink / raw)
To: Jan Nieuwenhuizen; +Cc: git list
In-Reply-To: <1257965806.26362.132.camel@heerbeest>
On Nov 11, 2009, at 7:56 PM, Jan Nieuwenhuizen wrote:
>> These are meant to be used with git-config(1):
>> git config branch.master.remote <nickname>
>
> Okay...that's the other thing I tried. Look
>
> $ cp .git/config .git/config.orig
> 19:32:05 janneke@peder:~/vc/gub
> $ git config branch.master.remote = eddy
> 19:32:08 janneke@peder:~/vc/gub
> $ diff -u .git/config.orig .git/config
> --- .git/config.orig 2009-11-11 19:32:05.724046086 +0100
> +++ .git/config 2009-11-11 19:32:08.304045852 +0100
> @@ -6,6 +6,7 @@
> [branch "master"]
> remote = origin
> merge = refs/heads/master
> + remote = =
> [remote "origin"]
> url = git@github.com:janneke/gub.git
> fetch = +refs/heads/*:refs/remotes/origin/*
> [1]19:32:10 janneke@peder:~/vc/gub
You used this:
$ git config branch.master.remote = <something>
Do you see the difference between that and what I posted?
> Also, if this is meant to be used with git config, then
> /why/ does the text say "in your configuration file"?
>
> I think it might be more helpful if this text said
> configuration file and gave a usable configuration file
> snippet, or alternatively said git config, and gave usable
> git config commands.
Feel free to send a patch ;)
>
>> Or if you want to manually edit the config file, add this:
>>
>> [branch "master"]
>> remote = <nickname>
>>
>> etc.
>
> Thanks! Tried this. However, there already was a
>
> [branch "master"]
> remote = origin
>
> which is my default branch that I publish to and pull
> from. After adding a nickname for this new branch that
> I'll probably be pulling from a lot, my config file reads
>
> [branch "master"]
> remote = origin
> merge = refs/heads/master
> [remote "origin"]
> url = git@github.com:janneke/gub.git
> fetch = +refs/heads/*:refs/remotes/origin/*
> # advise from git pull, using <nickname> = eddy
> # branch.master.remote = <nickname>
> # branch.master.merge = <remote-ref>
> # remote.<nickname>.url = <url>
> # remote.<nickname>.fetch = <refspec>
> [branch "master"]
> remote = eddy
> merge = refs/heads/master
> [remote "eddy"]
> url = http://github.com/epronk/gub.git
> fetch = +refs/heads/*:refs/remotes/origin/*
>
> With this new "eddy" addition
>
> git pull -r eddy
>
> seems to work fine, but the good old default pull now says
>
> $ git pull -r
> error: More than one value for the key branch.master.remote: eddy
> Current branch master is up to date.
branch.master.remote has two different values, git doesn't know which
remote to use. Do you want to pull from origin or eddy? I would
recommend only keeping one [branch "master"] section and edit it
appropriately.
> and I'm not really sure where it pulls from? Then I think,
> possibly now I need to specify the <nickname> for the default
> url too [never knew that was a nick], which has automagically
> be named "origin". Yes, that makes sense.
>
> Well, /then/ I get thoroughly confused
>
> $ git pull -r origin
> You asked me to pull without telling me which branch you
> want to merge with, and 'branch.master.merge' in
> your configuration file does not tell me either. Please
> specify 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.
>
> If you often merge with the same branch, you may want to
> configure the following variables in your configuration
> file:
>
> branch.master.remote = <nickname>
> branch.master.merge = <remote-ref>
> remote.<nickname>.url = <url>
> remote.<nickname>.fetch = <refspec>
>
> See git-config(1) for details.
> [1]19:43:02 janneke@peder:~/vc/gub
Hm, I can't explain that one. I would use either the short form (git
pull -r) or the long form (git pull -r origin master). Try removing
the duplicate branch.master section and try again.
>
>> As 'pull == fetch + merge' (pull -r == fetch + rebase), pull without
>> merge would be fetch.
>
> Okay, that's fighting over naming conventions, let me retry this.
> I still wonder why does Git have a shorthand for fetch + merge [pull],
> which you almost never want, and no shorthand for fetch + rebase
> [known to most *CS/*SCM users as "update"]?
Is 'git pull -r' not short enough for you? If not, feel free to create
a alias:
$ git config alias.up 'pull -r'
tom
^ permalink raw reply
* Re: Locally manage user/branch setting files without pushing them remotely
From: Nicolas Sebrecht @ 2009-11-11 19:24 UTC (permalink / raw)
To: Daniele Segato; +Cc: Git Mailing List, Nicolas Sebrecht
In-Reply-To: <9accb4400911110401g5c44d011u50cafcfe736a2ec6@mail.gmail.com>
The 11/11/09, Daniele Segato wrote:
> The project has a lot of setting that are really binded to the user
> and should not go pushed in a remote repository (example: database
> connections parameters / filesystem paths)
> We have a .template file for those settings but the actual settings
> are really binded to the user environment.
This looks to _not_ be a piece of the development project. Settings used
for the tests suites, company where you work, etc _are_ clones (from the
abstract POV, at least) of the maintainer public repository.
If you want to track changes of settings in a per-production-repo basis,
you should do it _out_ of your main development repository. The latter
should have a publishable template instead (eg. "user = user_login",
"password = set_your_password").
--
Nicolas Sebrecht
^ permalink raw reply
* Re: Unhelpful "branch.master.remote = <nickname>" advice?
From: Jan Nieuwenhuizen @ 2009-11-11 19:34 UTC (permalink / raw)
To: Tomas Carnecky; +Cc: git list
In-Reply-To: <D6B0AE61-6CA3-4F79-BB50-B8795415BAB7@dbservice.com>
Op woensdag 11-11-2009 om 20:10 uur [tijdzone +0100], schreef Tomas
Carnecky:
> On Nov 11, 2009, at 7:56 PM, Jan Nieuwenhuizen wrote:
Hi Tomas,
> You used this:
> $ git config branch.master.remote = <something>
> Do you see the difference between that and what I posted?
Sure, I now know what syntax you and the advise mean. However,
I'm just pointing out that the git pull advise makes no sense,
however way you try to interpret it?
> > I think it might be more helpful if this text said
> > configuration file and gave a usable configuration file
> > snippet, or alternatively said git config, and gave usable
> > git config commands.
>
> Feel free to send a patch ;)
[just maybe, if my uninstall patch goes in easily, but]
First I need to know what the new advise should be. As you
can see below, I'm still confused.
I was hoping someone would say: Ah blast! That was me,
stupid: Fixed in master :-) And everything would make
sense and work.
> branch.master.remote has two different values, git doesn't know which
> remote to use.
Well, it can see that there already is a value for branch.master.remote
defined, and it /still/ advises to add one. It also uses <nickname>,
which suggests there could be multiple values?
For all I know, pull can only handle one nickname and it shouldn't
give this advise at all?
> Do you want to pull from origin or eddy?
I'm publishing on origin -- that's what the original clone was
from. Also, I use it to update from most often, when I work
from different locations. All fine.
Now this Eddy guy says: pull from here. I try it and get
this advise. So, I'd like to have
git pull # use origin by default
git pull eddy # pull from eddy's url
> I would
> recommend only keeping one [branch "master"] section and edit it
> appropriately.
Yes, I tried that and came up with
[branch "master"]
remote = origin
merge = refs/heads/master
[remote "origin"]
url = git@github.com:janneke/gub.git
fetch = +refs/heads/*:refs/remotes/origin/*
# advise from git pull, using <nickname> = eddy
# branch.master.remote = <nickname>
# branch.master.merge = <remote-ref>
# remote.<nickname>.url = <url>
# remote.<nickname>.fetch = <refspec>
#[branch "master"]
# remote = eddy # ignore branch.master.remote advise
# merge = refs/heads/master
[remote "eddy"]
url = http://github.com/epronk/gub.git
fetch = +refs/heads/*:refs/remotes/origin/*
This /seems/ to work. However, I still get this
$ git pull -r
From git@github.com:janneke/gub
+ 7bb5905...8ff38da master -> origin/master (forced update)
First, rewinding head to replay your work on top of it...
Fast-forwarded master to 8ff38da0a7013a891de18a0b7bec12b9d1fa6637.
20:25:55 janneke@peder:~/vc/gub
[looks okay]
$ git pull -r eddy
From http://github.com/epronk/gub
+ 8ff38da...7bb5905 master -> origin/master (forced update)
[looks fine too, but still continues with]
You asked me to pull without telling me which branch you
want to merge with, and 'branch.master.merge' in
your configuration file does not tell me either. Please
specify 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.
If you often merge with the same branch, you may want to
configure the following variables in your configuration
file:
branch.master.remote = <nickname>
branch.master.merge = <remote-ref>
remote.<nickname>.url = <url>
remote.<nickname>.fetch = <refspec>
See git-config(1) for details.
[1]20:26:01 janneke@peder:~/vc/gub
$
so I'm still missing something?
> Is 'git pull -r' not short enough for you?
It's more of a usability thing. It annoys me that the most
used functionality needs a command line option. Worse however,
is that people [myself included] tend to forget that "-r",
and our logs have lots of these ugly, unnecessary
c377994 Merge branch 'master' of ssh+git://git.sv.gnu.org/srv/git/lilypond
Also, we need to explain this to all newcomers.
Jan.
--
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
Avatar®: http://AvatarAcademy.nl | http://lilypond.org
^ permalink raw reply
* Re: git-svn problem with v1.6.5
From: Avery Pennarun @ 2009-11-11 19:41 UTC (permalink / raw)
To: pascal; +Cc: Eric Wong, adambrewster, git list
In-Reply-To: <4AFA91BB.7050402@obry.net>
On Wed, Nov 11, 2009 at 5:28 AM, Pascal Obry <pascal@obry.net> wrote:
>> Avery wrote:
>> Is d2cf08bb67e4b7da33a250127aab784f1f2f58d3 a valid revision? (git
>> log d2cf08bb67e4b7da33a250127aab784f1f2f58d3).
>
> No.
Well, that's bad news. Does "git log --all --parents | grep
d2cf08bb67e4b7da33a250127aab784f1f2f58d3" reveal any places that refer
to it?
It sounds a bit like your git-svn thinks something maps on to that
commit id, but a previous 'git gc' or something has thrown it away.
However, that doesn't explain why earlier git versions don't have this
problem.
>> You could try using git bisect to figure out which exact commit to
>> git.git created the problem.
>
> I wanted to avoid that :) Anyway, here is the culprit:
>
> commit 6f5748e14cc5bb0a836b649fb8e2d6a5eb166f1d
> Author: Adam Brewster <adambrewster@gmail.com>
> Date: Tue Aug 11 23:14:27 2009 -0400
>
> svn: allow branches outside of refs/remotes
[...]
>
> But frankly I'm no expert on Perl... I fear that I won't be able to debug
> that!
If you retrieve the latest version of git and then git revert the
above commit, does that fix the problem, at least?
Is it possible you have some weird branches outside of the
refs/remotes tree (either in .git itself, or in .git/refs/*) that you
forgot about, and which the new version of git-svn is finding somehow?
Avery
^ permalink raw reply
* Re: [PATCHv2] Update gitworkflows man page to include release workflow
From: Junio C Hamano @ 2009-11-11 19:43 UTC (permalink / raw)
To: rocketraman; +Cc: git
In-Reply-To: <1257869339-15999-2-git-send-email-rocketraman@fastmail.fm>
rocketraman@fastmail.fm writes:
> From: Raman Gupta <raman@rocketraman.com>
>
> The gitworkflows man page currently provides an overview of the workflows
> used by git.git itself to serve as inspiration for people to use when
> designing their own workflows. The current man page does a reasonable
> job at describing the development process, but it does not contain any
> guidance as to the workflow used for releases. Now add a basic
> introduction to the branch management required for a release, so that a
> reader may understand how the maint, master, next, and topic branches are
> affected.
> ---
Is this meant to show how git.git does its release to serve as an
inspiration to others? The document does not seem to describe how I make
releases.
> diff --git a/Documentation/gitworkflows.txt b/Documentation/gitworkflows.txt
> index 2b021e3..69b789a 100644
> --- a/Documentation/gitworkflows.txt
> +++ b/Documentation/gitworkflows.txt
> @@ -348,6 +348,103 @@ in patches to figure out the merge base. See linkgit:git-am[1] for
> other options.
>
>
> +RELEASE WORKFLOW
> +----------------
> +
> +The maintainer may use the following release workflow:
Please set the tone straight. If this is to suggest various possible
workflows in general vague terms, "may use" would be good. If this is to
precisely describe what I do, then there won't be "you could do this, or
you could do that." Your "may use" suggests the former, but the commit
log message claims the latter. Which document are you writing?
Assuming that you are writing what I do...
> +He first tags the tip of 'master' with a release tag, then he updates
> +the 'maint' branch to the current tip of 'master' for managing future
> +maintenance fixes on the current release, and lastly he optionally
> +rebuilds 'next' from the tip of 'master'.
Not in that order.
- doubly make sure that there is nothing left in 'maint' that
is not in 'master';
- review 'master' more thoroughly than usual;
- review RelNotes symlink, Documentation/RelNotes-X.Y.Z.txt,
the stalenotes section in Documentation/git.git, and
GIT-VERSION-GEN for the last time;
- tag it;
- review it again for the last time;
- test on buildfarm;
- cut tarball;
- cut RPM on FC11 i386 and FC11 x86_64;
- push the tag and master branch alone to the public server---this
triggers an autobuilder for documentation pages, updates man and
html branches and documentation tarballs;
When making a maintenance release, everything is the same except that
'maint' is used instead of 'master'.
Then, after all the release task on 'master' (or 'maint') is done,
propagate that upwards (i.e. merge 'master' to 'next' and 'pu').
Merging 'master' to 'maint' is done totally as a separate step, often a
few days later, "Now the big release is done, let's start maintenance
track for that relase".
And then after that, 'next' may be rebuilt.
> +Release Tagging
> +~~~~~~~~~~~~~~~
> +
> +The new feature release is tagged on 'master' with a tag matching
> +vX.Y.Z, where X.Y.Z is the new feature release version.
> +
> +.Release tagging
> +[caption="Recipe: "]
> +=====================================
> +`git tag -s -m "GIT X.Y.Z" vX.Y.Z master`
> +=====================================
There is no incorrect information here, but I do not think there is
anything particularly worth saying here, either. It is in "git tag"
manpage and anybody can run "git cat-file tag v1.6.3" to learn what is in
there.
> +Maintenance branch update
> +~~~~~~~~~~~~~~~~~~~~~~~~~
This section largely overlaps with Documentation/howto/maintain-git.txt; I
am starting to doubt if we even need a new section in the workflows
document. Perhaps we could have a release management section in the
Documentation/howto/maintain-git.txt, though.
> +[caption="Recipe: "]
> +=====================================
> +* `git checkout maint`
> +* `git merge master`
> +=====================================
> +
> +This updates 'maint' from 'master', while preserving the 'maint'
> +reflog.
> +
> +An alternative approach to updating the 'maint' branch is to run
> +
> + $ git branch -f maint master
As I already said, I never do this "alternative", and I do not want
anybody who will take over git.git maintenance to do so. There is no
reason to encourage nor even mention "branch -f" here. As 'maint' is
supposed to be a strict subset, pulling 'master' to 'maint' should fast
forward and otherwise you (the maintainer) would notice that there was a
mistake made. If you use "branch -f", you will never notice.
^ permalink raw reply
* Re: excerpts from tomorrow's "What's cooking" draft
From: Nicolas Pitre @ 2009-11-11 19:50 UTC (permalink / raw)
To: Nicolas Sebrecht, Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <20091111184215.GG27518@vidovic>
On Wed, 11 Nov 2009, Nicolas Sebrecht wrote:
> A bit OT, I've noticed the following output today:
>
> % git clone git://repo.or.cz/girocco.git
> Initialized empty Git repository in /home/nicolas/dev/official_packages/girocco/.git/
> remote: Counting objects: 3017, done.
> g objects: 100% (994/994), done.
> remote: Total 3017 (delta 1911), reused 2988 (delta 1896)
> Receiving objects: 100% (3017/3017), 403.99 KiB | 309 KiB/s, done.
> Resolving deltas: 100% (1911/1911), done.
> %
>
> Notice the "g " at the begining at the 3th line. This is reproducible.
I get much worse:
Initialized empty Git repository in /home/nico/git/girocco/.git/
remote: Counting objects: 3017, done.
remote: Compressing objects: 5% (50/994) Receiving objects: 3% (91/3017)
remote: Compressing objects: 15% (150/994) Receiving objects: 7% (212/3017)
remote: Compressing oReceiving objects: 14% (423/3017), 76.00 KiB | 135 KiB/s
remote: Compressing objects: 35Receiving objects: 16% (483/3017), 76.00 KiB |
remote: Compressing objects: 38% (378/994)Receiving objects: 17% (513/3017), 7
remote: Compressing objectReceiving objects: 20% (604/3017), 76.00 KiB | 135 Ki
remote: Compressing objects: 48% (47Receiving objects: 22% (664/3017), 76.00 K
remote: Compressing objects: 5Receiving objects: 23% (694/3017), 76.00 KiB | 1
remote: Compressing objects: Receiving objects: 25% (755/3017), 76.00 KiB | 13
remote: Compressing objects: 84% (835/99Receiving objects: 26% (785/3017), 76.
remote: Compressing objeReceiving objects: 33% (996/3017), 76.00 KiB | 135 KiB/
remote: Compressing objects: 94% (Receiving objects: 36% (1087/3017), 76.00 Ki
remote: Compressing objects: 97% (965/994) Receiving objects: 39% (1177/3017
g objects: 100% (994/994), done.
remote: Total 3017 (delta 1911), reused 2988 (delta 1896)
Receiving objects: 100% (3017/3017), 403.99 KiB | 335 KiB/s, done.
Resolving deltas: 100% (1911/1911), done.
According to strace, data from sideband channel #2 (prefixed with
"remote: ") pertaining to object compression is printed way after pack
data has already started to arrive locally. This is really weird.
And this occurs only when fetching from repo.or.cz and not from
git.kernel.org for example. So there is something to investigate on the
server side. Pasky: anything you changed in your git installation
lately?
Nicolas
^ permalink raw reply
* Re: Unhelpful "branch.master.remote = <nickname>" advice?
From: Junio C Hamano @ 2009-11-11 19:54 UTC (permalink / raw)
To: Jan Nieuwenhuizen; +Cc: git
In-Reply-To: <1257945756.26362.79.camel@heerbeest>
Jan Nieuwenhuizen <janneke-list@xs4all.nl> writes:
> *) I've been wondering why GIT lacks a "update", ie
> pull-without-merge command. You almost never want
> to git pull /without/ -r?
"You almost never want to git pull w/o --rebase" is incorrect, and you
cannot draw any conclusion from that statement.
I never want to run "git pull --rebase" myself, not in this project, nor
at work. On the other hand, I always run "git pull --rebase" while
working on another OSS project that I am only following (I'm holding onto
a few private patches until they get applied).
So even the same person never uses --rebase or always uses --rebase,
depending on how he interacts with the repository on the other side,
^ permalink raw reply
* Re: git-svn problem with v1.6.5
From: Pascal Obry @ 2009-11-11 19:58 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Eric Wong, adambrewster, git list
In-Reply-To: <32541b130911111141n7b029b1ep68656d2eb39be3c7@mail.gmail.com>
Avery,
> Well, that's bad news. Does "git log --all --parents | grep
> d2cf08bb67e4b7da33a250127aab784f1f2f58d3" reveal any places that refer
> to it?
No.
> It sounds a bit like your git-svn thinks something maps on to that
> commit id, but a previous 'git gc' or something has thrown it away.
> However, that doesn't explain why earlier git versions don't have this
> problem.
Maybe, but that would be a quite annoying bug!
> If you retrieve the latest version of git and then git revert the
> above commit, does that fix the problem, at least?
I cannot, this does not revert cleanly and I don't know how to properly
resolve this conflict. I'm no Perl expert!
But reverting using the version just before fixes this problem.
> Is it possible you have some weird branches outside of the
> refs/remotes tree (either in .git itself, or in .git/refs/*) that you
> forgot about, and which the new version of git-svn is finding somehow?
I do not see something under .git/refs/* (only empty directories).
The project has been imported using something like this:
$ git svn clone --prefix=svn/ svn+ssh://server/path \
--revision=580:HEAD \
--trunk=trunk/project \
--tags=tags/project \
--branches=branches/project \
--branches="branches/global/*/project" project
Nothing fancy. The git-svn mirrors is updated every night using Git
1.6.4 without problem.
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net - http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B
^ permalink raw reply
* Re: git-svn problem with v1.6.5
From: Eric Wong @ 2009-11-11 20:22 UTC (permalink / raw)
To: Pascal Obry; +Cc: Avery Pennarun, adambrewster, git list
In-Reply-To: <4AFB1756.7090708@obry.net>
Pascal Obry <pascal@obry.net> wrote:
> Avery,
>
>> Well, that's bad news. Does "git log --all --parents | grep
>> d2cf08bb67e4b7da33a250127aab784f1f2f58d3" reveal any places that refer
>> to it?
>
> No.
Weird...
>> It sounds a bit like your git-svn thinks something maps on to that
>> commit id, but a previous 'git gc' or something has thrown it away.
>> However, that doesn't explain why earlier git versions don't have this
>> problem.
>
> Maybe, but that would be a quite annoying bug!
>> If you retrieve the latest version of git and then git revert the
>> above commit, does that fix the problem, at least?
>
> I cannot, this does not revert cleanly and I don't know how to properly
> resolve this conflict. I'm no Perl expert!
>
> But reverting using the version just before fixes this problem.
That should rule out filesystem corruption...
>> Is it possible you have some weird branches outside of the
>> refs/remotes tree (either in .git itself, or in .git/refs/*) that you
>> forgot about, and which the new version of git-svn is finding somehow?
>
> I do not see something under .git/refs/* (only empty directories).
>
> The project has been imported using something like this:
>
> $ git svn clone --prefix=svn/ svn+ssh://server/path \
> --revision=580:HEAD \
> --trunk=trunk/project \
> --tags=tags/project \
> --branches=branches/project \
> --branches="branches/global/*/project" project
It looks like you didn't use any of the weird[1] options that make it
unsafe to clobber the rev_maps. Can you try removing all the .rev_map.*
files in $GIT_DIR/svn and running "git svn fetch" to rebuild them?
[1] --no-metadata, --use-svm-props
--
Eric Wong
^ permalink raw reply
* Re: git-svn problem with v1.6.5
From: Eric Wong @ 2009-11-11 20:34 UTC (permalink / raw)
To: Pascal Obry; +Cc: Avery Pennarun, adambrewster, git list
In-Reply-To: <20091111202201.GA10351@dcvr.yhbt.net>
Eric Wong <normalperson@yhbt.net> wrote:
> Pascal Obry <pascal@obry.net> wrote:
> > I do not see something under .git/refs/* (only empty directories).
> >
> > The project has been imported using something like this:
> >
> > $ git svn clone --prefix=svn/ svn+ssh://server/path \
> > --revision=580:HEAD \
> > --trunk=trunk/project \
> > --tags=tags/project \
> > --branches=branches/project \
> > --branches="branches/global/*/project" project
>
> It looks like you didn't use any of the weird[1] options that make it
> unsafe to clobber the rev_maps. Can you try removing all the .rev_map.*
> files in $GIT_DIR/svn and running "git svn fetch" to rebuild them?
>
> [1] --no-metadata, --use-svm-props
Also, any chance you have multiple refs with "trunk" in the basename?
git rev-parse --symbolic --all | grep '/trunk'
It could be a backwards compatibility issue with git svn looking
in multiple places for trunk.
With Adam's commit, it'll try $GIT_DIR/svn/refs/remotes/trunk/* first
Then it'll try $GIT_DIR/svn/trunk/* as a fallback.
--
Eric Wong
^ permalink raw reply
* Re: [PATCH] Clarify documentation on the "ours" merge strategy.
From: Thomas Rast @ 2009-11-11 20:35 UTC (permalink / raw)
To: Baz
Cc: Peter Krefting, Git Mailing List, Johannes Schindelin,
Björn Steinbrink
In-Reply-To: <2faad3050911110713y4e33c7d2h21ad42efe4fd70b3@mail.gmail.com>
Baz wrote:
> 2009/11/11 Peter Krefting <peter@softwolves.pp.se>:
> > ours::
> > This resolves any number of heads, but the result of the
> > - merge is always the current branch head. It is meant to
> > + merge is always the current branch head, discarding any
> > + changes on the merged branch. It is meant to
>
> I think part of the problem is that it is unclear what the "current
> branch head" means when used in a rebase, and hence when this text is
> included in the help for git-rebase and git-pull.
[...]
> Perhaps something more in the way of an explicit warning?
>
> ours::
> This resolves any number of heads, but the result of the
> merge is always the current branch head, discarding any
> changes on the merged branch. It is meant to
> be used to supersede old development history of side
> branches. Note that when rebasing, the branch you are
> rebasing onto is the "current branch head", and using this
> strategy will lose all of your changes - unlikely to be what
> you wanted to do.
I'd much rather see this explained in the description of the rebase
-m/-s options since it (the swap) applies to all uses of 'git rebase
-m'. Perhaps with an extra (but short) note in the "ours"
description, like so:
diff --git i/Documentation/git-rebase.txt w/Documentation/git-rebase.txt
index 33e0ef1..181947c 100644
--- i/Documentation/git-rebase.txt
+++ w/Documentation/git-rebase.txt
@@ -228,6 +228,10 @@ OPTIONS
Use merging strategies to rebase. When the recursive (default) merge
strategy is used, this allows rebase to be aware of renames on the
upstream side.
++
+Note that in a rebase merge (hence merge conflict), the sides are
+swapped: "theirs" is the to-be-applied patch, and "ours" is the so-far
+rebased series, starting with <upstream>.
-s <strategy>::
--strategy=<strategy>::
diff --git i/Documentation/merge-strategies.txt w/Documentation/merge-strategies.txt
index 4365b7e..0cae1be 100644
--- i/Documentation/merge-strategies.txt
+++ w/Documentation/merge-strategies.txt
@@ -33,6 +33,9 @@ ours::
merge is always the current branch head. It is meant to
be used to supersede old development history of side
branches.
++
+Because the sides in a rebase are swapped, using this strategy with
+git-rebase is never a good idea.
subtree::
This is a modified recursive strategy. When merging trees A and
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply related
* Re: [PATCHv2] Update gitworkflows man page to include release workflow
From: Thomas Rast @ 2009-11-11 20:41 UTC (permalink / raw)
To: rocketraman; +Cc: git
In-Reply-To: <1257869339-15999-2-git-send-email-rocketraman@fastmail.fm>
It's nice to see someone work on this manpage :-) I sadly do not have
the time to read the whole patch right now, though I'll try and catch
up tomorrow or so. In the meantime I do have one remark:
rocketraman@fastmail.fm wrote:
> +The maintainer may use the following release workflow:
> +
> +He first tags the tip of 'master' with a release tag, then he updates
> +the 'maint' branch to the current tip of 'master' for managing future
> +maintenance fixes on the current release, and lastly he optionally
> +rebuilds 'next' from the tip of 'master'.
The current gitworkflows is mostly formulated in the imperative, as in
To test the interaction of several topics, merge them into a
throw-away branch. You must never base any work on such a branch!
or by directly describing the tools in the third person, as in
* linkgit:git-push[1] copies your branches to a remote repository,
usually to one that can be read by all involved parties;
It would certainly be nice to be somewhat consistent. Since at first
glance your description is aimed at the maintainer himself, I assume
that would mostly mean addressing the maintainer as "you", and
formulating the rules in the imperative.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH] Clarify documentation on the "ours" merge strategy.
From: Baz @ 2009-11-11 20:54 UTC (permalink / raw)
To: Thomas Rast
Cc: Peter Krefting, Git Mailing List, Johannes Schindelin,
Björn Steinbrink
In-Reply-To: <200911112135.25839.trast@student.ethz.ch>
2009/11/11 Thomas Rast <trast@student.ethz.ch>:
> Baz wrote:
>> 2009/11/11 Peter Krefting <peter@softwolves.pp.se>:
>> > ours::
>> > This resolves any number of heads, but the result of the
>> > - merge is always the current branch head. It is meant to
>> > + merge is always the current branch head, discarding any
>> > + changes on the merged branch. It is meant to
>>
>> I think part of the problem is that it is unclear what the "current
>> branch head" means when used in a rebase, and hence when this text is
>> included in the help for git-rebase and git-pull.
> [...]
>> Perhaps something more in the way of an explicit warning?
>>
>> ours::
>> This resolves any number of heads, but the result of the
>> merge is always the current branch head, discarding any
>> changes on the merged branch. It is meant to
>> be used to supersede old development history of side
>> branches. Note that when rebasing, the branch you are
>> rebasing onto is the "current branch head", and using this
>> strategy will lose all of your changes - unlikely to be what
>> you wanted to do.
>
> I'd much rather see this explained in the description of the rebase
> -m/-s options since it (the swap) applies to all uses of 'git rebase
> -m'. Perhaps with an extra (but short) note in the "ours"
> description, like so:
>
> diff --git i/Documentation/git-rebase.txt w/Documentation/git-rebase.txt
> index 33e0ef1..181947c 100644
> --- i/Documentation/git-rebase.txt
> +++ w/Documentation/git-rebase.txt
> @@ -228,6 +228,10 @@ OPTIONS
> Use merging strategies to rebase. When the recursive (default) merge
> strategy is used, this allows rebase to be aware of renames on the
> upstream side.
> ++
> +Note that in a rebase merge (hence merge conflict), the sides are
> +swapped: "theirs" is the to-be-applied patch, and "ours" is the so-far
> +rebased series, starting with <upstream>.
>
> -s <strategy>::
> --strategy=<strategy>::
> diff --git i/Documentation/merge-strategies.txt w/Documentation/merge-strategies.txt
> index 4365b7e..0cae1be 100644
> --- i/Documentation/merge-strategies.txt
> +++ w/Documentation/merge-strategies.txt
> @@ -33,6 +33,9 @@ ours::
> merge is always the current branch head. It is meant to
> be used to supersede old development history of side
> branches.
> ++
> +Because the sides in a rebase are swapped, using this strategy with
> +git-rebase is never a good idea.
Yes, this (with Peter's patch) makes the danger nice & clear.
Thanks!
-Baz
>
> subtree::
> This is a modified recursive strategy. When merging trees A and
>
> --
> Thomas Rast
> trast@{inf,student}.ethz.ch
>
^ permalink raw reply
* Re: [PATCH] Clarify documentation on the "ours" merge strategy.
From: Junio C Hamano @ 2009-11-11 21:02 UTC (permalink / raw)
To: Thomas Rast
Cc: Baz, Peter Krefting, Git Mailing List, Johannes Schindelin,
Björn Steinbrink
In-Reply-To: <200911112135.25839.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> I'd much rather see this explained in the description of the rebase
> -m/-s options since it (the swap) applies to all uses of 'git rebase
> -m'. Perhaps with an extra (but short) note in the "ours"
> description, like so:
>
> diff --git i/Documentation/git-rebase.txt w/Documentation/git-rebase.txt
> index 33e0ef1..181947c 100644
> --- i/Documentation/git-rebase.txt
> +++ w/Documentation/git-rebase.txt
> @@ -228,6 +228,10 @@ OPTIONS
> Use merging strategies to rebase. When the recursive (default) merge
> strategy is used, this allows rebase to be aware of renames on the
> upstream side.
> ++
> +Note that in a rebase merge (hence merge conflict), the sides are
> +swapped: "theirs" is the to-be-applied patch, and "ours" is the so-far
> +rebased series, starting with <upstream>.
>
> -s <strategy>::
> --strategy=<strategy>::
> diff --git i/Documentation/merge-strategies.txt w/Documentation/merge-strategies.txt
> index 4365b7e..0cae1be 100644
> --- i/Documentation/merge-strategies.txt
> +++ w/Documentation/merge-strategies.txt
> @@ -33,6 +33,9 @@ ours::
> merge is always the current branch head. It is meant to
> be used to supersede old development history of side
> branches.
> ++
> +Because the sides in a rebase are swapped, using this strategy with
> +git-rebase is never a good idea.
>
> subtree::
> This is a modified recursive strategy. When merging trees A and
Looking very good.
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.6.5.2
From: Jakub Narebski @ 2009-11-11 21:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vljiypw9s.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> The RPM binary packages for a few architectures are found in:
>
> RPMS/$arch/git-*-1.6.5.2-1.fc9.$arch.rpm (RPM)
I tried to install git from source RPM... and failed:
$ rpmbuild --rebuild git-1.6.5.2-1.fc11.src.rpm
Installing git-1.6.5.2-1.fc11.src.rpm
warning: user junio does not exist - using root
warning: group junio does not exist - using root
error: unpacking of archive failed on file
/home/local/builddir/SOURCES/git-1.6.5.2.tar.gz;
4afb1f6a: cpio: MD5 sum mismatch
error: git-1.6.5.2-1.fc11.src.rpm cannot be installed
Error messages are line wrapped for better readibility.
Redownloading the file didn't help
$ ls -l git-1.6.5.2-1.fc11.src.rpm
-rw-r--r-- 1 jnareb users 2713416 Oct 26 03:59 git-1.6.5.2-1.fc11.src.rpm
$ md5sum git-1.6.5.2-1.fc11.src.rpm
9f89a01b65e1b8e8934c3a2252064632 git-1.6.5.2-1.fc11.src.rpm
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: excerpts from tomorrow's "What's cooking" draft
From: Petr Baudis @ 2009-11-11 21:07 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Nicolas Sebrecht, Junio C Hamano, git
In-Reply-To: <alpine.LFD.2.00.0911111408380.16711@xanadu.home>
On Wed, Nov 11, 2009 at 02:50:22PM -0500, Nicolas Pitre wrote:
> On Wed, 11 Nov 2009, Nicolas Sebrecht wrote:
>
> > A bit OT, I've noticed the following output today:
> >
> > % git clone git://repo.or.cz/girocco.git
> > Initialized empty Git repository in /home/nicolas/dev/official_packages/girocco/.git/
> > remote: Counting objects: 3017, done.
> > g objects: 100% (994/994), done.
> > remote: Total 3017 (delta 1911), reused 2988 (delta 1896)
> > Receiving objects: 100% (3017/3017), 403.99 KiB | 309 KiB/s, done.
> > Resolving deltas: 100% (1911/1911), done.
> > %
> >
> > Notice the "g " at the begining at the 3th line. This is reproducible.
>
> I get much worse:
>
> Initialized empty Git repository in /home/nico/git/girocco/.git/
> remote: Counting objects: 3017, done.
> remote: Compressing objects: 5% (50/994) Receiving objects: 3% (91/3017)
> remote: Compressing objects: 15% (150/994) Receiving objects: 7% (212/3017)
> remote: Compressing oReceiving objects: 14% (423/3017), 76.00 KiB | 135 KiB/s
> remote: Compressing objects: 35Receiving objects: 16% (483/3017), 76.00 KiB |
> remote: Compressing objects: 38% (378/994)Receiving objects: 17% (513/3017), 7
> remote: Compressing objectReceiving objects: 20% (604/3017), 76.00 KiB | 135 Ki
> remote: Compressing objects: 48% (47Receiving objects: 22% (664/3017), 76.00 K
> remote: Compressing objects: 5Receiving objects: 23% (694/3017), 76.00 KiB | 1
> remote: Compressing objects: Receiving objects: 25% (755/3017), 76.00 KiB | 13
> remote: Compressing objects: 84% (835/99Receiving objects: 26% (785/3017), 76.
> remote: Compressing objeReceiving objects: 33% (996/3017), 76.00 KiB | 135 KiB/
> remote: Compressing objects: 94% (Receiving objects: 36% (1087/3017), 76.00 Ki
> remote: Compressing objects: 97% (965/994) Receiving objects: 39% (1177/3017
> g objects: 100% (994/994), done.
> remote: Total 3017 (delta 1911), reused 2988 (delta 1896)
> Receiving objects: 100% (3017/3017), 403.99 KiB | 335 KiB/s, done.
> Resolving deltas: 100% (1911/1911), done.
>
> According to strace, data from sideband channel #2 (prefixed with
> "remote: ") pertaining to object compression is printed way after pack
> data has already started to arrive locally. This is really weird.
>
> And this occurs only when fetching from repo.or.cz and not from
> git.kernel.org for example. So there is something to investigate on the
> server side. Pasky: anything you changed in your git installation
> lately?
Yes, but nothing should have changed in git-daemon, that's the only part
of the infrastructure that uses system-wide git (which it perhaps
shouldn't). I cannot reproduce this problem, though. I have changed
git-daemon to use my local git version (about one week old master), does
this still happen for you?
--
Petr "Pasky" Baudis
A lot of people have my books on their bookshelves.
That's the problem, they need to read them. -- Don Knuth
^ permalink raw reply
* Re: excerpts from tomorrow's "What's cooking" draft
From: Nicolas Pitre @ 2009-11-11 21:19 UTC (permalink / raw)
To: Petr Baudis; +Cc: Nicolas Sebrecht, Junio C Hamano, git
In-Reply-To: <20091111210727.GN12890@machine.or.cz>
On Wed, 11 Nov 2009, Petr Baudis wrote:
> On Wed, Nov 11, 2009 at 02:50:22PM -0500, Nicolas Pitre wrote:
> > According to strace, data from sideband channel #2 (prefixed with
> > "remote: ") pertaining to object compression is printed way after pack
> > data has already started to arrive locally. This is really weird.
> >
> > And this occurs only when fetching from repo.or.cz and not from
> > git.kernel.org for example. So there is something to investigate on the
> > server side. Pasky: anything you changed in your git installation
> > lately?
>
> Yes, but nothing should have changed in git-daemon, that's the only part
> of the infrastructure that uses system-wide git (which it perhaps
> shouldn't). I cannot reproduce this problem, though. I have changed
> git-daemon to use my local git version (about one week old master), does
> this still happen for you?
No, it doesn't happen anymore.
What was the git-daemon version before?
Nicolas
^ permalink raw reply
* Re: excerpts from tomorrow's "What's cooking" draft
From: Nicolas Sebrecht @ 2009-11-11 21:26 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Petr Baudis, Nicolas Sebrecht, Junio C Hamano, git
In-Reply-To: <alpine.LFD.2.00.0911111617440.16711@xanadu.home>
The 11/11/09, Nicolas Pitre wrote:
> On Wed, 11 Nov 2009, Petr Baudis wrote:
>
> > Yes, but nothing should have changed in git-daemon, that's the only part
> > of the infrastructure that uses system-wide git (which it perhaps
> > shouldn't). I cannot reproduce this problem, though. I have changed
> > git-daemon to use my local git version (about one week old master), does
> > this still happen for you?
>
> No, it doesn't happen anymore.
I couldn't reproduce it, me neither.
> What was the git-daemon version before?
--
Nicolas Sebrecht
^ permalink raw reply
* [PATCH] Re: Clarify documentation on the "ours" merge strategy.
From: Nicolas Sebrecht @ 2009-11-11 21:30 UTC (permalink / raw)
To: Junio C Hamano
Cc: Thomas Rast, Baz, Peter Krefting, Git Mailing List,
Johannes Schindelin, Björn Steinbrink, Nicolas Sebrecht
In-Reply-To: <7vskckn5b4.fsf@alter.siamese.dyndns.org>
The 11/11/09, Junio C Hamano wrote:
> Thomas Rast <trast@student.ethz.ch> writes:
>
> > ++
> > +Because the sides in a rebase are swapped, using this strategy with
> > +git-rebase is never a good idea.
>
> Looking very good.
If this strategy is _never_ a good idea in this case, I tend to think
that git should forbid this option, or at least, warn and refer to the
documentation.
--
Nicolas Sebrecht
^ 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