* Re: Bug: "git-svn fetch" segfaults on unknown user
From: Jens Seidel @ 2008-11-06 23:08 UTC (permalink / raw)
To: git
In-Reply-To: <20081106154808.GA27102@merkur.sol.de>
On Thu, Nov 06, 2008 at 04:48:09PM +0100, Jens Seidel wrote:
> On Thu, Nov 06, 2008 at 03:43:18PM +0100, Mikael Magnusson wrote:
> > 2008/11/6 Jens Seidel <jensseidel@users.sf.net>:
> > > I noticed the following bug in git-svn version 1.6.0.3 (svn 1.5.5):
> > >
> > > "git-svn fetch" segfaults
>
> "gdb -c core" is useless, it just mentions the error occured in
> "perl git-svn fetch" and there is no stacktrace (don't know how to
> debug perl).
>
> I removed now both [svn] options and it failed again. So it seems a problem
> with file:// access while svn+ssh:// works well.
Could this be possible?
I tried now also to svnsync the same repository on the server which I access with
svn+ssh://. "svn-git fetch" fails on this as well, strange ... The hook scripts
or the property added by "svnsync init" are not responsible, right?
> > Are you sure this isn't the regular svn 1.5.x crash? Ie, does
> > compiling subversion with --disable-runtime-module-search fix it?
No, it did not help.
I tried to reproduce it with a simple svn repository instead of my larger (not
public) one but failed.
What further information do you need? Is there any way to obtain more debug info?
Jens
^ permalink raw reply
* Re: [PATCH v2 3/3] pack-objects: honor '.keep' files
From: Brandon Casey @ 2008-11-06 23:22 UTC (permalink / raw)
To: Junio C Hamano
Cc: Git Mailing List, Shawn O. Pearce, Nicolas Pitre,
Andreas Ericsson
In-Reply-To: <GV8cY3fn8l5UV5cNoPN8bHchWt9u2tbZ8j_ypkiY-ZLfO1tx9d7ebA@cipher.nrlssc.navy.mil>
Brandon Casey wrote:
> Junio,
>
> Please leave this in pu for now, I have some concerns that I haven't
> had time to write down yet.
I've been thinking about pack-objects and repack.
Here's how I think the semantics of repack should be defined:
repack:
<no-options>
-incremental repack which does not repack any object currently packed
in any accessible pack.
Works (it currently works this way).
<-a>
-create a new pack containing all objects required by the repository
including those accessible through alternates, but excluding objects
in _local_ packs with .keep
Flawed, even with my recent patches.
If there are no local packs (or they all have .keep files), then the
pack-objects call will use --incremental which will exclude objects
packed in alt object store, even though -l was not used.
My patches do not differentiate local .keep files from remote .keep files,
which a user may have no control over.
<-A>
-Like -a, but local unreferenced objects which were previously packed
are made to be loose.
Ditto.
<-a -l>
-Restrict operation to only local objects. Only has any effect with -a|-A.
-Like -a, but additionally exclude objects in packs accessible through
alternates.
Works with my recent patches.
<-A -l>
-Like '-a -l', but loosen unreferenced local packed objects.
Ditto.
That set of repack operations needs to map to a combination of pack-objects
options:
<no-options>
-Create a pack with _all_ specified objects
<--unpacked>
-Exclude from packing any object already in an accessible pack.
(Ahh, this came from rev-list interface, and rejects objects at an
earlier stage than --incremental)
<--unpacked=sha1>
-Like '--unpacked', exclude already packed objects, but treat the objects
in the pack with specified sha1 as unpacked.
<--incremental>
-Exclude from packing any object already in an accessible pack,
regardless of whether it is in a pack specified by --unpacked=
(How is this different from --unpacked, even though the exclusion
operation is performed at a different stage? See my epiphany above
about the source of the --unpacked option)
<--unpacked --incremental>
-seems redundant, is there any functional difference?
<--local>
-Exclude objects from being packed that are not in the local object store.
The issue is how to provide my described 'repack -a' functionality.
There does not seem to be a mapping between the above options and the
required functionality.
I see two solutions, both require introducing a new option to pack-objects.
1) allow specifying a set of packs such that if an object resides
in any of the set, the object will not be included in the produced
pack.
Benefits:
-allows keeping pack-objects ignorant of .keep mechanism
-repack can easily be modified to produce the set of packs to ignore
Drawback:
-very round-about way just to have functionality to skip packs with
.keep file
2) New option telling pack-objects to skip objects in local .keep'd packs
Benefits:
-easy to implement in pack-objects
-easy to modify repack
Drawbacks:
-introduces new concept to pack-objects
Questions aside:
1) Are both --incremental and --unpacked still necessary pack-objects options?
2) Can --incremental become an alias for --unpacked, and go away?
patch(es) will follow.
-brandon
^ permalink raw reply
* Re: [PATCH v2 3/3] pack-objects: honor '.keep' files
From: Junio C Hamano @ 2008-11-07 0:30 UTC (permalink / raw)
To: Brandon Casey
Cc: Git Mailing List, Shawn O. Pearce, Nicolas Pitre,
Andreas Ericsson
In-Reply-To: <HBFmgmcvgPzZ0xq-fRUt98ZOBXGCvwxHGyEwF9bNcgpDgS-t-D3viw@cipher.nrlssc.navy.mil>
Brandon Casey <casey@nrlssc.navy.mil> writes:
> <-a>
> -create a new pack containing all objects required by the repository
> including those accessible through alternates, but excluding objects
> in _local_ packs with .keep
I have a feeling that it is debatable if this "fattening to dissociate
from alternates" is what people want.
> <-a -l>
> -Restrict operation to only local objects. Only has any effect with -a|-A.
> -Like -a, but additionally exclude objects in packs accessible through
> alternates.
Presumably you meant "exclude objects accessible through alternates,
either in packs or in loose form"? If so then I think it is a good thing
to have.
I am not sure if listing the behaviour by combination of flags is a good
way to start thinking about this. Wouldn't it be more productive to list
what kinds of repacking are needed, and then label them with combination
of flags? Otherwise you would miss a potentially useful operation that
cannot be expressed with the current set of flags you have.
I think the useful kinds are only these five:
- scoop loose objects that exist in local repository into a new pack,
without touching existing packs at all; exclude anything available in
any existing pack or in alternate repository (either loose or packed);
- pack everything that is needed by the local ref, except the ones that
are borrowed from alternate repositories (either loose or packed), into
a single new pack. There are two variants of this: eject what is
currently packed but unnecessary into loose format when existing local
packs are replaced with the new pack, or lose them (i.e. -A).
- fatten local repository by packing everything that is needed by the
local ref into a single new pack, including things that are currently
borrowed from alternates. There are two variants of this: eject what
is currently packed but unnecessary into loose format when existing
local packs are replaced with the new pack, or lose them (i.e. -A).
^ permalink raw reply
* Re: Need help for migration from CVS to git in one go (ie, FORGETTING CVS history)
From: Jakub Narebski @ 2008-11-07 0:34 UTC (permalink / raw)
To: Francis Galiegue; +Cc: git
In-Reply-To: <200811061313.50711.fg@one2team.net>
On Thu, 6 Nov 2008, Francis Galiegue wrote:
> Le Thursday 06 November 2008 04:08:16 Jakub Narebski, vous avez écrit :
> Hello,
> [...]
> > >
> > > * 52 CVS modules, fine; but then this can become one and 52
> > > subdirectories in them and still act as separate modules from
> > > the build system point of view (which I have implemented, so
> > > I can change it);
> >
> > I think that those CVS modules should become separate repositories,
> > perhaps joined together using submodules. This is one of more
> > difficult things during conversion.
> >
> > Note that in Git commits are always whole tree (whole project)
> > commits.
> >
>
> Honestly, I'm not fond of this approach. The problem with submodules as far as
> I'm concerned is that documentation is "not really there", and (unless the
> README of egit is _really_ outdated) that there's no support in egit.
>
> I know about commits affecting the whole tree, and even branches and tags, and
> that's more of an advantage to my eyes, for two reasons:
>
> * 99+% of queries currently done on the CVS tree (with Bonsai) cover all
> modules; only rarely is a single module concerned, and in this case you just
> fill in the appropriate field in the search page anyway;
Well, the mapping of CVS modules into Git repositories, and perhaps
also later binding those Git repositories together using submodules
support is IMHO one of more difficult decisions when deciding on
migration from CVS to Git.
What you would have to ask yourself is which of those CVS modules
are independent, for example having independent version numbers (tags)
and independent branches. And if commit really affects whole tree...
> * creating a branch is one command and that's it. It may also be one command
> with submodules, but again, the documentation makes me uncomfortable; with
> CVS, well... You get the picture.
Submodules are Git repositories of their own. So you have branching
there (almost) as easy as otherwise in Git. The only problem is a bit
lacking UI for binding those submodules together.
>
> What's more, I don't think we have the requirement of making specific
> per-module tags. Not as far as this has been discussed so far, anyway, and
> not as far as the history shows.
Well, that is one issue that would help in mapping CVS modules to Git
repositories (and submodules).
>
> > > * second: even though this may be a "non problem", we use Bonsai,
> > > which has the ability to see what was commited by whom, given a time
> > > interval (from d1 to d2): the base gitweb allows to search by
> > > commiter, which is good, but it has no date boundaries: do tools
> > > exist for git that can do this? If not, that wouldn't be a big deal,
> > > however...
> >
> > First, there are more web interfaces than gitweb, see
> > http://git.or.cz/gitweb/InterfacesFrontendsAndTools
>
> Yep, I've yet to try those... There are quite a few!
>
> > Second, you can do this from command line, using combination of commit
> > limiting a..b and a...b, or --since=<date> or --after=<date> and
> > --before=<date>, commit message searching --author, --committer, and
> > --grep, and path limiting "git log -- <pathspec>".
>
> Well, a Web-based search engine is kind of a requirement. I'm the only one to
> do command line... Thanks for the hints, though!
You can also use one of GUI; qgit and gitk + git-gui seems to be quite
mature and cross-platform.
> > Third, it would be not that hard to add more advanced search support
> > to gitweb; this is even one of planned features.
I think there are two possible ways of doing it: have a kind of
"advanced search" form, where one can have fill search terms, like
date limit, path limiting etc; or have an option to limit search to
current view context (for example current file or current directory).
> Which brings back to the subject of submodules, since as I said above, we
> generally search on the entire tree, and per-module searches are rare.
Hmmm...
>
> > > * third: also Bonsai-related; Bonsai can link to Bugzilla by
> > > matching (wild guess) /\b(?:#?)(\d+)\b/ and transforming this into
> > > http://your.bugzilla.fqdn.here/show_bug.cgi?id=$1. Does gitweb have
> > > this built-in? (haven't looked yet) Is this planned, or has it been
> > > discussed and been considered not worth the hassle?
> >
> > This is (under name of 'committags') in gitweb TODO; gitweb-xmms2
> > support this IIRC or supported this (for Mantis and not Bugzilla
> > though...)
>
> Interesting... I'll have a look at it.
Well, now I have bumped priority of this item in my gitweb TODO list...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH 2/3] Introduce rename factorization in diffcore.
From: Junio C Hamano @ 2008-11-07 1:10 UTC (permalink / raw)
To: Yann Dirson; +Cc: git
In-Reply-To: <20081101220319.1116.50509.stgit@gandelf.nowhere.earth>
Yann Dirson <ydirson@altern.org> writes:
> Rename factorization tries to group together files moving from and to
> identical directories - the most common case being directory renames.
> We do that by first identifying groups of bulk-moved files, and then
> hiding those of the individual renames which carry no other
> information (further name change, or content changes).
> This feature is activated by the new --factorize-renames diffcore
> flag.
I have a mixed feeling about this one, primarily because I cannot
visualize how a useful output should look like. Unless you rename one
directory to another without any content changes, you would have to say
"this directory changed to that, and among the paths underneath them, this
file have this content change in addition".
A related feature that would benefit from something like your change
without any downside/complication of output format issues is to boost
rename similarity score of a path when its neighbouring paths are moved to
the same location. E.g. when you see:
- three files a/{1,2,3} deleted;
- three files b/{1,2,3} created;
- (a/1 => b/1) and (a/2 => b/2) are similar enough;
- (a/3 => b/3) are not similar enough.
we currently detect only two renames and leave deletion of a/3 and
creation of b/3 unpaired. You should be able to help them paired up by
noticing that the entire a/* goes away (for that, reading the full
postimage like you do in your patch helps) and boost the similarity score
between these two.
Although I do not offhand think a good format to show the information you
are trying to capture in the textual diff output, one thing that would be
helped by the grouping of renames like you do would be process_renames()
in merge_recursive.c. This is especially so when you have added a new
path in a directory that has been moved by the other branch you are
merging. For this usage, there is no "textual output format" issues. It
does not even have to be expressed by replacing individual entries from
diffq with entries that represent a whole subtree --- you could for
example keep what diffq.queue records intact, and add a separate list of
directory renames as a hint for users like process_renames() to use.
^ permalink raw reply
* Re: [PATCH v2 3/3] pack-objects: honor '.keep' files
From: Brandon Casey @ 2008-11-07 1:17 UTC (permalink / raw)
To: Junio C Hamano
Cc: Git Mailing List, Shawn O. Pearce, Nicolas Pitre,
Andreas Ericsson
In-Reply-To: <7v8wrwidi3.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Brandon Casey <casey@nrlssc.navy.mil> writes:
>
>> <-a>
>> -create a new pack containing all objects required by the repository
>> including those accessible through alternates, but excluding objects
>> in _local_ packs with .keep
>
> I have a feeling that it is debatable if this "fattening to dissociate
> from alternates" is what people want.
I'm not sure I understand you here.
Andreas has suggested previously that 'repack -a' should pack everything,
including objects in packs with .keep. Is that what you mean?
With my current understanding it seems that that would muddy the semantics
of repack. If -a does not honor packs with .keep, then would it be intuitive
to expect that adding -l (i.e. exclude alternate packed objects) _would_
honor .keep?
>> <-a -l>
>> -Restrict operation to only local objects. Only has any effect with -a|-A.
>> -Like -a, but additionally exclude objects in packs accessible through
>> alternates.
>
> Presumably you meant "exclude objects accessible through alternates,
> either in packs or in loose form"? If so then I think it is a good thing
> to have.
Would that be an enhancement to the current behavior? I don't think I saw
any mechanism to exclude packing remote loose objects.
The documentation for pack-objects --local says:
--local
This flag is similar to --incremental; instead of ignoring all
packed objects, it only ignores objects that are packed and not
in the local object store (i.e. borrowed from an alternate).
It only mentions packed alternate objects.
>
> I am not sure if listing the behaviour by combination of flags is a good
> way to start thinking about this. Wouldn't it be more productive to list
> what kinds of repacking are needed, and then label them with combination
> of flags? Otherwise you would miss a potentially useful operation that
> cannot be expressed with the current set of flags you have.
I agree. I made a list of the options because I was trying to understand what
effect each option had, then I turned it into an email.
> I think the useful kinds are only these five:
>
> - scoop loose objects that exist in local repository into a new pack,
> without touching existing packs at all; exclude anything available in
> any existing pack or in alternate repository (either loose or packed);
>
> - pack everything that is needed by the local ref, except the ones that
> are borrowed from alternate repositories (either loose or packed), into
> a single new pack. There are two variants of this: eject what is
> currently packed but unnecessary into loose format when existing local
> packs are replaced with the new pack, or lose them (i.e. -A).
>
> - fatten local repository by packing everything that is needed by the
> local ref into a single new pack, including things that are currently
> borrowed from alternates. There are two variants of this: eject what
> is currently packed but unnecessary into loose format when existing
> local packs are replaced with the new pack, or lose them (i.e. -A).
You didn't say when local .keep should be honored, i.e. objects in local
packs with .keep should be excluded from repacking. always, never, only
with -l, new repack option?
-brandon
^ permalink raw reply
* [PATCH 1/4] pack-objects: new option --honor-pack-keep
From: Brandon Casey @ 2008-11-07 1:52 UTC (permalink / raw)
To: Junio C Hamano
Cc: Git Mailing List, Shawn O. Pearce, Nicolas Pitre,
Andreas Ericsson
In-Reply-To: <HBFmgmcvgPzZ0xq-fRUt98ZOBXGCvwxHGyEwF9bNcgpDgS-t-D3viw@cipher.nrlssc.navy.mil>
This adds a new option to pack-objects which will cause it to ignore an
object which appears in a local pack which has a .keep file, even if it
was specified for packing.
This option will be used by the porcelain repack.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
This series replaces the previous series starting at
6ee726bc "pack-objects: honor '.keep' files"
It should be applied on top of
f34cf12d "packed_git: convert pack_local flag into a bitfield and add pack_keep"
I created the series on top of f34cf12d rebased on top of master.
Suggestions for a more appropriate name for --honor-pack-keep are very welcome.
-brandon
Documentation/git-pack-objects.txt | 5 +++++
builtin-pack-objects.c | 7 +++++++
2 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-pack-objects.txt b/Documentation/git-pack-objects.txt
index 8c354bd..f9fac2c 100644
--- a/Documentation/git-pack-objects.txt
+++ b/Documentation/git-pack-objects.txt
@@ -109,6 +109,11 @@ base-name::
The default is unlimited, unless the config variable
`pack.packSizeLimit` is set.
+--honor-pack-keep::
+ This flag causes an object already in a local pack that
+ has a .keep file to be ignored, even if it appears in the
+ standard input.
+
--incremental::
This flag causes an object already in a pack ignored
even if it appears in the standard input.
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 15b80db..ddec341 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -71,6 +71,7 @@ static int reuse_delta = 1, reuse_object = 1;
static int keep_unreachable, unpack_unreachable, include_tag;
static int local;
static int incremental;
+static int ignore_packed_keep;
static int allow_ofs_delta;
static const char *base_name;
static int progress = 1;
@@ -703,6 +704,8 @@ static int add_object_entry(const unsigned char *sha1, enum object_type type,
return 0;
if (local && !p->pack_local)
return 0;
+ if (ignore_packed_keep && p->pack_local && p->pack_keep)
+ return 0;
}
}
@@ -2048,6 +2051,10 @@ int cmd_pack_objects(int argc, const char **argv, const char *prefix)
incremental = 1;
continue;
}
+ if (!strcmp("--honor-pack-keep", arg)) {
+ ignore_packed_keep = 1;
+ continue;
+ }
if (!prefixcmp(arg, "--compression=")) {
char *end;
int level = strtoul(arg+14, &end, 0);
--
1.6.0.3.552.g12334
^ permalink raw reply related
* [PATCH 2/4] repack: don't repack local objects in packs with .keep file
From: Brandon Casey @ 2008-11-07 1:54 UTC (permalink / raw)
To: Junio C Hamano
Cc: Git Mailing List, Shawn O. Pearce, Nicolas Pitre,
Andreas Ericsson
In-Reply-To: <oDevG_2ETMLvy6rfSqvxfmFqABeVqlDUcU6FjP07E5IzqLaopWkQbQ@cipher.nrlssc.navy.mil>
If the user created a .keep file for a local pack, then it can be inferred
that the user does not want those objects repacked.
This fixes the repack bug tested by t7700.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
git-repack.sh | 2 +-
t/t7700-repack.sh | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-repack.sh b/git-repack.sh
index d39eb6c..8bb2201 100755
--- a/git-repack.sh
+++ b/git-repack.sh
@@ -83,7 +83,7 @@ case ",$all_into_one," in
esac
args="$args $local $quiet $no_reuse$extra"
-names=$(git pack-objects --non-empty --all --reflog $args </dev/null "$PACKTMP") ||
+names=$(git pack-objects --honor-pack-keep --non-empty --all --reflog $args </dev/null "$PACKTMP") ||
exit 1
if [ -z "$names" ]; then
if test -z "$quiet"; then
diff --git a/t/t7700-repack.sh b/t/t7700-repack.sh
index 7aaff0b..356afe3 100755
--- a/t/t7700-repack.sh
+++ b/t/t7700-repack.sh
@@ -4,7 +4,7 @@ test_description='git repack works correctly'
. ./test-lib.sh
-test_expect_failure 'objects in packs marked .keep are not repacked' '
+test_expect_success 'objects in packs marked .keep are not repacked' '
echo content1 > file1 &&
echo content2 > file2 &&
git add . &&
--
1.6.0.3.552.g12334
^ permalink raw reply related
* [PATCH 3/4] repack: do not fall back to incremental repacking with [-a|-A]
From: Brandon Casey @ 2008-11-07 1:55 UTC (permalink / raw)
To: Junio C Hamano
Cc: Git Mailing List, Shawn O. Pearce, Nicolas Pitre,
Andreas Ericsson
In-Reply-To: <P5afFyDEMjF9ynd9dfSfGeRo_GFY_K6ZAn2nIYo8_xGgSl4LapbSOA@cipher.nrlssc.navy.mil>
When repack is called with either the -a or -A option, the user has
requested to repack all objects including those referenced by the
alternates mechanism. Currently, if there are no local packs without
.keep files, then repack will call pack-objects with the
'--unpacked --incremental' options which causes it to exclude alternate
packed objects. So, remove this fallback.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
git-repack.sh | 11 ++++-------
1 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/git-repack.sh b/git-repack.sh
index 8bb2201..4d313d1 100755
--- a/git-repack.sh
+++ b/git-repack.sh
@@ -71,13 +71,10 @@ case ",$all_into_one," in
existing="$existing $e"
fi
done
- fi
- if test -z "$args"
- then
- args='--unpacked --incremental'
- elif test -n "$unpack_unreachable"
- then
- args="$args $unpack_unreachable"
+ if test -n "$args" -a -n "$unpack_unreachable"
+ then
+ args="$args $unpack_unreachable"
+ fi
fi
;;
esac
--
1.6.0.3.552.g12334
^ permalink raw reply related
* [PATCH 4/4] builtin-gc.c: use new pack_keep bitfield to detect .keep file existence
From: Brandon Casey @ 2008-11-07 1:56 UTC (permalink / raw)
To: Junio C Hamano
Cc: Git Mailing List, Shawn O. Pearce, Nicolas Pitre,
Andreas Ericsson
In-Reply-To: <-NKrpBlnD0U49OczAyUd7HiIBqhMblkOkU4lOc2bc9qfTrGNrwpLTg@cipher.nrlssc.navy.mil>
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
I think the existing code was broken. Looks like it would only skip
counting a pack if the pack disappeared between the prepare_packed_git()
and the access() call. It never used the path it create with the .keep
extension.
-brandon
builtin-gc.c | 12 +-----------
1 files changed, 1 insertions(+), 11 deletions(-)
diff --git a/builtin-gc.c b/builtin-gc.c
index 7af65bb..781df60 100644
--- a/builtin-gc.c
+++ b/builtin-gc.c
@@ -131,19 +131,9 @@ static int too_many_packs(void)
prepare_packed_git();
for (cnt = 0, p = packed_git; p; p = p->next) {
- char path[PATH_MAX];
- size_t len;
- int keep;
-
if (!p->pack_local)
continue;
- len = strlen(p->pack_name);
- if (PATH_MAX <= len + 1)
- continue; /* oops, give up */
- memcpy(path, p->pack_name, len-5);
- memcpy(path + len - 5, ".keep", 6);
- keep = access(p->pack_name, F_OK) && (errno == ENOENT);
- if (keep)
+ if (p->pack_keep)
continue;
/*
* Perhaps check the size of the pack and count only
--
1.6.0.3.552.g12334
^ permalink raw reply related
* [KORG] Master backend downtime - hardware swap
From: J.H. @ 2008-11-07 1:43 UTC (permalink / raw)
To: users, git, linux-kernel, ftpadmin
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hey everyone,
Just a heads up to everyone, I'm going to be taking the master (hera)
backend server offline for a couple of hours tomorrow (Friday, CST)
afternoon. Downtime is going to get used for finishing flipping over
the master to new hardware, which was very generously donated by
Hewlett-Packard. We are moving up to a new DL380 G5. That said I will
need time to shut everything down, get a current rsync from the old
hardware to the new hardware and confirm that serves are restored on the
new machine.
I'm expecting the entire downtime to only take a couple of hours, but
since we all know things will take longer I'm going to declare the
window from 1200 CST (1800 UTC Friday Nov 7th). Expect the window to
run through 2000 UTC, and if things are up and running before that I'll
let people know. Otherwise if there are problems you'll see another
e-mail from me.
If you have questions, comments, concerns, etc - please send them to me
CC ftpadmin@kernel.org
- - John 'Warthog9' Hawley
Chief Kernel.org Administrator
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Remi - http://enigmail.mozdev.org
iD8DBQFJE51L/E3kyWU9dicRAs8/AJ9DVJjQxcOt9CUVsQYVM6elJkTr2gCePLJ8
+UuEcZdwUpAICFijAXp9ae4=
=c6vs
-----END PGP SIGNATURE-----
^ permalink raw reply
* Fwd: Documentation/user-manual.txt, asciidoc and "--" escapes
From: Piotr Findeisen @ 2008-11-07 3:09 UTC (permalink / raw)
To: git
In-Reply-To: <ddb82bf60811061904t5defc492m80cd1b759674eb6@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 918 bytes --]
Hello!
I've been reading
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html till
late night and found that "--" prefixing options names (like in "git
diff --cached") are replaced by asciidoc with a single unicode
character "—" which makes them unsuitable for pasting them to a
terminal.
I've cloned the git repository from
git://git.kernel.org/pub/scm/git/git.git, made some changes to
Documentation/user-manual.txt, tested the results and commited my work
locally.
The attached file is a result of running `git diff HEAD~1`.
My local log message:
------------------
asciidoc escaping of "--"
Asciidoc replaces "--" with "—" when not in verbatim mode. This is
sometimes unwanted -- especially when citing command line options like
"git diff --cached". This commit includes proper quotes in user-manual.txt.
------------------
Hope that's of any use.
Best regards,
Piotr
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: user-manual.txt.patch --]
[-- Type: text/x-diff; name=user-manual.txt.patch, Size: 7018 bytes --]
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 645d752..66d0cca 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -527,8 +527,8 @@ $ git reset --hard fb47ddb2db...
then test, run "bisect good" or "bisect bad" as appropriate, and
continue.
-Instead of "git bisect visualize" and then "git reset --hard
-fb47ddb2db...", you might just want to tell git that you want to skip
+Instead of "git bisect visualize" and then "+++git reset --hard
+fb47ddb2db...+++", you might just want to tell git that you want to skip
the current commit:
-------------------------------------------------
@@ -660,7 +660,7 @@ You can also ask git log to show patches:
$ git log -p
-------------------------------------------------
-See the "--pretty" option in the linkgit:git-log[1] man page for more
+See the "+++--pretty+++" option in the linkgit:git-log[1] man page for more
display options.
Note that git log starts with the most recent commit and works
@@ -900,7 +900,7 @@ $ gitk $( git show-ref --heads ) --not $( git show-ref --tags )
-------------------------------------------------
(See linkgit:git-rev-parse[1] for explanations of commit-selecting
-syntax such as `--not`.)
+syntax such as `+++--not+++`.)
[[making-a-release]]
Creating a changelog and tarball for a software release
@@ -1024,7 +1024,7 @@ at step 3, git maintains a snapshot of the tree's contents in a
special staging area called "the index."
At the beginning, the content of the index will be identical to
-that of the HEAD. The command "git diff --cached", which shows
+that of the HEAD. The command "+++git diff --cached+++", which shows
the difference between the HEAD and the index, should therefore
produce no output at that point.
@@ -1572,7 +1572,7 @@ Recovering lost changes
Reflogs
^^^^^^^
-Say you modify a branch with `linkgit:git-reset[1] --hard`, and then
+Say you modify a branch with `linkgit:git-reset[1] +++--hard+++`, and then
realize that the branch was the only reference you had to that point in
history.
@@ -1701,7 +1701,7 @@ $ git pull
More generally, a branch that is created from a remote branch will pull
by default from that branch. See the descriptions of the
branch.<name>.remote and branch.<name>.merge options in
-linkgit:git-config[1], and the discussion of the `--track` option in
+linkgit:git-config[1], and the discussion of the `+++--track+++` option in
linkgit:git-checkout[1], to learn how to control these defaults.
In addition to saving you keystrokes, "git pull" also helps you by
@@ -1978,8 +1978,8 @@ error: failed to push to 'ssh://yourserver.com/~you/proj.git'
This can happen, for example, if you:
- - use `git-reset --hard` to remove already-published commits, or
- - use `git-commit --amend` to replace already-published commits
+ - use `+++git-reset --hard+++` to remove already-published commits, or
+ - use `+++git-commit --amend+++` to replace already-published commits
(as in <<fixing-a-mistake-by-rewriting-history>>), or
- use `git-rebase` to rebase any already-published commits (as
in <<using-git-rebase>>).
@@ -2088,7 +2088,7 @@ linkgit:git-fetch[1] to keep them up-to-date; see
Now create the branches in which you are going to work; these start out
at the current tip of origin/master branch, and should be set up (using
-the --track option to linkgit:git-branch[1]) to merge changes in from
+the +++--track+++ option to linkgit:git-branch[1]) to merge changes in from
Linus by default.
-------------------------------------------------
@@ -2468,7 +2468,7 @@ $ git rebase --continue
and git will continue applying the rest of the patches.
-At any point you may use the `--abort` option to abort this process and
+At any point you may use the `+++--abort+++` option to abort this process and
return mywork to the state it had before you started the rebase:
-------------------------------------------------
@@ -2539,7 +2539,7 @@ $ gitk origin..mywork &
and browse through the list of patches in the mywork branch using gitk,
applying them (possibly in a different order) to mywork-new using
-cherry-pick, and possibly modifying them as you go using `commit --amend`.
+cherry-pick, and possibly modifying them as you go using `+++commit --amend+++`.
The linkgit:git-gui[1] command may also help as it allows you to
individually select diff hunks for inclusion in the index (by
right-clicking on the diff hunk and choosing "Stage Hunk for Commit").
@@ -2897,7 +2897,7 @@ Commit Object
~~~~~~~~~~~~~
The "commit" object links a physical state of a tree with a description
-of how we got there and why. Use the --pretty=raw option to
+of how we got there and why. Use the +++--pretty=raw+++ option to
linkgit:git-show[1] or linkgit:git-log[1] to examine your favorite
commit:
@@ -3700,16 +3700,16 @@ i.e. it will normally just update existing cache entries.
To tell git that yes, you really do realize that certain files no
longer exist, or that new files should be added, you
-should use the `--remove` and `--add` flags respectively.
+should use the `+++--remove+++` and `+++--add+++` flags respectively.
-NOTE! A `--remove` flag does 'not' mean that subsequent filenames will
+NOTE! A `+++--remove+++` flag does 'not' mean that subsequent filenames will
necessarily be removed: if the files still exist in your directory
structure, the index will be updated with their new status, not
-removed. The only thing `--remove` means is that update-index will be
+removed. The only thing `+++--remove+++` means is that update-index will be
considering a removed file to be a valid thing, and if the file really
does not exist any more, it will update the index accordingly.
-As a special case, you can also do `git update-index --refresh`, which
+As a special case, you can also do `+++git update-index --refresh+++`, which
will refresh the "stat" information of each index to match the current
stat information. It will 'not' update the object status itself, and
it will only update the fields that are used to quickly test whether
@@ -3956,7 +3956,7 @@ entries" in it. Such an index tree can 'NOT' be written out to a tree
object, and you will have to resolve any such merge clashes using
other tools before you can write out the result.
-You can examine such index state with `git ls-files --unmerged`
+You can examine such index state with `+++git ls-files --unmerged+++`
command. An example:
------------------------------------------------
@@ -3967,7 +3967,7 @@ $ git ls-files --unmerged
100644 cc44c73eb783565da5831b4d820c962954019b69 3 hello.c
------------------------------------------------
-Each line of the `git ls-files --unmerged` output begins with
+Each line of the `+++git ls-files --unmerged+++` output begins with
the blob mode bits, blob SHA1, 'stage number', and the
filename. The 'stage number' is git's way to say which tree it
came from: stage 1 corresponds to `$orig` tree, stage 2 `HEAD`
^ permalink raw reply related
* Re: [PATCH] Teach/Fix pull/fetch -q/-v options
From: Tuncer Ayaz @ 2008-11-07 3:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, git
In-Reply-To: <4ac8254d0811011023r10a4ce45ka962344ceef564f0@mail.gmail.com>
On Sat, Nov 1, 2008 at 6:23 PM, Tuncer Ayaz <tuncer.ayaz@gmail.com> wrote:
> On Tue, Oct 28, 2008 at 4:21 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> Nanako Shiraishi <nanako3@lavabit.com> writes:
>>
>>> Quoting Tuncer Ayaz <tuncer.ayaz@gmail.com>:
>>>
>>>> After fixing clone -q I noticed that pull -q does not do what
>>>> it's supposed to do and implemented --quiet/--verbose by
>>>> adding it to builtin-merge and fixing two places in builtin-fetch.
>>>
>>> Junio, may I ask what the status of this patch is? Maybe the patch was
>>> lost in the noise? The commit log message is written very differently from
>>> existing commits in the history of git, and I am thinking that maybe that is
>>> why you did not like the whole patch? Or is it lack of any test script?
>>
>> Well, perhaps you've been with us long enough to get too picky like
>> myself, but this was genuinely lost in the noise and my scrambling to get
>> back to normal. We do not typically say "I did this, I did that", but the
>> first paragraph in Tuncer's message is perfectly fine. I would probably
>> liked the second paragraph better if it were after --- lines (it is more
>> about the possible enhancements in other areas, and does not belong to the
>> commit log message for this change), but it is not a grave enough offence
>> to get the patch rejected.
>
> Should I resend the patch with a short and simple commit message
> like the following?
> --8<--
> Implement git-pull --quiet and --verbose by adding the
> options to git-pull and fixing verbosity handling in git-fetch.
> -->8--
>
>> The patch itself looks Ok; the lack of test script additions does indeed
>> bother me somewhat, but it is not too big a deal.
>
> I took a look at t/ and am not quite sure whether I should test -v/-q
> by analyzing stdout output's length & content.
>
> I think testing -q and -v makes more sense on a global and not
> git-pull or git-fetch level. For that to be possible I envision building
> common verbosity-based logging functions/macros.
>
> I don't like the idea of scanning stdout for length or content as
> long as we're not sure that all errors and warnings are sent
> to stderr and stdout is for info and verbose only.
>
>> P.S. We are having fun at GitTogether'08 in the first half of this week,
>> so please expect slower response than usual.
>
Please see my next patch revision arriving here in a moment.
^ permalink raw reply
* [PATCH] Teach/Fix pull/fetch -q/-v options
From: Tuncer Ayaz @ 2008-11-07 3:26 UTC (permalink / raw)
To: git
Implement git-pull --quiet and git-pull --verbose by
adding the options to git-pull and fixing verbosity
handling in git-fetch.
Signed-off-by: Tuncer Ayaz <tuncer.ayaz@gmail.com>
---
Documentation/merge-options.txt | 8 +++++
builtin-fetch.c | 21 +++++++------
builtin-merge.c | 22 ++++++++++----
git-pull.sh | 10 ++++--
t/t5521-pull-options.sh | 60 +++++++++++++++++++++++++++++++++++++++
5 files changed, 101 insertions(+), 20 deletions(-)
create mode 100755 t/t5521-pull-options.sh
diff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt
index 007909a..427cdef 100644
--- a/Documentation/merge-options.txt
+++ b/Documentation/merge-options.txt
@@ -1,3 +1,11 @@
+-q::
+--quiet::
+ Operate quietly.
+
+-v::
+--verbose::
+ Be verbose.
+
--stat::
Show a diffstat at the end of the merge. The diffstat is also
controlled by the configuration option merge.stat.
diff --git a/builtin-fetch.c b/builtin-fetch.c
index f151cfa..efc5801 100644
--- a/builtin-fetch.c
+++ b/builtin-fetch.c
@@ -22,16 +22,17 @@ enum {
TAGS_SET = 2
};
-static int append, force, keep, update_head_ok, verbose, quiet;
+static int append, force, keep, update_head_ok;
static int tags = TAGS_DEFAULT;
static const char *depth;
static const char *upload_pack;
static struct strbuf default_rla = STRBUF_INIT;
static struct transport *transport;
+static enum { QUIET, NORMAL, VERBOSE } verbosity = NORMAL;
static struct option builtin_fetch_options[] = {
- OPT__QUIET(&quiet),
- OPT__VERBOSE(&verbose),
+ OPT_SET_INT('v', "verbose", &verbosity, "be verbose", VERBOSE),
+ OPT_SET_INT('q', "quiet", &verbosity, "operate quietly", QUIET),
OPT_BOOLEAN('a', "append", &append,
"append to .git/FETCH_HEAD instead of overwriting"),
OPT_STRING(0, "upload-pack", &upload_pack, "PATH",
@@ -192,7 +193,6 @@ static int s_update_ref(const char *action,
static int update_local_ref(struct ref *ref,
const char *remote,
- int verbose,
char *display)
{
struct commit *current = NULL, *updated;
@@ -210,7 +210,7 @@ static int update_local_ref(struct ref *ref,
die("object %s not found", sha1_to_hex(ref->new_sha1));
if (!hashcmp(ref->old_sha1, ref->new_sha1)) {
- if (verbose)
+ if (verbosity == VERBOSE)
sprintf(display, "= %-*s %-*s -> %s", SUMMARY_WIDTH,
"[up to date]", REFCOL_WIDTH, remote,
pretty_ref);
@@ -366,18 +366,19 @@ static int store_updated_refs(const char *url, const char *remote_name,
note);
if (ref)
- rc |= update_local_ref(ref, what, verbose, note);
+ rc |= update_local_ref(ref, what, note);
else
sprintf(note, "* %-*s %-*s -> FETCH_HEAD",
SUMMARY_WIDTH, *kind ? kind : "branch",
REFCOL_WIDTH, *what ? what : "HEAD");
if (*note) {
- if (!shown_url) {
+ if (verbosity > QUIET && !shown_url) {
fprintf(stderr, "From %.*s\n",
url_len, url);
shown_url = 1;
}
- fprintf(stderr, " %s\n", note);
+ if (verbosity > QUIET)
+ fprintf(stderr, " %s\n", note);
}
}
fclose(fp);
@@ -637,9 +638,9 @@ int cmd_fetch(int argc, const char **argv, const char *prefix)
remote = remote_get(argv[0]);
transport = transport_get(remote, remote->url[0]);
- if (verbose >= 2)
+ if (verbosity == VERBOSE)
transport->verbose = 1;
- if (quiet)
+ if (verbosity == QUIET)
transport->verbose = -1;
if (upload_pack)
set_option(TRANS_OPT_UPLOADPACK, upload_pack);
diff --git a/builtin-merge.c b/builtin-merge.c
index 5e7910b..76e2890 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -50,6 +50,7 @@ static unsigned char head[20], stash[20];
static struct strategy **use_strategies;
static size_t use_strategies_nr, use_strategies_alloc;
static const char *branch;
+static enum { QUIET, NORMAL, VERBOSE } verbosity = NORMAL;
static struct strategy all_strategy[] = {
{ "recursive", DEFAULT_TWOHEAD | NO_TRIVIAL },
@@ -152,6 +153,8 @@ static int option_parse_n(const struct option *opt,
}
static struct option builtin_merge_options[] = {
+ OPT_SET_INT('v', "verbose", &verbosity, "be verbose", VERBOSE),
+ OPT_SET_INT('q', "quiet", &verbosity, "operate quietly", QUIET),
{ OPTION_CALLBACK, 'n', NULL, NULL, NULL,
"do not show a diffstat at the end of the merge",
PARSE_OPT_NOARG, option_parse_n },
@@ -250,7 +253,8 @@ static void restore_state(void)
/* This is called when no merge was necessary. */
static void finish_up_to_date(const char *msg)
{
- printf("%s%s\n", squash ? " (nothing to squash)" : "", msg);
+ if (verbosity > QUIET)
+ printf("%s%s\n", squash ? " (nothing to squash)" : "", msg);
drop_save();
}
@@ -331,14 +335,15 @@ static void finish(const unsigned char *new_head, const char *msg)
if (!msg)
strbuf_addstr(&reflog_message, getenv("GIT_REFLOG_ACTION"));
else {
- printf("%s\n", msg);
+ if (verbosity > QUIET)
+ printf("%s\n", msg);
strbuf_addf(&reflog_message, "%s: %s",
getenv("GIT_REFLOG_ACTION"), msg);
}
if (squash) {
squash_message();
} else {
- if (!merge_msg.len)
+ if (verbosity > QUIET && !merge_msg.len)
printf("No merge message -- not updating HEAD\n");
else {
const char *argv_gc_auto[] = { "gc", "--auto", NULL };
@@ -872,6 +877,8 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
argc = parse_options(argc, argv, builtin_merge_options,
builtin_merge_usage, 0);
+ if (verbosity > QUIET)
+ show_diffstat = 0;
if (squash) {
if (!allow_fast_forward)
@@ -1013,10 +1020,11 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
strcpy(hex, find_unique_abbrev(head, DEFAULT_ABBREV));
- printf("Updating %s..%s\n",
- hex,
- find_unique_abbrev(remoteheads->item->object.sha1,
- DEFAULT_ABBREV));
+ if (verbosity > QUIET)
+ printf("Updating %s..%s\n",
+ hex,
+ find_unique_abbrev(remoteheads->item->object.sha1,
+ DEFAULT_ABBREV));
strbuf_addstr(&msg, "Fast forward");
if (have_message)
strbuf_addstr(&msg,
diff --git a/git-pull.sh b/git-pull.sh
index 664fe34..8866f2a 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -16,13 +16,17 @@ cd_to_toplevel
test -z "$(git ls-files -u)" ||
die "You are in the middle of a conflicted merge."
-strategy_args= no_stat= no_commit= squash= no_ff= log_arg=
+strategy_args= no_stat= no_commit= squash= no_ff= log_arg= verbosity=
curr_branch=$(git symbolic-ref -q HEAD)
curr_branch_short=$(echo "$curr_branch" | sed "s|refs/heads/||")
rebase=$(git config --bool branch.$curr_branch_short.rebase)
while :
do
case "$1" in
+ -q|--quiet)
+ verbosity=-q ;;
+ -v|--verbose)
+ verbosity=-v ;;
-n|--no-stat|--no-summary)
no_stat=-n ;;
--stat|--summary)
@@ -121,7 +125,7 @@ test true = "$rebase" && {
"refs/remotes/$origin/$reflist" 2>/dev/null)"
}
orig_head=$(git rev-parse --verify HEAD 2>/dev/null)
-git fetch --update-head-ok "$@" || exit 1
+git fetch $verbosity --update-head-ok "$@" || exit 1
curr_head=$(git rev-parse --verify HEAD 2>/dev/null)
if test -n "$orig_head" && test "$curr_head" != "$orig_head"
@@ -182,4 +186,4 @@ test true = "$rebase" &&
exec git-rebase $strategy_args --onto $merge_head \
${oldremoteref:-$merge_head}
exec git-merge $no_stat $no_commit $squash $no_ff $log_arg $strategy_args \
- "$merge_name" HEAD $merge_head
+ "$merge_name" HEAD $merge_head $verbosity
diff --git a/t/t5521-pull-options.sh b/t/t5521-pull-options.sh
new file mode 100755
index 0000000..83e2e8a
--- /dev/null
+++ b/t/t5521-pull-options.sh
@@ -0,0 +1,60 @@
+#!/bin/sh
+
+test_description='pull options'
+
+. ./test-lib.sh
+
+D=`pwd`
+
+test_expect_success 'setup' '
+ mkdir parent &&
+ (cd parent && git init &&
+ echo one >file && git add file &&
+ git commit -m one)
+'
+
+cd "$D"
+
+test_expect_success 'git pull -q' '
+ mkdir clonedq &&
+ cd clonedq &&
+ git pull -q "$D/parent" >out 2>err &&
+ test ! -s out
+'
+
+cd "$D"
+
+test_expect_success 'git pull' '
+ mkdir cloned &&
+ cd cloned &&
+ git pull "$D/parent" >out 2>err &&
+ test -s out
+'
+cd "$D"
+
+test_expect_success 'git pull -v' '
+ mkdir clonedv &&
+ cd clonedv &&
+ git pull -v "$D/parent" >out 2>err &&
+ test -s out
+'
+
+cd "$D"
+
+test_expect_success 'git pull -v -q' '
+ mkdir clonedvq &&
+ cd clonedvq &&
+ git pull -v -q "$D/parent" >out 2>err &&
+ test ! -s out
+'
+
+cd "$D"
+
+test_expect_success 'git pull -q -v' '
+ mkdir clonedqv &&
+ cd clonedqv &&
+ git pull -q -v "$D/parent" >out 2>err &&
+ test -s out
+'
+
+test_done
--
1.6.0.2.GIT
^ permalink raw reply related
* Re: multiple-commit cherry-pick?
From: Linus Torvalds @ 2008-11-07 3:29 UTC (permalink / raw)
To: Alex Riesen; +Cc: Miles Bader, git
In-Reply-To: <20081106213711.GA4334@blimp.localdomain>
On Thu, 6 Nov 2008, Alex Riesen wrote:
>
> git format-patch --full-index --binary --stdout <range...> | git am -3
>
> This will not work if you want to pick a list, not a range, of
> commits.
Doesn't "--no-walk" + list commits individually work?
So it _should_ be possible to pick a list of commits too. Although I think
that git format-patch will reverse the order.
Linus
^ permalink raw reply
* Re: multiple-commit cherry-pick?
From: Miles Bader @ 2008-11-07 4:38 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Alex Riesen, git
In-Reply-To: <alpine.LFD.2.00.0811061925300.3451@nehalem.linux-foundation.org>
>> git format-patch --full-index --binary --stdout <range...> | git am -3
>>
>> This will not work if you want to pick a list, not a range, of
>> commits.
>
> Doesn't "--no-walk" + list commits individually work?
>
> So it _should_ be possible to pick a list of commits too. Although I think
> that git format-patch will reverse the order.
Incidentally, the reason I like a rebase-based solution is that many
of the rebase features like -i, --abort, and --continue (after
conflict resolution) are very nice for the multi-cherry-pick case too,
and I'm already very familiar with their operation from using rebase.
[git-am seems to have some similar features, but I don't know how well
they work.]
-Miles
--
Do not taunt Happy Fun Ball.
^ permalink raw reply
* Re: multiple-commit cherry-pick?
From: Junio C Hamano @ 2008-11-07 5:00 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Alex Riesen, Miles Bader, git
In-Reply-To: <alpine.LFD.2.00.0811061925300.3451@nehalem.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Thu, 6 Nov 2008, Alex Riesen wrote:
>>
>> git format-patch --full-index --binary --stdout <range...> | git am -3
>>
>> This will not work if you want to pick a list, not a range, of
>> commits.
>
> Doesn't "--no-walk" + list commits individually work?
>
> So it _should_ be possible to pick a list of commits too. Although I think
> that git format-patch will reverse the order.
Or "git show --pretty=email $commit1 $commit2" ... piped to "am"?
^ permalink raw reply
* Re: multiple-commit cherry-pick?
From: Miles Bader @ 2008-11-07 5:09 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Deskin Miller, git
In-Reply-To: <20081106122658.GB4192@atjola.homenet>
Björn Steinbrink <B.Steinbrink@gmx.de> writes:
>> > git reset --hard C
>> > git rebase --onto ORIG_HEAD A^
>>
>> Is that safe...? Doesn't git-rebase also set ORIG_HEAD?
>
> One of the first things rebase does is validating and resolving its
> arguments. And that's happening before any actions that would touch
> ORIG_HEAD.
Ah, I see.
Hmm, I guess using rebase --abort isn't a very good idea in this case
though... :-/
Kind of a shame, since it's nice being to just abort the whole operation
if it turns out you did something wrong and aren't sure how to recover.
Thanks,
-Miles
--
Kilt, n. A costume sometimes worn by Scotchmen [sic] in America and Americans
in Scotland.
^ permalink raw reply
* Re: Stgit and refresh-temp
From: Karl Hasselström @ 2008-11-07 5:44 UTC (permalink / raw)
To: Jon Smirl; +Cc: Catalin Marinas, Git Mailing List
In-Reply-To: <9e4733910811040537p4e88c09an94370154eca12778@mail.gmail.com>
On 2008-11-04 08:37:24 -0500, Jon Smirl wrote:
> I hit a case when refreshing a buried patch that needed a merge
> conflict sorted out. I'm unable to recover out of the state.
Hmm, so what you're saying is basically that you did something with
"stg refresh -p" that caused a merge conflict, and that messed things
up so that you needed to run "stg repair". Is that right?
Have you been able to reproduce it? (I would like to add the failing
case to the test suite.)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: multiple-commit cherry-pick?
From: Alex Riesen @ 2008-11-07 7:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Miles Bader, git
In-Reply-To: <7vskq4gmf5.fsf@gitster.siamese.dyndns.org>
Junio C Hamano, Fri, Nov 07, 2008 06:00:46 +0100:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
>
> > On Thu, 6 Nov 2008, Alex Riesen wrote:
> >>
> >> git format-patch --full-index --binary --stdout <range...> | git am -3
> >>
> >> This will not work if you want to pick a list, not a range, of
> >> commits.
> >
> > Doesn't "--no-walk" + list commits individually work?
> >
> > So it _should_ be possible to pick a list of commits too. Although I think
> > that git format-patch will reverse the order.
>
> Or "git show --pretty=email $commit1 $commit2" ... piped to "am"?
>
Does not work if there are ranges given :-/
It'd be very nice to have: git show #c1..$c2 $c3 $c4 $c5..$c6
^ permalink raw reply
* Re: multiple-commit cherry-pick?
From: Alex Riesen @ 2008-11-07 7:13 UTC (permalink / raw)
To: Miles Bader; +Cc: Linus Torvalds, git
In-Reply-To: <fc339e4a0811062038x22e7a3co503f09678f9ff5aa@mail.gmail.com>
Miles Bader, Fri, Nov 07, 2008 05:38:16 +0100:
> [git-am seems to have some similar features, but I don't know how well
> they work.]
They work well.
^ permalink raw reply
* Re: Setting Up a GIT Repository Mirror
From: Yaser Raja @ 2008-11-07 7:17 UTC (permalink / raw)
To: Santi Béjar; +Cc: git
In-Reply-To: <adf1fd3d0811060733t28008f0cld1a3b3c5bf4ff4d8@mail.gmail.com>
On Thu, Nov 6, 2008 at 8:33 PM, Santi Béjar <santi@agolina.net> wrote:
> On Thu, Nov 6, 2008 at 4:08 PM, Yaser Raja <yrraja@gmail.com> wrote:
>> Hi
> [...]
>
>> I came to know about --mirror option of git-clone and used it to make
>> a bare repository replica of the MainRep. Now i am not sure how to
>> keep it in sync with the MainRep.
>
> $ git fetch
>
> as it is bare you cannot merge, so you cannot pull.
>
> HTH,
> Santi
>
Here is what i get when i try to use git-fetch:
# git fetch
ssh: : Name or service not known
fatal: The remote end hung up unexpectedly
Following is the current content of my config file:
[core]
repositoryformatversion = 0
filemode = true
bare = true
[remote "origin"]
url = ssh://gituser@<addr removed>
fetch = +refs/*:refs/*
mirror = yes
I also tried git-fetch with the url as argument but that also gave the
same error. Do i need to do some additional configurations to make
fetch work?
Thanks
Yaser
^ permalink raw reply
* Re: [PATCH v2 3/3] pack-objects: honor '.keep' files
From: Andreas Ericsson @ 2008-11-07 8:12 UTC (permalink / raw)
To: Brandon Casey
Cc: Junio C Hamano, Git Mailing List, Shawn O. Pearce, Nicolas Pitre
In-Reply-To: <BgEXN35P6wpio928OZi_34hs22vqUQxIAIGxR5hR8LqmfPIyw565Mg@cipher.nrlssc.navy.mil>
Brandon Casey wrote:
> Junio C Hamano wrote:
>> Brandon Casey <casey@nrlssc.navy.mil> writes:
>>
>>> <-a>
>>> -create a new pack containing all objects required by the repository
>>> including those accessible through alternates, but excluding objects
>>> in _local_ packs with .keep
>> I have a feeling that it is debatable if this "fattening to dissociate
>> from alternates" is what people want.
>
> I'm not sure I understand you here.
>
> Andreas has suggested previously that 'repack -a' should pack everything,
> including objects in packs with .keep. Is that what you mean?
>
> With my current understanding it seems that that would muddy the semantics
> of repack. If -a does not honor packs with .keep, then would it be intuitive
> to expect that adding -l (i.e. exclude alternate packed objects) _would_
> honor .keep?
>
Only -d should honor .keep, imo. .keep-files is nothing about "don't copy
objects from this file" and all about "never delete this file".
The only muddying comes from you, who decided that .keep-files should
have impact on anything else than deleting the protected pack. Before that,
.keep files had a clear semantic, and repack's documentation was correct.
How do you explain .keep-files now? "protects pack-files that will forever
be used"? Then why the hell is it called ".keep" instead of "eternal"?
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH 1/4] pack-objects: new option --honor-pack-keep
From: Andreas Ericsson @ 2008-11-07 8:13 UTC (permalink / raw)
To: Brandon Casey
Cc: Junio C Hamano, Git Mailing List, Shawn O. Pearce, Nicolas Pitre
In-Reply-To: <oDevG_2ETMLvy6rfSqvxfmFqABeVqlDUcU6FjP07E5IzqLaopWkQbQ@cipher.nrlssc.navy.mil>
Brandon Casey wrote:
> This adds a new option to pack-objects which will cause it to ignore an
> object which appears in a local pack which has a .keep file, even if it
> was specified for packing.
>
> This option will be used by the porcelain repack.
>
> Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
> ---
>
>
> This series replaces the previous series starting at
> 6ee726bc "pack-objects: honor '.keep' files"
>
> It should be applied on top of
> f34cf12d "packed_git: convert pack_local flag into a bitfield and add pack_keep"
>
> I created the series on top of f34cf12d rebased on top of master.
>
> Suggestions for a more appropriate name for --honor-pack-keep are very welcome.
>
> -brandon
>
>
> Documentation/git-pack-objects.txt | 5 +++++
> builtin-pack-objects.c | 7 +++++++
> 2 files changed, 12 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/git-pack-objects.txt b/Documentation/git-pack-objects.txt
> index 8c354bd..f9fac2c 100644
> --- a/Documentation/git-pack-objects.txt
> +++ b/Documentation/git-pack-objects.txt
> @@ -109,6 +109,11 @@ base-name::
> The default is unlimited, unless the config variable
> `pack.packSizeLimit` is set.
>
> +--honor-pack-keep::
> + This flag causes an object already in a local pack that
> + has a .keep file to be ignored, even if it appears in the
> + standard input.
> +
Keep-files are *always* honored. Make this option "--ignore-kept" or
something instead, otherwise people will see the synopsis and think
they need to always pass it to not remove .keep-protected packs,
which is stupid.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH 2/4] repack: don't repack local objects in packs with .keep file
From: Andreas Ericsson @ 2008-11-07 8:14 UTC (permalink / raw)
To: Brandon Casey
Cc: Junio C Hamano, Git Mailing List, Shawn O. Pearce, Nicolas Pitre
In-Reply-To: <P5afFyDEMjF9ynd9dfSfGeRo_GFY_K6ZAn2nIYo8_xGgSl4LapbSOA@cipher.nrlssc.navy.mil>
Brandon Casey wrote:
> If the user created a .keep file for a local pack, then it can be inferred
> that the user does not want those objects repacked.
>
I disagree. It can be inferred that the user doesn't want those packfiles
*removed*.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ 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