* Move-delete merge conflict is not displayed using git ls-files --unmerged
From: Constantine Plotnikov @ 2008-12-22 14:29 UTC (permalink / raw)
To: git
Lets consider repository state created with the following script (git
version 1.6.0.4).
mkdir test-move-delete
cd test-move-delete
git init
echo test1 >file.txt
echo test2 >>file.txt
echo test3 >>file.txt
echo test4 >>file.txt
git add file.txt
git commit -m "start"
git checkout -b moved master
git mv file.txt copy.txt
git commit -m "moved"
git checkout -b deleted master
git rm file.txt
git commit -m "deleted"
git merge moved
The last merge command fails with move-delete conflict.
CONFLICT (rename/delete): Renamed file.txt->copy.txt in moved and
deleted in HEAD
Automatic merge failed; fix conflicts and then commit the result.
However git ls-files --unmerged does not list any conflict in that
case and it is possible to execute git commit command right away
without doing anything with the repository.
I think that if git merge reports the conflicts, such conflicts should
be discoverable using git ls-files and prevent commit with resolving
the conflict like it is done with modify-delete conflicts.
Regards,
Constantine
^ permalink raw reply
* git 1.6.1-rc4 testing dependency
From: Peter van der Does @ 2008-12-22 16:05 UTC (permalink / raw)
To: git
With git 1.6.1 it it seems you need to install the locale en_US.UTF-8
otherwise it won't pass the testing during building the package.
The locale comes in play with test:
t9129-git-svn-i18n-commitencoding.sh
compare_svn_head_with () {
LC_ALL=en_US.UTF-8 svn log --limit 1 `git svn info --url` | \
sed -e 1,3d -e "/^-\{1,\}\$/d" >current &&
test_cmp current "$1"
}
On my building machine I don't have any locales installed, making the
LC_ALL=C.
Not everybody will have this locale installed nor would they want it
installed on their machines.
Is the locale is a dependency for git svn?
Or can this test be changed? Either by not having the locale dependency
or by skipping the test completely?
I apologize if this message shows up twice.
--
Peter van der Does
GPG key: E77E8E98
^ permalink raw reply
* git 1.6.1-rc4 testing dependency
From: Peter van der Does @ 2008-12-22 15:06 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 799 bytes --]
With git 1.6.1 it it seems you need to install the locale en_US.UTF-8
otherwise it won't pass the testing during building the package.
The locale comes in play with test:
t9129-git-svn-i18n-commitencoding.sh
compare_svn_head_with () {
LC_ALL=en_US.UTF-8 svn log --limit 1 `git svn info --url` | \
sed -e 1,3d -e "/^-\{1,\}\$/d" >current &&
test_cmp current "$1"
}
On my building machine I don't have any locales installed, making the
LC_ALL=C.
Not everybody will have this locale installed nor would they want it
installed on their machines.
Is the locale is a dependency for git svn?
Or can this test be changed? Either by not having the locale dependency
or by skipping the test completely?
--
Peter van der Does
GPG key: E77E8E98
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* push to backup repo periodically fails with "not fast forward"
From: davetron5000 @ 2008-12-22 16:24 UTC (permalink / raw)
To: git
I have a repo on another disk that I ONLY use to backup my in-use
local repo. I have a post-commit hook that does the push (git push --
all remote-repo-name)
>git commit -a -m 'some change'
Counting objects: 71, done.
Compressing objects: 100% (26/26), done.
Writing objects: 100% (29/29), 2.31 KiB, done.
Total 29 (delta 12), reused 0 (delta 0)
Unpacking objects: 100% (29/29), done.
To file:///Volumes/Git/pose/main
22d7f10..0037aaf bimonthly-frequency -> bimonthly-frequency
! [rejected] master -> master (non-fast forward)
error: failed to push some refs to 'file:///Volumes/Git/pose/main'
Created commit 0037aaf: Removed assertion that made no sense.
1 files changed, 0 insertions(+), 2 deletions(-)
I'm using git as a front-end to Subversion, but I can't figure out why
this is happening.
The repo at /Volumes/Git/pose/main is NEVER pulled from or pushed to
by anything other than my hook. I can't understand why any push to it
would NOT be a fast-forward.
Any ideas how I can figure out what's going on?
^ permalink raw reply
* Re: push to backup repo periodically fails with "not fast forward"
From: Felipe Contreras @ 2008-12-22 17:11 UTC (permalink / raw)
To: davetron5000; +Cc: git
In-Reply-To: <19016122-e19d-4885-8b0f-dec7b686c6ea@o4g2000pra.googlegroups.com>
On Mon, Dec 22, 2008 at 6:24 PM, davetron5000 <davetron5000@gmail.com> wrote:
> I have a repo on another disk that I ONLY use to backup my in-use
> local repo. I have a post-commit hook that does the push (git push --
> all remote-repo-name)
>
>>git commit -a -m 'some change'
> Counting objects: 71, done.
> Compressing objects: 100% (26/26), done.
> Writing objects: 100% (29/29), 2.31 KiB, done.
> Total 29 (delta 12), reused 0 (delta 0)
> Unpacking objects: 100% (29/29), done.
> To file:///Volumes/Git/pose/main
> 22d7f10..0037aaf bimonthly-frequency -> bimonthly-frequency
> ! [rejected] master -> master (non-fast forward)
> error: failed to push some refs to 'file:///Volumes/Git/pose/main'
> Created commit 0037aaf: Removed assertion that made no sense.
> 1 files changed, 0 insertions(+), 2 deletions(-)
>
> I'm using git as a front-end to Subversion, but I can't figure out why
> this is happening.
>
> The repo at /Volumes/Git/pose/main is NEVER pulled from or pushed to
> by anything other than my hook. I can't understand why any push to it
> would NOT be a fast-forward.
>
> Any ideas how I can figure out what's going on?
Do you rebase your original repo?
--
Felipe Contreras
^ permalink raw reply
* Re: push to backup repo periodically fails with "not fast forward"
From: David Copeland @ 2008-12-22 17:15 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <94a0d4530812220911l37b825edj55178658f24755c1@mail.gmail.com>
the original gets rebased from a git svn rebase on occasion; so I
guess that is causing things to not be fast-forward.
I guess all I really want to do is keep a duplicate copy of my repo
somewhere else. Should I just use --force in my hook, or abandon git
as the mechanism and use rsync?
Dave
On Mon, Dec 22, 2008 at 12:11 PM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> On Mon, Dec 22, 2008 at 6:24 PM, davetron5000 <davetron5000@gmail.com> wrote:
>> I have a repo on another disk that I ONLY use to backup my in-use
>> local repo. I have a post-commit hook that does the push (git push --
>> all remote-repo-name)
>>
>>>git commit -a -m 'some change'
>> Counting objects: 71, done.
>> Compressing objects: 100% (26/26), done.
>> Writing objects: 100% (29/29), 2.31 KiB, done.
>> Total 29 (delta 12), reused 0 (delta 0)
>> Unpacking objects: 100% (29/29), done.
>> To file:///Volumes/Git/pose/main
>> 22d7f10..0037aaf bimonthly-frequency -> bimonthly-frequency
>> ! [rejected] master -> master (non-fast forward)
>> error: failed to push some refs to 'file:///Volumes/Git/pose/main'
>> Created commit 0037aaf: Removed assertion that made no sense.
>> 1 files changed, 0 insertions(+), 2 deletions(-)
>>
>> I'm using git as a front-end to Subversion, but I can't figure out why
>> this is happening.
>>
>> The repo at /Volumes/Git/pose/main is NEVER pulled from or pushed to
>> by anything other than my hook. I can't understand why any push to it
>> would NOT be a fast-forward.
>>
>> Any ideas how I can figure out what's going on?
>
> Do you rebase your original repo?
>
> --
> Felipe Contreras
>
^ permalink raw reply
* Re: push to backup repo periodically fails with "not fast forward"
From: Felipe Contreras @ 2008-12-22 17:19 UTC (permalink / raw)
To: David Copeland; +Cc: git
In-Reply-To: <f95d47890812220915h5286d2bdv7c8412ecf77be999@mail.gmail.com>
On Mon, Dec 22, 2008 at 7:15 PM, David Copeland <davetron5000@gmail.com> wrote:
> the original gets rebased from a git svn rebase on occasion; so I
> guess that is causing things to not be fast-forward.
>
> I guess all I really want to do is keep a duplicate copy of my repo
> somewhere else. Should I just use --force in my hook, or abandon git
> as the mechanism and use rsync?
I would manually do 'git push backup' at certain points since not all
my commits are meant to be backed up, specially on temporal feature
branches.
But --force should do the trick.
--
Felipe Contreras
^ permalink raw reply
* Re: push to backup repo periodically fails with "not fast forward"
From: Nicolas Pitre @ 2008-12-22 18:27 UTC (permalink / raw)
To: David Copeland; +Cc: Felipe Contreras, git
In-Reply-To: <f95d47890812220915h5286d2bdv7c8412ecf77be999@mail.gmail.com>
On Mon, 22 Dec 2008, David Copeland wrote:
> the original gets rebased from a git svn rebase on occasion; so I
> guess that is causing things to not be fast-forward.
>
> I guess all I really want to do is keep a duplicate copy of my repo
> somewhere else. Should I just use --force in my hook, or abandon git
> as the mechanism and use rsync?
Using --force is definitively better than rsync.
Nicolas
^ permalink raw reply
* Re: [RFC] Automagic patch merge ack emails
From: Junio C Hamano @ 2008-12-22 20:29 UTC (permalink / raw)
To: Richard Hartmann; +Cc: git
In-Reply-To: <2d460de70812220607j7f218ee3r7722bc8147a3dab4@mail.gmail.com>
"Richard Hartmann" <richih.mailinglist@gmail.com> writes:
> I poked around the docs, but I could not find any option to have git
> send email to people who signed off a patch when it's merged.
The correcty way to say that "the changes from a patch get incorporated"
is "it's applied", not "merged". There is no "post-am" hook you can use
to make an announcement. Nor the sample post-commit hook that is called
after every commit mentions anything about e-mails.
And these are good things, and here is why.
It does not matter a whit to you if/when I applied your patch to a topic
branch in my private repository that I work in, preparing for eventual
pushout to the public tree. Patches are reviewed in e-mail form, and
obvious typos and logic mistakes are corrected while still I am reading
your patch in my MUA, if they are trivial (otherwise you will get a reply
saying to which points I do not agree with your patch). After your patch
passes this process, it may be applied somewhere, perhaps directly on
'master' or 'maint', or perhaps on a new topic branch to house your
changes.
But that is only the beginning of the story. I'll apply many more changes
from other people, testing each step, rebasing and amending these changes
as necessary to fix breakages, and I may realize that some patches are not
quite ready to be in the public history during this process. Your patches
may be part of these patches discarded that way.
When I decide not to apply your patch (iow, it hits my mailbox but I
reject it while it is in my MUA), git obviously would not know about it at
all [*1*].
Even after I apply your patch somewhere, I may decide not to include it in
in any of the public branches after testing and re-reviewing. I may merge
the topic branch I created to host your patch to 'next', but after testing
and re-reviewing, I may decide it is not ready, and I'd rebuild 'next'
without the topic before pushing the results out. And I'd delete such a
topic branch after I am done with it.
What this means is that the time a commit is made (either by patch
application or "git pull" from somebody else's tree) is too early to make
any announcement. "git am" hook would not be useful for that purpose.
The only time that it may make a difference to you is when things are
pushed out to the public repository, and there is a mechanism for
automating tasks after new commits hits the public repository: the
post-receive hook. contrib/hooks/post-receive-email may be a good example
to study if you are interested (I use it in my day job repository, but I
do not use the hook in git.git because the style of announcing I adopted
on this list is to send out "What's in/cooking" messages once or twice a
week).
> Does anyone else think this is useful? Does anyone else think it should
> make it into main so it can be enabled via config, not via a hook that
> needs to be imported into each and every repo?
If your "each and every" repository is used for the same uniform purpose
(namely, publishing to the public), then they can be initialized with the
same hook scripts using the templates mechanism, so in a sense, there
already is a mechanism for that.
But it is very unlikely your repositories are uniform, so I doubt that the
mechanism based on custom templates, or your built-in announcement
mechanism triggered by configuration, would be very useful.
Most of the freedom in a DVCS workflow comes from the separation between
making commits (including patch application and merges) and publishing the
result. You do not want to fear committing crap, because you can
carefully check the result before making it public.
Because of that, private repositories where the real work takes place and
public repositories that serve as distribution points have very different
needs. You do not want to have any announcement triggers in the former
(that's the whole point of separating "making commits" and "publishing the
result"), while some people like announcement triggers in the latter.
[Footnote]
*1* There are two kinds of patches that rejected that way.
* One with good intention but wrong execution receives suggestion for
improvements.
* One with misguided intention or misleading description is requested to
clarify why the change is needed, before receiving comments on the
implementation.
^ permalink raw reply
* Bugs in sub argsfromdir of git-cvsserver
From: Le @ 2008-12-22 20:33 UTC (permalink / raw)
To: Git Mailing List
Hi, all,
I found a bug in git-cvsserver.
sub argsfromdir
{
if ( scalar(@{$state->{args}}) == 1 )
{
my $arg = $state->{args}[0];
#$arg .= $state->{prependdir} if ( defined (
$state->{prependdir} ) );
$arg = $state->{prependdir} . $arg if ( defined (
$state->{prependdir} ) );
$log->info("Only one arg specified, checking for directory
expansion on '$arg'");
...
}
...
}
It makes not sense of the above remarked out code.
But when I use the code followed remarked out, I have problem to use cvs
diff or cvs log in a sub directory of the root (may other commands as
well). Eg.:
I have a project called test1 and in test1 there is a test2 subdirectory
and a file test2/test3.txt.
I have no problem to cvs diff and cvs log in test1 directory. But if I
enter test1/test2 to check these commands then they are not working.
I tried to fixed the problem to remarked out the code:
#$filename = filecleanup($filename);
in req_log and req_diff, then both cvs diff and cvs log work.
In
sub filecleanup
{
...
$filename = $state->{prependdir} . $filename;
return $filename;
}
inserts $state->{prependdir} into the $filename.
But I don't know if what I did brings incompatibilities.
Can anybody check this issue?
Thanks!
Le Wen
^ permalink raw reply
* Re: Move-delete merge conflict is not displayed using git ls-files --unmerged
From: Junio C Hamano @ 2008-12-22 20:48 UTC (permalink / raw)
To: Constantine Plotnikov; +Cc: git, Johannes Schindelin, Alex Riesen
In-Reply-To: <85647ef50812220629o46134a70waf159bb6cd6d6e72@mail.gmail.com>
"Constantine Plotnikov" <constantine.plotnikov@gmail.com> writes:
> I think that if git merge reports the conflicts, such conflicts should
> be discoverable using git ls-files and prevent commit with resolving
> the conflict like it is done with modify-delete conflicts.
Yeah, I think so, too.
^ permalink raw reply
* Re: git 1.6.1-rc4 testing dependency
From: Junio C Hamano @ 2008-12-22 20:50 UTC (permalink / raw)
To: Peter van der Does; +Cc: git
In-Reply-To: <20081222100637.716c5b8a@montecarlo.grandprix.int>
Peter van der Does <peter@ourvirtualhome.com> writes:
> On my building machine I don't have any locales installed, making the
> LC_ALL=C.
> Not everybody will have this locale installed nor would they want it
> installed on their machines.
I think some tests play nicer than this one and skip tests that want UTF-8
locales; you may want to teach this script the same trick.
In the meantime, perhaps "GIT_SKIP_TETS='t9129' make test" would help.
^ permalink raw reply
* 'Theirs' merge between branches on a binary file.
From: Tim Visher @ 2008-12-22 20:56 UTC (permalink / raw)
To: git
Hello Everyone,
I have a binary file that is coming up with a merge conflict
(obviously) between two branches and I want to simply say, 'take their
version of the file'. Is this possible? In subversion it's a pretty
trivial merge operation, so I assume there's something similar in git.
Thanks in advance!
--
In Christ,
Timmy V.
http://burningones.com/
http://five.sentenc.es/ - Spend less time on e-mail
^ permalink raw reply
* Re: [RFC] Automagic patch merge ack emails
From: Boyd Stephen Smith Jr. @ 2008-12-22 20:59 UTC (permalink / raw)
To: git; +Cc: Richard Hartmann
In-Reply-To: <2d460de70812220607j7f218ee3r7722bc8147a3dab4@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1475 bytes --]
On Monday 2008 December 22 08:07:07 Richard Hartmann wrote:
> I poked around the docs, but I could not find any option to have git
> send email to people who signed off a patch when it's merged.
There's not one, since something that that should probably be done in a hook.
Maybe the update hook?
> I only realized the two patches I sent were merged because they were
> listed in the RC changelog summary and would have followed up my patch
> email in a about a week, asking about its status.
>
> Does anyone else think this is useful?
I think it would be nice to get a notification whenever Junio pushes commits
to 'master' or 'maint' in git.git if I've signed off on one of the commits.
I don't think everyone would though so the hook would need to be maintained
indefinitely (updating the email blacklist, etc.).
It would probably be a nice hook to have as an example, I guess.
> Does anyone else think it should
> make it into main so it can be enabled via config, not via a hook that
> needs to be imported into each and every repo?
Definitely not. It's not that difficult to add a hook to the repositories
that need it, and I think the majority of repositories will be private and
not need it.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] rebase -i -p: Fix --continue after a merge could not be redone
From: Johannes Schindelin @ 2008-12-22 21:06 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, Andreas Ericsson, Stephen Haberman, git
In-Reply-To: <1229335531-32707-2-git-send-email-j6t@kdbg.org>
Hi,
On Mon, 15 Dec 2008, Johannes Sixt wrote:
> When a merge that has a conflict was rebased, then rebase stopped to let
> the user resolve the conflicts. However, thereafter --continue failed
> because the author-script was not saved. (This is rebase -i's way to
> preserve a commit's authorship.) This fixes it by doing taking the same
> failure route after a merge that is also taken after a normal cherry-pick.
>
> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
> ---
> This is an attempt at fixing the failure. I don't know whether it is
> problematic to leave a "patch" behind if there was actually a merge.
I'd suggest leaving behind a --cc patch, so that nobody is tempted to
"fix" the patch until it applies.
> diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
> index 1172e47..89c39eb 100755
> --- a/git-rebase--interactive.sh
> +++ b/git-rebase--interactive.sh
> @@ -253,15 +253,14 @@ pick_one_preserving_merges () {
> if ! GIT_AUTHOR_NAME="$GIT_AUTHOR_NAME" \
> GIT_AUTHOR_EMAIL="$GIT_AUTHOR_EMAIL" \
> GIT_AUTHOR_DATE="$GIT_AUTHOR_DATE" \
> output git merge $STRATEGY -m "$msg" \
> $new_parents
> then
> - git rerere
Why? I found rerere pretty helpful when rebasing merges.
Ah, it is done by die_with_patch() already. You might want to prevent
headscratching and hunting around for a few minutes, by simply mentioning
that fact in the commit message.
I'll leave the commit message fixing to you, but the --cc patch probably
looks something like this -- feel free to squash in:
---
git-rebase--interactive.sh | 18 +++++++++++++++---
1 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 89c39eb..b20c101 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -115,9 +115,21 @@ mark_action_done () {
}
make_patch () {
- parent_sha1=$(git rev-parse --verify "$1"^) ||
- die "Cannot get patch for $1^"
- git diff-tree -p "$parent_sha1".."$1" > "$DOTEST"/patch
+ sha1_and_parents="$(git rev-list --parents -1 $1)"
+ case "$sha1_and_parents" in
+ *' '*' '*' '*)
+ echo "Octopus merge"
+ ;;
+ *' '*' '*)
+ git diff --cc $sha1_and_parents
+ ;;
+ *' '*)
+ git diff-tree -R -p $sha1_and_parents
+ ;;
+ *)
+ echo "Root commit"
+ ;;
+ esac > "$DOTEST"/patch
test -f "$DOTEST"/message ||
git cat-file commit "$1" | sed "1,/^$/d" > "$DOTEST"/message
test -f "$DOTEST"/author-script ||
^ permalink raw reply related
* Re: [PATCH 2/2] rebase -i -p: Fix --continue after a merge could not be redone
From: Johannes Schindelin @ 2008-12-22 21:16 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, Andreas Ericsson, Stephen Haberman, git
In-Reply-To: <alpine.DEB.1.00.0812222139340.30769@pacific.mpi-cbg.de>
Hi,
On Mon, 22 Dec 2008, Johannes Schindelin wrote:
> I'll leave the commit message fixing to you, but the --cc patch probably
> looks something like this -- feel free to squash in:
>
> ---
> [... a patch ...]
Ooops. Scratch that. I tested without running the test suite, and sure
enough, it failed. Take that instead.
--
git-rebase--interactive.sh | 18 +++++++++++++++---
1 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 89c39eb..f08409c 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -115,9 +115,21 @@ mark_action_done () {
}
make_patch () {
- parent_sha1=$(git rev-parse --verify "$1"^) ||
- die "Cannot get patch for $1^"
- git diff-tree -p "$parent_sha1".."$1" > "$DOTEST"/patch
+ sha1_and_parents="$(git rev-list --parents -1 $1)"
+ case "$sha1_and_parents" in
+ *' '*' '*' '*)
+ echo "Octopus merge"
+ ;;
+ *' '*' '*)
+ git diff --cc $sha1_and_parents
+ ;;
+ *' '*)
+ git diff-tree -p $1^!
+ ;;
+ *)
+ echo "Root commit"
+ ;;
+ esac > "$DOTEST"/patch
test -f "$DOTEST"/message ||
git cat-file commit "$1" | sed "1,/^$/d" > "$DOTEST"/message
test -f "$DOTEST"/author-script ||
^ permalink raw reply related
* Re: 'Theirs' merge between branches on a binary file.
From: Junio C Hamano @ 2008-12-22 21:11 UTC (permalink / raw)
To: Tim Visher; +Cc: git
In-Reply-To: <c115fd3c0812221256l494bb824ga8e1640efb07b20c@mail.gmail.com>
"Tim Visher" <tim.visher@gmail.com> writes:
> I have a binary file that is coming up with a merge conflict
> (obviously) between two branches and I want to simply say, 'take their
> version of the file'.
Do you mean during a conflicted merge resolution you would want to check
their version out of the index and declare that it is the merge result?
^ permalink raw reply
* Re: 'Theirs' merge between branches on a binary file.
From: Tim Visher @ 2008-12-22 21:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr63zhq4k.fsf@gitster.siamese.dyndns.org>
On Mon, Dec 22, 2008 at 4:11 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Do you mean during a conflicted merge resolution you would want to check
> their version out of the index and declare that it is the merge result?
Sure. Let me try to be a bit clearer.
I was developing on a feature branch and now want to merge back into
the master branch. Unfortunately, a binary file somewhat central to
the development effort was changed between the the feature branch and
the master branch and now there is a conflict. Obviously, I can't fix
the conflict via markers or something like that because it's a binary
file, and I know that I want the feature branch's version of the file,
not the one that it is in conflict with. How would I just select the
stage3 version of the file and add that to the index?
--
In Christ,
Timmy V.
http://burningones.com/
http://five.sentenc.es/ - Spend less time on e-mail
^ permalink raw reply
* Re: Bugs in sub argsfromdir of git-cvsserver
From: Le @ 2008-12-22 21:42 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <494FF9A9.9060706@distributel.ca>
Le wrote:
> Hi, all,
>
> I found a bug in git-cvsserver.
> sub argsfromdir
> {
>
> if ( scalar(@{$state->{args}}) == 1 )
> {
> my $arg = $state->{args}[0];
> #$arg .= $state->{prependdir} if ( defined (
> $state->{prependdir} ) );
> $arg = $state->{prependdir} . $arg if ( defined (
> $state->{prependdir} ) );
> $log->info("Only one arg specified, checking for directory
> expansion on '$arg'");
> ...
> }
> ...
> }
>
> It makes not sense of the above remarked out code.
>
> But when I use the code followed remarked out, I have problem to use
> cvs diff or cvs log in a sub directory of the root (may other commands
> as well). Eg.:
>
> I have a project called test1 and in test1 there is a test2
> subdirectory and a file test2/test3.txt.
> I have no problem to cvs diff and cvs log in test1 directory. But if I
> enter test1/test2 to check these commands then they are not working.
>
> I tried to fixed the problem to remarked out the code:
> #$filename = filecleanup($filename);
> in req_log and req_diff, then both cvs diff and cvs log work.
>
> In
> sub filecleanup
> {
> ...
> $filename = $state->{prependdir} . $filename;
> return $filename;
> }
>
> inserts $state->{prependdir} into the $filename.
>
> But I don't know if what I did brings incompatibilities.
>
> Can anybody check this issue?
>
> Thanks!
>
> Le Wen
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
It seems that req_up and req_status need to be changed as well. I am not
which subs need to be changed.
Le Wen
^ permalink raw reply
* Merge two repos with history included? (was Re: How do I..?)
From: Dylan Martin @ 2008-12-22 22:04 UTC (permalink / raw)
To: git
I tried converting an existing SVN repo to git and then adding it to
my main git repo using the subtree merge technique described at
http://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html.
I now have the various files in my repo, but they have no history.
I checked, and my initial SVN to git conversion does contain history.
I'm trying to add an exising repo as a subdir of my main repo with
history included. Can anyone tell me how to do that?
I'm sorry if I'm phrasing my question badly, or if I'm asking
something that should be obvious...
Thanks!
-Dylan
On Wed, Dec 17, 2008 at 3:49 PM, Miklos Vajna <vmiklos@frugalware.org> wrote:
> On Wed, Dec 17, 2008 at 03:16:59PM -0800, Dylan Martin <dmartin@sccd.ctc.edu> wrote:
>> Sorry if this is a dumb question. I've poked around the docs and
>> tried the google searches I could think of, but I don't even know what
>> kind of search terms one would use in trying to answer this.
>>
>> I'm a sysadmin and I've got a big monolithic git repo of all my
>> scripts, documents, etc... It used to be a CVS repo but I converted
>> it to git a while ago.
>> Before I switched to git, I played around with SVN a bit, and started
>> a few tiny SVN repos for various scripts I was working on. So, I know
>> have one git repo with %90 of my stuff and a handful of SVN repos.
>> I'd like to be able to add the SVN repos as subdirectories inside my
>> git repo. I've found lots of pages describing how to convert an SVN
>> repo into a _new_ git repo, but I haven't found anything yet about
>> importing the contents of an SVN repo as a subdirectory of an
>> _existing_ git repo.
>
> I would convert each repo to git, then merge them using subtree merge.
> See Documentation/howto/using-merge-subtree.txt.
>
^ permalink raw reply
* [PATCH] merge-recursive: mark rename/delete conflict as unmerged
From: Johannes Schindelin @ 2008-12-22 22:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Constantine Plotnikov, git, Alex Riesen
In-Reply-To: <7v4p0whr7a.fsf@gitster.siamese.dyndns.org>
When a file was renamed in one branch, but deleted in the other, one
should expect the index to contain an unmerged entry, namely the
target of the rename. Make it so.
Noticed by Constantine Plotnikov.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
On Mon, 22 Dec 2008, Junio C Hamano wrote:
> "Constantine Plotnikov" <constantine.plotnikov@gmail.com> writes:
>
> > I think that if git merge reports the conflicts, such
> > conflicts should be discoverable using git ls-files and prevent
> > commit with resolving the conflict like it is done with
> > modify-delete conflicts.
>
> Yeah, I think so, too.
A test case would have been nice.
merge-recursive.c | 5 +++++
t/t6024-recursive-merge.sh | 23 +++++++++++++++++++++++
2 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/merge-recursive.c b/merge-recursive.c
index a0c804c..69e7152 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -902,6 +902,11 @@ static int process_renames(struct merge_options *o,
ren1_src, ren1_dst, branch1,
branch2);
update_file(o, 0, ren1->pair->two->sha1, ren1->pair->two->mode, ren1_dst);
+ update_stages(ren1_dst, NULL,
+ branch1 == o->branch1 ?
+ ren1->pair->two : NULL,
+ branch1 == o->branch1 ?
+ NULL : ren1->pair->two, 1);
} else if (!sha_eq(dst_other.sha1, null_sha1)) {
const char *new_path;
clean_merge = 0;
diff --git a/t/t6024-recursive-merge.sh b/t/t6024-recursive-merge.sh
index 802d0d0..129fa30 100755
--- a/t/t6024-recursive-merge.sh
+++ b/t/t6024-recursive-merge.sh
@@ -97,4 +97,27 @@ test_expect_success 'refuse to merge binary files' '
merge.err
'
+test_expect_success 'mark rename/delete as unmerged' '
+
+ git reset --hard &&
+ git checkout -b delete &&
+ git rm a1 &&
+ test_tick &&
+ git commit -m delete &&
+ git checkout -b rename HEAD^ &&
+ git mv a1 a2
+ test_tick &&
+ git commit -m rename &&
+ test_must_fail git merge delete &&
+ test 1 = $(git ls-files --unmerged | wc -l) &&
+ git rev-parse --verify :2:a2 &&
+ test_must_fail git rev-parse --verify :3:a2 &&
+ git checkout -f delete &&
+ test_must_fail git merge rename &&
+ test 1 = $(git ls-files --unmerged | wc -l) &&
+ test_must_fail git rev-parse --verify :2:a2 &&
+ git rev-parse --verify :3:a2
+
+'
+
test_done
--
1.6.1.rc3.412.ga72b
^ permalink raw reply related
* Re: 'Theirs' merge between branches on a binary file.
From: Junio C Hamano @ 2008-12-22 22:52 UTC (permalink / raw)
To: Tim Visher; +Cc: git
In-Reply-To: <c115fd3c0812221316y24ce0c7q29807cd349a99e83@mail.gmail.com>
"Tim Visher" <tim.visher@gmail.com> writes:
> On Mon, Dec 22, 2008 at 4:11 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
>> Do you mean during a conflicted merge resolution you would want to check
>> their version out of the index and declare that it is the merge result?
>
> Sure.
That sounds like "git checkout --theirs"...
^ permalink raw reply
* Re: 'Theirs' merge between branches on a binary file.
From: Tim Visher @ 2008-12-22 22:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd4fjhlf8.fsf@gitster.siamese.dyndns.org>
On Mon, Dec 22, 2008 at 5:52 PM, Junio C Hamano <gitster@pobox.com> wrote:
> That sounds like "git checkout --theirs"...
I'm sorry, Junio. I don't mean to be dense but I can't find that in
the docs and when I execute it it comes back as an unknown command.
Perhaps you could just point me to the relevant man page? This seems
like such a fundamental operation, I just don't understand why there
isn't something like a `git resolve`.
Thanks for your help!
--
In Christ,
Timmy V.
http://burningones.com/
http://five.sentenc.es/ - Spend less time on e-mail
^ permalink raw reply
* Re: [PATCH] merge-recursive: mark rename/delete conflict as unmerged
From: Junio C Hamano @ 2008-12-22 23:12 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Constantine Plotnikov, git, Alex Riesen
In-Reply-To: <alpine.DEB.1.00.0812222308410.30769@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> When a file was renamed in one branch, but deleted in the other, one
> should expect the index to contain an unmerged entry, namely the
> target of the rename. Make it so.
That was quick, but the surrounding code makes me wonder if other
if/elseif branches also need similar handling.
For example, rename/add comes up with a new name that does not exist
anywhere, and adds both to the index; it is understandable that you need
to do this when processing a merge with non-zero depth because you need to
have a tree as the result, but shouldn't the final zero depth merge just
use the original names and leave the results in higher stages?
^ permalink raw reply
* Re: 'Theirs' merge between branches on a binary file.
From: Junio C Hamano @ 2008-12-22 23:18 UTC (permalink / raw)
To: Tim Visher; +Cc: git
In-Reply-To: <c115fd3c0812221458q3444cbcai7ab1716b9195ad08@mail.gmail.com>
"Tim Visher" <tim.visher@gmail.com> writes:
> On Mon, Dec 22, 2008 at 5:52 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
>> That sounds like "git checkout --theirs"...
>
> I'm sorry, Junio. I don't mean to be dense but I can't find that in
> the docs and when I execute it it comes back as an unknown command.
Hmph, I meant to point you at:
http://www.kernel.org/pub/software/scm/git/docs/git-checkout.html
I think you can use "git checkout-index --stage=3 path" if your git is
older than that one with the option.
v1.6.0.1-15-g38901a4 (checkout --ours/--theirs: allow checking out one
side of a conflicting merge, 2008-08-30) introduced the feature.
^ 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