* Re: GIT - releases workflow
From: Andreas Ericsson @ 2006-12-13 13:13 UTC (permalink / raw)
To: Sean Kelley; +Cc: Matthias Kestenholz, git
In-Reply-To: <89b129c60612130439m452b315x2278456396a248a5@mail.gmail.com>
Sean Kelley wrote:
> Hi,
>
> On 12/13/06, Sean Kelley <sean.v.kelley@gmail.com> wrote:
>> Hi,
>>
>> On 12/13/06, Matthias Kestenholz <lists@spinlock.ch> wrote:
>> >
>> How do I push that tag that I created to the maint/v0.1 branch on the
>> remote repository?
>
> Never mind, I answered my own question. Sorry for asking without
> doing my research first.
>
> git push --tags origin
>
Sort of, but not quite. This will push *all* your tags to wherever
origin points to. If you, like me, use un-annotated tags to remember a
particular snapshot you will then push a number of tags named "foo",
"fnurg", "sdf" and "werwer" to the mothership repo.
git push origin v0.1
works marvellously though.
Btw, this behaviour of mine, coupled with the company policy of only
allowing annotated tags signed by the project maintainer as
release-tags, lead to the creation of the update-hook I believe is still
shipped as the default update-hook template with the git repo. It
disallows un-annotated tags completely and should be used on the
mothership repo.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply
* More Perl fun: man and System directories
From: Brian Gernhardt @ 2006-12-13 13:07 UTC (permalink / raw)
To: git
Hello again!
Perl's MakeMaker seems to be a rather arcane thing. I'm trying to
figure out two things:
1) Perl is creating man files in the wrong place. My system expects
them to be in /usr/local/share/man, but Perl is installing them in /
usr/local/man. Currently I'm just moving them by hand every time I
pull-make-install, which is less than optimal.
2) In a bit of what I'm sure is OS X strangeness, Perl is creating a /
usr/local/System directory that contains one file: "System/Library/
Perl/5.8.6/darwin-thread-multi-2level/perllocal.pod". This doesn't
seem to be useful, and I'm deleting it without anything exploding
(noticeably) since I doubt anything is looking for a System directory
there. Is there a way to keep Perl from creating it in the first place?
Thanks for your time!
^ permalink raw reply
* Re: GIT - releases workflow
From: Sean Kelley @ 2006-12-13 12:39 UTC (permalink / raw)
To: Matthias Kestenholz; +Cc: git
In-Reply-To: <89b129c60612130434q18c69c7bxd96b7db0c423d8ea@mail.gmail.com>
Hi,
On 12/13/06, Sean Kelley <sean.v.kelley@gmail.com> wrote:
> Hi,
>
> On 12/13/06, Matthias Kestenholz <lists@spinlock.ch> wrote:
> >
> How do I push that tag that I created to the maint/v0.1 branch on the
> remote repository?
Never mind, I answered my own question. Sorry for asking without
doing my research first.
git push --tags origin
Thanks,
Sean
>
> Thanks,
>
> Sean
>
>
> >
> > I need a full branch, because I need the ability to do bugfixes for the
> > already-released version.
> >
> > Matthias
> >
> >
>
>
> --
> Sean Kelley
>
--
^ permalink raw reply
* Re: GIT - releases workflow
From: Sean Kelley @ 2006-12-13 12:34 UTC (permalink / raw)
To: Matthias Kestenholz; +Cc: git
In-Reply-To: <1166001019.19098.4.camel@localhost.localdomain>
Hi,
On 12/13/06, Matthias Kestenholz <lists@spinlock.ch> wrote:
> Hi,
>
> On Tue, 2006-12-12 at 23:54 +0100, Johannes Schindelin wrote:
> > Hi,
> >
> > On Tue, 12 Dec 2006, Sean Kelley wrote:
> >
> > > I was wondering if anyone could share ideas on how best to use GIT to
> > > handle releases for those working with a remote GIT repository? Do you
> > > create a branch and push it to the remote? Thus you have a new branch
> > > referencing the particular release?
> >
> > Why not just tag the release, and push the tag?
>
> I am doing both in my web SDK project.
>
> I currently have two branches, master and maint/v1. Over time, if
> necessary, I'll open new branches named maint/v2, maint/v3 etc.
>
> New development happens on master, bugfixes go to maint/v1 and get
> merged into master. If I do bugfix releases (2.0.x), I tag the tip of
> the maint/v1 branch.
That seems to match my use case. So if I follow your description:
git checkout -b maint/v0.1
git pull . <remote project repo>
git push origin maint/v0.1:maint/v0.1
Now the initial branch release is on the remote repo. So that my team
can start hacking on the release branch. When we are ready, we need
to create a release tag.
git tag -a -m "Release 0.1.0" rel-v0.1.0
How do I push that tag that I created to the maint/v0.1 branch on the
remote repository?
Thanks,
Sean
>
> I need a full branch, because I need the ability to do bugfixes for the
> already-released version.
>
> Matthias
>
>
--
^ permalink raw reply
* More merge-recursive woes
From: Shawn Pearce @ 2006-12-13 7:36 UTC (permalink / raw)
To: git
Today I found two new bugs in git-merge-recursive. I'm still
researching them, but I at least have a test case for one of the
two:
Bug #1: If one branch renames a file which existed in the merge base,
when we merge that change into a different branch the old version
of the file is not deleted from the working directory. The attached
test script shows this ("BAD: A still exists in working directory").
Bug #2: In that horrible repository that I have where I ran into the
empty tree missing bug I now have a pair of commits which when merged
together cause git-merge-recursive to go into an infinite loop,
or least burn CPU for hours on end without doing squat. I have
not been able to get enough data to even write a good analysis
of it yet. I'll try to do that this week, as I cannot share the
repository itself. It just happens to be two new commits along
the same two branches however. :-(
Both bugs are appearing with current 'next' (8662d0ea).
After I eat something and weed through my inbox I may take a stab
at the first one, if I haven't passed out on the couch. :-)
->->->->->->--t6024-merge-rename2.sh-->->->->->->->->-
#!/bin/sh
test_description='Merge-recursive merging renames'
. ./test-lib.sh
test_expect_success setup \
'
cat >A <<\EOF &&
a aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
b bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
c cccccccccccccccccccccccccccccccccccccccccccccccc
d dddddddddddddddddddddddddddddddddddddddddddddddd
e eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
f ffffffffffffffffffffffffffffffffffffffffffffffff
g gggggggggggggggggggggggggggggggggggggggggggggggg
h hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh
i iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii
j jjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjj
k kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk
l llllllllllllllllllllllllllllllllllllllllllllllll
m mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm
n nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn
o oooooooooooooooooooooooooooooooooooooooooooooooo
EOF
cat >M <<\EOF &&
A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
B BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
C CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
D DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD
E EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
F FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
G GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG
H HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
I IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII
J JJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJ
K KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK
L LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL
M MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM
N NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
O OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
EOF
git add A M &&
git commit -m "initial has A and M" &&
git branch white &&
git branch red &&
git checkout white &&
sed -e "/^g /s/.*/g : white changes a line/" <A >B &&
sed -e "/^G /s/.*/G : colored branch changes a line/" <M >N &&
rm -f A M &&
git update-index --add --remove A B M N &&
git commit -m "white renames A->B, M->N" &&
git checkout red &&
echo created by red >R &&
git update-index --add R &&
git commit -m "red creates R" &&
git checkout master'
test_expect_success 'merge white into red' \
'
git checkout -b red-white red &&
git merge white &&
git write-tree >/dev/null || {
echo "BAD: merge did not complete"
return 1
}
test -f B || {
echo "BAD: B does not exist in working directory"
return 1
}
test -f N || {
echo "BAD: N does not exist in working directory"
return 1
}
test -f R || {
echo "BAD: R does not exist in working directory"
return 1
}
test -f A && {
echo "BAD: A still exists in working directory"
return 1
}
test -f M && {
echo "BAD: M still exists in working directory"
return 1
}
'
^ permalink raw reply
* Re: StGit repo & gitweb, was Re: [PATCH] merge-recursive: add/add really is modify/modify with an empty base
From: Jakub Narebski @ 2006-12-13 11:56 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0612131232270.3635@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> Yet another question: On repo.or.cz, I searched for the "commit" "8d41555"
> (upper right side, very nice, although the search button is lacking, which
> is needed for some browsers like w3m).
The problem is where to put it. The previous version didn't even had the
"select type" but used [undocumented] search operators 'author:',
'committer:' and 'pickaxe:'.
> But I got _two_ results, the one I
> expected, and its child (probably because it contains the sha1 as part of
> the parent tag). Is this intended behaviour? After all, I search for the
> commit...
Actually, "commit" is a bit of misnomer, as it searches commits contents
(commit body). You can go to given commit easier by hand editing URL,
editing "a=commit;h=8d41555".
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* StGit repo & gitweb, was Re: [PATCH] merge-recursive: add/add really is modify/modify with an empty base
From: Johannes Schindelin @ 2006-12-13 11:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Catalin Marinas, Petr Baudis
In-Reply-To: <7vvekgl2z2.fsf@assigned-by-dhcp.cox.net>
Hi,
On Tue, 12 Dec 2006, Junio C Hamano wrote:
> Although I would feel very happy about this change, Catalin
> might want to be informed about potential interaction this
> change might have with his commit 8d41555 in StGIT.
Indeed. Catalin, do you have any suggestion how to proceed? Do you want to
introduce a check if the file exists prior to re-generating it? Or do you
need some version check?
BTW why is StGit not on kernel.org?
Not that it matters: repo.or.cz has a nice mirror. Pasky, how powerful is
that machine? I am a happy user of the gitweb interface on that box...
Yet another question: On repo.or.cz, I searched for the "commit" "8d41555"
(upper right side, very nice, although the search button is lacking, which
is needed for some browsers like w3m). But I got _two_ results, the one I
expected, and its child (probably because it contains the sha1 as part of
the parent tag). Is this intended behaviour? After all, I search for the
commit...
Ciao,
Dscho
^ permalink raw reply
* Re: Collection of stgit issues and wishes
From: Karl Hasselström @ 2006-12-13 11:03 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: David Kågedal, git
In-Reply-To: <457FD3E4.3090104@op5.se>
On 2006-12-13 11:20:20 +0100, Andreas Ericsson wrote:
> David Kågedal wrote:
>
> > "Catalin Marinas" <catalin.marinas@gmail.com> writes:
> >
> > > On 08/12/06, Yann Dirson <ydirson@altern.org> wrote:
> > >
> > > > - shortcuts (st -> status, etc.), possibly making use of the
> > > > git alias system ?
> > >
> > > Did this last night as it was pretty easy and without the GIT
> > > alias system (which I am not familiar with). The idea is that if
> > > it cannot find an exact match, it tries to look for all the
> > > commands starting with the passed argument. If more than one
> > > command is found, it reports an "ambiguous command".
> >
> > That approach can cause problems later on. If "stgit st" is
> > currently a unique prefix of "stgit status", people might use it
> > in scripts. Then, one day, you add the "stgit store" command, or
> > whatever, and their scripts start breaking for no good reason.
>
> People who use abbreviations of commands in scripts ought to be
> shot, not catered to, especially if they know this abbreviation is
> automagically calculated.
Well, yes, but there's no reason to not shoot them _politely_ ...
I'd prefer hand-picked command abbreviations to reduce namespace
clutter. That way, it's even possible to have "ambiguous" shortcuts --
for example, "stg st" -> "stg status" even if "stg store" exists. And
shortcuts that aren't prefixes, like "stg ua" -> "stg unapplied". And
the user doesn't need to retrain her fingers just because a prefix
gets ambiguous.
For prefixes, tab completion is a much better answer.
--
Karl Hasselström, kha@treskal.com
^ permalink raw reply
* Re: [PATCH] git-add --interactive (wip)
From: Johannes Schindelin @ 2006-12-13 11:20 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Junio C Hamano, Josef Weidendorfer, git
In-Reply-To: <20061213105754.GC9484@spearce.org>
Hi,
On Wed, 13 Dec 2006, Shawn Pearce wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > On Tue, 12 Dec 2006, Junio C Hamano wrote:
> > > Hmm, a way to easily stash away local changes and restoring
> > > would lead to a system where you can easily stash and unstash
> > > multiple snapshots and switch between them, and such a model
> > > sounds vaguely familiar...
> >
> > Hmm, what might that be? :-)
> >
> > A more simple approach than to buy into Python
>
> Hmmm... last I heard Git doesn't depend on Python anymore, thanks
> largely to you and Alex.
I referred to StGit, which is pure Python AFAIK.
> But it does stash and unstash snapshots of my working directory wicked
> fast using these things called branches... :-)
The PEBCAK. I cannot hardly type the commands as fast as Git need to stash
snapshots into branches.
So, git-revolve-stage would help me. Or maybe I create bash aliases
$ alias stash='stash_tree=$(git-write-tree)'
$ alias unstash='git-read-tree $stash_tree'
Ciao,
Dscho
^ permalink raw reply
* Re: GIT - releases workflow
From: Shawn Pearce @ 2006-12-13 11:14 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Matthias Kestenholz, Sean Kelley, git
In-Reply-To: <20061213105614.GB9484@spearce.org>
Shawn Pearce <spearce@spearce.org> wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > > On Tue, 12 Dec 2006, Sean Kelley wrote:
> > > >
> > > > > I was wondering if anyone could share ideas on how best to use GIT to
> > > > > handle releases for those working with a remote GIT repository? Do you
> > > > > create a branch and push it to the remote? Thus you have a new branch
> > > > > referencing the particular release?
> >
> > BTW, if the maintenance releases are sparse and long between, you can
> > actually create the branch from the tag, fix, and tag with the new version
> > number. No need to start the branches early.
>
> Indeed.
[snip]
> The script is really meant for QA people to take in topic branches
> from developers and apply them to a specific version, test that new
> version, then ship that new version. Some of the QA people I work
> with aren't developers and have a somewhat difficult time making
> a build from source; this script makes it a pretty simple process.
>
> The version number incrementor is smart; its based off commit
> lineage. It can automatically create a "2.0.1" tag when "2.1"
> has already been made but "2.0.1" is a bugfix of "2" or "2.0".
What I really should have said was the general idea here is that
we never even have a trunk.
Developers work on topic branches and share/merge those individual
branches as necessary to evolve a topic. When its suitably cooked
in developer land it gets sent off to testing by being pushed into
a someewhat descriptive ref under refs/heads/ready.
Testing can then accept topics by merging them together and creating
tags via the described script.
Developers update their still cooking topic branches when necessary
by pulling in the tags. git merge is smart enough to dereference the
tag and generate the merge. Normally this is held off to the latest
possible moment, and only to make sure there aren't any unexpected
surprises from the merge waiting for the unsuspecting QA person.
Developers start new topic branches off the relevent tag they need
to work on. New features are often made off the latest tag from QA;
bug fixes are often off the tag currently in production.
So like I said, we're basically trunkless and happy. Tag happy.
Thank you Linus, et.al. for packed refs!
--
^ permalink raw reply
* Re: [PATCH] git-add --interactive (wip)
From: Shawn Pearce @ 2006-12-13 10:57 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Josef Weidendorfer, git
In-Reply-To: <Pine.LNX.4.63.0612131137100.3635@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Tue, 12 Dec 2006, Junio C Hamano wrote:
> > Hmm, a way to easily stash away local changes and restoring
> > would lead to a system where you can easily stash and unstash
> > multiple snapshots and switch between them, and such a model
> > sounds vaguely familiar...
>
> Hmm, what might that be? :-)
>
> A more simple approach than to buy into Python
Hmmm... last I heard Git doesn't depend on Python anymore, thanks
largely to you and Alex. But it does stash and unstash snapshots
of my working directory wicked fast using these things called
branches... :-)
--
^ permalink raw reply
* Re: GIT - releases workflow
From: Shawn Pearce @ 2006-12-13 10:56 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Matthias Kestenholz, Sean Kelley, git
In-Reply-To: <Pine.LNX.4.63.0612131133160.3635@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > On Tue, 12 Dec 2006, Sean Kelley wrote:
> > >
> > > > I was wondering if anyone could share ideas on how best to use GIT to
> > > > handle releases for those working with a remote GIT repository? Do you
> > > > create a branch and push it to the remote? Thus you have a new branch
> > > > referencing the particular release?
>
> BTW, if the maintenance releases are sparse and long between, you can
> actually create the branch from the tag, fix, and tag with the new version
> number. No need to start the branches early.
Indeed.
I actually have a fancy (==~800 poorly written lines) Perl script that:
* Creates a "build" git repository using objects/info/alternates.
The user can reuse an existing directory if they have one.
(Obviously reusing an existing directory is faster, less files
to setup in the working directory.)
* Offers the user a menu of top 10 most recent tags to choose as
a base version. Tags are displayed first sorted by which tag
is considered to be in which runtime environment (QA testing,
end user testing, production release), then by tag date for
those tags not in any specific environment.
* Offers the user a menu of branches in a pre-configured namespace
(e.g. refs/heads/ready) which have commits not yet merged into
the selected base. Users can attempt to pull as many branches
as they like, the script merges each in turn until none remain
or the user says "build!".
* Increments the last component of the 'version number' of the tag
and makes an annotated tag object in the local build repository.
* Runs the project's configured build command (from repo-config
taken from builder.command variable).
* If builder.command is successful pushes the tag back to the origin
repository; if builder.command fails pushes the HEAD revision
up as a branch (e.g. refs/heads/failed/foo) so that someone more
skilled in the art of failed builds can look into the matter.
The script is really meant for QA people to take in topic branches
from developers and apply them to a specific version, test that new
version, then ship that new version. Some of the QA people I work
with aren't developers and have a somewhat difficult time making
a build from source; this script makes it a pretty simple process.
The version number incrementor is smart; its based off commit
lineage. It can automatically create a "2.0.1" tag when "2.1"
has already been made but "2.0.1" is a bugfix of "2" or "2.0".
I should clean it up some and post it, just in case others may
be interested. I'll try to do that this weekend.
--
^ permalink raw reply
* Re: [PATCH] Remove uncontested renamed files during merge.
From: Johannes Schindelin @ 2006-12-13 10:45 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20061213104244.GA9484@spearce.org>
Hi,
On Wed, 13 Dec 2006, Shawn Pearce wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > diff --git a/merge-recursive.c b/merge-recursive.c
> > > index 9d53bcd..741d17f 100644
> > > --- a/merge-recursive.c
> > > +++ b/merge-recursive.c
> > > @@ -873,7 +873,7 @@ static int process_renames(struct path_list *a_renames,
> > > struct diff_filespec src_other, dst_other;
> > > int try_merge, stage = a_renames == renames1 ? 3: 2;
> > >
> > > - remove_file(1, ren1_src, 1);
> > > + remove_file(1, ren1_src, 0);
> >
> > I _think_ that the "0" should be "!index_only".
>
> Err, actually "index_only". Since that's no_wd.
Oops. Correct. My memory starts failing me.
> -->-- corrected patch follows --<--
> Remove uncontested renamed files during merge.
Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Remove uncontested renamed files during merge.
From: Shawn Pearce @ 2006-12-13 10:42 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0612131129550.3635@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > diff --git a/merge-recursive.c b/merge-recursive.c
> > index 9d53bcd..741d17f 100644
> > --- a/merge-recursive.c
> > +++ b/merge-recursive.c
> > @@ -873,7 +873,7 @@ static int process_renames(struct path_list *a_renames,
> > struct diff_filespec src_other, dst_other;
> > int try_merge, stage = a_renames == renames1 ? 3: 2;
> >
> > - remove_file(1, ren1_src, 1);
> > + remove_file(1, ren1_src, 0);
>
> I _think_ that the "0" should be "!index_only".
Err, actually "index_only". Since that's no_wd. But yea, you are
right, I didn't consider the index_only mode of operation here.
-->-- corrected patch follows --<--
Remove uncontested renamed files during merge.
Prior to 65ac6e9c3f47807cb603af07a6a9e1a43bc119ae we deleted a file
from the working directory during a merge if the file existed before
the merge started but was renamed by the branch being merged in.
This broke in 65ac63 as git-merge-recursive did not actually update
the working directory on an uncontested rename.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
merge-recursive.c | 2 +-
t/t6024-merge-rename2.sh | 97 ++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 98 insertions(+), 1 deletions(-)
diff --git a/merge-recursive.c b/merge-recursive.c
index 9d53bcd..13e96eb 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -873,7 +873,7 @@ static int process_renames(struct path_list *a_renames,
struct diff_filespec src_other, dst_other;
int try_merge, stage = a_renames == renames1 ? 3: 2;
- remove_file(1, ren1_src, 1);
+ remove_file(1, ren1_src, index_only);
hashcpy(src_other.sha1, ren1->src_entry->stages[stage].sha);
src_other.mode = ren1->src_entry->stages[stage].mode;
diff --git a/t/t6024-merge-rename2.sh b/t/t6024-merge-rename2.sh
new file mode 100755
index 0000000..69c66cf
--- /dev/null
+++ b/t/t6024-merge-rename2.sh
@@ -0,0 +1,97 @@
+#!/bin/sh
+
+test_description='Merge-recursive merging renames'
+. ./test-lib.sh
+
+test_expect_success setup \
+'
+cat >A <<\EOF &&
+a aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
+b bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
+c cccccccccccccccccccccccccccccccccccccccccccccccc
+d dddddddddddddddddddddddddddddddddddddddddddddddd
+e eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
+f ffffffffffffffffffffffffffffffffffffffffffffffff
+g gggggggggggggggggggggggggggggggggggggggggggggggg
+h hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh
+i iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii
+j jjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjj
+k kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk
+l llllllllllllllllllllllllllllllllllllllllllllllll
+m mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm
+n nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn
+o oooooooooooooooooooooooooooooooooooooooooooooooo
+EOF
+
+cat >M <<\EOF &&
+A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
+B BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
+C CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
+D DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD
+E EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
+F FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
+G GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG
+H HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
+I IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII
+J JJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJ
+K KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK
+L LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL
+M MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM
+N NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
+O OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
+EOF
+
+git add A M &&
+git commit -m "initial has A and M" &&
+git branch white &&
+git branch red &&
+
+git checkout white &&
+sed -e "/^g /s/.*/g : white changes a line/" <A >B &&
+sed -e "/^G /s/.*/G : colored branch changes a line/" <M >N &&
+rm -f A M &&
+git update-index --add --remove A B M N &&
+git commit -m "white renames A->B, M->N" &&
+
+git checkout red &&
+echo created by red >R &&
+git update-index --add R &&
+git commit -m "red creates R" &&
+
+git checkout master'
+
+# This test broke in 65ac6e9c3f47807cb603af07a6a9e1a43bc119ae
+test_expect_success 'merge white into red (A->B,M->N)' \
+'
+ git checkout -b red-white red &&
+ git merge white &&
+ git write-tree >/dev/null || {
+ echo "BAD: merge did not complete"
+ return 1
+ }
+
+ test -f B || {
+ echo "BAD: B does not exist in working directory"
+ return 1
+ }
+ test -f N || {
+ echo "BAD: N does not exist in working directory"
+ return 1
+ }
+ test -f R || {
+ echo "BAD: R does not exist in working directory"
+ return 1
+ }
+
+ test -f A && {
+ echo "BAD: A still exists in working directory"
+ return 1
+ }
+ test -f M && {
+ echo "BAD: M still exists in working directory"
+ return 1
+ }
+ return 0
+'
+
+test_done
--
1.4.4.2.g8662
^ permalink raw reply related
* Re: [PATCH] git-add --interactive (wip)
From: Johannes Schindelin @ 2006-12-13 10:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Josef Weidendorfer, git
In-Reply-To: <7v1wn4mk9i.fsf@assigned-by-dhcp.cox.net>
Hi,
On Tue, 12 Dec 2006, Junio C Hamano wrote:
> Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
>
> > No. It currently is starting to get useful. With the ability
> > to temporarily store away a dirty state of the working directory,
> > it really could become very good.
>
> Hmm, a way to easily stash away local changes and restoring
> would lead to a system where you can easily stash and unstash
> multiple snapshots and switch between them, and such a model
> sounds vaguely familiar...
Hmm, what might that be? :-)
A more simple approach than to buy into Python would be to introduce a
very simple program, which exchanges work directory contents with index
contents. So,
$ git revolve-stage
$ [test the staged revision]
$ [possibly fix a thing or two]
$ git revolve-stage
$ git commit
Opinions?
Ciao,
Dscho
^ permalink raw reply
* Re: GIT - releases workflow
From: Johannes Schindelin @ 2006-12-13 10:36 UTC (permalink / raw)
To: Matthias Kestenholz; +Cc: Sean Kelley, git
In-Reply-To: <1166001019.19098.4.camel@localhost.localdomain>
Hi,
On Wed, 13 Dec 2006, Matthias Kestenholz wrote:
> On Tue, 2006-12-12 at 23:54 +0100, Johannes Schindelin wrote:
> >
> > On Tue, 12 Dec 2006, Sean Kelley wrote:
> >
> > > I was wondering if anyone could share ideas on how best to use GIT to
> > > handle releases for those working with a remote GIT repository? Do you
> > > create a branch and push it to the remote? Thus you have a new branch
> > > referencing the particular release?
> >
> > Why not just tag the release, and push the tag?
>
> I am doing both in my web SDK project.
>
> I currently have two branches, master and maint/v1. Over time, if
> necessary, I'll open new branches named maint/v2, maint/v3 etc.
>
> New development happens on master, bugfixes go to maint/v1 and get
> merged into master. If I do bugfix releases (2.0.x), I tag the tip of
> the maint/v1 branch.
>
> I need a full branch, because I need the ability to do bugfixes for the
> already-released version.
Ah, that's right. I always forget that there are maintenance releases
(mostly in Cathedral-ish projects)... I am not a release engineer during
my day job, and I am just as happy about that.
BTW, if the maintenance releases are sparse and long between, you can
actually create the branch from the tag, fix, and tag with the new version
number. No need to start the branches early.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Remove uncontested renamed files during merge.
From: Johannes Schindelin @ 2006-12-13 10:31 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20061213095540.GA25001@spearce.org>
Hi,
On Wed, 13 Dec 2006, Shawn O. Pearce wrote:
> Prior to 65ac6e9c3f47807cb603af07a6a9e1a43bc119ae we deleted a
> file from the working directory during a merge if the file existed
> in the working directory before the merge started but was renamed
> by the branch which is being merged in. This broke in 65ac63 as
> git-merge-recursive did not actually update the working directory
> on this uncontested rename case.
>
> [...]
>
> diff --git a/merge-recursive.c b/merge-recursive.c
> index 9d53bcd..741d17f 100644
> --- a/merge-recursive.c
> +++ b/merge-recursive.c
> @@ -873,7 +873,7 @@ static int process_renames(struct path_list *a_renames,
> struct diff_filespec src_other, dst_other;
> int try_merge, stage = a_renames == renames1 ? 3: 2;
>
> - remove_file(1, ren1_src, 1);
> + remove_file(1, ren1_src, 0);
I _think_ that the "0" should be "!index_only". After all, these functions
are not only called on the virtual merges, but also on the final merge,
which indeed should update the working directory. And since it is a
rename, the old file has to go.
Ciao,
^ permalink raw reply
* Re: Adding spell checker to GIT
From: Johannes Schindelin @ 2006-12-13 10:25 UTC (permalink / raw)
To: Sasikumar Kandhasamy; +Cc: Deepak Barua, git
In-Reply-To: <d22d265a0612130103o1efcbd87sb93be9c2dad71307@mail.gmail.com>
Hi,
On Wed, 13 Dec 2006, Sasikumar Kandhasamy wrote:
> We all know that linux is already having some tool like *aspell*. But
> this is not present in all the versions. This is one major disadvantage
> of using existing tool.
The advantage is: It already solved most problems for that particular
application, like getting all the words for the languages, providing a
user interface which actually helps using it, organizing the data
structures.
Besides, aspell is open source, just like Git. You can compile and install
it.
Hth,
Dscho
^ permalink raw reply
* Re: spurious .sp in manpages
From: Gerrit Pape @ 2006-12-13 10:17 UTC (permalink / raw)
To: git
In-Reply-To: <7vodq8kw97.fsf@assigned-by-dhcp.cox.net>
On Wed, Dec 13, 2006 at 12:58:28AM -0800, Junio C Hamano wrote:
> This is just a random hack to work around problems people seem
> to be seeing in manpage backend of xmlto (it appears we are
> getting ".sp" at the end of line without line break).
>
> Could people test this out?
The workaround works fine for me on Debian/unstable.
^ permalink raw reply
* Re: Collection of stgit issues and wishes
From: Andreas Ericsson @ 2006-12-13 10:20 UTC (permalink / raw)
To: David Kågedal; +Cc: git
In-Reply-To: <87y7pc2rc7.fsf@morpheus.local>
David Kågedal wrote:
> "Catalin Marinas" <catalin.marinas@gmail.com> writes:
>
>> On 08/12/06, Yann Dirson <ydirson@altern.org> wrote:
>>> - shortcuts (st -> status, etc.), possibly making use of the git alias
>>> system ?
>> Did this last night as it was pretty easy and without the GIT alias
>> system (which I am not familiar with). The idea is that if it cannot
>> find an exact match, it tries to look for all the commands starting
>> with the passed argument. If more than one command is found, it
>> reports an "ambiguous command".
>
> That approach can cause problems later on. If "stgit st" is currently
> a unique prefix of "stgit status", people might use it in scripts.
> Then, one day, you add the "stgit store" command, or whatever, and
> their scripts start breaking for no good reason.
>
People who use abbreviations of commands in scripts ought to be shot,
not catered to, especially if they know this abbreviation is
automagically calculated.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply
* Re: Collection of stgit issues and wishes
From: David Kågedal @ 2006-12-13 7:22 UTC (permalink / raw)
To: git
In-Reply-To: <b0943d9e0612120143j7d0c1026rab046c8f44ec43ca@mail.gmail.com>
"Catalin Marinas" <catalin.marinas@gmail.com> writes:
> On 08/12/06, Yann Dirson <ydirson@altern.org> wrote:
>> - shortcuts (st -> status, etc.), possibly making use of the git alias
>> system ?
>
> Did this last night as it was pretty easy and without the GIT alias
> system (which I am not familiar with). The idea is that if it cannot
> find an exact match, it tries to look for all the commands starting
> with the passed argument. If more than one command is found, it
> reports an "ambiguous command".
That approach can cause problems later on. If "stgit st" is currently
a unique prefix of "stgit status", people might use it in scripts.
Then, one day, you add the "stgit store" command, or whatever, and
their scripts start breaking for no good reason.
--
David Kågedal
^ permalink raw reply
* [PATCH] Remove uncontested renamed files during merge.
From: Shawn O. Pearce @ 2006-12-13 9:55 UTC (permalink / raw)
To: Junio C Hamano, Johannes Schindelin; +Cc: git
Prior to 65ac6e9c3f47807cb603af07a6a9e1a43bc119ae we deleted a
file from the working directory during a merge if the file existed
in the working directory before the merge started but was renamed
by the branch which is being merged in. This broke in 65ac63 as
git-merge-recursive did not actually update the working directory
on this uncontested rename case.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
The same repository that spawned my 'Bug in merge-recursive in
virtual commit corner case' thread discovered this feature of
git-merge-recursive today.
I'm not sure this is the right way to fix the issue, but it does
appear to fix the problem and passes both the existing tests and
this new one.
merge-recursive.c | 2 +-
t/t6024-merge-rename2.sh | 97 ++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 98 insertions(+), 1 deletions(-)
diff --git a/merge-recursive.c b/merge-recursive.c
index 9d53bcd..741d17f 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -873,7 +873,7 @@ static int process_renames(struct path_list *a_renames,
struct diff_filespec src_other, dst_other;
int try_merge, stage = a_renames == renames1 ? 3: 2;
- remove_file(1, ren1_src, 1);
+ remove_file(1, ren1_src, 0);
hashcpy(src_other.sha1, ren1->src_entry->stages[stage].sha);
src_other.mode = ren1->src_entry->stages[stage].mode;
diff --git a/t/t6024-merge-rename2.sh b/t/t6024-merge-rename2.sh
new file mode 100755
index 0000000..69c66cf
--- /dev/null
+++ b/t/t6024-merge-rename2.sh
@@ -0,0 +1,97 @@
+#!/bin/sh
+
+test_description='Merge-recursive merging renames'
+. ./test-lib.sh
+
+test_expect_success setup \
+'
+cat >A <<\EOF &&
+a aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
+b bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
+c cccccccccccccccccccccccccccccccccccccccccccccccc
+d dddddddddddddddddddddddddddddddddddddddddddddddd
+e eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
+f ffffffffffffffffffffffffffffffffffffffffffffffff
+g gggggggggggggggggggggggggggggggggggggggggggggggg
+h hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh
+i iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii
+j jjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjj
+k kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk
+l llllllllllllllllllllllllllllllllllllllllllllllll
+m mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm
+n nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn
+o oooooooooooooooooooooooooooooooooooooooooooooooo
+EOF
+
+cat >M <<\EOF &&
+A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
+B BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
+C CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
+D DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD
+E EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
+F FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
+G GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG
+H HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
+I IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII
+J JJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJ
+K KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK
+L LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL
+M MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM
+N NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
+O OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
+EOF
+
+git add A M &&
+git commit -m "initial has A and M" &&
+git branch white &&
+git branch red &&
+
+git checkout white &&
+sed -e "/^g /s/.*/g : white changes a line/" <A >B &&
+sed -e "/^G /s/.*/G : colored branch changes a line/" <M >N &&
+rm -f A M &&
+git update-index --add --remove A B M N &&
+git commit -m "white renames A->B, M->N" &&
+
+git checkout red &&
+echo created by red >R &&
+git update-index --add R &&
+git commit -m "red creates R" &&
+
+git checkout master'
+
+# This test broke in 65ac6e9c3f47807cb603af07a6a9e1a43bc119ae
+test_expect_success 'merge white into red (A->B,M->N)' \
+'
+ git checkout -b red-white red &&
+ git merge white &&
+ git write-tree >/dev/null || {
+ echo "BAD: merge did not complete"
+ return 1
+ }
+
+ test -f B || {
+ echo "BAD: B does not exist in working directory"
+ return 1
+ }
+ test -f N || {
+ echo "BAD: N does not exist in working directory"
+ return 1
+ }
+ test -f R || {
+ echo "BAD: R does not exist in working directory"
+ return 1
+ }
+
+ test -f A && {
+ echo "BAD: A still exists in working directory"
+ return 1
+ }
+ test -f M && {
+ echo "BAD: M still exists in working directory"
+ return 1
+ }
+ return 0
+'
+
+test_done
--
^ permalink raw reply related
* Re: t9100-git-svn-basic.sh fails
From: Junio C Hamano @ 2006-12-13 9:53 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20061213094320.GD8179@localdomain>
Eric Wong <normalperson@yhbt.net> writes:
> Junio:
> can you please cherry-pick that commit (and also apply
> "git-svn: correctly display fatal() error messages"
> (Message-Id: <11659636263755-git-send-email-normalperson@yhbt.net>)
> into maint?
Done.
^ permalink raw reply
* Re: [PATCH] git-add --interactive (wip)
From: Andreas Ericsson @ 2006-12-13 9:20 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Josef Weidendorfer, git
In-Reply-To: <Pine.LNX.4.63.0612122311400.2807@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> Hi,
>
> On Tue, 12 Dec 2006, Junio C Hamano wrote:
>
>> So in short, I think per-hunk update-index is a cute hack and may be
>> useful in a narrow simple cases, but it would not be so useful in the
>> real life.
>
> To the contrary! In spite of having written git-hunk-commit to please
> those poor souls coming from the darcs side, I already used it myself
> quite often! I think it is a killer feature.
>
I've tried it a couple of times as well, and it really is very, very
nice, especially for young projects where you know you have to make
loads of changes (often basic and codewise small features).
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply
* Re: t9100-git-svn-basic.sh fails
From: Eric Wong @ 2006-12-13 9:43 UTC (permalink / raw)
To: Junio C Hamano, Sebastian Harl; +Cc: git
In-Reply-To: <20061213084620.GN2476@albany.tokkee.org>
Sebastian Harl <sh@tokkee.org> wrote:
> Hi,
>
> On Wed, Dec 13, 2006 at 01:03:21AM +0100, Johannes Schindelin wrote:
> > On Wed, 13 Dec 2006, Sebastian Harl wrote:
> >
> > > When compiling git 1.4.4.2 on my Debian Sarge box t9100-git-svn-basic.sh
> > > fails with the following output:
> > >
> > > * FAIL 6: detect node change from directory to file #1
> > > git-svn commit --find-copies-harder --rmdir \
> > > remotes/git-svn..mybranch2
> >
> > Could you please run the test like this:
> >
> > git/t> sh t9100-* -i -v
>
> * expecting failure: git-svn commit --find-copies-harder --rmdir remotes/git-svn..mybranch2
> diff-tree 5d3b7d019e8fa8d509091bd1d80113c8f20f9f4f 91d77f97b74783aa97ba2aed5a966e936eb9d30f
> Transaction is out of date: Out of date: 'test-git-svn/bar' in transaction '2-2' at /home/tokkee/projects/debian/backports/backports.org/git-core/git-core-1.4.4.2/t/../git-svn line 1573
> 65280 at /home/tokkee/projects/debian/backports/backports.org/git-core/git-core-1.4.4.2/t/../git-svn line 575
> main::commit_lib('91d77f97b74783aa97ba2aed5a966e936eb9d30f') called at /home/tokkee/projects/debian/backports/backports.org/git-core/git-core-1.4.4.2/t/../git-svn line 481
> main::commit('remotes/git-svn..mybranch2') called at /home/tokkee/projects/debian/backports/backports.org/git-core/git-core-1.4.4.2/t/../git-svn line 173
> * FAIL 6: detect node change from directory to file #1
> git-svn commit --find-copies-harder --rmdir remotes/git-svn..mybranch2
Oh, *smacks head* I'm only half-awake at the moment, but
it looks like 1.4.4.2 doesn't have commit
d25c26e771fdf771f264dc85be348719886d354f
(git-svn: exit with status 1 for test failures)
Junio:
can you please cherry-pick that commit (and also apply
"git-svn: correctly display fatal() error messages"
(Message-Id: <11659636263755-git-send-email-normalperson@yhbt.net>)
into maint?
Thanks.
--
^ 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