* Re: Can Git push only first parent history commits?
From: Matthieu Moy @ 2008-12-08 7:44 UTC (permalink / raw)
To: Li Frank; +Cc: Junio C Hamano, git
In-Reply-To: <402F4B33D9C9DE4083DB96B416549FAF9E2D@zch01exm23.fsl.freescale.net>
"Li Frank" <Frank.Li@freescale.com> writes:
> I don't know the detail of git internal. Or my email subject
> description have some problem.
>
> I just want to combine some commits to one commit and push combined
> commit to remote. And at same time, keep commits history at my local
> repository. Rebase will make original history lost.
git merge --squash may help.
--
Matthieu
^ permalink raw reply
* RE: How to config git-daemon?
From: LIU JIN-YU-KFQP84 @ 2008-12-08 7:36 UTC (permalink / raw)
To: Ren LingYan-E5949C, git
In-Reply-To: <D13CA5792E8D5140A50EEDB89972CDCB053E21AA@zmy16exm63.ds.mot.com>
Hi,
Try to check if GIT_PROXY_COMMAND is set and your proxy can accept
internal address.
Regards
Simon Liu
-----Original Message-----
From: git-owner@vger.kernel.org [mailto:git-owner@vger.kernel.org] On
Behalf Of Ren LingYan-E5949C
Sent: Monday, December 08, 2008 2:28 PM
To: git@vger.kernel.org
Subject: How to config git-daemon?
Hello,
I want to public my repository testproject, which can be accessed by git
protocol.
My steps are as below:
On Server machine (for example 10.194.66.71) 1. Created testproject
under /home/e5949c/repositories 2. Created a file "git-daemon-export-ok"
under testproject/ .git directory.
3. Run command "git daemon --verbose --export-all"
On test machine
1. Run command "git clone
git://10.194.66.71/home/e5949c/repositories/testproject.git". Error as
below :
Initialized empty Git repository in
/export/home/e5949c/repositories/test/testproject/.git/
fatal: The remote end hung up unexpectedly
Can anyone help me on this error? What did I miss ?
Your help will be highly appreciated !
Thanks,
Emily
^ permalink raw reply
* Re: [PATCH 2/3] diff: allow turning on textconv explicitly for plumbing
From: Jeff King @ 2008-12-08 7:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vskoz88g8.fsf@gitster.siamese.dyndns.org>
On Sun, Dec 07, 2008 at 10:52:39PM -0800, Junio C Hamano wrote:
> > Right. _If_ it's a change that won't upset any plumbing consumers. If it
> > is, then it needs to be a separate option so that the plumbing consumers
> > who don't mind the change can start using it.
>
> In the above argument, you are assuming that you can have a complete
> enumeration of "plumbing consumers", so that we can tell what kind of
> changes to textconv output do affect them in a negative way, and what kind
> of changes are safe.
No, I'm assuming we have an idea of what is a "reasonable" change to the
feature that won't break consumers, and what is a change that will
break them. And it's the same judgement we have to make all the time
when thinking about how changes will impact the scriptable interface.
And furthermore, I'm proposing to take the safest path, which is to
say that the scriptable interface _doesn't_ change unless each consumer
decides to ask it to do so. That is, the output of "git diff-tree" is
unchanged unless the caller explicitly allows textconv. So now we have
given a meaning to "--textconv". If you want a _new_ textconv variant
(let's say you want it to output the textconv patch with some "this
isn't a real patch" munging, and also include the binary patch -- which
would make it both human readable and applicable), then I think it is
safe to say that is an incompatible change. And it gets called
--textconv-with-patch or whatever, and porcelain can move to it by
default. But the plumbing consumers still get the same thing via
--textconv, and they can opt into the new format if that is useful to
them.
So uptake of the new feature is slower (you have to wait for the
maintainer of the script to support it) but you never break
compatibility.
> Yes, you can enumerate in-tree consumers, but that misses the whole point
> of having "plumbing", which can be used by any scripts out of tree and
> they can rely on stable output from the plumbing. By giving --textconv to
> them to use with the plumbing, you are effecively casting textconv output
> in stone. By definition we will never know what kind of changes to the
> output from the textconv filter out of tree consumers would mind.
Right. But we _have_ to cast it in stone if we want to make it available
to them at all. So I am proposing to give what exists now a name, and
further enhancements will have to have a different name.
If you want to argue that it is too early to cast in stone, since we
will have to carry around this implementation and the name "--textconv"
forever, then I can accept that. But it is a bit annoying, since I want
to use it in gitk _now_. :)
But I do run 'next' usually, so maybe it is worth pushing it off until
the next release cycle.
> In any case, I've applied the series for an entirely different reason.
> The patch is the most natural way to allow users of Porcelain to disable
> textconv with the --no-textconv option, just like --no-ext-diff can be
> used to disable the external diff.
Yes, I agree that is worthwhile and should have been there since the
beginning (and I think should definitely ship in 1.6.1).
> We _might_ want to add another patch to make the plumbing layer ignore (or
> error out) --textconv option given from the command line before 1.6.1
> ships, and after we gain confidence with the stability of the feature,
> revert that patch to allow use of --textconv freely from the plumbing.
If you want to do that, the simplest thing is to simply take the
"--no-textconv" part of 2/3 and drop the rest. There is not really any
point in supporting --textconv just for porcelain, which already has it
on by default.
-Peff
^ permalink raw reply
* Re: [PATCH 2/3] diff: allow turning on textconv explicitly for plumbing
From: Junio C Hamano @ 2008-12-08 6:52 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20081208045924.GA22780@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
>> You can certainly argue that this "textconv" feature that is grafted from
>> Porcelain into plumbing is a special case in that its output is subject to
>> change any time to help human consumption and we never strive for its
>> stability as we do for other features in the plumbing to support machine
>> readability by scripts. You can propagate the later enhancement of
>> textconv diff output we'd make for Porcelain to the scripted users that
>> reads from the plumbing that way.
>
> Right. _If_ it's a change that won't upset any plumbing consumers. If it
> is, then it needs to be a separate option so that the plumbing consumers
> who don't mind the change can start using it.
In the above argument, you are assuming that you can have a complete
enumeration of "plumbing consumers", so that we can tell what kind of
changes to textconv output do affect them in a negative way, and what kind
of changes are safe.
Yes, you can enumerate in-tree consumers, but that misses the whole point
of having "plumbing", which can be used by any scripts out of tree and
they can rely on stable output from the plumbing. By giving --textconv to
them to use with the plumbing, you are effecively casting textconv output
in stone. By definition we will never know what kind of changes to the
output from the textconv filter out of tree consumers would mind.
Currently "diff" machinery uses the output of textconv filter as-is
without any further embellishment, but I think it is too early to tell if
that is really what we would want, or we may need some minimum
postprocessing on what we receive from the textconv filter before feeding
that to the textual diff machinery, because the feature has not been used
in the field at all yet.
In any case, I've applied the series for an entirely different reason.
The patch is the most natural way to allow users of Porcelain to disable
textconv with the --no-textconv option, just like --no-ext-diff can be
used to disable the external diff.
We _might_ want to add another patch to make the plumbing layer ignore (or
error out) --textconv option given from the command line before 1.6.1
ships, and after we gain confidence with the stability of the feature,
revert that patch to allow use of --textconv freely from the plumbing.
It always is easier to introduce a new feature in a more limited form and
then later loosen it, than adding it in an unrestricted form and having
later to limit it for whatever reason.
^ permalink raw reply
* How to config git-daemon?
From: Ren LingYan-E5949C @ 2008-12-08 6:27 UTC (permalink / raw)
To: git
Hello,
I want to public my repository testproject, which can be accessed by git
protocol.
My steps are as below:
On Server machine (for example 10.194.66.71) 1. Created testproject
under /home/e5949c/repositories 2. Created a file "git-daemon-export-ok"
under testproject/ .git directory.
3. Run command "git daemon --verbose --export-all"
On test machine
1. Run command "git clone
git://10.194.66.71/home/e5949c/repositories/testproject.git". Error as
below :
Initialized empty Git repository in
/export/home/e5949c/repositories/test/testproject/.git/
fatal: The remote end hung up unexpectedly
Can anyone help me on this error? What did I miss ?
Your help will be highly appreciated !
Thanks,
Emily
^ permalink raw reply
* [PATCH v2] git-svn: Make following parents atomic
From: Deskin Miller @ 2008-12-08 6:20 UTC (permalink / raw)
To: git; +Cc: normalperson, gitster, Deskin Miller
In-Reply-To: <20081207222444.GA10881@euler>
find_parent_branch generates branch@rev type branches when one has to
look back through SVN history to properly get the history for a branch
copied from somewhere not already being tracked by git-svn. If in the
process of fetching this history, git-svn is interrupted, then when one
fetches again, it will use whatever was last fetched as the parent
commit and fail to fetch any more history which it didn't get to before
being terminated. This is especially troubling in that different
git-svn copies of the same SVN repository can end up with different
commit sha1s, incorrectly showing the history as divergent and
precluding easy collaboration using git push and fetch.
To fix this, when we initialise the Git::SVN object $gs to search for
and perhaps fetch history, we check if there are any commits in SVN in
the range between the current revision $gs is at, and the top revision
for which we were asked to fill history. If there are commits we're
missing in that range, we continue the fetch from the current revision
to the top, properly getting all history before using it as the parent
for the branch we're trying to create.
Signed-off-by: Deskin Miller <deskinm@umich.edu>
---
Fixes the bug I found after sending v1. I squashed in a check for it
into the testcase; if it's preferable I can split it into its own
testcase (this one runs quite long as-is).
Deskin Miller
git-svn.perl | 16 ++++++++++---
t/t9104-git-svn-follow-parent.sh | 43 ++++++++++++++++++++++++++++++++++++++
2 files changed, 55 insertions(+), 4 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 56238da..25ed2f4 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -2318,12 +2318,20 @@ sub find_parent_branch {
$gs = Git::SVN->init($u, $p, $repo_id, $ref_id, 1);
}
my ($r0, $parent) = $gs->find_rev_before($r, 1);
- if (!defined $r0 || !defined $parent) {
- my ($base, $head) = parse_revision_argument(0, $r);
- if ($base <= $r) {
+ {
+ my ($base, $head);
+ if (!defined $r0 || !defined $parent) {
+ ($base, $head) = parse_revision_argument(0, $r);
+ } else {
+ if ($r0 < $r) {
+ $gs->ra->get_log([$gs->{path}], $r0 + 1, $r, 1,
+ 0, 1, sub { $base = $_[1] - 1 });
+ }
+ }
+ if (defined $base && $base <= $r) {
$gs->fetch($base, $r);
}
- ($r0, $parent) = $gs->last_rev_commit;
+ ($r0, $parent) = $gs->find_rev_before($r, 1);
}
if (defined $r0 && defined $parent) {
print STDERR "Found branch parent: ($self->{ref_id}) $parent\n";
diff --git a/t/t9104-git-svn-follow-parent.sh b/t/t9104-git-svn-follow-parent.sh
index 4d964e2..45138a2 100755
--- a/t/t9104-git-svn-follow-parent.sh
+++ b/t/t9104-git-svn-follow-parent.sh
@@ -149,6 +149,49 @@ test_expect_success "track initial change if it was only made to parent" '
"`git rev-parse r9270-d~1`"
'
+test_expect_success "follow-parent is atomic" '
+ cd wc &&
+ svn up &&
+ svn mkdir stunk &&
+ cd stunk &&
+ echo "trunk stunk" > readme &&
+ svn add readme &&
+ cd .. &&
+ svn ci -m "trunk stunk" &&
+ echo "stunk like junk" >> stunk/readme &&
+ svn ci -m "really stunk" &&
+ echo "stink stank stunk" >> stunk/readme &&
+ svn ci -m "even the grinch agrees" &&
+ cd .. &&
+ svn copy -m "stunk flunked" "$svnrepo"/stunk "$svnrepo"/flunk &&
+ (svn cp -m "early stunk flunked too" \
+ "$svnrepo"/stunk@17 "$svnrepo"/flunked ||
+ svn cp -m "early stunk flunked too" \
+ -r17 "$svnrepo"/stunk "$svnrepo"/flunked) &&
+ git svn init --minimize-url -i stunk "$svnrepo"/stunk &&
+ git svn fetch -i stunk &&
+ git update-ref refs/remotes/flunk@18 refs/remotes/stunk~2 &&
+ git update-ref -d refs/remotes/stunk &&
+ git config --unset svn-remote.svn.fetch stunk &&
+ mkdir -p "$GIT_DIR"/svn/flunk@18 &&
+ rev_map=$(cd "$GIT_DIR"/svn/stunk && ls .rev_map*) &&
+ dd if="$GIT_DIR"/svn/stunk/$rev_map \
+ of="$GIT_DIR"/svn/flunk@18/$rev_map bs=24 count=1 &&
+ rm -rf "$GIT_DIR"/svn/stunk &&
+ git svn init --minimize-url -i flunk "$svnrepo"/flunk &&
+ git svn fetch -i flunk &&
+ git svn init --minimize-url -i stunk "$svnrepo"/stunk &&
+ git svn fetch -i stunk &&
+ git svn init --minimize-url -i flunked "$svnrepo"/flunked &&
+ git svn fetch -i flunked
+ test "`git rev-parse --verify refs/remotes/flunk@18`" \
+ = "`git rev-parse --verify refs/remotes/stunk`" &&
+ test "`git rev-parse --verify refs/remotes/flunk~1`" \
+ = "`git rev-parse --verify refs/remotes/stunk`" &&
+ test "`git rev-parse --verify refs/remotes/flunked~1`" \
+ = "`git rev-parse --verify refs/remotes/stunk~1`"
+ '
+
test_expect_success "track multi-parent paths" '
svn cp -m "resurrect /glob" "$svnrepo"/r9270 "$svnrepo"/glob &&
git-svn multi-fetch &&
--
1.6.1.rc1.45.g123ed
^ permalink raw reply related
* Re: [PATCH 2/3] diff: allow turning on textconv explicitly for plumbing
From: Jeff King @ 2008-12-08 4:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfxkz9v8f.fsf@gitster.siamese.dyndns.org>
On Sun, Dec 07, 2008 at 07:55:12PM -0800, Junio C Hamano wrote:
> But I am not 100% sure if the scripting part is "the right way".
>
> If a script wants to take whatever Porcelain users are happy as the
> "presentation for human consumption" and pass that through as its own
> output to the end user, maybe it is better off reading from Porcelain,
> instead of reading from the plumbing (the latter of which requires making
> the plumbing output less reliable)?
But I don't think having gitk call the porcelain makes sense, either.
That would enable, for example, external diff drivers which might
actually spawn an entirely new window. And I don't think most people
would want that from gitk.
Now, obviously it could call "git diff --no-ext-diff" to opt out of
that. But I think it is backwards to call porcelain but opt out of
features that you don't want. It makes more sense to start with the bare
minimum (i.e., plumbing) and opt in to features that you are OK with.
And yes, you increase the risk that a script which blindly passes
options to plumbing may now be asked to generate a textconv'd diff which
will be useless to the user. But:
1. that is already a risk with --ext-diff
2. it is actually a _feature_. It is asking the user to say "is this
a sane option to pass for my situation or not" instead of forcing
the script to make that decision.
> When we later enhance textconv output from the "diff" Porcelain to
> benefit interactive users, it will automatically help the script that
> passes through the "diff" output to the end users.
I'm not sure what enhancement you mean. But it is possible that gitk
would not _want_ such an enhancement, and it would then have to opt out
of it.
> You can certainly argue that this "textconv" feature that is grafted from
> Porcelain into plumbing is a special case in that its output is subject to
> change any time to help human consumption and we never strive for its
> stability as we do for other features in the plumbing to support machine
> readability by scripts. You can propagate the later enhancement of
> textconv diff output we'd make for Porcelain to the scripted users that
> reads from the plumbing that way.
Right. _If_ it's a change that won't upset any plumbing consumers. If it
is, then it needs to be a separate option so that the plumbing consumers
who don't mind the change can start using it.
> But then wouldn't it be the same for these scripts that do value the
> "presentation meant for human consumption" over "machine readability" to
> read from Porcelain? That would not have to blur the distinction between
> the Porcelain and plumbing like the approach you are suggesting here.
I don't agree that this is blurring the distinction. I don't see
textconv diffs as a "porcelain feature" that has been grafted on to
plumbing. I see it as a core diff feature which can be turned off or on.
Porcelain has it on by default, and plumbing has it off by default. But
you can ask either to change their default settings[1].
-Peff
[1]: You can argue that the current implementation is buggy in this
sense, though, since some porcelains will accept "--textconv" but not
change their behavior. I think blame, for example, will have that
problem, because it accepts diff options but does not necessarily use
them to create diffs. But I think that just means we have a bug and
eventually should handle the case of "git blame --textconv" correctly.
^ permalink raw reply
* Re: [PATCH 2/3] diff: allow turning on textconv explicitly for plumbing
From: Junio C Hamano @ 2008-12-08 4:08 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <7vfxkz9v8f.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Jeff King <peff@peff.net> writes:
>
>> I know this is not strictly a bugfix and we are in -rc, but:
>>
>> 1. It is an enhancement to a previously unreleased feature, and
>> shouldn't affect anything outside of that.
>>
>> 2. It affects the scripting interface to textconv, so I would like to
>> get it in before textconv is ever released so that it is always the
>> "right way" to turn text conversion off or on.
>
> I'd agree with #1, especially if you said "doesn't" instead of
> "shouldn't".
>
> But I am not 100% sure if the scripting part is "the right way".
But I'll apply them anyway.
^ permalink raw reply
* Re: Can Git push only first parent history commits?
From: Boyd Stephen Smith Jr. @ 2008-12-08 4:03 UTC (permalink / raw)
To: git; +Cc: Li Frank
In-Reply-To: <402F4B33D9C9DE4083DB96B416549FAF9E12@zch01exm23.fsl.freescale.net>
[-- Attachment #1: Type: text/plain, Size: 1230 bytes --]
On Sunday 07 December 2008, "Li Frank" <Frank.Li@freescale.com> wrote
about 'Can Git push only first parent history commits?':
> The commit history is:
> origin/master
> Commit1..Commit2..Commit3(T1 branch).
>
> I want to combined Commit1, Commit2 and Commit3 to one commit_X
>and push to origin master and keep old T1 branch history. So I can't
>use rebase. T1 branch history will be lost after rebase.
I'm pretty sure you want to do something like this:
git branch T2 T1
git rebase -i master T2
# Editor opens
# Edit commit list to squash 3 commits into 1.
git push origin T2:master
git fetch origin
At the end, you'll have a history that looks like:
*--> origin/master (T2)
\
-> C1 --> C2 --> C3 (T1)
I'm not sure why you'd want to do this though. If the commits don't stand
alone well, they should be squashed on T1 before pushing. If the commits
do stand alone well, the history should preserve them on master as well.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss03@volumehost.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.org/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 2/3] diff: allow turning on textconv explicitly for plumbing
From: Junio C Hamano @ 2008-12-08 3:55 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20081208025700.GB22072@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> I know this is not strictly a bugfix and we are in -rc, but:
>
> 1. It is an enhancement to a previously unreleased feature, and
> shouldn't affect anything outside of that.
>
> 2. It affects the scripting interface to textconv, so I would like to
> get it in before textconv is ever released so that it is always the
> "right way" to turn text conversion off or on.
I'd agree with #1, especially if you said "doesn't" instead of
"shouldn't".
But I am not 100% sure if the scripting part is "the right way".
If a script wants to take whatever Porcelain users are happy as the
"presentation for human consumption" and pass that through as its own
output to the end user, maybe it is better off reading from Porcelain,
instead of reading from the plumbing (the latter of which requires making
the plumbing output less reliable)?
When we later enhance textconv output from the "diff" Porcelain to benefit
interactive users, it will automatically help the script that passes
through the "diff" output to the end users.
You can certainly argue that this "textconv" feature that is grafted from
Porcelain into plumbing is a special case in that its output is subject to
change any time to help human consumption and we never strive for its
stability as we do for other features in the plumbing to support machine
readability by scripts. You can propagate the later enhancement of
textconv diff output we'd make for Porcelain to the scripted users that
reads from the plumbing that way.
But then wouldn't it be the same for these scripts that do value the
"presentation meant for human consumption" over "machine readability" to
read from Porcelain? That would not have to blur the distinction between
the Porcelain and plumbing like the approach you are suggesting here.
^ permalink raw reply
* RE: Can Git push only first parent history commits?
From: Li Frank @ 2008-12-08 3:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7i6bbcc6.fsf@gitster.siamese.dyndns.org>
I don't know the detail of git internal. Or my email subject
description have some problem.
I just want to combine some commits to one commit and push combined
commit to remote. And at same time, keep commits history at my local
repository. Rebase will make original history lost.
-----Original Message-----
From: Junio C Hamano [mailto:gitster@pobox.com]
Sent: Monday, December 08, 2008 11:00 AM
To: Li Frank-B20596
Cc: git@vger.kernel.org
Subject: Re: Can Git push only first parent history commits?
Your drawing nor explanation unfortunately does not make much sense to
me, so I'll respond only to the subject.
Pushing only first parent history would mean that the commits you will
be transferring will still record their true parents, but you are not
sending any parents but the first ones. The repository that receives
such a push would not pass fsck, in other words, you are deliberately
corrupting the repository.
Naturally we won't support such an operation by default.
It is plausible that you can implement an option to do so, but it would
make it hard at the receiving end to tell between a true repository
corruption and a corruption you are deliberately introducing by such a
push, so it won't be useful unless accompanied by a corresponding option
to fsck to make it not complain when parent commits and associated
objects that are not necessary for first parent history.
^ permalink raw reply
* [gitk PATCH 3/3] gitk: allow text-conversion in diffs
From: Jeff King @ 2008-12-08 3:00 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Junio C Hamano, git
The "textconv" feature of git requires explicit enabling in
plumbing because the resulting diffs are not useful for
feeding to "git-apply" or "patch". Thus any callers should
make a conscious choice that they want the human-friendly
version.
Since the diffs presented by gitk are meant primarily for
human consumption, and not applying, it makes sense to allow
text conversion.
---
Paul,
I am cc'ing you only on 3/3 since it is the only gitk patch (the others
implement --textconv in git itself). Textconv is basically a feature to
show human-readable text diffs of binary files by doing a one-way binary
to text conversion (and so they can't be applied).
I think gitk would always want to support these; if not, then the
alternative is a "diff flags" option for gitk where the user could
specify this flag manually.
gitk | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/gitk b/gitk
index a5e24e4..0fb87c7 100755
--- a/gitk
+++ b/gitk
@@ -7198,7 +7198,7 @@ proc getblobdiffs {ids} {
global limitdiffs vfilelimit curview
global diffencoding targetline diffnparents
- set cmd [diffcmd $ids "-p -C --cc --no-commit-id -U$diffcontext"]
+ set cmd [diffcmd $ids "-p -C --cc --no-commit-id -U$diffcontext --textconv"]
if {$ignorespace} {
append cmd " -w"
}
--
1.6.1.rc2.285.gc1cf2
^ permalink raw reply related
* Re: Can Git push only first parent history commits?
From: Junio C Hamano @ 2008-12-08 3:00 UTC (permalink / raw)
To: Li Frank; +Cc: git
In-Reply-To: <402F4B33D9C9DE4083DB96B416549FAF9E12@zch01exm23.fsl.freescale.net>
Your drawing nor explanation unfortunately does not make much sense to me,
so I'll respond only to the subject.
Pushing only first parent history would mean that the commits you will be
transferring will still record their true parents, but you are not sending
any parents but the first ones. The repository that receives such a push
would not pass fsck, in other words, you are deliberately corrupting the
repository.
Naturally we won't support such an operation by default.
It is plausible that you can implement an option to do so, but it would
make it hard at the receiving end to tell between a true repository
corruption and a corruption you are deliberately introducing by such a
push, so it won't be useful unless accompanied by a corresponding option
to fsck to make it not complain when parent commits and associated objects
that are not necessary for first parent history.
^ permalink raw reply
* [PATCH 2/3] diff: allow turning on textconv explicitly for plumbing
From: Jeff King @ 2008-12-08 2:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Some history viewers use the diff plumbing to generate diffs
rather than going through the "git diff" porcelain.
Currently, there is no way for them to specify that they
would like to see the text-converted version of the diff.
This patch adds a "--textconv" option to allow such a
plumbing user to allow text conversion. The user can then
tell the viewer whether or not they would like text
conversion enabled.
While it may be tempting add a configuration option rather
than requiring each plumbing user to be configured to pass
--textconv, that is somewhat dangerous. Text-converted diffs
generally cannot be applied directly, so each plumbing user
should "opt in" to generating such a diff, either by
explicit request of the user or by confirming that their
output will not be fed to patch.
Signed-off-by: Jeff King <peff@peff.net>
---
My ultimate goal is to see these diffs in gitk, which is implemented in
3/3. As a bonus side effect, the --no-textconv option can be used with
"git diff" or "git log" if you really don't want to see them there
(e.g., because you are abusing "git log" to produce a binary patch you
mean to apply).
I know this is not strictly a bugfix and we are in -rc, but:
1. It is an enhancement to a previously unreleased feature, and
shouldn't affect anything outside of that.
2. It affects the scripting interface to textconv, so I would like to
get it in before textconv is ever released so that it is always the
"right way" to turn text conversion off or on.
diff.c | 4 ++++
diff.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/diff.c b/diff.c
index f644947..e21af3b 100644
--- a/diff.c
+++ b/diff.c
@@ -2477,6 +2477,10 @@ int diff_opt_parse(struct diff_options *options, const char **av, int ac)
DIFF_OPT_SET(options, ALLOW_EXTERNAL);
else if (!strcmp(arg, "--no-ext-diff"))
DIFF_OPT_CLR(options, ALLOW_EXTERNAL);
+ else if (!strcmp(arg, "--textconv"))
+ DIFF_OPT_SET(options, ALLOW_TEXTCONV);
+ else if (!strcmp(arg, "--no-textconv"))
+ DIFF_OPT_CLR(options, ALLOW_TEXTCONV);
else if (!strcmp(arg, "--ignore-submodules"))
DIFF_OPT_SET(options, IGNORE_SUBMODULES);
--
1.6.1.rc2.285.gc1cf2
^ permalink raw reply related
* [PATCH 1/3] reorder ALLOW_TEXTCONV option setting
From: Jeff King @ 2008-12-08 2:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Right now for the diff porcelain and the log family, we
call:
init_revisions();
setup_revisions();
DIFF_OPT_SET(ALLOW_TEXTCONV);
However, that means textconv will _always_ be on, instead of
being a default that can be manipulated with
setup_revisions. Instead, we want:
init_revisions();
DIFF_OPT_SET(ALLOW_TEXTCONV);
setup_revisions();
which is what this patch does.
We'll go ahead and move the callsite in wt-status, also;
even though the user can't pass any options here, it is a
cleanup that will help avoid any surprise later if the
setup_revisions line is changed.
Signed-off-by: Jeff King <peff@peff.net>
---
This is a "bug fix" in the sense that the code does not match the
original intent (which was to set a default for these porcelains). But
you can't _trigger_ the bug since setup_revisions never munges the value
(but it will in 2/3).
builtin-diff.c | 4 ++--
builtin-log.c | 2 +-
wt-status.c | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/builtin-diff.c b/builtin-diff.c
index dddcf69..d75d69b 100644
--- a/builtin-diff.c
+++ b/builtin-diff.c
@@ -290,8 +290,9 @@ int cmd_diff(int argc, const char **argv, const char *prefix)
/* Otherwise, we are doing the usual "git" diff */
rev.diffopt.skip_stat_unmatch = !!diff_auto_refresh_index;
- /* Default to let external be used */
+ /* Default to let external and textconv be used */
DIFF_OPT_SET(&rev.diffopt, ALLOW_EXTERNAL);
+ DIFF_OPT_SET(&rev.diffopt, ALLOW_TEXTCONV);
if (nongit)
die("Not a git repository");
@@ -303,7 +304,6 @@ int cmd_diff(int argc, const char **argv, const char *prefix)
}
DIFF_OPT_SET(&rev.diffopt, RECURSIVE);
- DIFF_OPT_SET(&rev.diffopt, ALLOW_TEXTCONV);
/*
* If the user asked for our exit code then don't start a
diff --git a/builtin-log.c b/builtin-log.c
index b164717..840daf9 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -37,6 +37,7 @@ static void cmd_log_init(int argc, const char **argv, const char *prefix,
DIFF_OPT_SET(&rev->diffopt, RECURSIVE);
rev->show_root_diff = default_show_root;
rev->subject_prefix = fmt_patch_subject_prefix;
+ DIFF_OPT_SET(&rev->diffopt, ALLOW_TEXTCONV);
if (default_date_mode)
rev->date_mode = parse_date_format(default_date_mode);
@@ -60,7 +61,6 @@ static void cmd_log_init(int argc, const char **argv, const char *prefix,
} else
die("unrecognized argument: %s", arg);
}
- DIFF_OPT_SET(&rev->diffopt, ALLOW_TEXTCONV);
}
/*
diff --git a/wt-status.c b/wt-status.c
index 3edae43..96ff2f8 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -279,11 +279,11 @@ static void wt_status_print_verbose(struct wt_status *s)
struct rev_info rev;
init_revisions(&rev, NULL);
+ DIFF_OPT_SET(&rev.diffopt, ALLOW_TEXTCONV);
setup_revisions(0, NULL, &rev,
s->is_initial ? EMPTY_TREE_SHA1_HEX : s->reference);
rev.diffopt.output_format |= DIFF_FORMAT_PATCH;
rev.diffopt.detect_rename = 1;
- DIFF_OPT_SET(&rev.diffopt, ALLOW_TEXTCONV);
rev.diffopt.file = s->fp;
rev.diffopt.close_file = 0;
/*
--
1.6.1.rc2.285.gc1cf2
^ permalink raw reply related
* [ANNOUNCE] GIT 1.6.1-rc2
From: Junio C Hamano @ 2008-12-08 2:53 UTC (permalink / raw)
To: git; +Cc: linux-kernel
Another week, another rc. There are no outstanding features that should
graduate from 'next' anymore until final.
http://www.kernel.org/pub/software/scm/git/
git-1.6.1-rc2.tar.{gz,bz2} (source tarball)
git-htmldocs-1.6.1-rc2.tar.{gz,bz2} (preformatted docs)
git-manpages-1.6.1-rc2.tar.{gz,bz2} (preformatted docs)
The RPM binary packages for a few architectures are also there.
testing/git-*-1.6.1-rc2-1.fc9.$arch.rpm (RPM)
----------------------------------------------------------------
Changes since v1.6.1-rc1 are as follows:
Alex Riesen (3):
Make some of fwrite/fclose/write/close failures visible
Make chdir failures visible
Report symlink failures in merge-recursive
Alexander Gavrilov (2):
gitk: Make line origin search update the busy status
gitk: Add a menu option to start git gui
Christian Couder (2):
bisect: fix "git bisect skip <commit>" and add tests cases
Documentation: describe how to "bisect skip" a range of commits
Christian Stimming (1):
gitk: Update German translation
Davide Libenzi (1):
xdiff: give up scanning similar lines early
Deskin Miller (1):
git-svn: Make branch use correct svn-remote
Giuseppe Bilotta (2):
gitweb: make gitweb_check_feature a boolean wrapper
Update comment on gitweb_check/get_feature
Jakub Narebski (2):
gitweb: Fix handling of non-ASCII characters in inserted HTML files
gitweb: Make project specific override for 'grep' feature work
Jeff King (2):
add stage to gitignore
tag: delete TAG_EDITMSG only on successful tag
Johannes Sixt (1):
t4030-diff-textconv: Make octal escape sequence more portable
Junio C Hamano (17):
builtin-rm.c: explain and clarify the "local change" logic
git add --intent-to-add: fix removal of cached emptiness
git add --intent-to-add: do not let an empty blob be committed by accident
gitweb: fix 'ctags' feature check and others
gitweb: rename gitweb_check_feature to gitweb_get_feature
Makefile: introduce NO_PTHREADS
Install git-stage in exec-path
git-am --whitespace: do not lose the command line option
git-am: propagate -C<n>, -p<n> options as well
git-am: propagate --3way options as well
Test that git-am does not lose -C/-p/--whitespace options
git-am: rename apply_opt_extra file to apply-opt
Update draft release notes to 1.6.1
GIT 1.6.0.5
Update draft release notes for 1.6.1
Revert "git-stash: use git rev-parse -q"
Point "stale" 1.6.0.5 documentation from the main git documentation page
Linus Torvalds (1):
Add backslash to list of 'crud' characters in real name
Mark Burton (1):
git-gui: Teach start_push_anywhere_action{} to notice when remote is a mirror.
Matt McCutchen (1):
"git diff <tree>{3,}": do not reverse order of arguments
Miklos Vajna (8):
User's Manual: remove duplicated url at the end of Appendix B
git-stash: use git rev-parse -q
filter-branch: use git rev-parse -q
lost-found: use git rev-parse -q
pull: use git rev-parse -q
rebase: use git rev-parse -q
submodule: use git rev-parse -q
http.c: use 'git_config_string' to get 'curl_http_proxy'
Nguyễn Thái Ngọc Duy (1):
Extend index to save more flags
Paul Mackerras (3):
gitk: Fix context menu items for generating diffs when in tree mode
gitk: Highlight only when search type is "containing:".
gitk: Fix bug in accessing undefined "notflag" variable
Scott Chacon (1):
Add a built-in alias for 'stage' to the 'add' command
Thomas Rast (1):
fetch-pack: Avoid memcpy() with src==dst
Tor Arvid Lund (1):
git-p4: Fix bug in p4Where method.
^ permalink raw reply
* Can Git push only first parent history commits?
From: Li Frank @ 2008-12-08 2:52 UTC (permalink / raw)
To: git
The commit history is:
origin/master
Commit1..Commit2..Commit3(T1 branch).
I want to combined Commit1, Commit2 and Commit3 to one commit_X
and push to origin master and keep old T1 branch history. So I can't
use rebase. T1 branch history will be lost after rebase.
So I create T2 branch at origin/master:
origin/master
Commit1..Commit2..Commit3(T1 branch).
T2 (branch).
Then I use "git merge --no-ff --log T1" merge T1 to T2.
So
origin/master
+--Commit1..Commit2..Commit3(T1 branch). +
+----------------------------------------------------------------+--Comm
itX(T2 branch).
But when I push T2 to origin master, Commit1 ,2, 3 also pushed.
I expect there are only CommitX at origin master branch.
How can I do?
best regards
Frank Li
^ permalink raw reply
* Re: [PATCH] fetch-pack: Avoid memcpy() with src==dst
From: Junio C Hamano @ 2008-12-08 2:47 UTC (permalink / raw)
To: Thomas Rast; +Cc: git
In-Reply-To: <1228596609-12720-1-git-send-email-trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> memcpy() may only be used for disjoint memory areas, but when invoked
> from cmd_fetch_pack(), we have my_args == &args. (The argument cannot
> be removed entirely because transport.c invokes with its own
> variable.)
It makes me wonder if it might be a better fix to abolish the use of file
scoped global "args" and pass a pointer to "struct fetch_pack_args"
throughout the callchain instead.
In the current code, cmd_fetch_pack() is the only caller that passes &args
to this function, but it is not so implausible to have a future callchain
that makes two calls to cmd_fetch_pack(), perhaps implementing some sort
of alias to fetch from multiple places, would horribly break without such
a fix, because cmd_fetch_pack() assumes that args is in its pristine
state.
I'll apply this to 'maint' and merge it up, because the patch is
independent of the above issue.
Thanks.
^ permalink raw reply
* [PATCH] work around Python warnings from AsciiDoc
From: Junio C Hamano @ 2008-12-08 2:38 UTC (permalink / raw)
To: git
It appears that a reference to an anchor defined as [[anchor-name]] from
another place using <<anchor-name>> syntax, when the anchor name contains
a string "-with-" in its name, triggers these warnings from Python
interpreter.
asciidoc -b docbook -d book user-manual.txt
<string>:1: Warning: 'with' will become a reserved keyword in Python 2.6
<string>:1: Warning: 'with' will become a reserved keyword in Python 2.6
<string>:1: Warning: 'with' will become a reserved keyword in Python 2.6
<string>:1: Warning: 'with' will become a reserved keyword in Python 2.6
There currently is no reference to "Finding comments with given content",
but for consistency and for futureproofing, the anchor is also updated as
the other ones that are actually used and trigger these warnings.
Signed-off-by: Junio C Hamano <junio@pobox.com>
---
Documentation/user-manual.txt | 18 +++++++++---------
1 files changed, 9 insertions(+), 9 deletions(-)
diff --git c/Documentation/user-manual.txt w/Documentation/user-manual.txt
index 9f527d3..c0c2f8d 100644
--- c/Documentation/user-manual.txt
+++ w/Documentation/user-manual.txt
@@ -13,7 +13,7 @@ to build and test a particular version of a software project, search for
regressions, and so on.
People needing to do actual development will also want to read
-<<Developing-with-git>> and <<sharing-development>>.
+<<Developing-With-git>> and <<sharing-development>>.
Further chapters cover more specialized topics.
@@ -399,7 +399,7 @@ the order it uses to decide which to choose when there are multiple
references with the same shorthand name, see the "SPECIFYING
REVISIONS" section of linkgit:git-rev-parse[1].
-[[Updating-a-repository-with-git-fetch]]
+[[Updating-a-repository-With-git-fetch]]
Updating a repository with git-fetch
------------------------------------
@@ -955,7 +955,7 @@ echo "git diff --stat --summary -M v$last v$new > ../diffstat-$new"
and then he just cut-and-pastes the output commands after verifying that
they look OK.
-[[Finding-comments-with-given-content]]
+[[Finding-comments-With-given-Content]]
Finding commits referencing a file with given content
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -972,7 +972,7 @@ Figuring out why this works is left as an exercise to the (advanced)
student. The linkgit:git-log[1], linkgit:git-diff-tree[1], and
linkgit:git-hash-object[1] man pages may prove helpful.
-[[Developing-with-git]]
+[[Developing-With-git]]
Developing with git
===================
@@ -1675,7 +1675,7 @@ dangling objects can arise in other situations.
Sharing development with others
===============================
-[[getting-updates-with-git-pull]]
+[[getting-updates-With-git-pull]]
Getting updates with git-pull
-----------------------------
@@ -1683,7 +1683,7 @@ After you clone a repository and make a few changes of your own, you
may wish to check the original repository for updates and merge them
into your own work.
-We have already seen <<Updating-a-repository-with-git-fetch,how to
+We have already seen <<Updating-a-repository-With-git-fetch,how to
keep remote tracking branches up to date>> with linkgit:git-fetch[1],
and how to merge two branches. So you can merge in changes from the
original repository's master branch with:
@@ -1794,7 +1794,7 @@ Public git repositories
Another way to submit changes to a project is to tell the maintainer
of that project to pull the changes from your repository using
-linkgit:git-pull[1]. In the section "<<getting-updates-with-git-pull,
+linkgit:git-pull[1]. In the section "<<getting-updates-With-git-pull,
Getting updates with git-pull>>" we described this as a way to get
updates from the "main" repository, but it works just as well in the
other direction.
@@ -2004,7 +2004,7 @@ $ git push ssh://yourserver.com/~you/proj.git +master
Normally whenever a branch head in a public repository is modified, it
is modified to point to a descendant of the commit that it pointed to
before. By forcing a push in this situation, you break that convention.
-(See <<problems-with-rewriting-history>>.)
+(See <<problems-With-rewriting-history>>.)
Nevertheless, this is a common practice for people that need a simple
way to publish a work-in-progress patch series, and it is an acceptable
@@ -2573,7 +2573,7 @@ There are numerous other tools, such as StGIT, which exist for the
purpose of maintaining a patch series. These are outside of the scope of
this manual.
-[[problems-with-rewriting-history]]
+[[problems-With-rewriting-history]]
Problems with rewriting history
-------------------------------
^ permalink raw reply related
* [ANNOUNCE] GIT 1.6.0.5
From: Junio C Hamano @ 2008-12-08 2:13 UTC (permalink / raw)
To: git; +Cc: linux-kernel
The latest maintenance release GIT 1.6.0.5 is available at the
usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.6.0.5.tar.{gz,bz2} (source tarball)
git-htmldocs-1.6.0.5.tar.{gz,bz2} (preformatted docs)
git-manpages-1.6.0.5.tar.{gz,bz2} (preformatted docs)
The RPM binary packages for a few architectures are also provided
as courtesy.
RPMS/$arch/git-*-1.6.0.5-1.fc9.$arch.rpm (RPM)
Although we are into 1.6.1-rc cycle, we have accumulated enough fixes to
warrant a new maintenance release, so here it is.
----------------------------------------------------------------
GIT v1.6.0.5 Release Notes
==========================
Fixes since v1.6.0.4
--------------------
* "git checkout" used to crash when your HEAD was pointing at a deleted
branch.
* "git checkout" from an un-checked-out state did not allow switching out
of the current branch.
* "git diff" always allowed GIT_EXTERNAL_DIFF and --no-ext-diff was no-op for
the command.
* Giving 3 or more tree-ish to "git diff" is supposed to show the combined
diff from second and subsequent trees to the first one, but the order was
screwed up.
* "git fast-export" did not export all tags.
* "git ls-files --with-tree=<tree>" did not work with options other
than -c, most notably with -m.
* "git pack-objects" did not make its best effort to honor --max-pack-size
option when a single first object already busted the given limit and
placed many objects in a single pack.
* "git-p4" fast import frontend was too eager to trigger its keyword expansion
logic, even on a keyword-looking string that does not have closing '$' on the
same line.
* "git push $there" when the remote $there is defined in $GIT_DIR/branches/$there
behaves more like what cg-push from Cogito used to work.
* when giving up resolving a conflicted merge, "git reset --hard" failed
to remove new paths from the working tree.
* "git tag" did not complain when given mutually incompatible set of options.
* The message constructed in the internal editor was discarded when "git
tag -s" failed to sign the message, which was often caused by the user
not configuring GPG correctly.
* "make check" cannot be run without sparse; people may have meant to say
"make test" instead, so suggest that.
* Internal diff machinery had a corner case performance bug that choked on
a large file with many repeated contents.
* "git repack" used to grab objects out of packs marked with .keep
into a new pack.
* Many unsafe call to sprintf() style varargs functions are corrected.
* Also contains quite a few documentation updates.
----------------------------------------------------------------
Changes since v1.6.0.4 are as follows:
Alexandre Julliard (2):
checkout: Don't crash when switching away from an invalid branch.
git-submodule: Avoid printing a spurious message.
Brandon Casey (12):
t7700: demonstrate mishandling of objects in packs with a .keep file
packed_git: convert pack_local flag into a bitfield and add pack_keep
pack-objects: new option --honor-pack-keep
repack: don't repack local objects in packs with .keep file
repack: do not fall back to incremental repacking with [-a|-A]
builtin-gc.c: use new pack_keep bitfield to detect .keep file existence
t7700: demonstrate mishandling of loose objects in an alternate ODB
sha1_file.c: split has_loose_object() into local and non-local counterparts
pack-objects: extend --local to mean ignore non-local loose objects too
t7700: test that 'repack -a' packs alternate packed objects
repack: only unpack-unreachable if we are deleting redundant packs
revision.c: use proper data type in call to sizeof() within xrealloc
Bryan Drewery (1):
Fix misleading wording for git-cherry-pick
Christian Couder (3):
Documentation: rev-list: change a few instances of "git-cmd" to "git cmd"
Documentation: bisect: change a few instances of "git-cmd" to "git cmd"
Documentation: fix links to "everyday.html"
Daniel Lowe (1):
Fix non-literal format in printf-style calls
Davide Libenzi (1):
xdiff: give up scanning similar lines early
Jakub Narebski (1):
gitweb: Make project specific override for 'grep' feature work
Jan Krüger (1):
Documentation: git-svn: fix example for centralized SVN clone
Jeff King (2):
commit: Fix stripping of patch in verbose mode.
tag: delete TAG_EDITMSG only on successful tag
Joey Hess (1):
sha1_file: avoid bogus "file exists" error message
Johannes Schindelin (1):
fast-export: use an unsorted string list for extra_refs
Johannes Sixt (1):
compat/mingw.c: Teach mingw_rename() to replace read-only files
Junio C Hamano (8):
Makefile: help people who run 'make check' by mistake
checkout: Fix "initial checkout" detection
Start 1.6.0.5 cycle
builtin-ls-files.c: coding style fix.
Teach ls-files --with-tree=<tree> to work with options other than -c
Teach "git diff" to honour --[no-]ext-diff
Update draft release notes to 1.6.0.5
GIT 1.6.0.5
Linus Torvalds (1):
date/time: do not get confused by fractional seconds
Martin Koegler (1):
git push: Interpret $GIT_DIR/branches in a Cogito compatible way
Matt Kraai (1):
Remove the period after the git-check-attr summary
Matt McCutchen (3):
config.txt: alphabetize configuration sections
git checkout: don't warn about unborn branch if -f is already passed
"git diff <tree>{3,}": do not reverse order of arguments
Miklos Vajna (3):
Add new testcase to show fast-export does not always exports all tags
User's Manual: remove duplicated url at the end of Appendix B
http.c: use 'git_config_string' to get 'curl_http_proxy'
Nguyễn Thái Ngọc Duy (1):
generate-cmdlist.sh: avoid selecting synopsis at wrong place
Nicolas Pitre (1):
Fix pack.packSizeLimit and --max-pack-size handling
Pete Wyckoff (1):
git-p4: fix keyword-expansion regex
Ralf Wildenhues (1):
Fix typos in the documentation.
SZEDER Gábor (2):
bash: remove dashed command leftovers
bash: offer refs instead of filenames for 'git revert'
Sam Vilain (1):
sha1_file.c: resolve confusion EACCES vs EPERM
Samuel Tardieu (2):
tag: Check that options are only allowed in the appropriate mode
tag: Add more tests about mixing incompatible modes and options
Stefan Naewe (2):
git ls-remote: make usage string match manpage
request-pull: make usage string match manpage
Thomas Rast (1):
fetch-pack: Avoid memcpy() with src==dst
^ permalink raw reply
* Re: [PATCH] git-stash: use git rev-parse -q
From: Junio C Hamano @ 2008-12-08 1:42 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Miklos Vajna, git
In-Reply-To: <20081207231723.GA5068@atjola.homenet>
Thanks; I'll revert this one. Use of -q is simply not worth this
aggravation.
^ permalink raw reply
* Re: How to clone git repository with git-svn meta-data included?
From: Nick Andrew @ 2008-12-08 0:03 UTC (permalink / raw)
To: Jacob Helwig; +Cc: Grzegorz Kossakowski, git
In-Reply-To: <8c9a060812070043r472e10abu7a76152b5fe1314d@mail.gmail.com>
On Sun, Dec 07, 2008 at 12:43:32AM -0800, Jacob Helwig wrote:
> I use git-svn quite a bit at $work, but I haven't seen a way to clone
> a git repo, and have it Just Work(TM) with git-svn in the new clone,
> unfortunately.
At $work I nightly publish a .tar.gz file of a pristine git repo
synced from svn, with the metadata. So if a developer wants to start
using git they untar the file into their directory and start working,
and after that they have to do "git svn fetch" themselves.
Nick.
^ permalink raw reply
* Re: How to clone git repository with git-svn meta-data included?
From: Peter Harris @ 2008-12-07 23:51 UTC (permalink / raw)
To: Grzegorz Kossakowski; +Cc: git
In-Reply-To: <493C47FD.4080302@tuffmail.com>
On Sun, Dec 7, 2008 at 5:02 PM, Grzegorz Kossakowski wrote:
> Peter Harris pisze:
>> After the git clone, I do the following:
>> git svn init -s svn://repo/sitory
>> git svn rebase
>>
>> No data is transferred[1], although 'git svn rebase' does spend a
>> minute or so reading the commit messages to rebuild its index.
>
> I've tried this method with Cocoon repository
> (http://jukka.zitting.name/git/?p=cocoon.git;a=summary) and got this error:
>
> git clone git://jukka.zitting.name/cocoon.git
> git svn init -s https://svn.eu.apache.org/repos/asf/cocoon/
> git svn rebase
> Unable to determine upstream SVN information from working tree history
Odd. Usually that indicates a lack of metadata, but that repo appears
to contain the right stuff. Beats me.
Peter Harris
^ permalink raw reply
* Re: [PATCH] git-stash: use git rev-parse -q
From: Björn Steinbrink @ 2008-12-07 23:17 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Junio C Hamano, git
In-Reply-To: <1228179369-3766-1-git-send-email-vmiklos@frugalware.org>
On 2008.12.02 01:56:09 +0100, Miklos Vajna wrote:
> Don't redirect stderr to /dev/null, use -q to suppress the output on
> stderr.
>
> Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
> ---
>
> # clear_stash if we just dropped the last stash entry
> - git rev-parse --verify "$ref_stash@{0}" > /dev/null 2>&1 || clear_stash
> + git rev-parse -q --verify "$ref_stash@{0}" > /dev/null || clear_stash
This one causes an error message to pop up when the last stash entry is
dropped:
doener@atjola:git (master) $ echo 123 >> Makefile
doener@atjola:git (master) $ git stash
Saved working directory and index state "WIP on master: 2dd6202...
Update draft release notes to 1.6.1"
HEAD is now at 2dd6202 Update draft release notes to 1.6.1
(To restore them type "git stash apply")
doener@atjola:git (master) $ git stash drop
Dropped refs/stash@{0} (e692e43ce03fe0b5f0eb94123123ea61a0f2097a)
fatal: Log .git/logs/refs/stash is empty.
git version 1.6.1.rc1.56.g2dd62
After "git stash drop" finished the rev-parse won't complain anymore,
even if you recreate an empty .git/logs/refs/stash file, because
.git/refs/stash is also gone, and then it doesn't seem to care anymore.
But having a valid ref and an empty log makes it unhappy:
doener@atjola:git (master) $ git rev-parse HEAD > .git/refs/stash
doener@atjola:git (master) $ : > .git/logs/refs/stash
doener@atjola:git (master) $ git rev-parse -q --verify 'refs/stash@{1}'
fatal: Log .git/logs/refs/stash is empty.
Björn
^ permalink raw reply
* Re: [PATCH] git-svn: Make following parents atomic
From: Deskin Miller @ 2008-12-07 22:24 UTC (permalink / raw)
To: git; +Cc: normalperson, gitster
In-Reply-To: <1228665970-21204-1-git-send-email-deskinm@umich.edu>
On Sun, Dec 07, 2008 at 11:06:10AM -0500, Deskin Miller wrote:
> [...]
>
> To fix this, when we initialise the Git::SVN object $gs to search for
> and perhaps fetch history, we check if there are any commits in SVN in
> the range between the current revision $gs is at, and the top revision
> for which we were asked to fill history. If there are commits we're
> missing in that range, we continue the fetch from the current revision
> to the top, properly getting all history before using it as the parent
> for the branch we're trying to create.
On looking at the patch again, I think I might have introduced a bug:
it'll take the most commit on the parent branch, even if it was branched
from an earlier point. I'll spend more time looking at it and should
have a v2 in a day at most if I'm rigth, hopefully more like a few
hours.
Deskin Miller
^ 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