* Re: Strange merge conflicts against earlier merge.
From: Junio C Hamano @ 2005-11-11 17:29 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20051111114511.GQ30496@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Does core GIT have support for multibase merges, except for the
> recursive merge strategy? How do you do it?
There were lengthy discussion on this and a lot of work that
went into the resolution. We do three things.
- The first implementation does a trial read-tree 3-way using
each of the base candidates without smudging the working
tree, and counts paths that need file-level merges, to guess
the best base, and uses that base. This is in the 'stupid'
stratagy.
- The above turned out to have a risky corner case, especially
when one side reverted a patch and the other one did not. To
address this, read-tree was rewritten and 3-way form of
read-tree can take more than three trees these days, letting
you feed it all the merge base candidates. This code is used
in 'resolve' strategy.
- The 'recursive' strategy tries to come up with a merge of the
candidate bases and uses it as the base of the final merge.
^ permalink raw reply
* Re: lock
From: Paolo Teti @ 2005-11-11 16:48 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20051111164101.GV30496@pasky.or.cz>
2005/11/11, Petr Baudis <pasky@suse.cz>:
> Do you want to lock the file so that noone else will be able to check it
> out? That's impossible from GIT's very nature of distributed version
> control system.
No! I know that is impossible using GIT
> Do you want to lock the file in your working copy so that you won't be
> able to remove it or change it? In that case, this is possible, but not
> implemented yet. Part of the solution would involve making the file
> read-only, the rest would be probably to make sure all the tools handle
> that case gracefully.
Yes! this is my case.. The as work-around I can use an hook (i.e. a
kind of ClearCase trigger). But remain a work-around!
^ permalink raw reply
* Re: lock
From: Petr Baudis @ 2005-11-11 16:41 UTC (permalink / raw)
To: Paolo Teti; +Cc: git
In-Reply-To: <34a7ae040511110831y3e896738o@mail.gmail.com>
Dear diary, on Fri, Nov 11, 2005 at 05:31:31PM CET, I got a letter
where Paolo Teti <paolo.teti@gmail.com> said that...
> Just a question probably stupid because I'm a quite new GIT user.
>
> Is possible to apply a lock (as in ClearCase) on a given file etc in order to
> prevent accidental check-out or any other tool operation?
Can you be a bit more detailed in the description of what do you exactly
want?
Do you want to lock the file so that noone else will be able to check it
out? That's impossible from GIT's very nature of distributed version
control system.
Do you want to lock the file in your working copy so that you won't be
able to remove it or change it? In that case, this is possible, but not
implemented yet. Part of the solution would involve making the file
read-only, the rest would be probably to make sure all the tools handle
that case gracefully.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: lock
From: Johannes Schindelin @ 2005-11-11 16:38 UTC (permalink / raw)
To: Paolo Teti; +Cc: git
In-Reply-To: <34a7ae040511110831y3e896738o@mail.gmail.com>
Hi,
On Fri, 11 Nov 2005, Paolo Teti wrote:
> Is possible to apply a lock (as in ClearCase) on a given file etc in
> order to prevent accidental check-out or any other tool operation?
You should be able to do that with a hook (see Documentation/hooks.txt).
Hth,
Dscho
^ permalink raw reply
* lock
From: Paolo Teti @ 2005-11-11 16:31 UTC (permalink / raw)
To: git
Just a question probably stupid because I'm a quite new GIT user.
Is possible to apply a lock (as in ClearCase) on a given file etc in order to
prevent accidental check-out or any other tool operation?
Pao
^ permalink raw reply
* Re: merge-base: fully contaminate the well.
From: Linus Torvalds @ 2005-11-11 16:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7viruzu3du.fsf@assigned-by-dhcp.cox.net>
On Thu, 10 Nov 2005, Junio C Hamano wrote:
>
> > Btw, I don't think your contamination logic is necessarily complete. We
> > may not even have parsed some of the commits that end up being on that
> > strange corner case.
>
> I haven't tried walking any other test cases, but wouldn't that
> be arguing that the our assumption that the current merge-base
> is at least complete if not optimum?
Oh yes, it's always complete, even though it may not be optimal. And it's
going to be optimal in all realistic cases.
And even in the unrealistic cases if we end up returning a commit that is
actually reachable by another one (through at least two levels of other
commits that were in the wrong date-order with the _other_ ways of
reaching that commit), the recursive strategy of merging the merge-bases
will always end up boiling it doing to the optimal thing.
So I think this is absolutely 100% correct.
Linus
^ permalink raw reply
* Re: [PATCH] cg-pull to stop treating "master" specially, fix fetch_local for .git/HEAD
From: Josef Weidendorfer @ 2005-11-11 16:10 UTC (permalink / raw)
To: Pavel Roskin; +Cc: Petr Baudis, git
In-Reply-To: <1131722791.1284.20.camel@dv>
On Friday 11 November 2005 16:26, Pavel Roskin wrote:
> > AFAIK, there is not really a "new" and "old" style, but more the
> > git way (attributes for remote repositories in .git/remotes) and the
> > Cogito way (attributes for a remote branch).
>
> Switching to the "git way" is long overdue, since hashes can be used in
> the actual path.
Currently, Git does not store mappings of remote to local branches in
.git/remotes/ per se. "Pull" lines allow you to specify default actions
for git-fetch/git-pull, but even this is quite limited:
"git-fetch" defaults to fetching all heads mentioned, and "git-pull"
defaults to merging the first head on the first "Pull" line.
Because the git way is per-remote-repository, you always have to specify
the remote repository shortcut in git-fetch/git-pull/git-push, as there
is no implicit remote repository. With per-branch, it is far simpler as
you always have a current active branch which is HEAD. By using
.git/remotes, you more or less get a shortcut name for a remote repository.
Of course, Cogito could use this shortcut in the .git/branches/, too.
Another thing: Per branch configuration is not only about branches which
have a mapping to a remote file. I would *love* to be able to specify
merge candidates and default merge branches for every local branch.
Such configuration of local branches can also reside in .git/branches.
But you are right, hashes can be part of an path, so Cogito should use
multiple lines in .git/branches/ like Git does in .git/remotes.
So what are possible configuration items for a branch?
Branches can be of 2 kinds: either a branch should track a remote branch,
or it is used for local development.
A branch which is tracking a remote one does need
* the remote repository URL, or path (if local)
* the branch name to track from the remote repository
A branch used for development can have:
* set of local branch names which are candidates for merging
* set of local branch names for default merge action
* a default remote branch to use for pushing
> > For cg-clone, this is no problem because cg-clone writes this file itself.
> > Another thing is if you add later on a remote branch with cg-branch-add
> > without specifying a concrete remote branch name. Do we want the
> > record the branch name at the first cg-fetch for the future?
>
> Good that you noticed that.
>
> cg-fetch could do that, but maybe cg-branch-add would be an even better
> place for that? I mean, cg-branch-add could actually check the
> repository and prompt the user which branch to use if there is no
> obvious default. I think, there should be a way to run cg-branch-add
> without having it connect the repository or prompt the user, but the
> default should be user-friendly.
Yes.
Josef
^ permalink raw reply
* Re: Getting rid of symlinks in .git?
From: Johannes Schindelin @ 2005-11-11 16:03 UTC (permalink / raw)
To: Petr Baudis; +Cc: Simon Richter, Pavel Roskin, git
In-Reply-To: <20051111154938.GU30496@pasky.or.cz>
Hi,
On Fri, 11 Nov 2005, Petr Baudis wrote:
> This is about being consistent, and also to support dumber protocols
> better.
For my local development, I couldn't care less about dumber protocols.
Hth,
Dscho
^ permalink raw reply
* Re: Getting rid of symlinks in .git?
From: Nick Hengeveld @ 2005-11-11 15:55 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Petr Baudis, Simon Richter, Pavel Roskin, git
In-Reply-To: <Pine.LNX.4.63.0511111636400.16210@wbgn013.biozentrum.uni-wuerzburg.de>
On Fri, Nov 11, 2005 at 04:40:43PM +0100, Johannes Schindelin wrote:
> Note that the only symlink/symref you usually have is .git/HEAD. But it
> feels wrong to take the worse approach in *all* cases, just because
> *one* brain-fscked file system/operating system does not support the
> superior approach.
Symlinks at the other end of an HTTP transport are also similarly
brain-challenged.
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply
* Re: Getting rid of symlinks in .git?
From: Petr Baudis @ 2005-11-11 15:49 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Simon Richter, Pavel Roskin, git
In-Reply-To: <Pine.LNX.4.63.0511111636400.16210@wbgn013.biozentrum.uni-wuerzburg.de>
Dear diary, on Fri, Nov 11, 2005 at 04:40:43PM CET, I got a letter
where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> On Fri, 11 Nov 2005, Petr Baudis wrote:
>
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> > >
> > > Please note that symlinks are much more performant than symrefs. Working a
> > > lot with switching branches, this matters.
> >
> > What operations get slowed down noticeably in particular?
>
> Well, if you have to read two files instead of one, it is 100% slower ;-)
But you usually don't read the HEAD that often...
Besides, the kernel has to read the symlink file as well in order to
follow the symlink. ;-)
> Note that the only symlink/symref you usually have is .git/HEAD. But it
> feels wrong to take the worse approach in *all* cases, just because
> *one* brain-fscked file system/operating system does not support the
> superior approach.
This is about being consistent, and also to support dumber protocols
better.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: Getting rid of symlinks in .git?
From: Johannes Schindelin @ 2005-11-11 15:40 UTC (permalink / raw)
To: Petr Baudis; +Cc: Simon Richter, Pavel Roskin, git
In-Reply-To: <20051111150530.GT30496@pasky.or.cz>
Hi,
On Fri, 11 Nov 2005, Petr Baudis wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> >
> > Please note that symlinks are much more performant than symrefs. Working a
> > lot with switching branches, this matters.
>
> What operations get slowed down noticeably in particular?
Well, if you have to read two files instead of one, it is 100% slower ;-)
> Do you have any timing testcases and data at hand?
No and no.
Note that the only symlink/symref you usually have is .git/HEAD. But it
feels wrong to take the worse approach in *all* cases, just because
*one* brain-fscked file system/operating system does not support the
superior approach.
Conclusion: I can live with the symref support in git "AS IS".
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Change 'cache' to 'index' in the docs
From: Johannes Schindelin @ 2005-11-11 15:35 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <4374ABF7.1010304@op5.se>
Hi,
On Fri, 11 Nov 2005, Andreas Ericsson wrote:
> Johannes Schindelin wrote:
> >
> > > The wording in git-diff-index.txt isn't exactly stellar either.
> >
> >
> > Agree. Want to do something about it?
> >
>
> Why not? Usually I can't even understand my own documentation, but it
> might at least raise the discussion.
*grin* One thing I learnt developing Open Source: even the boring, tedious
tasks can be fun, and the result very good, when working in a team.
Ciao,
Dscho
^ permalink raw reply
* Re: RPM build report
From: Josh Boyer @ 2005-11-11 15:28 UTC (permalink / raw)
To: Horst von Brand; +Cc: git
In-Reply-To: <200511111440.jABEeV7c023333@pincoya.inf.utfsm.cl>
On 11/11/05, Horst von Brand <vonbrand@inf.utfsm.cl> wrote:
> Again, on Fedora rawhide, x86_64.
>
> After the big splitup, the builds for git and cogito go fine but
> git-core-email requires perl(Email::Valid), which is not in Fedora's
> repositories. The rest installs OK.
How recent of a rawhide snapshot did you use? I ask because openssl
was recently updated in rawhide and I was just wondering if git coped
with that.
josh
^ permalink raw reply
* Re: [PATCH] cg-pull to stop treating "master" specially, fix fetch_local for .git/HEAD
From: Pavel Roskin @ 2005-11-11 15:26 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: Petr Baudis, git
In-Reply-To: <200511111522.37979.Josef.Weidendorfer@gmx.de>
On Fri, 2005-11-11 at 15:22 +0100, Josef Weidendorfer wrote:
> On Friday 11 November 2005 05:53, Pavel Roskin wrote:
> > I'm not sure if we understand each other, but "recorded" refers to
> > automatically determined branch name. If cg-clone can determine the
> > branch name, that name should be saved and used for updates.
> >
> > Whether the branch name is saved in .git/branches/ using hash notation
> > (old style) or in .git/remotes/ (new style) is irrelevant.
>
> Yes.
> But for the conrete implementation it is relevant.
>
> AFAIK, there is not really a "new" and "old" style, but more the
> git way (attributes for remote repositories in .git/remotes) and the
> Cogito way (attributes for a remote branch).
Switching to the "git way" is long overdue, since hashes can be used in
the actual path.
> "Recording" talks about storing the name of the remote branch that
> maps to the local "origin" branch, so I would vote for storing this
> in .git/branches/origin.
Yes, cg-clone should do its best to determine the branch name and to
save it for future use by cg-fetch.
> For cg-clone, this is no problem because cg-clone writes this file itself.
> Another thing is if you add later on a remote branch with cg-branch-add
> without specifying a concrete remote branch name. Do we want the
> record the branch name at the first cg-fetch for the future?
Good that you noticed that.
cg-fetch could do that, but maybe cg-branch-add would be an even better
place for that? I mean, cg-branch-add could actually check the
repository and prompt the user which branch to use if there is no
obvious default. I think, there should be a way to run cg-branch-add
without having it connect the repository or prompt the user, but the
default should be user-friendly.
--
Regards,
Pavel Roskin
^ permalink raw reply
* [PATCH] gitk: use git-diff-tree --no-commit-id
From: Pavel Roskin @ 2005-11-11 15:09 UTC (permalink / raw)
To: Paul Mackerras, git
gitk switched to use git-diff-tree with one argument in gettreediffs and
getblobdiffs. git-diff-tree with one argument outputs commit ID in from
of the patch. This causes an empty line after "Comments" in the lower
right pane. Also, the diff in the lower left pane has the commit ID,
which is useless there.
This patch makes git use the newly added -no-commit-id option for
git-diff-tree to suppress commit ID. It also removes the p variable in
both functions, since it has become useless after switching to the
one-argument invocation for git-diff-tree.
Signed-off-by: Pavel Roskin <proski@gnu.org>
diff --git a/gitk b/gitk
index a9d37d9..6d47139 100755
--- a/gitk
+++ b/gitk
@@ -2805,8 +2805,7 @@ proc gettreediffs {ids} {
set treepending $ids
set treediff {}
set id [lindex $ids 0]
- set p [lindex $ids 1]
- if [catch {set gdtf [open "|git-diff-tree -r $id" r]}] return
+ if [catch {set gdtf [open "|git-diff-tree --no-commit-id -r $id" r]}] return
fconfigure $gdtf -blocking 0
fileevent $gdtf readable [list gettreediffline $gdtf $ids]
}
@@ -2840,9 +2839,8 @@ proc getblobdiffs {ids} {
global difffilestart nextupdate diffinhdr treediffs
set id [lindex $ids 0]
- set p [lindex $ids 1]
set env(GIT_DIFF_OPTS) $diffopts
- set cmd [list | git-diff-tree -r -p -C $id]
+ set cmd [list | git-diff-tree --no-commit-id -r -p -C $id]
if {[catch {set bdf [open $cmd r]} err]} {
puts "error getting diffs: $err"
return
--
Regards,
Pavel Roskin
^ permalink raw reply related
* Re: Getting rid of symlinks in .git?
From: Petr Baudis @ 2005-11-11 15:05 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Simon Richter, Pavel Roskin, git
In-Reply-To: <Pine.LNX.4.63.0511111511050.7575@wbgn013.biozentrum.uni-wuerzburg.de>
Hello,
Dear diary, on Fri, Nov 11, 2005 at 03:14:24PM CET, I got a letter
where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> On Fri, 11 Nov 2005, Simon Richter wrote:
>
> > As someone who carries around git repositories on VFAT formatted USB
> > sticks, I welcome our symlink-deprived overlords.
>
> Please note that symlinks are much more performant than symrefs. Working a
> lot with switching branches, this matters.
this is interesting. What operations get slowed down noticeably in
particular? Do you have any timing testcases and data at hand?
Thanks,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* git-core-arch: Missing dependency
From: Horst von Brand @ 2005-11-11 14:46 UTC (permalink / raw)
To: git
The command git-archimport makes use of tla, but the relevant package(s) are
not on the requirements
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
^ permalink raw reply
* RPM build report
From: Horst von Brand @ 2005-11-11 14:40 UTC (permalink / raw)
To: git
Again, on Fedora rawhide, x86_64.
After the big splitup, the builds for git and cogito go fine but
git-core-email requires perl(Email::Valid), which is not in Fedora's
repositories. The rest installs OK.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
^ permalink raw reply
* Re: [PATCH] Change 'cache' to 'index' in the docs
From: Andreas Ericsson @ 2005-11-11 14:34 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0511111514420.7575@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> Hi,
>
> On Fri, 11 Nov 2005, Andreas Ericsson wrote:
>
>
>>This had me puzzled for quite some time. Some notice to the tutorial about
>>what's meant when it says "tree-ish" or "commit-ish" would be nice (I still
>>haven't been able to figure it out).
>
>
> See glossary.txt.
>
Ahhh. Terminology (here daft ole me was grep'ing away for
"nomenclature"...). Thanks a million.
Although it would be nice if it was mentioned up top with the other
"read these first" files.
>
>>The wording in git-diff-index.txt isn't exactly stellar either.
>
>
> Agree. Want to do something about it?
>
Why not? Usually I can't even understand my own documentation, but it
might at least raise the discussion.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* merge-recursive: include heapq?
From: Johannes Schindelin @ 2005-11-11 14:23 UTC (permalink / raw)
To: git
Hi,
I get this when pulling:
-- snip --
Traceback (most recent call last):
File "./git-merge-recursive", line 4, in ?
from heapq import heappush, heappop
ImportError: No module named heapq
-- snap --
Okay, my python is *old*:
$ python -V
Python 2.2.1
Is it worthwhile to include heapq as we did with subprocess? Or should I
upgrade...
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] cg-pull to stop treating "master" specially, fix fetch_local for .git/HEAD
From: Josef Weidendorfer @ 2005-11-11 14:22 UTC (permalink / raw)
To: Pavel Roskin; +Cc: Petr Baudis, git
In-Reply-To: <1131684784.31172.16.camel@dv>
On Friday 11 November 2005 05:53, Pavel Roskin wrote:
> I'm not sure if we understand each other, but "recorded" refers to
> automatically determined branch name. If cg-clone can determine the
> branch name, that name should be saved and used for updates.
>
> Whether the branch name is saved in .git/branches/ using hash notation
> (old style) or in .git/remotes/ (new style) is irrelevant.
Yes.
But for the conrete implementation it is relevant.
AFAIK, there is not really a "new" and "old" style, but more the
git way (attributes for remote repositories in .git/remotes) and the
Cogito way (attributes for a remote branch).
"Recording" talks about storing the name of the remote branch that
maps to the local "origin" branch, so I would vote for storing this
in .git/branches/origin.
For cg-clone, this is no problem because cg-clone writes this file itself.
Another thing is if you add later on a remote branch with cg-branch-add
without specifying a concrete remote branch name. Do we want the
record the branch name at the first cg-fetch for the future?
> That's why I mentioned the idea of having a separate file to indicate
> the default branch for export.
Agree.
Josef
^ permalink raw reply
* Re: [ANNOUNCE] GIT 0.99.9g
From: Johannes Schindelin @ 2005-11-11 14:19 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Junio C Hamano, git, linux-kernel
In-Reply-To: <43737EC7.6090109@zytor.com>
Hi,
On Thu, 10 Nov 2005, H. Peter Anvin wrote:
> May I *STRONGLY* urge you to name that something different. "lost+found"
> is a name with special properties in Unix; for example, many backup
> solutions will ignore a directory with that name.
Two reasons against renaming:
- we call it fsck-objects for a reason. We are working on a file system,
which just so happens to be implemented in user space, not kernel space.
If lost+found has to find a new name, so does fsck-objects.
- lost+found has a special meaning, granted. So, a backup would not be
made of it. So what? I *don't* want it backup'ed. I want to repair what
was wrong with it. When I repaired it, the result is stored somewhere
else. To backup lost+found would make as much sense as to backup /tmp.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Change 'cache' to 'index' in the docs
From: Johannes Schindelin @ 2005-11-11 14:15 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <43748566.2070204@op5.se>
Hi,
On Fri, 11 Nov 2005, Andreas Ericsson wrote:
> This had me puzzled for quite some time. Some notice to the tutorial about
> what's meant when it says "tree-ish" or "commit-ish" would be nice (I still
> haven't been able to figure it out).
See glossary.txt.
> The wording in git-diff-index.txt isn't exactly stellar either.
Agree. Want to do something about it?
Ciao,
Dscho
^ permalink raw reply
* Re: Getting rid of symlinks in .git?
From: Johannes Schindelin @ 2005-11-11 14:14 UTC (permalink / raw)
To: Simon Richter; +Cc: Petr Baudis, Pavel Roskin, git
In-Reply-To: <43746118.30404@hogyros.de>
Hi,
On Fri, 11 Nov 2005, Simon Richter wrote:
> As someone who carries around git repositories on VFAT formatted USB
> sticks, I welcome our symlink-deprived overlords.
Please note that symlinks are much more performant than symrefs. Working a
lot with switching branches, this matters.
And -- as has been mentioned elsewhere -- it is no longer a problem to
work on filesystems which don't support symlinks using a platform which
does.
Hth,
Dscho
^ permalink raw reply
* Re: Strange merge conflicts against earlier merge.
From: Petr Baudis @ 2005-11-11 13:12 UTC (permalink / raw)
To: Fredrik Kuivinen; +Cc: Martin Langhoff, Git Mailing List
In-Reply-To: <20051111114511.GQ30496@pasky.or.cz>
Dear diary, on Fri, Nov 11, 2005 at 12:45:11PM CET, I got a letter
where Petr Baudis <pasky@suse.cz> said that...
> I guess I really don't want to do that, but instead choose one of the
> bases. Hmm. Well, I suppose it's as good as anything to leave this
> decision on the user. Kind of:
>
> if [ $(wc -l merge-bases) -ge 1 ]; then
> echo "Multiple merge bases, please select one by the -b parameter:" >&2
> cat merge-bases
> echo -n "The most conservative base (but likely a lot of conflicts):" >&2
> while true; do
> git-merge-base --all $(cat merge-bases) >merge-bases~
> mv merge-bases~ merge-bases
> [ $(wc -l merge-bases) -eq 1 ] && break
> done
> cat merge-bases
> exit 1
> fi
I just did something in this style. Since I'm unable to get the
repository, could someone please test it?
I'll try to come up with some automated testcase later.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ 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