* [ANNOUNCE] GIT 1.6.1-rc3
From: Junio C Hamano @ 2008-12-15 8:32 UTC (permalink / raw)
To: git; +Cc: linux-kernel
In-Reply-To: <7vbpvnbcoa.fsf@gitster.siamese.dyndns.org>
I have fixed a few more smallish (old) bugs after I tagged this, which
will be in 'master' shortly, but it seems that this cycle is stabilizing
fairly nicely. Let's have a successful 1.6.1 tagged on 20th. Please hunt
and fix bugs until then.
http://www.kernel.org/pub/software/scm/git/
git-1.6.1-rc3.tar.{gz,bz2} (source tarball)
git-htmldocs-1.6.1-rc3.tar.{gz,bz2} (preformatted docs)
git-manpages-1.6.1-rc3.tar.{gz,bz2} (preformatted docs)
The RPM binary packages for a few architectures are also there.
testing/git-*-1.6.1-rc3-1.fc9.$arch.rpm (RPM)
----------------------------------------------------------------
Changes since v1.6.1-rc2 are as follows:
Alexander Gavrilov (1):
Documentation: Describe git-gui Tools menu configuration options.
Alexander Potashev (2):
Fix typos in documentation
Fix typo in comment in builtin-add.c
Alexey Borzenkov (1):
Define linkgit macro in [macros] section
Brandon Casey (1):
git-branch: display sha1 on branch deletion
Deskin Miller (1):
git-svn: Make following parents atomic
Jakub Narebski (1):
gitweb: Fix bug in insert_file() subroutine
Jeff King (5):
reorder ALLOW_TEXTCONV option setting
diff: allow turning on textconv explicitly for plumbing
diff: fix handling of binary rewrite diffs
diff: respect textconv in rewrite diffs
rebase: improve error messages about dirty state
Jim Meyering (1):
git-config.txt: fix a typo
Johannes Schindelin (1):
Get rid of the last remnants of GIT_CONFIG_LOCAL
Junio C Hamano (4):
builtin-checkout.c: check error return from read_cache()
read-cache.c: typofix in comment
work around Python warnings from AsciiDoc
Fix t4031
Linus Torvalds (1):
fsck: reduce stack footprint
Markus Heidelberg (1):
builtin-commit: remove unused message variable
Nicolas Pitre (1):
make sure packs to be replaced are closed beforehand
Ralf Wildenhues (1):
Improve language in git-merge.txt and related docs
Tor Arvid Lund (1):
git-p4: Fix regression in p4Where method.
YONETANI Tomokazu (1):
git-fast-import possible memory corruption problem
^ permalink raw reply
* Re: fatal output from git-show really wants a terminal
From: Jeff King @ 2008-12-15 8:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Boyd Stephen Smith Jr., Johannes Schindelin, git
In-Reply-To: <7v3agpzwet.fsf@gitster.siamese.dyndns.org>
On Mon, Dec 15, 2008 at 12:15:38AM -0800, Junio C Hamano wrote:
> I haven't heard anything more about this, but if you were indeed
> discussing the change made by 61b8050, I think the fix should just be like
> this.
> [...]
> - dup2(pager_process.in, 2);
> + if (isatty(2))
> + dup2(pager_process.in, 2);
I can't speak for the original poster, but I do think this behavior
should be less surprising to users who perform the one particular
redirection (and in the other 99% of cases, should behave exactly the
same). So I think it's a positive change.
-Peff
^ permalink raw reply
* Re: fatal output from git-show really wants a terminal
From: Junio C Hamano @ 2008-12-15 8:23 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.; +Cc: Jeff King, Johannes Schindelin, git
In-Reply-To: <7v3agpzwet.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
>> Isn't the issue about 61b8050 (sending errors to stdout under $PAGER,
>> 2008-02-16)? With that commit, we changed things so that when we send the
>> standard output to the $PAGER, we dup stderr to the $PAGER as well,
>> because otherwise any output to stderr will be wiped out by whatever the
>> pager does and the user will not notice the breakage. E.g.
>>
>> $ git log
>>
>> will just show reams of output, and you won't see any errors and warnings
>> even if there were any encountered during the process.
>>
>> Unfortunately we did it unconditionally.
By the by, I noticed that the example shown in the commit message of
61b8050 has been broken since 4f3dcc2 (Fix 'git show' on signed tag of
signed tag of commit, 2008-07-01).
Here is a fix.
builtin-log.c | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git c/builtin-log.c w/builtin-log.c
index 840daf9..99d1137 100644
--- c/builtin-log.c
+++ w/builtin-log.c
@@ -340,7 +340,13 @@ int cmd_show(int argc, const char **argv, const char *prefix)
t->tag,
diff_get_color_opt(&rev.diffopt, DIFF_RESET));
ret = show_object(o->sha1, 1, &rev);
- objects[i].item = parse_object(t->tagged->sha1);
+ if (ret)
+ break;
+ o = parse_object(t->tagged->sha1);
+ if (!o)
+ ret = error("Could not read object %s",
+ sha1_to_hex(t->tagged->sha1));
+ objects[i].item = o;
i--;
break;
}
^ permalink raw reply related
* Re: fatal output from git-show really wants a terminal
From: Junio C Hamano @ 2008-12-15 8:15 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.; +Cc: Jeff King, Johannes Schindelin, git
In-Reply-To: <7vr64eb9ha.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> "Boyd Stephen Smith Jr." <bss03@volumehost.net> writes:
>
>>> $ git log >foo.out
>>>
>>>and start a pager, which makes no sense.
>>
>> Good point, I'll try and consider that while I investgate the history of the
>> issue.
>
> Isn't the issue about 61b8050 (sending errors to stdout under $PAGER,
> 2008-02-16)? With that commit, we changed things so that when we send the
> standard output to the $PAGER, we dup stderr to the $PAGER as well,
> because otherwise any output to stderr will be wiped out by whatever the
> pager does and the user will not notice the breakage. E.g.
>
> $ git log
>
> will just show reams of output, and you won't see any errors and warnings
> even if there were any encountered during the process.
>
> Unfortunately we did it unconditionally. There is no reason to dup stderr
> to the $PAGER if the command line was:
>
> $ git log 2>error.log
>
> in which case you would want to view the normal output in your $PAGER and
> you are keeping the log of the error output in a separate file.
I haven't heard anything more about this, but if you were indeed
discussing the change made by 61b8050, I think the fix should just be like
this.
| 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
--git c/pager.c w/pager.c
index aa0966c..f19ddbc 100644
--- c/pager.c
+++ w/pager.c
@@ -70,7 +70,8 @@ void setup_pager(void)
/* original process continues, but writes to the pipe */
dup2(pager_process.in, 1);
- dup2(pager_process.in, 2);
+ if (isatty(2))
+ dup2(pager_process.in, 2);
close(pager_process.in);
/* this makes sure that the parent terminates after the pager */
^ permalink raw reply related
* Re: is gitosis secure?
From: Mike Hommey @ 2008-12-15 7:17 UTC (permalink / raw)
To: david; +Cc: martin, git
In-Reply-To: <alpine.DEB.1.10.0812141655150.17688@asgard.lang.hm>
On Sun, Dec 14, 2008 at 05:00:14PM -0800, david@lang.hm wrote:
> 1. if you are running multiple different applications that all want to be
> exposed via port 22 (like git for 'git push') then you may need to expose
> numerous machines. tools that use SSH don't tend to have the ability to
> use a gateway box before they start executing commands, they assume that
> you will SSH directly into the destination box.
But ssh itself allows you to do proxying. See ProxyCommand in
ssh_config's manpage.
Mike
^ permalink raw reply
* Re: is gitosis secure?
From: Rogan Dawes @ 2008-12-15 7:52 UTC (permalink / raw)
To: david; +Cc: Sitaram Chamarty, git
In-Reply-To: <alpine.DEB.1.10.0812150026570.17688@asgard.lang.hm>
david@lang.hm wrote:
> On Mon, 15 Dec 2008, Rogan Dawes wrote:
>
>> david@lang.hm wrote:
>>
>>>
>>> what would I like to see in an ideal world?
>>>
>>> something that runs as the git user, does not enable tunneling, and only
>>> does the data transfer functions needed for a push. it should use
>>> off-the-shelf libraries for certificate authentication and tie into PAM
>>> for additional authentication.
>>
>> How about a git-specific deployment/configuration of ssh? You can
>> certainly run multiple copies of SSH (on different ports), by providing
>> a restricted configuration file you can disable tunneling and any other
>> functionality that you don't like.
>>
>> And if you want it to run as a non-root user, simply choose a port>1024,
>> but keep in mind that you won't be able to authenticate by password
>> (IIRC, only key auth will work when running non-root), or setuid to
>> those users when they log in. Nonetheless, this could be sufficient for
>> gitosis, since everything runs as the specified user anyway, and IIRC,
>> gitosis wants individual SSH pubkeys to allow access.
>
> IMHO this is better then exposing a 'normal' ssh daemon to the Internet
> just to be able to do a git push. the fact that you loose authentication
> options is not a good thing, are you sure that you cannot hook into PAM
> authentication for this?
I *think* that an unprivileged user cannot invoke PAM for accounts other
than its own, and most certainly cannot change to that other user
without being setuid (or having the appropriate capability).
>> In many cases, especially if the tool is unix based, you can specify (in
>> ~/.ssh/config) a Proxy command that is executed before the SSH protocol
>> negotiation begins, which results in stdin and stdout being connected to
>> the SSH daemon at the destination. The most common variations are the
>> HTTP and Socks proxy connectors (e.g. corkscrew?), but the sky is really
>> the limit in terms of what is possible.
>
> as I just commented, this looks like it's a per-user config option that
> is designed to be used as a proxy out of the network you are in to get
> to the Internet, not to be used at the far side of a connection to get
> to things on a remote network. as I understand it, you would need to
> change this config file for each different destination network you need
> to connect to.
That may be its original intention, but it can nonetheless be used for
other purposes. Yes, you might need a different configuration for each
network that you need to access, and quite possibly for each location
that you need to access them from. This may result in config entry
proliferation, but it is manageable, especially with the openssh
wildcard syntax in the config file.
man ssh_config:
Host
Restricts the following declarations (up to the next Host keyword) to be
only for those hosts that match one of the patterns given after the
keyword. If more than one pattern is provided, they should be separated
by whitespace. A single `*' as a pattern can be used to provide global
defaults for all hosts. The host is the hostname argument given on the
command line (i.e. the name is not converted to a canonicalized host
name before matching).
e.g
Host *-home
ProxyCommand . . . .
FWIW.
Rogan
^ permalink raw reply
* Re: is gitosis secure?
From: david @ 2008-12-15 8:37 UTC (permalink / raw)
To: Rogan Dawes; +Cc: Sitaram Chamarty, git
In-Reply-To: <49460531.8010808@dawes.za.net>
On Mon, 15 Dec 2008, Rogan Dawes wrote:
> david@lang.hm wrote:
>
>>
>> as a security person who doesn't like how ssh is used for everything,
>> let me list a couple of concerns.
>>
>> ssh is default allow (it lets you run any commands), you can lock it
>> down with effort.
>>
>> ssh defaults to establishing a tunnel between machines that other
>> network traffic can use to bypass your system. yes I know that with
>> enough effort and control of both systems you can tunnel over anything,
>> the point is that ssh is eager to do this for you (overly eager IMHO)
>>
>> ssh depends primarily on certificates that reside on untrusted machines.
>> it can be made to work with tokens or such, but it takes a fair bit of
>> effort.
>>
>> sshd runs as root on just about every system
>>
>> people trust ssh too much. they tend to think that anything is
>> acceptable if it's done over ssh (this isn't a technical issue, but it
>> is a social issue)
>>
>>
>> what would I like to see in an ideal world?
>>
>> something that runs as the git user, does not enable tunneling, and only
>> does the data transfer functions needed for a push. it should use
>> off-the-shelf libraries for certificate authentication and tie into PAM
>> for additional authentication.
>
> How about a git-specific deployment/configuration of ssh? You can
> certainly run multiple copies of SSH (on different ports), by providing
> a restricted configuration file you can disable tunneling and any other
> functionality that you don't like.
>
> And if you want it to run as a non-root user, simply choose a port>1024,
> but keep in mind that you won't be able to authenticate by password
> (IIRC, only key auth will work when running non-root), or setuid to
> those users when they log in. Nonetheless, this could be sufficient for
> gitosis, since everything runs as the specified user anyway, and IIRC,
> gitosis wants individual SSH pubkeys to allow access.
IMHO this is better then exposing a 'normal' ssh daemon to the Internet
just to be able to do a git push. the fact that you loose authentication
options is not a good thing, are you sure that you cannot hook into PAM
authentication for this?
>> the authentication would not be any better than with SSH, but the rest
>> would be better. I was very pleased to watch the git-daemon development,
>> and the emphisis on it running with minimum privilages and provide just
>> the functionality that was needed, and appropriately assuming that any
>> connection from the outside is hostile until proven otherwise.
>
> In another mail, David wrote:
>
>> 1. if you are running multiple different applications that all want
>> to be exposed via port 22 (like git for 'git push') then you may need
>> to expose numerous machines. tools that use SSH don't tend to have the
>> ability to use a gateway box before they start executing commands,
>> they assume that you will SSH directly into the destination box.
>
> In many cases, especially if the tool is unix based, you can specify (in
> ~/.ssh/config) a Proxy command that is executed before the SSH protocol
> negotiation begins, which results in stdin and stdout being connected to
> the SSH daemon at the destination. The most common variations are the
> HTTP and Socks proxy connectors (e.g. corkscrew?), but the sky is really
> the limit in terms of what is possible.
as I just commented, this looks like it's a per-user config option that is
designed to be used as a proxy out of the network you are in to get to the
Internet, not to be used at the far side of a connection to get to things
on a remote network. as I understand it, you would need to change this
config file for each different destination network you need to connect to.
David Lang
^ permalink raw reply
* Re: is gitosis secure?
From: david @ 2008-12-15 8:25 UTC (permalink / raw)
To: Mike Hommey; +Cc: martin, git
In-Reply-To: <20081215071737.GA32387@glandium.org>
On Mon, 15 Dec 2008, Mike Hommey wrote:
> On Sun, Dec 14, 2008 at 05:00:14PM -0800, david@lang.hm wrote:
>> 1. if you are running multiple different applications that all want to be
>> exposed via port 22 (like git for 'git push') then you may need to expose
>> numerous machines. tools that use SSH don't tend to have the ability to
>> use a gateway box before they start executing commands, they assume that
>> you will SSH directly into the destination box.
>
> But ssh itself allows you to do proxying. See ProxyCommand in
> ssh_config's manpage.
I was not aware of that option, but it looks like it's designed to be one
setting for all your ssh communications, so unless you always use the same
gateway box to get to your destination you would need to tweak your ssh
config for each different thing that you are doing.
David Lang
^ permalink raw reply
* Re: is gitosis secure?
From: Rogan Dawes @ 2008-12-15 7:20 UTC (permalink / raw)
To: david; +Cc: Sitaram Chamarty, git
In-Reply-To: <alpine.DEB.1.10.0812132126470.17688@asgard.lang.hm>
david@lang.hm wrote:
>
> as a security person who doesn't like how ssh is used for everything,
> let me list a couple of concerns.
>
> ssh is default allow (it lets you run any commands), you can lock it
> down with effort.
>
> ssh defaults to establishing a tunnel between machines that other
> network traffic can use to bypass your system. yes I know that with
> enough effort and control of both systems you can tunnel over anything,
> the point is that ssh is eager to do this for you (overly eager IMHO)
>
> ssh depends primarily on certificates that reside on untrusted machines.
> it can be made to work with tokens or such, but it takes a fair bit of
> effort.
>
> sshd runs as root on just about every system
>
> people trust ssh too much. they tend to think that anything is
> acceptable if it's done over ssh (this isn't a technical issue, but it
> is a social issue)
>
>
> what would I like to see in an ideal world?
>
> something that runs as the git user, does not enable tunneling, and only
> does the data transfer functions needed for a push. it should use
> off-the-shelf libraries for certificate authentication and tie into PAM
> for additional authentication.
How about a git-specific deployment/configuration of ssh? You can
certainly run multiple copies of SSH (on different ports), by providing
a restricted configuration file you can disable tunneling and any other
functionality that you don't like.
And if you want it to run as a non-root user, simply choose a port>1024,
but keep in mind that you won't be able to authenticate by password
(IIRC, only key auth will work when running non-root), or setuid to
those users when they log in. Nonetheless, this could be sufficient for
gitosis, since everything runs as the specified user anyway, and IIRC,
gitosis wants individual SSH pubkeys to allow access.
> the authentication would not be any better than with SSH, but the rest
> would be better. I was very pleased to watch the git-daemon development,
> and the emphisis on it running with minimum privilages and provide just
> the functionality that was needed, and appropriately assuming that any
> connection from the outside is hostile until proven otherwise.
In another mail, David wrote:
> 1. if you are running multiple different applications that all want
> to be exposed via port 22 (like git for 'git push') then you may need
> to expose numerous machines. tools that use SSH don't tend to have the
> ability to use a gateway box before they start executing commands,
> they assume that you will SSH directly into the destination box.
In many cases, especially if the tool is unix based, you can specify (in
~/.ssh/config) a Proxy command that is executed before the SSH protocol
negotiation begins, which results in stdin and stdout being connected to
the SSH daemon at the destination. The most common variations are the
HTTP and Socks proxy connectors (e.g. corkscrew?), but the sky is really
the limit in terms of what is possible.
Rogan
^ permalink raw reply
* Re: What's cooking in git.git (Dec 2008, #02; Sun, 14)
From: Junio C Hamano @ 2008-12-15 6:16 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3prjvdngm.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> writes:
>> [New Topics]
>>
>> * jn/gitweb-blame (Thu Dec 11 01:33:29 2008 +0100) 3 commits
>> - gitweb: cache $parent_commit info in git_blame()
>> - gitweb: A bit of code cleanup in git_blame()
>> - gitweb: Move 'lineno' id from link to row element in git_blame
>
> I wonder if it should made into 1.6.1 for the performance improvements
> in 'blame' view...
Does is addresses a grave bug? I thought not.
>> [Post 1.6.1 items]
>>
>> * gb/gitweb-patch (Sat Dec 6 16:02:35 2008 +0100) 3 commits
>> Updated series. Reviews and Acks?
>
> I'll try to find time to review (and most probably Ack) later today.
Thanks.
>> * jn/gitweb-utf8 (Mon Dec 1 19:01:42 2008 +0100) 1 commit
>> + gitweb: Fix handling of non-ASCII characters in inserted HTML
>> files.
>>
>> A bugfix.
>
> What about
>
> + gitweb: Fix bug in insert_file() subroutine
It already is part of 'master' for some time, isn't it?.
>> * jc/stripspace (Sun Mar 9 00:30:35 2008 -0800) 6 commits
> ...
> What happened to this series to be so stale^Wstalled?
Mostly lack of positive feedbacks which is the same thing as "nobody but
the author is interested'.
^ permalink raw reply
* Re: is gitosis secure?
From: david @ 2008-12-15 6:32 UTC (permalink / raw)
To: Asheesh Laroia; +Cc: Nix, git
In-Reply-To: <alpine.DEB.2.00.0812142121090.9552@vellum.laroia.net>
On Sun, 14 Dec 2008, Asheesh Laroia wrote:
> On Mon, 15 Dec 2008, Nix wrote:
>
>> On 14 Dec 2008, Jakub Narebski spake thusly:
>>> BTW. is outgoing SSH transport (from network to outside) blocked as well?
>>
>> *No* ports are open. All they have is a (non-transparent) buggy HTTP proxy.
>> These guys really don't get the Internet, despite their sales literature
>> banging on endlessly about it.
>
> If that's the only way you can access the network, you can take advantage of
> the way HTTP proxies deal with HTTPS: they typically let it through byte for
> byte.
>
> "connect.c is the simple relaying command to make network connection via
> SOCKS and https proxy. It is mainly intended to be used as proxy command of
> OpenSSH."
>
> Run sshd on port 443, use connect.c, and you're set.
>
> (Except for some really smart SSL-aware HTTP proxies that verify that it's an
> SSL connection of some kind. In theory, you could then sslwrap your sshd and
> then be set.)
although, if the company is doing this as a deliberate security measure
(as opposed to not knowing what they are doing), setting up a bypass like
this can get you fired for deliberatly bypassing a security device.
also, examples of people going to this sort of effort to bypass security
policies end up with employees being trusted less.
you are far better off going through channels and discussing what you are
trying to do and why.
David Lang
^ permalink raw reply
* Re: is gitosis secure?
From: Asheesh Laroia @ 2008-12-15 5:24 UTC (permalink / raw)
To: Nix; +Cc: git
In-Reply-To: <87prju5m6s.fsf@hades.wkstn.nix>
On Mon, 15 Dec 2008, Nix wrote:
> On 14 Dec 2008, Jakub Narebski spake thusly:
>> BTW. is outgoing SSH transport (from network to outside) blocked as
>> well?
>
> *No* ports are open. All they have is a (non-transparent) buggy HTTP
> proxy. These guys really don't get the Internet, despite their sales
> literature banging on endlessly about it.
If that's the only way you can access the network, you can take advantage
of the way HTTP proxies deal with HTTPS: they typically let it through
byte for byte.
"connect.c is the simple relaying command to make network connection via
SOCKS and https proxy. It is mainly intended to be used as proxy command
of OpenSSH."
Run sshd on port 443, use connect.c, and you're set.
(Except for some really smart SSL-aware HTTP proxies that verify that it's
an SSL connection of some kind. In theory, you could then sslwrap your
sshd and then be set.)
-- Asheesh.
--
Q: Why did the astrophysicist order three hamburgers?
A: Because he was hungry.
^ permalink raw reply
* Re: TortoiseGit
From: Geoffrey Lee @ 2008-12-15 3:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Li Frank, git
In-Reply-To: <7vhc56yume.fsf@gitster.siamese.dyndns.org>
On Sun, Dec 14, 2008 at 7:39 PM, Junio C Hamano <gitster@pobox.com> wrote:
> That cuts both ways. Most development around git happen on this list and
> taking a project's development discussion away from here will hide it from
> the mainstream development. People involved in TortoiseGit may decide
> that asking for some change in the core is a good idea on their own Wiki,
> and after spending significant amount of effort come back to this list
> with a request for change, which may turn out to be suboptimal (or worse,
> impossible) solution, and you can avoid such wasted effort by keeping the
> discussion on list here.
We ended up creating:
http://groups.google.com/group/tortoisegit-users
http://groups.google.com/group/tortoisegit-dev
http://groups.google.com/group/tortoisegit-announce
Although I believe Frank wanted to keep discussion on here for now
until our growth warrants a separate list.
-Geoffrey Lee
^ permalink raw reply
* Re: TortoiseGit
From: Junio C Hamano @ 2008-12-15 3:39 UTC (permalink / raw)
To: Geoffrey Lee; +Cc: Li Frank, git
In-Reply-To: <83d7aaa40812141803x4cdc1151y8ef82b9e19eceb80@mail.gmail.com>
"Geoffrey Lee" <geoffreyj.lee@gmail.com> writes:
> On Sun, Dec 14, 2008 at 5:12 PM, Li Frank <lznuaa@gmail.com> wrote:
>> What's better github compared with repos.or.cz.
>
> Github projects come with a wiki,...
That cuts both ways. Most development around git happen on this list and
taking a project's development discussion away from here will hide it from
the mainstream development. People involved in TortoiseGit may decide
that asking for some change in the core is a good idea on their own Wiki,
and after spending significant amount of effort come back to this list
with a request for change, which may turn out to be suboptimal (or worse,
impossible) solution, and you can avoid such wasted effort by keeping the
discussion on list here.
^ permalink raw reply
* Re: [PATCH] modify/delete conflict resolution overwrites untracked file
From: Junio C Hamano @ 2008-12-15 3:34 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: git
In-Reply-To: <7v63lm1c76.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Clemens Buchacher <drizzd@aon.at> writes:
>
>> On Wed, Dec 10, 2008 at 09:12:59PM +0100, Clemens Buchacher wrote:
>>> If a file was removed in HEAD, but modified in MERGE_HEAD, recursive merge
>>> will result in a "CONFLICT (delete/modify)". If the (now untracked) file
>>> already exists and was not added to the index, it is overwritten with the
>>> conflict resolution contents.
>>
>> The following patch fixes the problem described above, but it also breaks
>> t6023-merge-rename-nocruft.sh, which tries to merge "A" renamed to "B" in
>> HEAD and "A" modified in MERGE_HEAD, while ignoring an untracked file "A" in
>> the working tree. If we want to be able to do this, we have to handle the
>> other case after rename detection.
>
> If the breakage is in merge-recursive but not in merge-resolve, my gut
> feeling is that we should not be touching unpack-trees at all. With luck
> I may be able to find some time to take a look at this myself but right
> now we are entertaining a guest, so....
-- >8 --
merge-recursive: do not clobber untracked working tree garbage
When merge-recursive wanted to create a new file in the work tree (either
as the final result, or a hint for reference purposes while delete/modify
conflicts), it unconditionally overwrote an untracked file in the working
tree. Be careful not to lose whatever the user has that is not tracked.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
merge-recursive.c | 32 ++++++++++++++++++++++++++++++++
1 files changed, 32 insertions(+), 0 deletions(-)
diff --git c/merge-recursive.c w/merge-recursive.c
index a0c804c..2da4333 100644
--- c/merge-recursive.c
+++ w/merge-recursive.c
@@ -447,6 +447,30 @@ static void flush_buffer(int fd, const char *buf, unsigned long size)
}
}
+static int would_lose_untracked(const char *path)
+{
+ int pos = cache_name_pos(path, strlen(path));
+
+ if (pos < 0)
+ pos = -1 - pos;
+ while (pos < active_nr &&
+ !strcmp(path, active_cache[pos]->name)) {
+ /*
+ * If stage #0, it is definitely tracked.
+ * If it has stage #2 then it was tracked
+ * before this merge started. All other
+ * cases the path was not tracked.
+ */
+ switch (ce_stage(active_cache[pos])) {
+ case 0:
+ case 2:
+ return 0;
+ }
+ pos++;
+ }
+ return file_exists(path);
+}
+
static int make_room_for_path(const char *path)
{
int status;
@@ -462,6 +486,14 @@ static int make_room_for_path(const char *path)
die(msg, path, "");
}
+ /*
+ * Do not unlink a file in the work tree if we are not
+ * tracking it.
+ */
+ if (would_lose_untracked(path))
+ return error("refusing to lose untracked file at '%s'",
+ path);
+
/* Successful unlink is good.. */
if (!unlink(path))
return 0;
^ permalink raw reply related
* Re: TortoiseGit
From: Geoffrey Lee @ 2008-12-15 2:03 UTC (permalink / raw)
To: Li Frank; +Cc: git
In-Reply-To: <1976ea660812141712w196540caue9525ddbae8192f3@mail.gmail.com>
On Sun, Dec 14, 2008 at 5:12 PM, Li Frank <lznuaa@gmail.com> wrote:
> What's better github compared with repos.or.cz.
Github projects come with a wiki, and you can watch the project for
changes. If you are only concerned about having your source code
publicly accessible, then repo.or.cz is perfectly fine.
Regardless of whether or not you migrate to github, I recommend that
you setup mailing lists for announcements, users, and devs.
-Geoffrey Lee
^ permalink raw reply
* Re: TortoiseGit
From: Junio C Hamano @ 2008-12-15 1:29 UTC (permalink / raw)
To: Li Frank; +Cc: Tim Visher, git
In-Reply-To: <1976ea660812141712w196540caue9525ddbae8192f3@mail.gmail.com>
"Li Frank" <lznuaa@gmail.com> writes:
> What's better github compared with repos.or.cz.
People just wanted to have it on some publicly accessible site.
repo.or.cz should be just fine, I think.
^ permalink raw reply
* Re: Possibly-spurious 'not uptodate. Cannot merge'
From: Junio C Hamano @ 2008-12-15 1:27 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: git
In-Reply-To: <gi4adq$cr1$1@ger.gmane.org>
Sitaram Chamarty <sitaramc@gmail.com> writes:
> On 2008-12-14, Nix <nix@esperi.org.uk> wrote:
>> In this situation, 'git diff' reports no changes at all, but 'git reset
>> --hard' gets the tree back into a state where merging succeeds, as does
>> 'git update-index --refresh'.
>
> Wasn't there some situation in which merely running 'git
> status' would have a similar effect? I seem to recall
> reading that somewhere but now I can't find any mention of
> it in 'git help status'.
It would, but this is a pure bug in the re-implementation of git-merge
that was introduced soon after v1.5.6. The users shouldn't be required to
run refresh to work this around.
^ permalink raw reply
* Re: TortoiseGit: missing CloneDlg.htm
From: Li Frank @ 2008-12-15 1:17 UTC (permalink / raw)
To: Jamie Border, git
In-Reply-To: <8666c7870812140955t7da5461avc17562b8aa17dbaf@mail.gmail.com>
Okay, I will check it.
Clone have not completed.
2008/12/15 Jamie Border <jborder@gmail.com>:
> Hey Frank!
>
> Nice work, but I think you might have left src\Tortoise\CloneDlg.htm
> out of the repo...
>
> TortoiseProcENG.rc line 2348 (IDR_HTML_CLONEDLG)
>
> master @ 3b2f3b4...
>
> Keep up the good work!
>
> Jamie
>
> --
>
> Jamie Border <jborder@gmail.com>
>
^ permalink raw reply
* Re: TortoiseGit
From: Li Frank @ 2008-12-15 1:12 UTC (permalink / raw)
To: Tim Visher, git
In-Reply-To: <c115fd3c0812140900k69b07101k7ce16002727c8268@mail.gmail.com>
What's better github compared with repos.or.cz.
2008/12/15 Tim Visher <tim.visher@gmail.com>:
> On Sun, Dec 14, 2008 at 7:26 AM, Alcides Fonseca <me@alcidesfonseca.com> wrote:
>
>> have your main git repo in github.com
>
> +1
>
> --
>
> In Christ,
>
> Timmy V.
>
> http://burningones.com/
> http://five.sentenc.es/ - Spend less time on e-mail
>
^ permalink raw reply
* Re: TortoiseGit
From: Li Frank @ 2008-12-15 1:11 UTC (permalink / raw)
To: Geoffrey Lee; +Cc: git
In-Reply-To: <83d7aaa40812141412j20ae6b5l356d70a45d1d480b@mail.gmail.com>
TortoiseGit is base on TortoiseSVN 14459.
I will push 14459 TSVNCache code to repository tonight.
So you can have a base.
2008/12/15 Geoffrey Lee <geoffreyj.lee@gmail.com>:
> Ok, I'll start taking a look at TSVNCache.
> -Geoffrey Lee
>
> On Sun, Dec 14, 2008 at 1:46 AM, Li Frank <lznuaa@gmail.com> wrote:
>>
>> Yes!
>> TSVNcache.exe has not started porting! TSVNCache is used for overlay icon.
>> TortoiseMerge have not started porting!
>>
>> I think this release is just a begining.
>>
>> best regards
>> Frank Li
>>
>> 2008/12/14 Geoffrey Lee <geoffreyj.lee@gmail.com>:
>> > Hi Frank,
>> > I was just about to start a TortoiseGit project until I saw your project
>> > today. Would you like any help?
>> > -Geoffrey Lee
>
>
^ permalink raw reply
* Re: Possibly-spurious 'not uptodate. Cannot merge'
From: Sitaram Chamarty @ 2008-12-15 1:03 UTC (permalink / raw)
To: git
In-Reply-To: <874p16puuq.fsf@hades.wkstn.nix>
On 2008-12-14, Nix <nix@esperi.org.uk> wrote:
> In this situation, 'git diff' reports no changes at all, but 'git reset
> --hard' gets the tree back into a state where merging succeeds, as does
> 'git update-index --refresh'.
Wasn't there some situation in which merely running 'git
status' would have a similar effect? I seem to recall
reading that somewhere but now I can't find any mention of
it in 'git help status'.
^ permalink raw reply
* Re: [PATCH] modify/delete conflict resolution overwrites untracked file
From: Junio C Hamano @ 2008-12-15 1:03 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: git
In-Reply-To: <20081215004651.GA16205@localhost>
Clemens Buchacher <drizzd@aon.at> writes:
> On Wed, Dec 10, 2008 at 09:12:59PM +0100, Clemens Buchacher wrote:
>> If a file was removed in HEAD, but modified in MERGE_HEAD, recursive merge
>> will result in a "CONFLICT (delete/modify)". If the (now untracked) file
>> already exists and was not added to the index, it is overwritten with the
>> conflict resolution contents.
>
> The following patch fixes the problem described above, but it also breaks
> t6023-merge-rename-nocruft.sh, which tries to merge "A" renamed to "B" in
> HEAD and "A" modified in MERGE_HEAD, while ignoring an untracked file "A" in
> the working tree. If we want to be able to do this, we have to handle the
> other case after rename detection.
If the breakage is in merge-recursive but not in merge-resolve, my gut
feeling is that we should not be touching unpack-trees at all. With luck
I may be able to find some time to take a look at this myself but right
now we are entertaining a guest, so....
^ permalink raw reply
* Re: [PATCH] modify/delete conflict resolution overwrites untracked file
From: Clemens Buchacher @ 2008-12-15 0:46 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <20081210201259.GA12928@localhost>
On Wed, Dec 10, 2008 at 09:12:59PM +0100, Clemens Buchacher wrote:
> If a file was removed in HEAD, but modified in MERGE_HEAD, recursive merge
> will result in a "CONFLICT (delete/modify)". If the (now untracked) file
> already exists and was not added to the index, it is overwritten with the
> conflict resolution contents.
The following patch fixes the problem described above, but it also breaks
t6023-merge-rename-nocruft.sh, which tries to merge "A" renamed to "B" in
HEAD and "A" modified in MERGE_HEAD, while ignoring an untracked file "A" in
the working tree. If we want to be able to do this, we have to handle the
other case after rename detection.
---
unpack-trees.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/unpack-trees.c b/unpack-trees.c
index 54f301d..de5b616 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -859,6 +859,9 @@ int threeway_merge(struct cache_entry **stages, struct unpack_trees_options *o)
if (index) {
if (verify_uptodate(index, o))
return -1;
+ } else if (remote && !remote_match) {
+ if (verify_absent(remote, "overwritten", o))
+ return -1;
}
o->nontrivial_merge = 1;
--
1.6.1.rc2
^ permalink raw reply related
* Re: [PATCH] Get rid of the last remnants of GIT_CONFIG_LOCAL
From: Junio C Hamano @ 2008-12-15 0:43 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0812142310210.25197@racer>
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