* How to deal with mixed tree?
From: Pascal Obry @ 2011-11-22 11:21 UTC (permalink / raw)
To: Git Mailing List
A project P1 is under Git.
A project P2 is under Subversion.
P2 in fact replace a sub-directory (say SD) in P1. The project P2 is a
replacement (extension) of the code in P1.
How to deal with this?
If you clone P1, remove SD in P1 to replace it by P2:
$ git diff
-> will display all the changes in SD, is there a way to avoid that?
$ git merge (between branches) will try to merge changes in SD
I'd like to really tell Git to ignore SD as if it was not there. Any solution?
Thanks,
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
^ permalink raw reply
* Re: [PATCH v2 0/3] Re: cherry-pick/revert error messages
From: Jonathan Nieder @ 2011-11-22 11:27 UTC (permalink / raw)
To: Ramkumar Ramachandra
Cc: git, Christian Couder, Martin von Zweigbergk, Phil Hord,
Jay Soffian
In-Reply-To: <20111122111207.GA7399@elie.hsd1.il.comcast.net>
Errata:
Jonathan Nieder wrote:
> May the series can provide some amusement.
"Maybe".
[...]
> Jonathan Nieder (3):
> revert: rename --reset option to --quit
> revert: rearrange pick_revisions() for clarity
> revert: improve error message for cherry-pick during cherry-pick
I took these from pu before tweaking them, so in a sense it's
appropriate that Junio's sign-off is there, but I do not mean to claim
he looked at and acked the tweaked form. I should have just left my
sign-off.
Sorry for the noise.
^ permalink raw reply
* Re: How to deal with mixed tree?
From: Holger Hellmuth @ 2011-11-22 11:35 UTC (permalink / raw)
To: Pascal Obry; +Cc: Git Mailing List
In-Reply-To: <CA+9ZNic-9U0nP1NGL0shUijnxdhaoEHwyxWM8rOzR2B6Qjq6zQ@mail.gmail.com>
On 22.11.2011 12:21, Pascal Obry wrote:
> A project P1 is under Git.
>
> A project P2 is under Subversion.
>
> P2 in fact replace a sub-directory (say SD) in P1. The project P2 is a
> replacement (extension) of the code in P1.
>
> How to deal with this?
Remove SD in P1, make a logical link from P2 to SD, add SD to
.git/info/exclude
(see "Bug report - local (and git ignored) file silently removed after
checkout" on the mailing list why exclude is better than .gitignore at
the moment)
^ permalink raw reply
* bug, Git, Windows XP, uninstallation
From: Napadovsky Vyacheslav @ 2011-11-22 13:43 UTC (permalink / raw)
To: git
Dear, Git mailing list.
Sorry, if I've sent this message to wrong address, I actually don't
know, where I should send it.
I have a problem with Uninstalling Git for Windows. For installation
I've used this url:
http://code.google.com/p/msysgit/downloads/detail?name=Git-1.7.7.1-preview20111027.exe&can=3&q=
During installation I haven't changed any settings (all was keeped default).
My OS is Windows XP Professional, Russian.
I've tried to reinstall and then uninstall it again - same error.
There error during uninstallation is on the picture here:
http://img42.imageshack.us/img42/8979/gituninstallation.jpg
Thank you.
Best regards,
Napadovskiy Vyacheslav.
^ permalink raw reply
* Git ticket / issue tracking ERA: Git shouldn't allow to push a new branch called HEAD
From: Daniele Segato @ 2011-11-22 14:04 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano, Jeff King
On Mon, 2011-11-14 at 15:26 -0500, Jeff King wrote:
On Mon, Nov 14, 2011 at 12:22:59PM -0800, Junio C Hamano wrote:
>
> > Jeff King <peff@peff.net> writes:
> >
> > > So one solution is to block fetching of remote branches called
HEAD
> > > (which I would be OK with). But another is...
> > > ... Obviously there's a lot more to it than just tweaking the
default fetch
> > > refspecs. The ref lookup rules need to be changed to take this
into
> > > account. There was some discussion about this over the summer
(under the
> > > subject of possible "1.8.0" changes), but I don't think any work
has
> > > been done.
> >
> > I would say discussing and ironing out the kinks of the design
counts as
> > work, but I agree nobody was seriously interested in laying out a
sensible
> > transition plan and discussion died out before anything concrete
happened.
>
> Yeah, I should have said "...has been done since then".
>
> > Regardless of the layout chanage, which probably is a 2.X topic, I
think a
> > good first step would be to start forbidding anything that ends with
_?HEAD
> > as a branch or tag name, on top of Michael's "enforce the refname
rules more
> > vigorously when a ref is created" series.
>
> Agreed. Changing the layout is a long-term fix, and I think
disallowing
> HEAD is a reasonable stop-gap measure.
Hi,
I pretty much agree with you that this is the right solution in the
long-term.
But how are you going to remember this?
Is there an issue tracking?
Do you use some other kind of ticketing system?
Since the *official* repo is now hosted on github, why don't making use
of the github ticketing system? [1]
You probably already discussed this tons of times but I can't figure out
how you are gonna remember to do something if you don't have a roadmap
and a ticketing system that allow you to trace the bugs and features.
Do you have to dig into the mailing list archive to look for the
previous discussion?
This is actually just out of curiosity, sorry if this hurt someones
feeling.
Thanks and regards,
Daniele Segato
[1] according to http://git-scm.com/ the link on "Git source repository"
is https://github.com/gitster/git
^ permalink raw reply
* Re: bug, Git, Windows XP, uninstallation
From: Konstantin Khomoutov @ 2011-11-22 14:04 UTC (permalink / raw)
To: Napadovsky Vyacheslav; +Cc: git
In-Reply-To: <CA+hB07RJ6guYR6wGG=-88wjAdMd4_LR0Qtpd=tAWqv+tbH6Mtw@mail.gmail.com>
On Tue, 22 Nov 2011 17:43:43 +0400
Napadovsky Vyacheslav <napadovskiy@gmail.com> wrote:
> Sorry, if I've sent this message to wrong address, I actually don't
> know, where I should send it.
>
> I have a problem with Uninstalling Git for Windows. For installation
> I've used this url:
> http://code.google.com/p/msysgit/downloads/detail?name=Git-1.7.7.1-preview20111027.exe&can=3&q=
http://groups.google.com/group/msysgit/browse_thread/thread/f3c64ced53a3ae9d
^ permalink raw reply
* Re: How to deal with mixed tree?
From: Pascal Obry @ 2011-11-22 14:20 UTC (permalink / raw)
To: Holger Hellmuth; +Cc: Git Mailing List
In-Reply-To: <4ECB8917.8010305@ira.uka.de>
Holger,
> Remove SD in P1, make a logical link from P2 to SD, add SD to
> .git/info/exclude
Thanks for your quick reply. That's what I have tested but...
> (see "Bug report - local (and git ignored) file silently removed after
> checkout" on the mailing list why exclude is better than .gitignore at
> the moment)
Seems like this is working only if file names are different. This is not
my case as the replacement is very similar. With the following script
I'm expecting empty status and no diff:
<<
#!/bin/sh
# create sd (directory that will replace src2)
mkdir sd
echo sd1 > sd/file1
echo sd2 > sd/file2
# create Git repo
mkdir repo
cd repo
git init
mkdir src1
mkdir src2
echo file > src1/file
echo 3 > src2/file3
git add .
git ci -a -m "first"
# let's replace src2 by sd
rm -fr src2
# ln -s ../sd src2
cp -r ../sd src2
# make sure src2 is excluded
echo 'src2/*' >> .git/info/exclude
# the following output should be clean
echo '============== Status'
git status
echo '============== Diff'
git diff
>>
But the output is actually:
Initialized empty Git repository in /home/obry/tmp/repo/.git/
[master (root-commit) 527c7a1] first
2 files changed, 2 insertions(+), 0 deletions(-)
create mode 100644 src1/file
create mode 100644 src2/file3
cp: cannot stat `../src': No such file or directory
============== Status
# On branch master
# Changes not staged for commit:
# (use "git add/rm <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working
directory)
#
# deleted: src2/file3
#
no changes added to commit (use "git add" and/or "git commit -a")
============== Diff
diff --git a/src2/file3 b/src2/file3
deleted file mode 100644
index 00750ed..0000000
--- a/src2/file3
+++ /dev/null
@@ -1 +0,0 @@
-3
Any other idea?
Thanks.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net - http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B
^ permalink raw reply related
* Re: How to deal with mixed tree?
From: Holger Hellmuth @ 2011-11-22 15:08 UTC (permalink / raw)
To: pascal; +Cc: Git Mailing List
In-Reply-To: <4ECBAFB7.9040505@obry.net>
On 22.11.2011 15:20, Pascal Obry wrote:
>
> Holger,
>
>> Remove SD in P1, make a logical link from P2 to SD, add SD to
>> .git/info/exclude
>
> Thanks for your quick reply. That's what I have tested but...
>
>> (see "Bug report - local (and git ignored) file silently removed after
>> checkout" on the mailing list why exclude is better than .gitignore at
>> the moment)
>
> Seems like this is working only if file names are different. This is not
> my case as the replacement is very similar. With the following script
> I'm expecting empty status and no diff:
>
> <<
> #!/bin/sh
>
> # create sd (directory that will replace src2)
> mkdir sd
> echo sd1> sd/file1
> echo sd2> sd/file2
>
> # create Git repo
> mkdir repo
> cd repo
> git init
> mkdir src1
> mkdir src2
> echo file> src1/file
> echo 3> src2/file3
> git add .
> git ci -a -m "first"
>
> # let's replace src2 by sd
>
> rm -fr src2
> # ln -s ../sd src2
> cp -r ../sd src2
>
> # make sure src2 is excluded
>
> echo 'src2/*'>> .git/info/exclude
>
> # the following output should be clean
You should also remove src2 and all files in it from the git repository.
Something like
git rm -r src2
git ci
echo 'src2' >> .git/info/exclude
instead of
rm -fr src2
echo 'src2/*' >> .git/info/exclude
^ permalink raw reply
* Re: Feature requset: listing of current stash in git gui
From: Stefan Näwe @ 2011-11-22 15:19 UTC (permalink / raw)
To: David Aguilar; +Cc: dexen deVries, git@vger.kernel.org
In-Reply-To: <-8099236111493298698@unknownmsgid>
Am 22.11.2011 11:24, schrieb David Aguilar:
> On Nov 21, 2011, at 4:41 AM, dexen deVries <dexen.devries@gmail.com> wrote:
>
>> On Monday 21 of November 2011 11:53:03 Stefan Näwe wrote:
>>> You can simply put the following in your ~/.gitconfig:
>>>
>>> [guitool "Stash/show"]
>>> cmd = git stash show -p
>>> [guitool "Stash/list"]
>>> cmd = git stash list
>>> [guitool "Stash/pop"]
>>> cmd = git stash pop
>>> [guitool "Stash/drop"]
>>> cmd = git stash drop
>>> confirm = yes
>>
>> that's nice, but doesn't list visually the stashed changes. I'd rather have a
>> listing similar to Unstanged Changes / Staged Changes, with ability to view
>> line-by-line diff just like for Changes.
>
> [blatant plug]
>
> git-cola has this feature.
>>
>
> http://git-cola.github.com/
Yeah, right. I totally forgot about git cola.
But I guess there's no way of starting only the stash view like the 'DAG'
view, is there ?
Stefan
--
----------------------------------------------------------------
/dev/random says: This is a Tagline mirror><rorrim enilgaT a si sihT
python -c "print '73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')"
^ permalink raw reply
* Re: How to deal with mixed tree?
From: Pascal Obry @ 2011-11-22 15:21 UTC (permalink / raw)
To: Holger Hellmuth; +Cc: Git Mailing List
In-Reply-To: <4ECBBAD4.6080206@ira.uka.de>
Holger,
> You should also remove src2 and all files in it from the git repository.
> Something like
>
> git rm -r src2
> git ci
> echo 'src2' >> .git/info/exclude
>
> instead of
>
> rm -fr src2
> echo 'src2/*' >> .git/info/exclude
Thanks this is working indeed. But it was not the whole story :)
In fact I want to do that in a branch (say work) and keep master as-is
as this branch is used to pull changes from origin. And in this case,
doing 'git diff master' still shows the files under src2. See script to
reproduce:
<<
#!/bin/sh
# create sd (directory that will replace src2)
mkdir sd
echo sd1 > sd/file1
echo sd2 > sd/file2
# create Git repo
mkdir repo
cd repo
git init
mkdir src1
mkdir src2
echo file > src1/file
echo 3 > src2/file3
git add .
git ci -a -m "first"
# let's replace src2 by sd in branch work
git checkout -b work
git rm src2/*
git ci -m "no more src2"
# ln -s ../sd src2
cp -r ../sd src2
# make sure src2 is excluded
echo 'src2' >> .git/info/exclude
# the following output should be clean
echo '============== Status'
git status
echo '============== Diff'
git diff
echo '============== Diff master'
git diff master
>>
Is that possible?
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net - http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B
^ permalink raw reply
* Re: Git ticket / issue tracking ERA: Git shouldn't allow to push a new branch called HEAD
From: Daniele Segato @ 2011-11-22 15:56 UTC (permalink / raw)
To: Andrew Ardill; +Cc: Git Mailing List, Junio C Hamano, Jeff King
In-Reply-To: <CAH5451==iXuB=QPW7bQvahB-jMnKC2axJYnW2OfFq=UNO9U6mg@mail.gmail.com>
On Wed, 2011-11-23 at 01:29 +1100, Andrew Ardill wrote:
> > Since the *official* repo is now hosted on github, why don't making
> use
> > of the github ticketing system? [1]
>
> From memory, only members of an organisation/owner of an account can
> manage tickets on github. This would be difficult to organise for
> git.
Well... Actually I think the mailing list works pretty well.
And the ticketing system would only be useful to use as a shared TODO
list.
Let me explain my idea with an example:
An issue is discussed, a bug is acknowledged and a proposed solution is
discussed, this all happen in the mailing list, like it always has.
Someone in the "git management" (the one that usually choose how git
should evolve) open a ticket, copy the relevant part of the mailing list
(or link to the discussion in the archive) and (optionally) place the
bug / feature / enhancement into a roadmap / milestone
If the issue is not assigned anyone can see it and come by in the email
with a patch proposal.
This is just an idea, I can't propose myself to such a job, I wouldn't
be able to provide the appropriate support to it.
> > You probably already discussed this tons of times but I can't figure
> out
> > how you are gonna remember to do something if you don't have a
> roadmap
> > and a ticketing system that allow you to trace the bugs and
> features.
> We have previously discussed this, and it boils down to "if someone
> can ensure it is maintained, let's do it". So far no-one has put their
> hand up and there is a fear of the system becoming clogged with many
> issues that are not maintained.
I see, I can understand why, it's hard to just find the time to read all
the messages in this mailing list.
Regards,
Daniele Segato
^ permalink raw reply
* Re: How to deal with mixed tree?
From: Holger Hellmuth @ 2011-11-22 16:14 UTC (permalink / raw)
To: pascal; +Cc: Git Mailing List
In-Reply-To: <4ECBBDE3.3010904@obry.net>
On 22.11.2011 16:21, Pascal Obry wrote:
> In fact I want to do that in a branch (say work) and keep master as-is
> as this branch is used to pull changes from origin. And in this case,
> doing 'git diff master' still shows the files under src2. See script to
> reproduce:
[...]
> # let's replace src2 by sd in branch work
>
> git checkout -b work
> git rm src2/*
> git ci -m "no more src2"
> # ln -s ../sd src2
> cp -r ../sd src2
>
> # make sure src2 is excluded
>
> echo 'src2'>> .git/info/exclude
>
> # the following output should be clean
>
> echo '============== Status'
> git status
>
> echo '============== Diff'
> git diff
>
> echo '============== Diff master'
> git diff master
>>>
>
> Is that possible?
>
In my not-really-expert opinion no. At least git diff master has to show
something because there obviously is a difference between what is in
master (that you can't gitignore) and your branch (whether you ignore it
or not).
I would
a) use a different directory name for src2 and adapt the Makefile to
cope with that
or
b) remove the src2 link from .git/info/exclude and commit it into the
branch. That way whenever you switch branch and master, the correct dir
or link will be present and still because of the link none of the files
in the svn will be handled by git in any way
^ permalink raw reply
* Re: How to deal with mixed tree?
From: Pascal Obry @ 2011-11-22 17:29 UTC (permalink / raw)
To: Holger Hellmuth; +Cc: Git Mailing List
In-Reply-To: <4ECBCA4F.5090505@ira.uka.de>
Holger,
> In my not-really-expert opinion no. At least git diff master has to show
> something because there obviously is a difference between what is in
> master (that you can't gitignore) and your branch (whether you ignore it
> or not).
I had come to the same conclusion. Sad, it would have been nice to have
an option to fully ignore a path in a repository.
Anyway, thanks a lot for your feedback.
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net - http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B
^ permalink raw reply
* Re: Possible bug with branch names and case sensitivity
From: Jay Soffian @ 2011-11-22 17:31 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Gerd Knops, git
In-Reply-To: <4ECB315F.4080701@alum.mit.edu>
On Tue, Nov 22, 2011 at 12:21 AM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
> Is it obvious how references *should* be handled on case-insensitive
> filesystems? It's certainly not obvious to me (has it been discussed
> elsewhere?) I don't think it is a good idea to "fix" this one problem
> without defining an overall policy.
Indeed, I hadn't thought this through very well at all. My initial
take was just that if I were on a case-insensitive file system, I
don't get to have references that differ only in case. This is of
course quite short-sighted in a distributed VCS. :-(
> Currently git handles references names case-sensitively and allows
> multiple reference names that differ only in case. If this behavior is
> to be preserved on case-insensitive filesystems, then either loose
> references must be stored differently (e.g., multiple references in the
> same file) or ambiguous references need always to be packed. Moreover,
> given a refname, we would need to be careful not to just try to open a
> file with that name and assume that it is the correct reference; rather,
> we would have to ask the filesystem for the name of the file in its
> original case and make sure that it agrees with the case of the refname
> that we seek.
I wonder what the downside would be of always using packed refs on
case-insenstive file systems. This would seem analogous to how git no
longer uses symlinks.
> By the way, this could have ramifications for the recently-added test
> that top-level refnames should be in ALL_CAPS.
>
> If we want to consider bending git's behavior, there are a number of
> ways we could go:
>
> 1. Remain case-sensitive but prohibit refnames that differ only in case.
>
> 2. Remain case-sensitive but prohibit refnames that differ only in case
> *when running on a case-insensitive filesystem*.
>
> 3. Change the handling of refnames to be case-insensitive but
> case-preserving.
>
> The above all assumes a case-insensitive filesystem that is
> *case-preserving*. If we want to support filesystems that do not
> preserve case, things get even more complicated.
>
> And if we want to pretend to support non-ASCII refnames, then the issue
> of encodings is another nasty can of worms...
These all seem like sub-optimal things to do if we can just always
used packed refs.
j.
^ permalink raw reply
* Re: Possible bug with branch names and case sensitivity
From: Junio C Hamano @ 2011-11-22 17:49 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Jay Soffian, Gerd Knops, git
In-Reply-To: <4ECB315F.4080701@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
> Is it obvious how references *should* be handled on case-insensitive
> filesystems? It's certainly not obvious to me (has it been discussed
> elsewhere?) I don't think it is a good idea to "fix" this one problem
> without defining an overall policy.
Thanks for a very sane comment.
> Currently git handles references names case-sensitively and allows
> multiple reference names that differ only in case.
We do the same for in-tree paths, by the way. Ultimately, I think the
sane thing to do is to appeal to the user's common sense. In a project
where its participants may use, or in a project that is about, a platform
where a case-folding filesystem is the default choice, the project would
avoid in-tree paths that are different only in case and would not have
xt_TCPMSS.c and xt_tcpmss.c at the same time. Even though Git allows you
on such a platform to add case-conflicting pair of paths by using
"update-index --cacheinfo", people would not do that, because it is not a
useful thing to do. And Git by default does not forbid recording such pair
of paths, as projects for whatever reason may want to use such pair of
paths if they know its participants can deal with case sensitivity just
fine.
I think refnames have exactly the same issue. In theory, you could have
"Master" and "master" branches, and nothing stops you from trying to do
so, but in practice, if it is not useful for you and your project, and
if it is equally fine to use some other name instead of "Master" for the
purpose of you and your project, then there is no strong reason for doing
so, unless you are trying to irritate users on case folding platforms.
^ permalink raw reply
* Re: Possible bug with branch names and case sensitivity
From: Junio C Hamano @ 2011-11-22 18:01 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Jay Soffian, Gerd Knops, git
In-Reply-To: <4ECB315F.4080701@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
> If we want to consider bending git's behavior, there are a number of
> ways we could go:
>
> 1. Remain case-sensitive but prohibit refnames that differ only in case.
I do not see a strong enough reason to be that draconian.
> 2. Remain case-sensitive but prohibit refnames that differ only in case
> *when running on a case-insensitive filesystem*.
If you make it conditional, it should be per-project, not per-repository.
You may be participating in a cross platform project and you may happen to
be on the case-sensitive system, but absense of such a check for you may
end up hurting other participants who work on a case-insensitive one.
> 3. Change the handling of refnames to be case-insensitive but
> case-preserving.
I do not see it is worth the effort. If you were to expend much effort
then I could see in the longer term (now I am talking about Git 2.0 in
this paragraph) one solution is to remove on-filesystem $GIT_DIR/refs/
hierarchy, put it in a trivial database of some sort, keyed with case
sensitive strings.
The transfer of refs over the wire will stay case sensitive so such a
change would be purely local to the repository, so transition would only
matter if you network mount a new style repository and attempt to use with
older version of Git.
If you go that route, we still would need to think about how to deal with
the $GIT_DIR/logs/ hierarchy, though.
^ permalink raw reply
* Re: [PATCH] Documentation update for 'git branch --list'
From: Junio C Hamano @ 2011-11-22 18:04 UTC (permalink / raw)
To: Vincent van Ravesteijn; +Cc: git, git
In-Reply-To: <4ECB43E4.7030607@lyx.org>
Vincent van Ravesteijn <vfr@lyx.org> writes:
> Op 21-11-2011 18:37, Junio C Hamano schreef:
> ...
>> It is natural to expect "git branch --merged pu vr/\*" to list branches
>> that are contained in 'pu' whose names match the given pattern, but it
>> seems to try creating a branch called "vr/*" and fails, for example.
>
> If this is what you naturally would expect, I would expect the
> following "git branch vr/*" to work as well.
> What would you say if we try to interpret the argument as a pattern
> when the argument is not a valid ref name?
We don't, as that is inviting mistakes. "git branch vr/*" if you have a
vr/ directory in your working tree may create vr/a branch from where the
tip of vr/b points at by mistake.
The "--merged" option is an explicit clue that the user is not interested
in creating new branch, and the string being a pattern is additional clue.
The "--list" option was recently added for the explicit purpose of giving
such a clue as safety measure.
^ permalink raw reply
* Re: How to deal with mixed tree?
From: Junio C Hamano @ 2011-11-22 18:29 UTC (permalink / raw)
To: Holger Hellmuth; +Cc: Pascal Obry, Git Mailing List
In-Reply-To: <4ECB8917.8010305@ira.uka.de>
Holger Hellmuth <hellmuth@ira.uka.de> writes:
> (see "Bug report - local (and git ignored) file silently removed after
> checkout" on the mailing list why exclude is better than .gitignore at
> the moment)
Don't look at it or encourage people to rely on that bug to be
fixed. exclude and .gitignore should behave the same way.
^ permalink raw reply
* [ANN] SubGit Early Access Program Build #789
From: Semen Vadishev @ 2011-11-22 19:15 UTC (permalink / raw)
To: jgit-dev, EGit developer discussion, Git Mailing List
Hello All,
Let me introduce our new project: SubGit (http://subgit.com/).
SubGit is a tool for smooth migration from Subversion to Git. As well as
from Git to Subversion. Without git-svn insanity.
It works like this:
- Install SubGit into your repository on the server side
- Let initial translation complete (time depends on the size of repository)
- SubGit installs hooks into repository, so it translates every svn
revision and git commit
- Committers may now use either Git or Subversion (or both) with the
tools of their choice
SubGit uses JGit to work with the Git stuff. JGit handles heavy load
perfectly thus fitting our needs, and we appreciate efforts JGit
community put into this excellent library. Thank you, guys!
SubGit EAP builds are free to use, you may try these and let us know
what do you miss, so that we make sure that all the features you need
are included into the final version of SubGit.
SubGit works on Linux, Windows or OS X and requires Java 5 or newer.
Download new SubGit EAP build from http://subgit.com/ and follow us at
@subgit and +subgit.
--
Semen Vadishev,
TMate Software,
http://subgit.com/ - Two Way Ticket to The Dark Side
^ permalink raw reply
* Re: Git ticket / issue tracking ERA: Git shouldn't allow to push a new branch called HEAD
From: Junio C Hamano @ 2011-11-22 19:41 UTC (permalink / raw)
To: Daniele Segato; +Cc: Git Mailing List, Junio C Hamano, Jeff King
In-Reply-To: <1321970646.3289.19.camel@mastroc3.mobc3.local>
Daniele Segato <daniele.bilug@gmail.com> writes:
> [1] according to http://git-scm.com/ the link on "Git source repository"
> is https://github.com/gitster/git
That one is as official as anybody's "git clone" from many of the
distribution points.
I do not see any reason to name an official repository, but if I were
pressed, that copy at github is not the one I would nominate.
^ permalink raw reply
* Re: Git ticket / issue tracking ERA: Git shouldn't allow to push a new branch called HEAD
From: Junio C Hamano @ 2011-11-22 19:46 UTC (permalink / raw)
To: Daniele Segato; +Cc: Andrew Ardill, Git Mailing List, Jeff King
In-Reply-To: <1321977372.3289.38.camel@mastroc3.mobc3.local>
Daniele Segato <daniele.bilug@gmail.com> writes:
> Let me explain my idea with an example:
>
> An issue is discussed, a bug is acknowledged and a proposed solution is
> discussed, this all happen in the mailing list, like it always has.
>
> Someone in the "git management" (the one that usually choose how git
> should evolve) open a ticket, copy the relevant part of the mailing list
> (or link to the discussion in the archive) and (optionally) place the
> bug / feature / enhancement into a roadmap / milestone
This step I wouldn't buy, if you count me as part of "management".
But I suspect that curation of issues, prodding parties involved and
closing inactive/stale ones can be done by volunteer project secretaries
without requiring an authority to choose how git should evolve.
cf. http://thread.gmane.org/gmane.comp.version-control.git/110117/focus=110129
^ permalink raw reply
* Re: [msysGit] [PATCH 1/2] MSVC: Do not close stdout to prevent a crash
From: Johannes Sixt @ 2011-11-22 20:24 UTC (permalink / raw)
To: Vincent van Ravesteijn
Cc: git, msysgit, gitster, kusmabite, Johannes.Schindelin
In-Reply-To: <4ECB4501.1060100@lyx.org>
Am 22.11.2011 07:45, schrieb Vincent van Ravesteijn:
>>> To prevent the crash and to prevent git from writing cruft into the
>>> patch
>>> file, we do not close stdout, but redirect it to "nul" instead.
>> A more robust solution is to add invalidcontinue.obj to the linker
>> command line. This installs an invalid argument handler that does not
>> abort, and restores a sane behavior.
>
> This seems to work only for release builds or did I miss something ?
I cannot tell, but I would be surprised if that were the case. I didn't
test with debug builds (only our 'make MSVC=1' build). A cursory look at
the CRT source code does not show anything that would be different
between a debug and a release build regarding invalidcontinue.obj.
> Is there any argument to not redirect stdout to "/dev/null" on all
> platforms ?
You paper over a crack in the wall. You hide a bug.
-- Hannes
^ permalink raw reply
* Re: [msysGit] [PATCH 1/2] MSVC: Do not close stdout to prevent a crash
From: Vincent van Ravesteijn @ 2011-11-22 21:27 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, msysgit, gitster, kusmabite, Johannes.Schindelin
In-Reply-To: <4ECC04E3.70407@kdbg.org>
>> Is there any argument to not redirect stdout to "/dev/null" on all
>> platforms ?
> You paper over a crack in the wall. You hide a bug.
Luckily I'm still trying to find the crack and not ready to tape
anything yet.
Vincent
^ permalink raw reply
* Re: [PATCH 4/3] revert: write REVERT_HEAD pseudoref during conflicted revert
From: Thiago Farina @ 2011-11-22 21:40 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Ramkumar Ramachandra, git, Christian Couder,
Martin von Zweigbergk, Phil Hord, Jay Soffian
In-Reply-To: <20111122111736.GE7399@elie.hsd1.il.comcast.net>
There seems to be something wrong with the subject. I says [4/3],
instead of [4/6]?
On Tue, Nov 22, 2011 at 9:17 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> When conflicts are encountered while reverting a commit, it can be
> handy to have the name of that commit easily available. For example,
> to produce a copy of the patch to refer to while resolving conflicts:
>
> $ git revert 2eceb2a8
> error: could not revert 2eceb2a8... awesome, buggy feature
> $ git show -R REVERT_HEAD >the-patch
> $ edit $(git diff --name-only)
>
> Set a REVERT_HEAD pseudoref when "git revert" does not make a commit,
> for cases like this. This also makes it possible for scripts to
> distinguish between a revert that encountered conflicts and other
> sources of an unmerged index.
>
> After successfully committing, resetting with "git reset", or moving
> to another commit with "git checkout" or "git reset", the pseudoref is
> no longer useful, so remove it.
>
> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
> ---
> branch.c | 1 +
> builtin/commit.c | 1 +
> builtin/revert.c | 8 +++--
> t/t3507-cherry-pick-conflict.sh | 54 +++++++++++++++++++++++++++++++++++++++
> 4 files changed, 61 insertions(+), 3 deletions(-)
>
> diff --git a/branch.c b/branch.c
> index d8098762..025a97be 100644
> --- a/branch.c
> +++ b/branch.c
> @@ -241,6 +241,7 @@ void create_branch(const char *head,
> void remove_branch_state(void)
> {
> unlink(git_path("CHERRY_PICK_HEAD"));
> + unlink(git_path("REVERT_HEAD"));
> unlink(git_path("MERGE_HEAD"));
> unlink(git_path("MERGE_RR"));
> unlink(git_path("MERGE_MSG"));
> diff --git a/builtin/commit.c b/builtin/commit.c
> index c46f2d18..8f2bebec 100644
> --- a/builtin/commit.c
> +++ b/builtin/commit.c
> @@ -1514,6 +1514,7 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
> }
>
> unlink(git_path("CHERRY_PICK_HEAD"));
> + unlink(git_path("REVERT_HEAD"));
> unlink(git_path("MERGE_HEAD"));
> unlink(git_path("MERGE_MSG"));
> unlink(git_path("MERGE_MODE"));
> diff --git a/builtin/revert.c b/builtin/revert.c
> index 1d112e4c..f5ba67a5 100644
> --- a/builtin/revert.c
> +++ b/builtin/revert.c
> @@ -289,7 +289,7 @@ static char *get_encoding(const char *message)
> return NULL;
> }
>
> -static void write_cherry_pick_head(struct commit *commit)
> +static void write_cherry_pick_head(struct commit *commit, const char *pseudoref)
> {
> const char *filename;
> int fd;
> @@ -297,7 +297,7 @@ static void write_cherry_pick_head(struct commit *commit)
>
> strbuf_addf(&buf, "%s\n", sha1_to_hex(commit->object.sha1));
>
> - filename = git_path("CHERRY_PICK_HEAD");
> + filename = git_path(pseudoref);
> fd = open(filename, O_WRONLY | O_CREAT, 0666);
> if (fd < 0)
> die_errno(_("Could not open '%s' for writing"), filename);
> @@ -597,7 +597,9 @@ static int do_pick_commit(struct commit *commit, struct replay_opts *opts)
> * write it at all.
> */
> if (opts->action == CHERRY_PICK && !opts->no_commit && (res == 0 || res == 1))
> - write_cherry_pick_head(commit);
> + write_cherry_pick_head(commit, "CHERRY_PICK_HEAD");
> + if (opts->action == REVERT && ((opts->no_commit && res == 0) || res == 1))
> + write_cherry_pick_head(commit, "REVERT_HEAD");
>
> if (res) {
> error(opts->action == REVERT
> diff --git a/t/t3507-cherry-pick-conflict.sh b/t/t3507-cherry-pick-conflict.sh
> index cb45574a..ee1659c1 100755
> --- a/t/t3507-cherry-pick-conflict.sh
> +++ b/t/t3507-cherry-pick-conflict.sh
> @@ -253,6 +253,60 @@ test_expect_success 'revert also handles conflicts sanely' '
> test_cmp expected actual
> '
>
> +test_expect_success 'failed revert sets REVERT_HEAD' '
> + pristine_detach initial &&
> + test_must_fail git revert picked &&
> + test_cmp_rev picked REVERT_HEAD
> +'
> +
> +test_expect_success 'successful revert does not set REVERT_HEAD' '
> + pristine_detach base &&
> + git revert base &&
> + test_must_fail git rev-parse --verify CHERRY_PICK_HEAD &&
> + test_must_fail git rev-parse --verify REVERT_HEAD
> +'
> +
> +test_expect_success 'revert --no-commit sets REVERT_HEAD' '
> + pristine_detach base &&
> + git revert --no-commit base &&
> + test_must_fail git rev-parse --verify CHERRY_PICK_HEAD &&
> + test_cmp_rev base REVERT_HEAD
> +'
> +
> +test_expect_success 'revert w/dirty tree does not set REVERT_HEAD' '
> + pristine_detach base &&
> + echo foo > foo &&
> + test_must_fail git revert base &&
> + test_must_fail git rev-parse --verify CHERRY_PICK_HEAD &&
> + test_must_fail git rev-parse --verify REVERT_HEAD
> +'
> +
> +test_expect_success 'GIT_CHERRY_PICK_HELP does not suppress REVERT_HEAD' '
> + pristine_detach initial &&
> + (
> + GIT_CHERRY_PICK_HELP="and then do something else" &&
> + GIT_REVERT_HELP="and then do something else, again" &&
> + export GIT_CHERRY_PICK_HELP GIT_REVERT_HELP &&
> + test_must_fail git revert picked
> + ) &&
> + test_must_fail git rev-parse --verify CHERRY_PICK_HEAD &&
> + test_cmp_rev picked REVERT_HEAD
> +'
> +
> +test_expect_success 'git reset clears REVERT_HEAD' '
> + pristine_detach initial &&
> + test_must_fail git revert picked &&
> + git reset &&
> + test_must_fail git rev-parse --verify REVERT_HEAD
> +'
> +
> +test_expect_success 'failed commit does not clear REVERT_HEAD' '
> + pristine_detach initial &&
> + test_must_fail git revert picked &&
> + test_must_fail git commit &&
> + test_cmp_rev picked REVERT_HEAD
> +'
> +
> test_expect_success 'revert conflict, diff3 -m style' '
> pristine_detach initial &&
> git config merge.conflictstyle diff3 &&
> --
> 1.7.8.rc3
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH 6/3] revert: remove --reset compatibility option
From: Junio C Hamano @ 2011-11-22 21:49 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Ramkumar Ramachandra, git, Christian Couder,
Martin von Zweigbergk, Phil Hord, Jay Soffian
In-Reply-To: <20111122112046.GG7399@elie.hsd1.il.comcast.net>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Remove the "git cherry-pick --reset" option, which has a different
> preferred spelling nowadays ("--quit"). Luckily the old --reset name
> was not around long enough for anyone to get used to it.
If we want to reach this point eventually, given that --reset was not in
any released version, and also given that we are deep in pre-release
phase, we probably should either just apply the first one (and perhaps
this one) from the series immediately before 1.7.8 final, or delay the
final and swallow the entire series.
I am not quite convinced that quit is *that* superiour over reset
though. The description in 1/3 "has a confusing name" does not say why it
is confusing, either, to help readers agree with the conclusion.
^ 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