* [PATCH 1/2] Accept root <tree-ish> in 'git-svn commit-diff'
From: Sergey Yanovich @ 2007-06-17 19:38 UTC (permalink / raw)
To: git, normalperson; +Cc: Sergey Yanovich
In-Reply-To: <11821091373273-git-send-email-ynvich@gmail.com>
Signed-off-by: Sergey Yanovich <ynvich@gmail.com>
---
git-svn.perl | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 50128d7..8ad291b 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -2572,7 +2572,12 @@ sub generate_diff {
}
push @diff_tree, '--find-copies-harder' if $_find_copies_harder;
push @diff_tree, "-l$_rename_limit" if defined $_rename_limit;
- push @diff_tree, $tree_a, $tree_b;
+ if ($tree_a eq '0000000000000000000000000000000000000000') {
+ push @diff_tree, '--root';
+ } else {
+ push @diff_tree, $tree_a;
+ }
+ push @diff_tree, $tree_b;
my ($diff_fh, $ctx) = command_output_pipe(@diff_tree);
local $/ = "\0";
my $state = 'meta';
@@ -2606,6 +2611,8 @@ sub generate_diff {
}
$x->{file_b} = $_;
$state = 'meta';
+ } elsif ($state eq 'meta' && $_ eq $tree_b &&
+ $tree_a eq '0000000000000000000000000000000000000000') {
} else {
croak "Error parsing $_\n";
}
--
1.5.2.1
^ permalink raw reply related
* Re: repack behaves unexpectedly if called in a bare _subrepo_
From: Alex Riesen @ 2007-06-17 19:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vir9mzeao.fsf@assigned-by-dhcp.pobox.com>
Junio C Hamano, Sun, Jun 17, 2007 19:22:39 +0200:
> > Just a heads-up. This took me by surprise. And I suppose it will be
> > the same even if the subrepo is a real subproject.
> >
> > To illustrate:
> >
> > (
> > mkdir super && cd super
> > git init
> > echo 0 > a; git add a; git commit -m0
> > echo 2 >> a; git commit -a -m1
> > echo 3 >> a; git commit -a -m2
> > cp -a .git sub
> > cd sub
> > git --bare config --bool core.bare true
> > git repack -a -d
> > )
>
> I think what is happening is that in that bare repository 'sub',
> the sequence we find where a git repository is is defined so
> that the current directory is checked way after "one of my
> parents with .git/ subdirectory" check.
Yes, that's what I found. Couldn't convince myself it could be wrong,
feels right to me.
> If super (a directory) has a subproject sub as its subproject,
> then you would be copying .git to sub/.git, not sub/, wouldn't
> you?
Yes, very likely. But it is not a super project in subproject sense,
and why? Is there a reason I can't have a bare subproject?
> What are you trying to achieve?
I mirror some projects I am interested in. There is a directory where
all the mirrors are: ~/src. It contains the git/git-svn/git-cvs
repositories _and_ the scripts which do the mirroring:
$ ls -a
./ gitk/ motion.gitsvn/ uclibc.gitsvn/
../ gnulib.git/ moto4lin/ udev/
busybox.gitsvn/ gpsbabel.git/ mutt/ udhcp.gitsvn/
coreutils.git/ historic/ rt2500/ update-gits*
count-git-objects* .htaccess sparse/ use-src/
dclock/ iproute2.git/ sunset/ wireless-2.6.git/
git/ klibc/ tig/
.git/ linux.git/ torsmo/
.gitignore mimesplit3/ tuner/
The super in my example is this ~/src, and it keeps track of changes
to the scripts (some mirrors can be complicated, so I wanted to be
prepared). Felt kind of natural to do it this way. Until I tried to
repack the mirrored repos, and it didn't work as I expected. The repos
are not tracked as subprojects (in fact, they're .gitignored).
There is no point for me to have working directories for the mirrors:
it is my home server, if I do something, I do it elsewhere.
It is not exactly a "problem", and anyway there is a couple of
solutions (pass --bare, create <mirror>/.git, for instance), I just
fall into it and though it'd be a good idea to let others know.
^ permalink raw reply
* Re: [PATCH] mergetool: make Apple's FileMerge available as a merge_tool
From: Steffen Prohaska @ 2007-06-17 19:20 UTC (permalink / raw)
To: Theodore Tso; +Cc: Git Mailing List
In-Reply-To: <20070617181200.GA15218@thunk.org>
On Jun 17, 2007, at 8:12 PM, Theodore Tso wrote:
> On Sun, Jun 17, 2007 at 06:13:11PM +0200, Steffen Prohaska wrote:
>
>> I wasn't aware of this fact. git-mergetool proposed to use vimdiff
>> although I had preferred the graphical application FileMerge, which
>> would have been launched by opendiff.
>
> Do you know of a way of determining whether or not under MacOS X, a
> program can easily determine whether or not the user is sitting in
> front of the graphical display, as opposed to coming in via an SSH
> connection?
this might do the job:
--- SNIP ---
#! /bin/sh
pid=$$
while [ $pid -ne 1 ] ; do
command=$(ps -p $pid | tail -n 1 | cut -b 27-)
echo $command | grep -q sshd && { echo "ssh" ; exit ; }
echo $command | grep -q Terminal && { echo "local" ; exit ; }
pid=$(ps -O ppid -p $pid | tail -n 1 | cut -b 6-11)
done
echo "unknown"
--- SNIP ---
> If so, we could use that under MacOS to make the defaults be to use
> opendiff under those circumstances.
>
> Realistically, though, past a certain point we can only be so smart
> with the heuristics. If you know what you want, you should really set
> the merge.tool config option in your ~/.gitconfig file, and be done
> with it.
Well, I'm done with it. I learned that opendiff and FileMerge are the
same, which I wasn't aware of before.
>> Don't know if my patch makes any sense. Probably a note in the
>> documentation that opendiff launches the GUI would be nice.
>
> Maybe a change so that opendiff is listed as "opendiff (aka
> FileMerge)", perhaps?
perhaps. It wouldn't make things worse.
Steffen
^ permalink raw reply
* Re: Newbie using git -- need a little help
From: Thomas Glanzmann @ 2007-06-17 19:17 UTC (permalink / raw)
To: Robert Smith; +Cc: git
In-Reply-To: <42118.74778.qm@web57410.mail.re1.yahoo.com>
Hello Robert,
> I'm not sure what I'm doing wrong. I see the change once the tree is
> pushed to the server (from the desktop), but it is undone
> automatically with a git commit -a.
When you push to your server, the repository is updated (that is the
thing that is in .git) but your working tree isn't.
So when you push to a repository that also has a working tree attached
to it, you have to do a "git checkout" on the working tree. Or pull from
the repository and not push to it.
For a long time I did the same thing you did. I had a repository with a
working tree that I pushed into. I did it with bitkeeper and I did with
git. However these days I dropped that idea because it is not worth the
trouble (and it wasn't from the beginning) I just got used to it and did
not thought about it.
What I do now is the following:
On my laptop:
mkdir dir
git init
# add some files
git add .
git commit
Than I publish my project to the server without giving the repository at
the server a working directory attached to it. A working directory is
where you can edit files and commit changes locally, just in case I
didn't introduce the term yet.
# This creates the repository _without_ the working tree on the server.
ssh 131.188.30.102 git --git-dir=/home/cip/adm/sithglan/work/repositories/private/astro.git init-db
# This adds the remote origin to the config so that I don't have to
# type in the long repository path each time I am going to push or pull
# something.
git remote add origin 131.188.30.102:/home/cip/adm/sithglan/work/repositories/private/astro.git
# Now I publish my stuff to the central repository. You need at least
# one commit in order to be able to do that.
git push origin master:master
# I add a few lines to my config so that when I type in "git pull" it
#fetches the stuff and merges it with my local repositories master branch.
"vim .git/config" and add the following lines:
[branch "master"]
remote = origin
merge = refs/heads/master
EOF
# Now I can fetch back to see if everything works
git pull
Now I am fine the infrastructure is all set up. The next time I am going
to access the project from a different machine I simply do:
git pull 131.188.30.102:/home/cip/adm/sithglan/work/repositories/private/astro.git
And that's it. The origin and where it is going to merge stuff is set
automatically up by git. Note: I use ssh (attached to a ssh-agent so that I
don't have to passwords all the time I am doing a push or pull). I hope that
helps you and didn't miss your original question. I just fly over your e-Mail
and picked a few keywords to comment on.
Thomas
^ permalink raw reply
* Newbie using git -- need a little help
From: Robert Smith @ 2007-06-17 18:55 UTC (permalink / raw)
To: git
Hi,
I apologize right off the bat for the stupid newbie questions. I've read over the documentation (the full manual) numerous times and must admit it's slightly overwhelming. What I'm trying to do is pretty basic, though, so hopefully someone can help me out. Please forgive me for the long post (I'm going to try to describe exactly what I'm doing so that someone can point me to what I'm doing wrong).
I have both a desktop computer, a laptop, and a server where I host my git repository. The goal for having this public repository is for me to be able to
program on my desktop, then push the changes to the server, and then
continue development on, say, my laptop later on grabbing the newer tree. Here's what I've done so far:
On the server, I've put all my programming projects. Then I did a:
git init && git add . && git commit -a
in one of my project directories.
I have a git-daemon running on this server so that people (me, for the most part :)) can pull my tree.
So on one of my two machines (desktop/laptop), I then clone the tree:
git clone git://my.server.com/project
It downloads the tree just fine. Then I go into the directory and start making changes. Here's an example:
---------------
>> on the desktop <<
~/temp rsmith$ git clone git://my.server.com/testing
Initialized empty Git repository in /home/rsmith/temp/testing/.git/
remote: Generating pack...
Done counting 3 objects.
Deltifying 3 objects...
remote: /3) done
Total 3 (delta 0), reused 0 (delta 0)
Indexing 3 objects.
100% (3/3) done
~/temp rsmith$ cd testing/
~/temp/testing rsmith$ ls
testing
~/temp/testing rsmith$ cat testing
This is a file that was created on the repository (server) machine...
~/temp/testing rsmith$ echo "I put this line in using the client (cloned) tree... I want to push this change up to the server that has the repo." >> testing
~/temp/testing rsmith$ cat testing
This is a file that was created on the repository (server) machine...
I put this line in using the client (cloned) tree... I want to push this change up to the server that has the repo.
~/temp/testing rsmith$ git commit -a
Created commit bae2b3e9a8d939cc3982b9ab398eb398eb29a13
1 files changed, 1 insertions(+), 0 deletions(-)
~/temp/testing rsmith$ git show
commit bae2b3e9a8d939cc3982b9ab398eb398eb29a13
Author: Robert Smith <wolf1boy79@yahoo.com>
Date: Sun Jun 17 13:54:59 2007 -0400
Added an extra line to the file...
diff --git a/testing b/testing
index ae22fbe..bae5e8f 100644
--- a/testing
+++ b/testing
@@ -1 +1,2 @@
This is a file that was created on the repository (server) machine...
+I put this line in using the client (cloned) tree... I want to push this change up to the server that has the repo.
---------------
Now I push the tree up to my repository...
>> on the desktop <<
~/temp/testing rsmith$ git push ssh://my.server.com/scm/git/testing master
Password:
updating 'refs/heads/master'
from b39be3baa3b29eb39e98bd92b3ab39bee3b3a291
to bae2b3e9a8d939cc3982b9ab398eb398eb29a13
Generating pack...
Done counting 5 objects.
Result has 3 objects.
Deltifying 3 objects.
100% (3/3) done
Writing 3 objects.
100% (3/3) done
Total 3 (delta 0), reused 0 (delta 0)
Unpacking 3 objects
refs/heads/master: b39be3baa3b29eb39e98bd92b3ab39bee3b3a291 -> bae2b3e9a8d939cc3982b9ab398eb398eb29a13
---------------
Now, on the SERVER (the machine with the repository that I pushed my tree to), I can see the changes by doing a "git show"...
~/scm/git/testing rsmith$ git show
commit bae2b3e9a8d939cc3982b9ab398eb398eb29a13
Author: Robert Smith <wolf1boy79@yahoo.com>
Date: Sun Jun 17 14:22:26 2007 -0400
Added an extra line to the file...
diff --git a/testing b/testing
index ae22fbe..bae5e8f 1206be
--- a/testing
+++ b/testing
@@ -1 +1,2 @@
This is a file that was created on the repository machine...
+I put this line in using the client (cloned) tree... I want to push this change up to the server that has the repo.
lines 1-13/13 (END)
HOWEVER, the testing file still doesn't show the change... (look below)
~/scm/git/testing rsmith$ cat testing
This is a file that was created on the repository machine...
So I figure I'll go ahead and commit the changes (since "git show" shows that the change has been pushed from the desktop to the server)... I go ahead and do a "git commit -a" on the SERVER...
commit b3eebe298b2399238a3becc9823b3982109ebea
Author: Robert Smith <wolf1boy79@yahoo.com>
Date: Sun Jun 17 14:34:11 2007 -0400
Testing.
diff --git a/testing b/testing
index b3ab382..3b32098a 102415
--- a/testing
+++ b/testing
@@ -1,2 +1 @@
This is a file that was created on the repository machine...
-I put this line in using the client (cloned) tree... I want to push this change up to the server that has the repo.
---------------
I'm not sure what I'm doing wrong. I see the change once the tree is pushed to the server (from the desktop), but it is undone automatically with a git commit -a. According to the documentation, everything up to the "push" step seems to be correct... But what do I do once I pushed the tree up to the public repo? How do I get those changes to be reflected on the public repo (the server?) without a git commit -a undoing those changes I've made?
Any ideas/help would be greatly appreciated.
- robert -
____________________________________________________________________________________
Be a PS3 game guru.
Get your game face on with the latest PS3 news and previews at Yahoo! Games.
http://videogames.yahoo.com/platform?platform=120121
^ permalink raw reply related
* git tool to keep a subversion mirror
From: Sergey Yanovich @ 2007-06-17 18:49 UTC (permalink / raw)
To: git, normalperson
I am actively using git for my project. Thanks everyone envolved.
However, I got tired of administering own web server and registered my
project at sourceforge. Unlike repo.or.cz (thanks again for everyone
envolved), they do not provide git hosting. But a project without a
source repository is non-sence.
I am not in any way going to use Subversion after I tried git, but I
need to be able to export to a Subversion repository. I found an
excellent tool called 'git-svn'. However, the flawed nature of
Subversion put shackles on normal git usage after you do 'git-svn init'.
Since git is the best scm system, my situation is probably quite common.
So I am filing these patches.
There is a 'git-svn' command which does want I need, so I created a
simple wrapper around it. I also found that 'git-svn commit-diff' is
having a small trouble dealing with root <tree-ish>, which is corrected
by an attached patch.
^ permalink raw reply
* Re: [PATCH] mergetool: make Apple's FileMerge available as a merge_tool
From: Theodore Tso @ 2007-06-17 18:12 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Git Mailing List
In-Reply-To: <B12626B9-766E-4EA4-888F-B3E2DA889D15@zib.de>
On Sun, Jun 17, 2007 at 06:13:11PM +0200, Steffen Prohaska wrote:
>
> Hmm, now I found out that opendiff, which was already available
> as an option, actually launches FileMerge.
Yep.
> I wasn't aware of this fact. git-mergetool proposed to use vimdiff
> although I had preferred the graphical application FileMerge, which
> would have been launched by opendiff.
Do you know of a way of determining whether or not under MacOS X, a
program can easily determine whether or not the user is sitting in
front of the graphical display, as opposed to coming in via an SSH
connection?
If so, we could use that under MacOS to make the defaults be to use
opendiff under those circumstances.
Realistically, though, past a certain point we can only be so smart
with the hueristics. If you know what you want, you should really set
the merge.tool config option in your ~/.gitconfig file, and be done
with it.
> Don't know if my patch makes any sense. Probably a note in the
> documentation that opendiff launches the GUI would be nice.
Maybe a change so that opendiff is listed as "opendiff (aka
FileMerge)", perhaps?
- Ted
^ permalink raw reply
* Re: repack behaves unexpectedly if called in a bare _subrepo_
From: Junio C Hamano @ 2007-06-17 17:22 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20070617153810.GB2763@steel.home>
Alex Riesen <raa.lkml@gmail.com> writes:
> Just a heads-up. This took me by surprise. And I suppose it will be
> the same even if the subrepo is a real subproject.
>
> To illustrate:
>
> (
> mkdir super && cd super
> git init
> echo 0 > a; git add a; git commit -m0
> echo 2 >> a; git commit -a -m1
> echo 3 >> a; git commit -a -m2
> cp -a .git sub
> cd sub
> git --bare config --bool core.bare true
> git repack -a -d
> )
I think what is happening is that in that bare repository 'sub',
the sequence we find where a git repository is is defined so
that the current directory is checked way after "one of my
parents with .git/ subdirectory" check.
If super (a directory) has a subproject sub as its subproject,
then you would be copying .git to sub/.git, not sub/, wouldn't
you? What are you trying to achieve?
^ permalink raw reply
* Re: [PATCH] cvsserver: fix legacy cvs client and branch rev issues
From: Frank Lichtenheld @ 2007-06-17 17:20 UTC (permalink / raw)
To: Dirk Koopman; +Cc: git
In-Reply-To: <46756707.5020805@tobit.co.uk>
On Sun, Jun 17, 2007 at 05:53:27PM +0100, Dirk Koopman wrote:
> Frank Lichtenheld wrote:
> >Summary: You're (ab)using cvsserver in very interesting ways that are not
> >really beeing thought of in the current design/implementation. There'll
> >be dragons ;)
> >
>
> Hmm... I think that is becoming clear. The trouble is that I am not at
> all certain that what I am doing is particularly unusual. After all,
> using git, the whole point is that working on branches or the main line
> should easy and cheap!
Sure, it is a know limitation of cvsserver. But it is not trivially
to remove. Patches welcome ;)
Gruesse,
--
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
^ permalink raw reply
* Re: [PATCH] cvsserver: fix legacy cvs client and branch rev issues
From: Dirk Koopman @ 2007-06-17 16:53 UTC (permalink / raw)
To: Frank Lichtenheld; +Cc: git
In-Reply-To: <20070617103744.GE1828@planck.djpig.de>
Frank Lichtenheld wrote:
>
> Summary: You're (ab)using cvsserver in very interesting ways that are not
> really beeing thought of in the current design/implementation. There'll
> be dragons ;)
>
Hmm... I think that is becoming clear. The trouble is that I am not at
all certain that what I am doing is particularly unusual. After all,
using git, the whole point is that working on branches or the main line
should easy and cheap!
If it were me, I might have been inclined to always set Repository to
'master' (or even to the name of the repository with .git removed), then
git checkout <tag> <file> each file, one at a time, using the (<tag> ||
'master') from each Entry that is sent. So with no tag, you get the
master copy, otherwise the <tag>ged copy - this all assuming that the
git repo is set up correctly.
But as I am CVS read only, what is there does for me so I am not
complaining :-) The two people that can also commit can start to use git
and send me patches... Do them good :-)
Dirk
^ permalink raw reply
* Re: [PATCH] mergetool: make Apple's FileMerge available as a merge_tool
From: Steffen Prohaska @ 2007-06-17 16:13 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <11820959413590-git-send-email-prohaska@zib.de>
On Jun 17, 2007, at 5:59 PM, Steffen Prohaska wrote:
> Apple's developer tools include the application FileMerge,
> which supports graphical three way merges with ancestor.
> This patch makes the tool available through git-mergetool.
>
> FileMerge is assumed to be installed at its default location.
Hmm, now I found out that opendiff, which was already available
as an option, actually launches FileMerge.
I wasn't aware of this fact. git-mergetool proposed to use vimdiff
although I had preferred the graphical application FileMerge, which
would have been launched by opendiff.
Don't know if my patch makes any sense. Probably a note in the
documentation that opendiff launches the GUI would be nice.
Steffen
^ permalink raw reply
* Re: git-p4 fails when cloning a p4 depo.
From: Benjamin Sergeant @ 2007-06-17 16:09 UTC (permalink / raw)
To: Simon Hausmann; +Cc: git
In-Reply-To: <200706171011.52492.simon@lst.de>
[-- Attachment #1: Type: text/plain, Size: 1812 bytes --]
On 6/17/07, Simon Hausmann <simon@lst.de> wrote:
> On Tuesday 12 June 2007 03:13:17 Han-Wen Nienhuys wrote:
> > Benjamin Sergeant escreveu:
> > > A perforce command with all the files in the repo is generated to get
> > > all the file content.
> > > Here is a patch to break it into multiple successive perforce command
> > > who uses 4K of parameter max, and collect the output for later.
> > >
> > > It works, but not for big depos, because the whole perforce depo
> > > content is stored in memory in P4Sync.run(), and it looks like mine is
> > > bigger than 2 Gigs, so I had to kill the process.
> >
> > General idea of the patch is ok. some nits:
> > > + chunk = ''
> > > + filedata = []
> > > + for i in xrange(len(files)):
> >
> > why not
> >
> > for f in files:
> >
> > ?
>
> It seems 'i' is used a bit later. Is there a nicer way to express this in
> python?
>
> > > + f = files[i]
> > > + chunk += '"%s#%s" ' % (f['path'], f['rev'])
> > > + if len(chunk) > 4000 or i == len(files)-1:
> >
> > 4k seems reasonable enough, but can you take the min() with
> > os.sysconf('SC_ARG_MAX') ?
> >
> > Can you address this and resend so we can apply the patch?
> > Thanks.
>
> Since I ran into the very problem of a too long commandline myself yesterday I
> took the liberty of adding the SC_ARG_MAX bit to Benjamin's patch and
> comitting it then.
>
Cool.
(probably useless but)
For what it's worth ; Here is a tar file with 2 patchs:
- The original one
- The second one that adds the SC_ARG_MAX
BTW, doing a += on a string is not supposed to be fast, appending elem
to a sequence and then using ' '.join on them to build the big string
is said to be faster (I did not timed it thought). (in the second
patch also)
Thanks,
Benjamin.
>
> Simon
>
>
[-- Attachment #2: p4-sync-chunks.tar --]
[-- Type: application/x-tar, Size: 10240 bytes --]
^ permalink raw reply
* [PATCH] mergetool: make Apple's FileMerge available as a merge_tool
From: Steffen Prohaska @ 2007-06-17 15:59 UTC (permalink / raw)
To: git; +Cc: Steffen Prohaska
Apple's developer tools include the application FileMerge,
which supports graphical three way merges with ancestor.
This patch makes the tool available through git-mergetool.
FileMerge is assumed to be installed at its default location.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
Documentation/git-mergetool.txt | 3 ++-
git-mergetool.sh | 20 ++++++++++++++++++++
2 files changed, 22 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-mergetool.txt b/Documentation/git-mergetool.txt
index 6c32c6d..ff4cdf2 100644
--- a/Documentation/git-mergetool.txt
+++ b/Documentation/git-mergetool.txt
@@ -25,7 +25,8 @@ OPTIONS
-t or --tool=<tool>::
Use the merge resolution program specified by <tool>.
Valid merge tools are:
- kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, and opendiff
+ kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, opendiff,
+ and FileMerge
+
If a merge resolution program is not specified, 'git mergetool'
will use the configuration variable merge.tool. If the
diff --git a/git-mergetool.sh b/git-mergetool.sh
index 7b66309..abe2a97 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -258,6 +258,16 @@ merge_file () {
status=$?
save_backup
;;
+ *FileMerge)
+ touch "$BACKUP"
+ if base_present; then
+ $merge_tool -left "$LOCAL" -right "$REMOTE" -ancestor "$BASE" -merge "$path" | cat
+ else
+ $merge_tool -left "$LOCAL" -right "$REMOTE" -merge "$path" | cat
+ fi
+ check_unchanged
+ save_backup
+ ;;
esac
if test "$status" -ne 0; then
echo "merge of $path failed" 1>&2
@@ -326,6 +336,9 @@ if test -z "$merge_tool" ; then
merge_tool_candidates="$merge_tool_candidates vimdiff"
fi
merge_tool_candidates="$merge_tool_candidates opendiff emerge vimdiff"
+ if test $(uname) = "Darwin" ; then
+ merge_tool_candidates="/Developer/Applications/Utilities/FileMerge.app/Contents/MacOS/FileMerge $merge_tool_candidates"
+ fi
echo "merge tool candidates: $merge_tool_candidates"
for i in $merge_tool_candidates; do
if test $i = emerge ; then
@@ -357,6 +370,13 @@ case "$merge_tool" in
exit 1
fi
;;
+ *FileMerge)
+ merge_tool=/Developer/Applications/Utilities/FileMerge.app/Contents/MacOS/FileMerge
+ if ! test -x $merge_tool ; then
+ echo "FileMerge is not available"
+ exit 1
+ fi
+ ;;
*)
echo "Unknown merge tool: $merge_tool"
exit 1
--
1.5.2.2.252.gbc777-dirty
^ permalink raw reply related
* Re: [PATCH 1/2] git-submodule: move cloning into a separate function
From: Lars Hjemli @ 2007-06-17 15:56 UTC (permalink / raw)
To: skimo; +Cc: Johannes Sixt, git@vger.kernel.org
In-Reply-To: <20070617143802.GV955MdfPADPa@greensroom.kotnet.org>
On 6/17/07, Sven Verdoolaege <skimo@kotnet.org> wrote:
> On Tue, Jun 05, 2007 at 01:13:28PM +0200, Lars Hjemli wrote:
> > +module_clone()
> > +{
> > + path=$1
> > + url=$2
> > +
> > + # If there already is a directory at the submodule path,
> > + # expect it to be empty (since that is the default checkout
> > + # action) and try to remove it.
> > + # Note: if $path is a symlink to a directory the test will
> > + # succeed but the rmdir will fail. We might want to fix this.
> > + if test -d "$path"
> > + then
> > + rmdir "$path" 2>/dev/null ||
> > + die "Directory '$path' exist, but is neither empty nor a git repository"
>
> What makes you say that '$path' is not a git repository?
>
The function assumes it's only invoked when no repo is present in $path/.git.
--
larsh
^ permalink raw reply
* Re: [PATCH] gitweb: Add test t9500 for gitweb (as standalone script)
From: Sven Verdoolaege @ 2007-06-17 15:39 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <11795339604115-git-send-email-jnareb@gmail.com>
On Sat, May 19, 2007 at 02:19:20AM +0200, Jakub Narebski wrote:
> This test runs gitweb (git web interface) as CGI script from
> commandline, and checks that it would not write any errors
> or warnings to log.
Could you please skip this test if the version of perl is too old?
In particular, I get
[Sun Jun 17 17:28:11 2007] gitweb.perl: Too many arguments for Encode::decode_utf8 at ../../gitweb/gitweb.perl line 618, near "Encode::FB_CROAK)"
[Sun Jun 17 17:28:11 2007] gitweb.perl: Execution of ../../gitweb/gitweb.perl aborted due to compilation errors.
My Encode.pm has
----
sub decode_utf8($)
{
my ($str) = @_;
return undef unless utf8::decode($str);
return $str;
}
----
Curiously, it also has
----
=item $string = decode_utf8($octets [, CHECK]);
equivalent to C<$string = decode("utf8", $octets [, CHECK])>.
The sequence of octets represented by
$octets is decoded from UTF-8 into a sequence of logical
characters. Not all sequences of octets form valid UTF-8 encodings, so
it is possible for this call to fail. For CHECK, see
L</"Handling Malformed Data">.
----
In any case, I don't feel like upgrading perl just for gitweb
on this machine.
bash-3.00$ perl -V
Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration:
Platform:
osname=linux, osvers=2.4.18, archname=i686-linux-thread-multi
uname='linux greensroom 2.4.18 #2 smp fri jul 19 13:03:13 cest 2002 i686 unknown '
config_args='-Doptimize=-g -Dprefix=/usr -Dusedevel -Dusethreads -Duseithreads -Duseshrplib -Dinstallusrbinperl -des'
hint=recommended, useposix=true, d_sigaction=define
usethreads=define use5005threads=undef useithreads=define usemultiplicity=define
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DDEBUGGING -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
optimize='-g',
cppflags='-D_REENTRANT -D_GNU_SOURCE -DDEBUGGING -fno-strict-aliasing -I/usr/local/include'
ccversion='', gccversion='2.95.3 20010315 (SuSE)', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
alignbytes=4, prototype=define
Linker and Libraries:
ld='cc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lnsl -lndbm -lgdbm -ldb -ldl -lm -lpthread -lc -lcrypt -lutil
perllibs=-lnsl -ldl -lm -lpthread -lc -lcrypt -lutil
libc=, so=so, useshrplib=true, libperl=libperl.so
gnulibc_version='2.2.5'
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic -Wl,-rpath,/usr/lib/perl5/5.8.0/i686-linux-thread-multi/CORE'
cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'
Characteristics of this binary (from libperl):
Compile-time options: DEBUGGING MULTIPLICITY USE_ITHREADS USE_LARGE_FILES PERL_IMPLICIT_CONTEXT
Built under linux
Compiled at Jul 19 2002 18:11:28
@INC:
/usr/lib/perl5/5.8.0/i686-linux-thread-multi
/usr/lib/perl5/5.8.0
/usr/lib/perl5/site_perl/5.8.0/i686-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.0
/usr/lib/perl5/site_perl
.
skimo
^ permalink raw reply
* repack behaves unexpectedly if called in a bare _subrepo_
From: Alex Riesen @ 2007-06-17 15:38 UTC (permalink / raw)
To: git
Just a heads-up. This took me by surprise. And I suppose it will be
the same even if the subrepo is a real subproject.
To illustrate:
(
mkdir super && cd super
git init
echo 0 > a; git add a; git commit -m0
echo 2 >> a; git commit -a -m1
echo 3 >> a; git commit -a -m2
cp -a .git sub
cd sub
git --bare config --bool core.bare true
git repack -a -d
)
Unexpectedly, the "super" repo is repacked, even though repack is
called from the "sub". To actually repack the repo in the current
directory if it is bare, use "git --bare repack ...".
This kind of makes core.bare pointless: can't rely on it anyway.
^ permalink raw reply
* GIT_DIR question
From: Yakov Lerner @ 2007-06-17 15:34 UTC (permalink / raw)
To: git
In-Reply-To: <f36b08ee0706170829w59979d86i7bf09bc35ff28fca@mail.gmail.com>
I wanted to create cloned repo, but with metaninfo separately from data.
I cloned the repo ( git-clone ~/repo ~/x) ,
then I moved ~/x/.git to different place (mv ~/x/.git ~/git);
then exported GIT_DIR=~/git; then
cd ~/x;
But now 'git status' says 'fatal: runstatus must be run in a work tree' . Why ?
'ls $GIT_DIR' shows
FETCH_HEAD HEAD ORIG_HEAD branches config
description hooks index info logs objects refs
This is ok, no ?
Thanks
Yakov
^ permalink raw reply
* [PATCH] git-submodule: provide easy way of adding new submodules
From: Sven Verdoolaege @ 2007-06-17 15:23 UTC (permalink / raw)
To: git, Lars Hjemli, Junio C Hamano; +Cc: skimo
To make a submodule effectively usable, the path and
a URL where the submodule can be cloned need to be stored
in .gitmodules. This subcommand takes care of setting
this information after cloning the new submodule.
Only the index is updated, so, if needed, the user may still
change the URL or switch to a different branch of the submodule
before committing.
Signed-off-by: Sven Verdoolaege <skimo@kotnet.org>
---
Documentation/git-submodule.txt | 8 +++++
git-submodule.sh | 65 +++++++++++++++++++++++++++++++++++---
2 files changed, 67 insertions(+), 6 deletions(-)
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index f8fb80f..bf9cbf9 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -8,11 +8,19 @@ git-submodule - Initialize, update or inspect submodules
SYNOPSIS
--------
+'git-submodule' [--quiet] add <repository> [<path>]
'git-submodule' [--quiet] [--cached] [status|init|update] [--] [<path>...]
COMMANDS
--------
+add::
+ Add the given repository as a submodule at the given path
+ to the changeset to be committed next. In particular, the
+ repository is cloned at the specified path, added to the
+ changeset and registered in .gitmodules. If no path is
+ specified, the path is deduced from the repository specification.
+
status::
Show the status of the submodules. This will print the SHA-1 of the
currently checked out commit for each submodule, along with the
diff --git a/git-submodule.sh b/git-submodule.sh
index 89a3885..85ae275 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -1,13 +1,14 @@
#!/bin/sh
#
-# git-submodules.sh: init, update or list git submodules
+# git-submodules.sh: add, init, update or list git submodules
#
# Copyright (c) 2007 Lars Hjemli
-USAGE='[--quiet] [--cached] [status|init|update] [--] [<path>...]'
+USAGE='[--quiet] [--cached] [add <repo>|status|init|update] [--] [<path>...]'
. git-sh-setup
require_work_tree
+add=
init=
update=
status=
@@ -25,6 +26,17 @@ say()
fi
}
+get_repo_base() {
+ (
+ cd "`/bin/pwd`" &&
+ cd "$1" || cd "$1.git" &&
+ {
+ cd .git
+ pwd
+ }
+ ) 2>/dev/null
+}
+
#
# Map submodule path to submodule name
#
@@ -66,6 +78,41 @@ module_clone()
}
#
+# Add a new submodule to the working tree, .gitmodules and the index
+#
+# $@ = repo [path]
+#
+module_add()
+{
+ repo=$1
+ path=$2
+
+ # Turn the source into an absolute path if
+ # it is local
+ if base=$(get_repo_base "$repo"); then
+ repo="$base"
+ fi
+
+ # Guess path from repo if not specified or strip trailing slashes
+ if test -z "$path"; then
+ path=$(echo "$repo" | sed -e 's|/*$||' -e 's|:*/*\.git$||' -e 's|.*[/:]||g')
+ else
+ path=$(echo "$path" | sed -e 's|/*$||')
+ fi
+
+ module_clone "$path" "$repo" || exit
+ (unset GIT_DIR && cd "$path" && git checkout -q) ||
+ die "Unable to checkout submodule '$path'"
+ git add "$path" ||
+ die "Failed to add submodule '$path'"
+
+ GIT_CONFIG=.gitmodules git config submodule."$path".path "$path" &&
+ GIT_CONFIG=.gitmodules git config submodule."$path".url "$repo" &&
+ git add .gitmodules ||
+ die "Failed to register submodule '$path'"
+}
+
+#
# Register submodules in .git/config
#
# $@ = requested paths (default to all)
@@ -173,6 +220,9 @@ modules_list()
while case "$#" in 0) break ;; esac
do
case "$1" in
+ add)
+ add=1
+ ;;
init)
init=1
;;
@@ -201,14 +251,17 @@ do
shift
done
-case "$init,$update,$status,$cached" in
-1,,,)
+case "$add,$init,$update,$status,$cached" in
+1,,,,)
+ module_add "$@"
+ ;;
+,1,,,)
modules_init "$@"
;;
-,1,,)
+,,1,,)
modules_update "$@"
;;
-,,*,*)
+,,,*,*)
modules_list "$@"
;;
*)
--
1.5.2.1.1088.ge05f4-dirty
^ permalink raw reply related
* Re: [PATCH 1/2] git-submodule: move cloning into a separate function
From: Sven Verdoolaege @ 2007-06-17 14:38 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Johannes Sixt, git@vger.kernel.org
In-Reply-To: <op.ttf34qd99pspc6@localhost>
On Tue, Jun 05, 2007 at 01:13:28PM +0200, Lars Hjemli wrote:
> +module_clone()
> +{
> + path=$1
> + url=$2
> +
> + # If there already is a directory at the submodule path,
> + # expect it to be empty (since that is the default checkout
> + # action) and try to remove it.
> + # Note: if $path is a symlink to a directory the test will
> + # succeed but the rmdir will fail. We might want to fix this.
> + if test -d "$path"
> + then
> + rmdir "$path" 2>/dev/null ||
> + die "Directory '$path' exist, but is neither empty nor a git repository"
What makes you say that '$path' is not a git repository?
skimo
^ permalink raw reply
* [PATCH] cvsserver: always initialize state in argsplit()
From: Frank Lichtenheld @ 2007-06-17 8:31 UTC (permalink / raw)
To: git; +Cc: Frank Lichtenheld, Dirk Koopman
In-Reply-To: <11820198064114-git-send-email-djk@tobit.co.uk>
Other code assumes that this is initialized, so do it
even if there were no arguments given.
Signed-off-by: Dirk Koopman <djk@tobit.co.uk>
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
---
git-cvsserver.perl | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
Hrm, sorry to Dirk for the double mail. This time actually
send to the list and not to git@localhost ...
diff --git a/git-cvsserver.perl b/git-cvsserver.perl
index 5cbf27e..10aba50 100755
--- a/git-cvsserver.perl
+++ b/git-cvsserver.perl
@@ -1813,14 +1813,14 @@ sub req_annotate
# the second is $state->{files} which is everything after it.
sub argsplit
{
- return unless( defined($state->{arguments}) and ref $state->{arguments} eq "ARRAY" );
-
- my $type = shift;
-
$state->{args} = [];
$state->{files} = [];
$state->{opt} = {};
+ return unless( defined($state->{arguments}) and ref $state->{arguments} eq "ARRAY" );
+
+ my $type = shift;
+
if ( defined($type) )
{
my $opt = {};
--
1.5.2.1
^ permalink raw reply related
* Re: [ANNOUNCE] GIT 1.5.2.2
From: Arkadiusz Miskiewicz @ 2007-06-17 10:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vodjf1gxl.fsf@assigned-by-dhcp.pobox.com>
On Sunday 17 of June 2007, Junio C Hamano wrote:
> The latest maintenance release GIT 1.5.2.2 is available at the
> usual places:
>
> http://www.kernel.org/pub/software/scm/git/
>
> git-1.5.2.2.tar.{gz,bz2} (tarball)
> git-htmldocs-1.5.2.2.tar.{gz,bz2} (preformatted docs)
> git-manpages-1.5.2.2.tar.{gz,bz2} (preformatted docs)
> RPMS/$arch/git-*-1.5.2.2-1.$arch.rpm (RPM)
Should git testsuite (make test) go without any problem? (I'm asking because
some projects have test suites where some tests are expected to fail).
I have 4 failures on amd64/linux and this git release:
* FAIL 11: compare delta flavors
perl -e '
defined($_ = -s $_) or die for @ARGV;
exit 1 if $ARGV[0] <= $ARGV[1];
' test-2-$packname_2.pack test-3-$packname_3.pack
[...]
* FAIL 16: corrupt a pack and see if verify catches
cat test-1-${packname_1}.idx >test-3.idx &&
cat test-2-${packname_2}.pack >test-3.pack &&
if git-verify-pack test-3.idx
then false
else :;
fi &&
: PACK_SIGNATURE &&
cat test-1-${packname_1}.pack >test-3.pack &&
dd if=/dev/zero of=test-3.pack count=1 bs=1 conv=notrunc seek=2
&&
if git-verify-pack test-3.idx
then false
else :;
fi &&
: PACK_VERSION &&
cat test-1-${packname_1}.pack >test-3.pack &&
dd if=/dev/zero of=test-3.pack count=1 bs=1 conv=notrunc seek=7
&&
if git-verify-pack test-3.idx
then false
else :;
fi &&
: TYPE/SIZE byte of the first packed object data &&
cat test-1-${packname_1}.pack >test-3.pack &&
dd if=/dev/zero of=test-3.pack count=1 bs=1 conv=notrunc seek=12
&&
if git-verify-pack test-3.idx
then false
else :;
fi &&
: sum of the index file itself &&
l=`wc -c <test-3.idx` &&
l=`expr $l - 20` &&
cat test-1-${packname_1}.pack >test-3.pack &&
dd if=/dev/zero of=test-3.idx count=20 bs=1 conv=notrunc seek=$l
&&
if git-verify-pack test-3.pack
then false
else :;
fi &&
:
[...]
* FAIL 18: fake a SHA1 hash collision
test -f .git/objects/c8/2de19312b6c3695c0c18f70709a6c535682a67 &&
cp -f .git/objects/9d/235ed07cd19811a6ceb342de82f190e49c9f68
\
.git/objects/c8/2de19312b6c3695c0c18f70709a6c535682a67
* FAIL 19: make sure index-pack detects the SHA1 collision
git-index-pack -o bad.idx test-3.pack
* failed 4 among 19 test(s)
--
Arkadiusz Miśkiewicz PLD/Linux Team
arekm / maven.pl http://ftp.pld-linux.org/
^ permalink raw reply
* Re: [PATCH] cvsserver: fix legacy cvs client and branch rev issues
From: Frank Lichtenheld @ 2007-06-17 10:37 UTC (permalink / raw)
To: Dirk Koopman; +Cc: git
In-Reply-To: <4674FA9B.10806@tobit.co.uk>
On Sun, Jun 17, 2007 at 10:10:51AM +0100, Dirk Koopman wrote:
> Frank Lichtenheld wrote:
> >On Sat, Jun 16, 2007 at 07:50:06PM +0100, Dirk Koopman wrote:
> >Hmm, I don't see how you could have a problem with that since cvsserver
> >doesn't support branches and never generates any revision numbers in
> >that format?
> >
> >There is probably much more code out there in cvsserver that does assume
> >that revision is always a simple integer.
Let me rephrase that (after actually looking through the code):
All of the revision handling code assumes that.
> The specific issue that I was trying to solve is that I have (in CVS
> terms) a main line (git head: master) and an active CVS development
> branch and git head (called SR [for the sake of argument]).
>
> I have imported both into git using cvsimport. For compatibility (and
> windows users) I need a anonymous, read only, :pserver: CVS
> implementation that can serve either head.
>
> The version numbers in the CVS import on branch SR are standard CVS
> single level branch 1.2.3.4. Doing a 'cvs update' on this branch was
> causing all sorts of warnings about 1.2.3.4 not being numeric on that
> test. After changing the test, the warnings have gone away and it all
> still seems to work.
>
> Having said that, I haven't worked out where cvsserver is getting those
> version numbers from in the first place, but it obviously knows that it
> is dealing with a branch sufficient to work well enough for my needs.
Hmm, so you did the cvs update in an old working copy of the original
CVS repository? Then CVS sent those version numbers from the CVS/Entries
file to the server, cvsserver certainly never generates numbers like
that. And I would be very suprised if you could do anything remotely
useful with abusing the old working copy this way... The revision
numbers that cvsserver assigns to the files of the main branch might
be almost always identical to the ones they had in CVS before the
import, but the ones for branches will definetly not be.
> Of course, quite what happens when the branch merges back and people
> want to 'cvs update -A', I shall leave for the future...
I don't think that cvsserver actually cares about what the client sends
as sticky tags/dates/..., so it might not actually change anything
whether you use -A or not (pure speculation on my part here).
Summary: You're (ab)using cvsserver in very interesting ways that are not
really beeing thought of in the current design/implementation. There'll
be dragons ;)
Gruesse,
--
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
^ permalink raw reply
* Re: merge into branch currently not active / checked out
From: Thomas Glanzmann @ 2007-06-17 10:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: GIT
In-Reply-To: <7vmyyzylpl.fsf@assigned-by-dhcp.pobox.com>
Hi Junio,
> If you plan to eventually ask somebody who integrates the 'master' to
> pull from you, and keep the resulting development history clean, (1)
> is _NOT_ a good reason to merge 'master' into your topics. Because
> after your topic finally is finished, when 'master' pulls it, it will
> see many "senseless" merges from itself.
the problem is. Getting a patch into mutt takes several years. At least
it took for the hcache. So what I do is keep my patches up2date on top
of there HEAD. So I prefer topic branches. And my patches throw _once_
in 4 years a conflict that was not automatically resolved. I used
bitkeeper before, now I use git.
> Such "an integration testing" is better done, instead, by forking a
> 'test' (perhaps throw-away) branch from 'master', and merging all your
> topics into it.
I dislike it myself.
> Also, if you do not publish your work-in-progress topics, you
> might want to consider rebasing on top of 'master', instead of
> 'merging'. Rebase can take the topic branch name and switch
> your current branch for you when you give it, like so:
I don't push my work other than in patches that is, so I am going to
give it a try. I always wanted to try rebase, but I never actually did
try it.
Thanks,
Thomas
^ permalink raw reply
* Re: merge into branch currently not active / checked out
From: Alex Riesen @ 2007-06-17 9:45 UTC (permalink / raw)
To: Thomas Glanzmann; +Cc: git
In-Reply-To: <20070617072225.GF23473@cip.informatik.uni-erlangen.de>
Thomas Glanzmann, Sun, Jun 17, 2007 09:22:25 +0200:
> Hello,
> is it possible to merge into a branch currently not active/checked out?
not in current implementation of merge algorithms and conflict
handling.
> I want to merge master in every of the feature branches. Is that possible or
> just bullshit because I don't have a working tree to handle conflicts?
You are _very_ welcome to improve this :) It's not very often need, so
people just do without it (i.e. clone the repo, do a merge there and
pull back).
^ permalink raw reply
* Re: merge into branch currently not active / checked out
From: Junio C Hamano @ 2007-06-17 9:27 UTC (permalink / raw)
To: Thomas Glanzmann; +Cc: GIT
In-Reply-To: <20070617072225.GF23473@cip.informatik.uni-erlangen.de>
Thomas Glanzmann <thomas@glanzmann.de> writes:
> Hello,
> is it possible to merge into a branch currently not active/checked out?
> I have the following scenario:
>
> - One branch per feature (cstatus, headers, mutt-collapse-flags, small-fixes)
> - One upstream branch (master)
> - One branch that has every feature branch (tg)
>
> (faui00u) [~/work/mutt/mutt] git branch
> cstatus
> headers
> master
> mutt-collapse-flags
> small-fixes
> * tg
>
> I want to merge master in every of the feature branches. Is that possible or
> just bullshit because I don't have a working tree to handle conflicts?
Exactly. Merge would want to have working tree, so merging into
the current branch is not just the default but the only mode of
operation.
In general, I would recommend against merging 'master' to topic
branches, if you can avoid it.
There are two reasons you would ever want to merge 'master' to
them.
(1) You notice that 'master' has new stuff. It does not
necessarily conflict with the changes you made to your
topic branches, and it often doesn't, if the project is
well modularized. Still, you want to make sure that your
topic branches are compatible with it. IOW to see if the
changes in the master did not break your topic.
(2) You notice that 'master' actually have new change that
actively interact with what you set out to do in some of
your toipcs.
If you plan to eventually ask somebody who integrates the
'master' to pull from you, and keep the resulting development
history clean, (1) is _NOT_ a good reason to merge 'master' into
your topics. Because after your topic finally is finished, when
'master' pulls it, it will see many "senseless" merges from
itself.
Such "an integration testing" is better done, instead, by
forking a 'test' (perhaps throw-away) branch from 'master', and
merging all your topics into it.
On the other hand, (2) is a valid reason to resolve conflict
(both textual and semantic) early before you eventually present
your work for inclusion to 'master'.
Also, if you do not publish your work-in-progress topics, you
might want to consider rebasing on top of 'master', instead of
'merging'. Rebase can take the topic branch name and switch
your current branch for you when you give it, like so:
$ git rebase master topic1
$ git rebase master topic2
...
^ 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