* Re: Weird filename encoding issue
From: Johannes Sixt @ 2008-10-17 8:55 UTC (permalink / raw)
To: Alexander Gladysh; +Cc: msysgit, git
In-Reply-To: <c6c947f60810170108q3038b66bj2ad89bdcb7105903@mail.gmail.com>
Alexander Gladysh schrieb:
> 3. Clone repo to OS X machine and see the weird behaviour. Git status
> can't decide how file should be named, "%CA%EE%EF%E8%FF.txt" or
> "\312\356\357\350\377.txt".
It's not 'git status' that cannot decide how to name the file. It's OS X.
> $ git status
> # On branch master
> # Untracked files:
> # (use "git add <file>..." to include in what will be committed)
> #
> # %CA%EE%EF%E8%FF.txt
> nothing added to commit but untracked files present (use "git add" to track)
> $ ls
> %CA%EE%EF%E8%FF.txt
git asked OS X:
Does the file "\312\356\357\350\377.txt" exist?
and OS X said: "Yes". Because otherwise, you would have seen the file
listed as "deleted:" in the 'git status' call above.
But then git also requested a file listing from OS X in order to list the
untracked files. And now OS X returned the name "%CA%EE%EF%E8%FF.txt". How
could you expect git to tell that this is the same file when OS X cannot
decide how to name it?
The solution: Do not use file names with some local (let alone Windows
specific) encoding if you have to use the files on OS X, too.
-- Hannes
^ permalink raw reply
* Re: commiting while the current version is in conflict
From: Junio C Hamano @ 2008-10-17 8:37 UTC (permalink / raw)
To: Richard Hartmann; +Cc: Shawn O. Pearce, Miklos Vajna, git
In-Reply-To: <2d460de70810170021q5daa902er1e6e2fb6633400ec@mail.gmail.com>
"Richard Hartmann" <richih.mailinglist@gmail.com> writes:
>> (2) pre-commit hook is a last ditch effort to help ignorant
>> users who have already done "git add" without thinking and
>> lost the "unmerged" state. It has to look at and guess at
>> the contents for that.
>
> Ignoring the ad hominem attack, I would argue that the two
Eh, Sorry about that --- I did not mean "ignorant" in that sense. Perhaps
replacing the word with "unfortunate" would sound nicer?
> To err is human, which is why rm -i exists. Else, you could
> just use alias rm='rm -rf'.
>
> Also, within certain boundaries, a tool should adapt to the
> user, not vice versa.
Don't you realize that is what the hook is doing already? After making
such an error, the definitive information is lost, because the user told
the tool that the resolution is done and the file is ready to be
committed) by mistake. Even then the hook is trying its best to help the
user.
Replace your "rm=rm -rf" sentence with "why undelete exists" and read it
again. No, filesystem undelete does not always work (disk block could
have been recycled for other files), but it could help you when you did
remove a file you wanted to keep by mistake when it can.
As to pre-add hook, I am not enthused, but if somebody sends in a clean
patch, I wouldn't be opposed to it at least in principle.
^ permalink raw reply
* Re: --diff-filter=T does not list x changes
From: Junio C Hamano @ 2008-10-17 8:29 UTC (permalink / raw)
To: Anders Melchiorsen; +Cc: Jeff King, git
In-Reply-To: <87ej2fvgv9.fsf@kalibalik.dk>
Anders Melchiorsen <mail@cup.kalibalik.dk> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> That documentation is quite loosely written. Typechange diff is what
>> T has always meant, and it never was about the executable bit. The
>> word "mode" in that sentence only means the upper bits
>> S_IFREG/S_IFLNK (iow, masked by S_IFMT).
>
> I hope you agree that this reading is not obvious from the
> documentation,...
Yup, didn't I already say that the documentation is buggy?
> How about adding a diff-filter=X for the executable bit?
I do not think it is a good idea for two reasons. Backward compatibility
and sane design.
For one thing, "diff --name-status" never shows X, so you would introduce
an unnecessary inconsistency. If you change "--name-status" to avoid
that, you would be breaking people's existing scripts that expect to see
"M" for such a change.
Even if you were forgiven by these people whose scripts are broken by your
change, you need to decide between "M" and "X" when both contents and
executable bit are changed. The least surprising logic would probably be
to show "X" when _only_ executable bit is changed and show "M" when
contents changed (even when executable bit also did), but that feels quite
arbitrary. And the other way around isn't any better.
^ permalink raw reply
* Re: Weird filename encoding issue
From: Alexander Gladysh @ 2008-10-17 8:08 UTC (permalink / raw)
To: msysgit, git
In-Reply-To: <c6c947f60810170059s3859d906r9935b5e80d8a41c6@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1585 bytes --]
On Fri, Oct 17, 2008 at 11:59 AM, Alexander Gladysh <agladysh@gmail.com> wrote:
> Hi, all!
>
> OS X 10.5.5 (English locale), Git 1.5.5.1
> Windows XP SP2 (Russian), msysGit 1.5.6.1.1071.g76fb
My apologies, Gmail eaten part of my message.
Sorry for such old Git versions, I can not upgrade right now. Perhaps
it was fixed in 1.6.x?
Steps to reproduce:
1. Create git repo on Windows machine, add there file, named
"Копия.txt" (Russian for Copy.txt) in CP1251 (NOT UTF-8). Just in
case, hopefully correctly named file is attached.
File must be added and committed from git gui, not from command line.
$ mkdir test && cd test
$ git init
<put file there>
$ git gui
2. Share the repo somewhere, so it would be accessible from OS X (repo
should still be on Windows machine).
3. Clone repo to OS X machine and see the weird behaviour. Git status
can't decide how file should be named, "%CA%EE%EF%E8%FF.txt" or
"\312\356\357\350\377.txt".
$ git clone /Volumes/Exchange/test/
Initialized empty Git repository in /Users/agladysh/test/.git/
$ cd test
$ git status
# On branch master
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# %CA%EE%EF%E8%FF.txt
nothing added to commit but untracked files present (use "git add" to track)
$ ls
%CA%EE%EF%E8%FF.txt
$ git clean -fd
Removing %CA%EE%EF%E8%FF.txt
$ git status
# On branch master
# Changed but not updated:
# (use "git add/rm <file>..." to update what will be committed)
#
# deleted: "\312\356\357\350\377.txt"
#
no changes added to commit (use "git add" and/or "git commit -a")
Alexander.
[-- Attachment #2: Copy.zip --]
[-- Type: application/zip, Size: 116 bytes --]
^ permalink raw reply
* Weird filename encoding issue
From: Alexander Gladysh @ 2008-10-17 7:59 UTC (permalink / raw)
To: msysgit, git
[-- Attachment #1: Type: text/plain, Size: 105 bytes --]
Hi, all!
OS X 10.5.5 (English locale), Git 1.5.5.1
Windows XP SP2 (Russian), msysGit 1.5.6.1.1071.g76fb
[-- Attachment #2: Copy.zip --]
[-- Type: application/zip, Size: 116 bytes --]
^ permalink raw reply
* Re: Working with remotes; cloning remote references
From: Michael J Gruber @ 2008-10-17 7:33 UTC (permalink / raw)
To: Marc Branchaud; +Cc: Peter Harris, git
In-Reply-To: <48F7BBAC.2090907@xiplink.com>
Marc Branchaud venit, vidit, dixit 17.10.2008 00:09:
> Peter Harris wrote:
>> Ah. I believe I misunderstood what you wanted. Perhaps you want "git
>> remote add", then? Unfortunately, you have to know what your remotes
>> are outside of git for this. Perhaps a script in the root of your
>> repository you can run to set this up after the initial clone?
>
> I think we're converging onto the same track.
>
> Yes, I do want to use "git remote add". My point is basically that,
> having done various git-remote-adds in the main repository, I'd like to
> avoid having to redo them in a clone of that repository.
>
> A script would work, sure, but to me this seems like something git
> should handle for me. If I have to re-establish my connections to the
> remotes whenever I want to pull in updates, then I don't see much point
> in keeping the remotes defined in any git repo.
>
>> I seem to recall some discussion of allowing a .gitconfig to be in
>> repositories (similar to .gitignore), but the idea was shot down for
>> security reasons.
>
> I think I can understand why that would be undesirable, but I don't know
> if something like that would be necessary for what I'm talking about.
I don't think there is a direct gittish way for transferring the remote
config from one repo to a clone (other than copying what git submodule
does with .gitmodules etc.).
Would it be sufficient for you if a clone could trigger the main repo to
update its remotes (i.e. git remote update)?
Michael
^ permalink raw reply
* Re: commiting while the current version is in conflict
From: Richard Hartmann @ 2008-10-17 7:25 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3ljwojeeu.fsf@localhost.localdomain>
On Fri, Oct 17, 2008 at 01:42, Jakub Narebski <jnareb@gmail.com> wrote:
> [a lot of detailed information]
Thanks! 'Unfortunately', I figured all this out by myself, in the
meantime, but I really appreciate that you took the time to
explain all this .
Thanks!
Richard
PS: Well, I lie, I did not figure out the mv $1.sample $1 bit
as my git version still uses the old format.
^ permalink raw reply
* Re: What's in git.git (Oct 2008, #03; Tue, 14)
From: Arjen Laarhoven @ 2008-10-17 7:02 UTC (permalink / raw)
To: Pieter de Bie
Cc: Brandon Casey, Jeff King, Junio C Hamano, git, Shawn O. Pearce,
Mike Ralphson
In-Reply-To: <465E8DD6-CBDC-4E02-9C7F-57CBE81E3549@frim.nl>
On Thu, Oct 16, 2008 at 05:37:10PM +0200, Pieter de Bie wrote:
>
> On 16 okt 2008, at 17:21, Brandon Casey wrote:
>
> >Darwin, anyone?
>
> 'maint' passes for me on Darwin (OS X Leopard) after removing the
> regex stuff in Makefile
Yup, confirmed.
Arjen
--
Arjen Laarhoven
The presence of those seeking the truth is infinitely to be preferred to
those who think they've found it.
-- Terry Pratchett, "Monstrous Regiment"
^ permalink raw reply
* Re: commiting while the current version is in conflict
From: Richard Hartmann @ 2008-10-17 7:21 UTC (permalink / raw)
To: Junio Hamano; +Cc: Shawn O. Pearce, Miklos Vajna, git
In-Reply-To: <7vy70of6t2.fsf@arte.twinsun.com>
On Fri, Oct 17, 2008 at 01:39, Junio Hamano <junio@twinsun.com> wrote:
> (0) You are wrong to assume that git does not keep conflict
> information; we can tell if the index is "unmerged" to see
> if you still have unresolved conflicts;
That information is already lost at the point when the
pre-commit hook is executed. Thus, I more or less had to
arrive at the wrong conclusion :)
> (1) When the index is unmerged, git-commit will stop even
> before getting to pre-commit hook, so there is no point
> for pre-commit hook to check if the index is unmerged;
I realize this, now.
> (2) pre-commit hook is a last ditch effort to help ignorant
> users who have already done "git add" without thinking and
> lost the "unmerged" state. It has to look at and guess at
> the contents for that.
Ignoring the ad hominem attack, I would argue that the two
distinct mental concepts of 'I want to commit this in the next
commit' and 'I have resolved this conflict' should have two
distinct commands.
To err is human, which is why rm -i exists. Else, you could
just use alias rm='rm -rf'.
Also, within certain boundaries, a tool should adapt to the
user, not vice versa.
In my opinion, a pre-add hook which is able to warn the user
that something they are about to add is still in conflict would
be best. The one piece of feedback I had up to now was
very positive.
Richard
^ permalink raw reply
* Re: --diff-filter=T does not list x changes
From: Anders Melchiorsen @ 2008-10-17 7:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <7vhc7cq8uq.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Jeff King <peff@peff.net> writes:
>
>> Select only files [...] have their type (mode) changed (T) [...]
>>
>> which to me indicates that your test case should work.
>
> That documentation is quite loosely written. Typechange diff is what
> T has always meant, and it never was about the executable bit. The
> word "mode" in that sentence only means the upper bits
> S_IFREG/S_IFLNK (iow, masked by S_IFMT).
I hope you agree that this reading is not obvious from the
documentation, so I will send a patch later fixing up the prose (if
nobody beats me to it).
How about adding a diff-filter=X for the executable bit? I could
probably look at that during the weekend.
Anders.
^ permalink raw reply
* Re: Git and tagging hook
From: Andreas Ericsson @ 2008-10-17 7:04 UTC (permalink / raw)
To: Jan Hudec; +Cc: Kristis Makris, Jakub Narebski, git
In-Reply-To: <20081016201502.GA6362@efreet.light.src>
Jan Hudec wrote:
> As for people replacing their local commits, this is common especially in
> Linux (and Git) development model.
It's common everywhere where projects use peer review.
Results 1 - 50 of about 14,600 for '"PATCH v2" vger.kernel.org'
Results 1 - 50 of about 360,000 for "PATCH v2"
So yes, it is a very common practice and anything interacting with a remote
database based on each commit action will almost certainly be doing something
wrong quite a lot of the time, especially since not all the patch-series end
up being incorporated into a release anyway.
The only sane integration point is the public watering-hole repository used
for the project, and especially the release branch (or the "for-linus" branches
around the world for sub-projects).
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* "checkout --track -b" broken? (with suggested fix)
From: Junio C Hamano @ 2008-10-17 6:37 UTC (permalink / raw)
To: git; +Cc: Jay Soffian, Daniel Barkalow
Sorry for bringing up a potentially old issue, but I do not think the test
added by 9ed36cf (branch: optionally setup branch.*.merge from upstream
local branches, 2008-02-19) is correct. It does this:
test_expect_success \
'checkout w/--track from non-branch HEAD fails' '
git checkout -b delete-me master &&
rm .git/refs/heads/delete-me &&
test refs/heads/delete-me = "$(git symbolic-ref HEAD)" &&
test_must_fail git checkout --track -b track'
It creates branch 'delete-me' at the tip of 'master' to check it out, and
then it manually deletes the branch. It expects "checkout --track -b track"
to fail because the current branch is broken and there is no way to set up
a tracking information for the new branch.
But I think this is bogus. The checkout fails not because of lack of
trackability (due to broken current _branch_), but because there is no
current _commit_ to branch from.
Jay CC'ed because 9ed36cf is his; Daniel CC'ed as branch.c was
originally his.
Here is an attempt to fix the test, which then revealed that the feature
the commit introduced is broken in the tip of 'maint'. Back when 9ed36cf
was written, test_must_fail was unavailable, and test_expect_failure meant
something different, so transplanting this on top of that old commit won't
reveal the breakage, but I strongly suspect that the feature was broken
from the very beginning.
The patch to branch.c is a quick fix for this issue. The resulting code
passes all the tests, but I am not very proud of hardcoding the "HEAD" in
the code. There must be a better way to do this.
branch.c | 4 +++-
t/t7201-co.sh | 11 +++++------
2 files changed, 8 insertions(+), 7 deletions(-)
diff --git c/branch.c w/branch.c
index b1e59f2..6a75057 100644
--- c/branch.c
+++ w/branch.c
@@ -129,7 +129,9 @@ void create_branch(const char *head,
die("Cannot setup tracking information; starting point is not a branch.");
break;
case 1:
- /* Unique completion -- good */
+ /* Unique completion -- good, only if it is a real ref */
+ if (track == BRANCH_TRACK_EXPLICIT && !strcmp(real_ref, "HEAD"))
+ die("Cannot setup tracking information; starting point is not a branch.");
break;
default:
die("Ambiguous object name: '%s'.", start_name);
diff --git c/t/t7201-co.sh w/t/t7201-co.sh
index fbec70d..da1fbf8 100755
--- c/t/t7201-co.sh
+++ w/t/t7201-co.sh
@@ -330,12 +330,11 @@ test_expect_success \
test "$(git config branch.track2.merge)"
git config branch.autosetupmerge false'
-test_expect_success \
- 'checkout w/--track from non-branch HEAD fails' '
- git checkout -b delete-me master &&
- rm .git/refs/heads/delete-me &&
- test refs/heads/delete-me = "$(git symbolic-ref HEAD)" &&
- test_must_fail git checkout --track -b track'
+test_expect_success 'checkout w/--track from non-branch HEAD fails' '
+ git checkout master^0 &&
+ test_must_fail git symbolic-ref HEAD &&
+ test_must_fail git checkout --track -b track
+'
test_expect_success 'checkout an unmerged path should fail' '
rm -f .git/index &&
^ permalink raw reply related
* Git hooks are not called over HTTP
From: KwangYul Seo @ 2008-10-17 6:23 UTC (permalink / raw)
To: git
Hi,
I have setup a git repository with post-receive and post-update
enabled. I configured hooks.envelopesender and hooks.mailinglist. I
confirmed that it works fine with push from local repositories.
However, hooks are never called when push is done over HTTP. I added
'echo abc' to post-receive to see if it is called or not. With local
push, abc was printed, but with HTTP push it was not printed. What is
the problem here?
BTW, I use Ubuntu hardy.
Regards,
Kwang Yul Seo
^ permalink raw reply
* Re: [PATCH try 2] t1301-shared-repo.sh: don't let a default ACL interfere with the test
From: Matt McCutchen @ 2008-10-17 4:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, git
In-Reply-To: <7viqrrq1wz.fsf@gitster.siamese.dyndns.org>
On Thu, 2008-10-16 at 21:30 -0700, Junio C Hamano wrote:
> Matt McCutchen <matt@mattmccutchen.net> writes:
> > As I said in my other message, default ACLs do not break git, they only
> > break the way git is being tested in t1301-shared-repo.sh . There is no
> > cause for concern.
>
> Is it also true if the default is too tight? Wouldn't that interfere with
> the attempt to loosen the permission bits by core.sharedrepository?
No. adjust_shared_perm does an explicit chmod, which always sets
exactly the requested permissions. A default ACL just replaces the
umask in the calculation of a file's *initial* permissions.
Matt
^ permalink raw reply
* Re: [PATCH try 2] t1301-shared-repo.sh: don't let a default ACL interfere with the test
From: Junio C Hamano @ 2008-10-17 4:30 UTC (permalink / raw)
To: Matt McCutchen; +Cc: Johannes Sixt, git
In-Reply-To: <1224210520.2952.39.camel@mattlaptop2.local>
Matt McCutchen <matt@mattmccutchen.net> writes:
> As I said in my other message, default ACLs do not break git, they only
> break the way git is being tested in t1301-shared-repo.sh . There is no
> cause for concern.
Is it also true if the default is too tight? Wouldn't that interfere with
the attempt to loosen the permission bits by core.sharedrepository?
Just being curious.
^ permalink raw reply
* [PATCH try 4] t1301-shared-repo.sh: don't let a default ACL interfere with the test
From: Matt McCutchen @ 2008-10-17 2:32 UTC (permalink / raw)
To: git
In-Reply-To: <7vzll5jepj.fsf@gitster.siamese.dyndns.org>
This test creates files with several different umasks and expects their
permissions to be initialized according to the umask, so a default ACL on the
trash directory (which overrides the umask for files created in that directory)
causes the test to fail. To avoid that, remove the default ACL if possible with
setfacl(1).
Signed-off-by: Matt McCutchen <matt@mattmccutchen.net>
---
Fix typo in commit message. I'm sorry for the noise.
t/t1301-shared-repo.sh | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/t/t1301-shared-repo.sh b/t/t1301-shared-repo.sh
index dc85e8b..2275caa 100755
--- a/t/t1301-shared-repo.sh
+++ b/t/t1301-shared-repo.sh
@@ -7,6 +7,9 @@ test_description='Test shared repository initialization'
. ./test-lib.sh
+# Remove a default ACL from the test dir if possible.
+setfacl -k . 2>/dev/null
+
# User must have read permissions to the repo -> failure on --shared=0400
test_expect_success 'shared = 0400 (faulty permission u-w)' '
mkdir sub && (
--
1.6.0.2.530.gb503b
^ permalink raw reply related
* [PATCH try 3] t1301-shared-repo.sh: don't let a default ACL interfere with the test
From: Matt McCutchen @ 2008-10-17 2:28 UTC (permalink / raw)
To: git
In-Reply-To: <7vzll5jepj.fsf@gitster.siamese.dyndns.org>
This test creates files with several different umasks and expects thei
permissions to be initialized according to the umask, so a default ACL on the
trash directory (which overrides the umask for files created in that directory)
causes the test to fail. To avoid that, remove the default ACL if possible with
setfacl(1).
Signed-off-by: Matt McCutchen <matt@mattmccutchen.net>
---
t/t1301-shared-repo.sh | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/t/t1301-shared-repo.sh b/t/t1301-shared-repo.sh
index dc85e8b..2275caa 100755
--- a/t/t1301-shared-repo.sh
+++ b/t/t1301-shared-repo.sh
@@ -7,6 +7,9 @@ test_description='Test shared repository initialization'
. ./test-lib.sh
+# Remove a default ACL from the test dir if possible.
+setfacl -k . 2>/dev/null
+
# User must have read permissions to the repo -> failure on --shared=0400
test_expect_success 'shared = 0400 (faulty permission u-w)' '
mkdir sub && (
--
1.6.0.2.530.gb503b
^ permalink raw reply related
* Re: [PATCH try 2] t1301-shared-repo.sh: don't let a default ACL interfere with the test
From: Matt McCutchen @ 2008-10-17 2:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, git
In-Reply-To: <7vzll5jepj.fsf@gitster.siamese.dyndns.org>
On Wed, 2008-10-15 at 22:23 -0700, Junio C Hamano wrote:
> Johannes Sixt <j.sixt@viscovery.net> writes:
> > We have to decide case by case. In the case of shared directories it makes
> > sense to suggest "do not play ACL games". In other cases, however, this
> > suggestion could not work out that well, and a workaround in the code is
> > the better solutions. But we do not know what those other cases are, and
> > the test suite may be a tool to uncover them.
>
> Although I am not particularly interested in hypothetical case that does
> not have concrete examples, I do not care deeply enough either. So let's
> take this patch (with updated/corrected log message) that minimally covers
> the parts that can be broken by ACL games.
As I said in my other message, default ACLs do not break git, they only
break the way git is being tested in t1301-shared-repo.sh . There is no
cause for concern.
In fact, default ACLs obsolete core.sharedrepository as a means of
setting default permissions on a repository because default ACLs apply
to files created by any program while core.sharedrepository is
recognized only by git. Thus, a user who has a default ACL would be
unlikely to also have core.sharedrepository, so even if there were a bad
interaction between the two, no one would be likely to encounter it.
Updated patch to follow.
Matt
^ permalink raw reply
* Re: Rebasing Multiple branches at once...
From: Junio C Hamano @ 2008-10-17 2:00 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Rick Moynihan, git
In-Reply-To: <20081016135908.GI536@genesis.frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> writes:
> On Thu, Oct 16, 2008 at 01:17:20PM +0100, Rick Moynihan <rick@calicojack.co.uk> wrote:
>> I have a master branch, a dev branch and a number of feature branches from
>> dev. And I was wondering if there was an easy way to rebase dev and all of
>> it's sub-branches onto master.
>
> In general this is considered harmful. Why do you rebase your branch
> from time to time? For example in git.git, topic branches are based on
> master, then merged to master when they are ready, but they are never
> rebased.
I do not think it is harmful per-se as long as they are not published.
But rebasing topic branches regularly (i.e. without reasons better than
"the master has more commits than before") is _pointless_. The whole
point of a topic branch is to house the development related to one single
topic. If you keep rebasing it, its progress (when you look at the
differences between topic@{1} and topic, topic@{2} and topic@{1}, ...)
would not be about the single topic, but about the single topic _and
all the other random things that happened on the master branch_.
When you merge a topic branch that forked from an older version of
'master', you may have conflicts, and you may want to resolve it earlier
and that might be why you would want to rebase. But if you _know_ you are
going to have conflicts, you wouldn't wish to rebase all of them at once
to begin with, as you would need to resolve such conflicts yourself
anyway. On the other hand, if you expect there won't be any conflict,
then there absolutely is no point in rebasing them. If you want to make
sure that your topics would all work with the updated 'master', you are
much better off creating trial tree, merging your topics on top of the
updated 'master' one by one, than rebasing all of your topic branches.
^ permalink raw reply
* Re: --diff-filter=T does not list x changes
From: Junio C Hamano @ 2008-10-17 2:00 UTC (permalink / raw)
To: Jeff King; +Cc: Anders Melchiorsen, git
In-Reply-To: <20081016102201.GB20762@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Wed, Oct 15, 2008 at 08:42:35PM +0200, Anders Melchiorsen wrote:
>
>> From documentation, I would expect --diff-filter to list changes in
>> the execute bit, but it does not. I hear on #git that this is
>> intended, though I still do not know how to filter on the execute bit.
>> Is it impossible?
>
> Looking at the code, I think it's impossible, and one would have to add
> a new --diff-filter letter. However, at the very least, the
> documentation should clarify this situation. The --diff-filter
> explanation says:
>
> Select only files [...] have their type (mode) changed (T) [...]
>
> which to me indicates that your test case should work.
That documentation is quite loosely written. Typechange diff is what T
has always meant, and it never was about the executable bit. The word
"mode" in that sentence only means the upper bits S_IFREG/S_IFLNK (iow,
masked by S_IFMT).
^ permalink raw reply
* Re: git-scm.com
From: Junio C Hamano @ 2008-10-17 1:57 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Petr Baudis, Scott Chacon, Wincent Colaiuta, git
In-Reply-To: <20081016184239.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Quoting Petr Baudis <pasky@suse.cz>:
>> On Wed, Oct 15, 2008 at 09:21:50AM -0700, Scott Chacon wrote:
>>> I do wish that there wasn't this 'us vs them' mentality on this list,
>>> though. I think GitHub is doing some good things for the community,
>>> and I also think that 'the community' is bigger than this list.
>>
>> I think this last sentence is where we differ - for (most of?) us the
>> Git developers, 'the community' pretty much _is_ this list (with the IRC
>> channel as its casual extension).
>
> Curiously, whenever somebody says "git-scm.com is the official git
> homepage", you are not involved in the discussion. Could you share your
> position on this issue with the rest of the "community"?
The thing is, I do not think whatever I say would be any more official
than what Pasky says when it comes to "the git homepage", even though I
might be a fairly central person in the developer community.
I first have to say that in this era of the Internet and distributed
development, "official" status means much less than what everybody seems
to think [*1*]. It is perfectly fine for people to decide which site they
would want to go for git related information for themselves, and direct
their friends to.
In other words, I do not care either way very much, personally.
The "official" maintainer of git was Shawn for a short while last year in
October, after he claimed to act as one during my absense, and everybody
accepted it not because I named him but he had the necessary respect and
trust from the developers. I asked him to be the maintainer again this
year during early October, and again it worked quite well. I imagine it
would have worked if it were not Shawn but any other people among the few
people I trust on this list. I don't have to name them but you know who
you are, and more importantly, people in the developer community know who
you are. That is what respect and trust are about.
It wouldn't have worked well if the self-claimed interim maintainer were
just some random Joe, and it wouldn't have worked well either, even if I
endorsed him, if the random Joe did not have enough respect and trust from
the community.
Pasky's site came first from very early in git's life, people contributed
contents to it over time, and he kept the site up-to-date, and through all
that effort, Pasky earned (at least my) respect and trust that the site
will keep serving the git users and developers well as it has been in the
past. For this reason, to me personally, the "official homepage" has
always been git.or.cz, and will continue to be so, until Pasky says he
considers Scott and his pages earned enough respect and trust _from him_,
and wants to redirect git.or.cz traffic to git-scm.com [*2*].
Regarding "the community", I think what Pasky said in the quoted message
is right in that the word, used in a message on _this_ mailing list,
refers to "the developer community", whose definition I 100% agree with
what he said.
I sense that people around GitHub come from a different world --- it may
also be a legitimate "git community" (perhaps a "users and evangelists
community", which is not a bad thing in itself), but certainly it is
different from the git developer community as I know it.
I think "us vs them" mentality is unavoidable to a certain degree. More
importantly, I should also point out that it goes both ways. I think the
"fork once and part forever" attitude of git-scm.com from the very
beginning stems from the very same "us vs them" mentality. The developer
community ("them" for Scott, "us" for me and Pasky) has been (and will
always be) text oriented, because we tend to try shooting for the greatest
common denominator. The end-user community in this Web 2.0 era ("us" for
Scott, "them" for me and Pasky) on the other hand, would want to be
entertained by singing and dancing contents. The two communities serve
different purposes and consist of different audiences.
Very early on, Scott made his intention clear that git-scm.com once copies
from git.or.cz, forks and is very unlikely to merge back because of this
vast difference of the target audience. That's "us vs them" mentality
right there, but I do not think this division was particularly a bad thing
at all. It led to what git-scm.com site has in addition to what it copied
from git.or.cz; git-scm.com has made git more approachable by the kinds of
end users who were repelled by the spartan git.or.cz's contents and
organization. It was a good thing.
So let's help both sites improve support for git users _and_ developers,
and watch git-scm.com continue earning our respect and trust. It is my
understanding that Pasky is hoping that it can turn into a good site that
supports not just end users but developers well, so that he can start
redirecting repo.or.cz traffic to it, and I am hoping the same.
And let's do so without flaming anybody ;-).
[Footnote]
*1* While I was researching to write this message, I was kind of surprised
to find that the Wikipedia article on git went through a few rounds of
flipping between pointing at git.or.cz and git-scm.com. I didn't study
the page history deeply enough to see who did what change, but I doubt any
of the people who are doing real work on either site are stupid enough to
have got involved in the self promotion nonsense. I trust Pasky that much
(and much more), and also I came to trust Scott at least that much, after
seeing git-scm.com adding useful contents over the past few months
(admittedly the rate of the improvement may have slowed down somewhat
recently, compared to its initial bulk import from git.or.cz).
*2* There is no point in duplicated effort when the goals of two sites are
compatible and when there is such trust between two parties. I do not yet
know if the goals are compatible, though. We'll see.
^ permalink raw reply
* Re: commiting while the current version is in conflict
From: Avery Pennarun @ 2008-10-17 1:16 UTC (permalink / raw)
To: Richard Hartmann; +Cc: Shawn O. Pearce, Miklos Vajna, git
In-Reply-To: <2d460de70810161626n4f4c4489k489b20f2e6cce186@mail.gmail.com>
On Thu, Oct 16, 2008 at 7:26 PM, Richard Hartmann
<richih.mailinglist@gmail.com> wrote:
> On Fri, Oct 17, 2008 at 01:00, Shawn O. Pearce <spearce@spearce.org> wrote:
>> and merge conflicts are "resolved" by you running "git add $path"
>> after you have finished fixing that path.
>
> True, git add is an implicit resolving, I did not think about it this way.
> Personally, I think that git should break at this point, but that's
> just me.
>
> The obvious fix would be a pre-add hook. Does anyone else think
> this would make sense?
That would be awesome. I've frequently been bitten by accidentally
running "git add" on a file that I *think* I've resolved the conflicts
on, but it turns out I missed a commit marker or two. And then the
handy conflict-style "git diff" is no longer available, among other
things. If "git add" could prevent me from adding the file at all, it
might save me some trouble.
On the other hand, an even better alternative would be to have a way
to "unadd" a file and bring back the conflict information, but I don't
know how that would really work.
Have fun,
Avery
^ permalink raw reply
* Re: commiting while the current version is in conflict
From: Junio Hamano @ 2008-10-16 23:39 UTC (permalink / raw)
To: Richard Hartmann; +Cc: Shawn O. Pearce, Miklos Vajna, git
> Judging from the code in the pre-commit script, git does not
> keep conflict information in its metadata cache, but tries to guess
> conflicts from the file's contents/ This seems to be a strange
> thing to do, imo. What's the reason for this?
Because
(0) You are wrong to assume that git does not keep conflict
information; we can tell if the index is "unmerged" to see
if you still have unresolved conflicts;
(1) When the index is unmerged, git-commit will stop even
before getting to pre-commit hook, so there is no point
for pre-commit hook to check if the index is unmerged;
(2) pre-commit hook is a last ditch effort to help ignorant
users who have already done "git add" without thinking and
lost the "unmerged" state. It has to look at and guess at
the contents for that.
^ permalink raw reply
* Re: commiting while the current version is in conflict
From: Jakub Narebski @ 2008-10-16 23:42 UTC (permalink / raw)
To: Richard Hartmann; +Cc: git
In-Reply-To: <2d460de70810161510ha220593g4615a55b2c3e3b25@mail.gmail.com>
"Richard Hartmann" <richih.mailinglist@gmail.com> writes:
> I fooled around with git a liitle bit and noticed something
> rather strange. I merged two branches, creating a conflict
> on purpose. When I then did a
>
> git commit -a
>
> all changes were submitted. Of course, I now have a
> file with the conflict markers inlined in my repository. Not
> a good thing, imo. Is there a way to make git block all
> conflicting versions?
The default pre-commit hook shipped with git includes this check.
All you have to do is enable it: it has to be named 'pre-commit' and
it has to be exacutable. In older git version you would do:
$ chmod a+x .git/hooks/pre-commit
while in never versions it would be
$ mv .git/hooks/pre-commit.sample .git/hooks/pre-commit
> Also, I would be interested in the design decissions
> behind the current behaviour. Any pointers?
It is a git policy that it ships with all hooks disabled.
P.S. You can always bypass pre-commit hook (for example if comitting
AsciiDoc files, which may include something that looks like conflict
markers, or if you are committing test which includes conflicted file
as one of test vectors), by using `--no-verify' option to git-commit.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: commiting while the current version is in conflict
From: Richard Hartmann @ 2008-10-16 23:31 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Miklos Vajna, git
In-Reply-To: <20081016232332.GD9877@spearce.org>
On Fri, Oct 17, 2008 at 01:23, Shawn O. Pearce <spearce@spearce.org> wrote:
> Yes, in the index. But it erases it when you stage the file with
> "git add".
>
> Go look at my prior message about how "git commit -a" is staging
> the files prior to commit. That makes git commit think everything
> has been resolved, because you've told git, everything is resolved.
This makes a good part of my latest email obsolete. Asynchronous
communication ftw ;)
Richard
^ 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