* Re: Merging tags does not fast-forward with git 1.7.9
From: Carlos Martín Nieto @ 2012-02-09 16:06 UTC (permalink / raw)
To: Domenico Andreoli; +Cc: git
In-Reply-To: <20120209095415.GA19230@glitch>
[-- Attachment #1: Type: text/plain, Size: 823 bytes --]
On Thu, 2012-02-09 at 10:54 +0100, Domenico Andreoli wrote:
> Hi,
>
> with the recent changes in tag merging (I updated git to 1.7.9),
> my usual "git merge v3.X-rcY" command does not fast-forward any more.
> Of course the initial head is something like "v3.X-rcZ" without any
> change so that it should (and usually did) fast-forward to the new head.
>
> The editor is instead fired off and I have to fill the details of a
> merge commit, diverging from mainline as soon as I save and exit.
>
> Is there any simple and clear explanation for this? Thank you.
>
> cheers,
> Domenico
>
> ps: I admit I didn't follow the details about tag signatures so probably
> I missed something that I shouldn't.
This was discussed recently
http://thread.gmane.org/gmane.comp.version-control.git/189825
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: Merging tags does not fast-forward with git 1.7.9
From: Domenico Andreoli @ 2012-02-09 16:04 UTC (permalink / raw)
To: Dan Johnson; +Cc: git
In-Reply-To: <CAPBPrntqaFk7YNf7Rz5aVNOMQVTAFaQcJoPFtsOn6rk8n2Q_sg@mail.gmail.com>
On Thu, Feb 09, 2012 at 10:50:50AM -0500, Dan Johnson wrote:
> On Thu, Feb 9, 2012 at 4:54 AM, Domenico Andreoli <cavokz@gmail.com> wrote:
> >
> > with the recent changes in tag merging (I updated git to 1.7.9),
> > my usual "git merge v3.X-rcY" command does not fast-forward any more.
> > Of course the initial head is something like "v3.X-rcZ" without any
> > change so that it should (and usually did) fast-forward to the new head.
> >
> > The editor is instead fired off and I have to fill the details of a
> > merge commit, diverging from mainline as soon as I save and exit.
> >
> > Is there any simple and clear explanation for this? Thank you.
>
> Someone else can explain what is going on more fully, but can you
> report what happens when you run "git merge --ff-only v3.X-rcY"?
This is Debian unstable, out-of-the-box git package 1.7.9-1.
$ git reset --hard v3.3-rc2
HEAD is now at 62aa2b5 Linux 3.3-rc2
$ git merge --ff-only v3.3-rc3
fatal: Not possible to fast-forward, aborting.
$
Same for v3.3-rc1 -> v3.3-rc2.
Thanks,
Domenico
^ permalink raw reply
* Re: Merging tags does not fast-forward with git 1.7.9
From: Dan Johnson @ 2012-02-09 15:50 UTC (permalink / raw)
To: Domenico Andreoli; +Cc: git
In-Reply-To: <20120209095415.GA19230@glitch>
On Thu, Feb 9, 2012 at 4:54 AM, Domenico Andreoli <cavokz@gmail.com> wrote:
> Hi,
>
> with the recent changes in tag merging (I updated git to 1.7.9),
> my usual "git merge v3.X-rcY" command does not fast-forward any more.
> Of course the initial head is something like "v3.X-rcZ" without any
> change so that it should (and usually did) fast-forward to the new head.
>
> The editor is instead fired off and I have to fill the details of a
> merge commit, diverging from mainline as soon as I save and exit.
>
> Is there any simple and clear explanation for this? Thank you.
Someone else can explain what is going on more fully, but can you
report what happens when you run "git merge --ff-only v3.X-rcY"?
--
-Dan
^ permalink raw reply
* Re: ANNOUNCE: Git for Windows 1.7.9
From: Atsushi Nakagawa @ 2012-02-09 13:44 UTC (permalink / raw)
To: Stefan Nawe
Cc: Pat Thoyts, msysGit, Git Mailing List, Karsten Blees, Heiko Voigt
In-Reply-To: <4F33798F.2010908@atlas-elektronik.com>
On Thu, 09 Feb 2012 08:45:19 +0100
Stefan Nawe <stefan.naewe@atlas-elektronik.com> wrote:
> Am 01.02.2012 12:23, schrieb Pat Thoyts:
> > This release brings the latest release of Git to Windows users.
> >
> > [...]
>
> I'm getting errors from 'git repack -Ad' with this version on Windows XP:
>
> $ /bin/git repack -Ad
> Counting objects: 147960, done.
> Delta compression using up to 2 threads.
> Compressing objects: 100% (35552/35552), done.
> Writing objects: 100% (147960/147960), done.
> Total 147960 (delta 110699), reused 147960 (delta 110699)
> Deletion of directory '.git/objects/01/' failed. Should I try again? (y/n)
> Deletion of directory '.git/objects/05/' failed. Should I try again? (y/n) n
> Deletion of directory '.git/objects/07/' failed. Should I try again? (y/n) n
> Deletion of directory '.git/objects/0c/' failed. Should I try again? (y/n) n
> Deletion of directory '.git/objects/10/' failed. Should I try again? (y/n)
> ...
I was getting this a few months back before I set GIT_ASK_YESNO to
false and forgot all about it.
For me, it occurred every time I allowed git-gui to pack loose objects
and I sort of assumed repack was doing a 'rmdir .git/objects/*/" to
clean up empty directories and was triggering the prompt on non-empty
directories.
There was a bit of discussion regarding a slightly different symptom a
while back:
http://groups.google.com/group/msysgit/browse_thread/thread/0f75ac5abd850e21
Regards,
--
Atsushi Nakagawa
<atnak@chejz.com>
Changes are made when there is inconvenience.
^ permalink raw reply
* Re: ANNOUNCE: Git for Windows 1.7.9
From: Stefan Näwe @ 2012-02-09 13:25 UTC (permalink / raw)
Cc: Karsten Blees, Git Mailing List, msysGit, Pat Thoyts
In-Reply-To: <OF7242D083.08C458C8-ONC125799F.0043D7D2-C125799F.0047B5A4@dcon.de>
Am 09.02.2012 14:00, schrieb karsten.blees@dcon.de:
> Stefan Näwe <stefan.naewe@atlas-elektronik.com> wrote on 09.02.2012
> 09:11:03:
>
>> Am 09.02.2012 08:45, schrieb Stefan Näwe:
>>> Am 01.02.2012 12:23, schrieb Pat Thoyts:
>>>> This release brings the latest release of Git to Windows users.
>>>>
>>>> Pre-built installers are available from
>>>> http://code.google.com/p/msysgit/downloads/list
>>>>
>>>> Further details about the Git for Windows project are at
>>>> http://code.google.com/p/msysgit/
>>>
>>> I'm getting errors from 'git repack -Ad' with this version on Windows
> XP:
>>>
>>> $ /bin/git repack -Ad
>>> Counting objects: 147960, done.
>>> Delta compression using up to 2 threads.
>>> Compressing objects: 100% (35552/35552), done.
>>> Writing objects: 100% (147960/147960), done.
>>> Total 147960 (delta 110699), reused 147960 (delta 110699)
>>> Deletion of directory '.git/objects/01/' failed. Should I try again?
> (y/n)
>>> Deletion of directory '.git/objects/05/' failed. Should I try again?
> (y/n) n
>>> Deletion of directory '.git/objects/07/' failed. Should I try again?
> (y/n) n
>>> Deletion of directory '.git/objects/0c/' failed. Should I try again?
> (y/n) n
>>> Deletion of directory '.git/objects/10/' failed. Should I try again?
> (y/n)
>>> ....
>>>
>>>
>>> A bisection pointed me to this commit (https://github.
>> com/msysgit/git/commit/19d1e75):
>>>
>>> "Win32: Unicode file name support (except dirent)"
>>>
>>> When I reset "/git" to this commit and recompile, 'git gc' and
>> 'git repack -Ad'
>>
>> s/this commit/parent of this commit (c5d4ecfe)/
>>
>
> c5d4ecfe just adds unicode conversion functions without using them
> anywhere, so I doubt that this commit has anything to do with the error.
Right. But the commit that comes after it: 19d1e75
> Besides, that code was merged only this week, so its not even in the
> pre-built v1.7.9 installer.
I built the installer myself.
> Have you checked virus scanners or other background jobs that might keep
> the directories open?
I tried that on a physical machine with an on-access virus scanner
enabled and disabled, and also on a virtual machine (VirtualBox) with
no virus scanner installed. Makes no difference.
I also used "Process Explorer" (www.sysinternals.com) to find any
other process that might have the directory open, but there wasn't any.
If you know any other tools for that, let me know.
Regards,
Stefan
--
----------------------------------------------------------------
/dev/random says: Aren't cats just widdle furry balls of love?
python -c "print '73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')"
^ permalink raw reply
* Re: ANNOUNCE: Git for Windows 1.7.9
From: karsten.blees @ 2012-02-09 13:00 UTC (permalink / raw)
To: Stefan Näwe; +Cc: Karsten Blees, Git Mailing List, msysGit, Pat Thoyts
In-Reply-To: <4F337F97.8000903@atlas-elektronik.com>
Stefan Näwe <stefan.naewe@atlas-elektronik.com> wrote on 09.02.2012
09:11:03:
> Am 09.02.2012 08:45, schrieb Stefan Näwe:
> > Am 01.02.2012 12:23, schrieb Pat Thoyts:
> >> This release brings the latest release of Git to Windows users.
> >>
> >> Pre-built installers are available from
> >> http://code.google.com/p/msysgit/downloads/list
> >>
> >> Further details about the Git for Windows project are at
> >> http://code.google.com/p/msysgit/
> >
> > I'm getting errors from 'git repack -Ad' with this version on Windows
XP:
> >
> > $ /bin/git repack -Ad
> > Counting objects: 147960, done.
> > Delta compression using up to 2 threads.
> > Compressing objects: 100% (35552/35552), done.
> > Writing objects: 100% (147960/147960), done.
> > Total 147960 (delta 110699), reused 147960 (delta 110699)
> > Deletion of directory '.git/objects/01/' failed. Should I try again?
(y/n)
> > Deletion of directory '.git/objects/05/' failed. Should I try again?
(y/n) n
> > Deletion of directory '.git/objects/07/' failed. Should I try again?
(y/n) n
> > Deletion of directory '.git/objects/0c/' failed. Should I try again?
(y/n) n
> > Deletion of directory '.git/objects/10/' failed. Should I try again?
(y/n)
> > ....
> >
> >
> > A bisection pointed me to this commit (https://github.
> com/msysgit/git/commit/19d1e75):
> >
> > "Win32: Unicode file name support (except dirent)"
> >
> > When I reset "/git" to this commit and recompile, 'git gc' and
> 'git repack -Ad'
>
> s/this commit/parent of this commit (c5d4ecfe)/
>
c5d4ecfe just adds unicode conversion functions without using them
anywhere, so I doubt that this commit has anything to do with the error.
Besides, that code was merged only this week, so its not even in the
pre-built v1.7.9 installer.
Have you checked virus scanners or other background jobs that might keep
the directories open?
> > don't raise this error anymore.
> >
> > Any ideas ?
> >
> >
> > Thanks,
> > Stefan
>
>
> --
> ----------------------------------------------------------------
> /dev/random says: Take two crows and caw me in the morning
> python -c "print
> '73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.
> decode('hex')"
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en
^ permalink raw reply
* Re: git-subtree Ready for Inspection
From: Matthieu Moy @ 2012-02-09 12:39 UTC (permalink / raw)
To: David A. Greene; +Cc: Jan, git
In-Reply-To: <87liocoayz.fsf@smith.obbligato.org>
greened@obbligato.org (David A. Greene) writes:
> Jan <jk@jk.gs> writes:
>> A publicly accessible URL would be much more helpful. :-)
>
> Do you mean running gitweb? Are you not able to access the above
> repository? I can do that if it makes things easier but it will take a
> bit of time.
I guess a push to whatever public git hosting website you like would do
it.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* [PATCHv4 2/2] git-p4: initial demonstration of possible RCS keyword fixup
From: Luke Diamand @ 2012-02-09 11:03 UTC (permalink / raw)
To: git; +Cc: Pete Wyckoff, Eric Scouten, Luke Diamand
In-Reply-To: <1328785409-30936-1-git-send-email-luke@diamand.org>
This change has a go at showing a possible way to fixup RCS
keyword handling in git-p4.
It does not cope with deleted files.
It does not have good test coverage.
It does not solve the problem of the incorrect error messages.
But it does at least work after a fashion, and could provide
a starting point.
Signed-off-by: Luke Diamand <luke@diamand.org>
---
contrib/fast-import/git-p4 | 43 +++++++++++++++++++++++++++++++++++++++++--
t/t9810-git-p4-rcs.sh | 1 +
2 files changed, 42 insertions(+), 2 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index a78d9c5..205fefd 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -753,6 +753,23 @@ class P4Submit(Command, P4UserMap):
return result
+ def patchRCSKeywords(self, file):
+ # Attempt to zap the RCS keywords in a p4 controlled file
+ p4_edit(file)
+ (handle, outFileName) = tempfile.mkstemp()
+ outFile = os.fdopen(handle, "w+")
+ inFile = open(file, "r")
+ for line in inFile.readlines():
+ line = re.sub(r'\$(Id|Header|Author|Date|DateTime|Change|File|Revision)[^$]*\$',
+ r'$\1$', line)
+ outFile.write(line)
+ inFile.close()
+ outFile.close()
+ # Forcibly overwrite the original file
+ system("cat %s" % outFileName)
+ system(["mv", "-f", outFileName, file])
+ print "Patched up RCS keywords in %s" % file
+
def p4UserForCommit(self,id):
# Return the tuple (perforce user,git email) for a given git commit id
self.getUserMapFromPerforceServer()
@@ -918,6 +935,7 @@ class P4Submit(Command, P4UserMap):
filesToDelete = set()
editedFiles = set()
filesToChangeExecBit = {}
+
for line in diff:
diff = parseDiffTreeEntry(line)
modifier = diff['status']
@@ -964,9 +982,30 @@ class P4Submit(Command, P4UserMap):
patchcmd = diffcmd + " | git apply "
tryPatchCmd = patchcmd + "--check -"
applyPatchCmd = patchcmd + "--check --apply -"
+ patch_succeeded = True
if os.system(tryPatchCmd) != 0:
+ fixed_rcs_keywords = False
+ patch_succeeded = False
print "Unfortunately applying the change failed!"
+
+ # Patch failed, maybe it's just RCS keyword woes. Look through
+ # the patch to see if that's possible.
+ if gitConfig("git-p4.attemptRCSCleanup","--bool") == "true":
+ file = None
+ for line in read_pipe_lines(diffcmd):
+ m = re.match(r'^diff --git a/(.*)\s+b/(.*)', line)
+ if m:
+ file = m.group(1)
+ if re.match(r'.*\$(Id|Header|Author|Date|DateTime|Change|File|Revision)[^$]*\$', line):
+ self.patchRCSKeywords(file)
+ fixed_rcs_keywords = True
+ if fixed_rcs_keywords:
+ print "Retrying the patch with RCS keywords cleaned up"
+ if os.system(tryPatchCmd) == 0:
+ patch_succeeded = True
+
+ if not patch_succeeded:
print "What do you want to do?"
response = "x"
while response != "s" and response != "a" and response != "w":
@@ -1588,11 +1627,11 @@ class P4Sync(Command, P4UserMap):
if type_base in ("text", "unicode", "binary"):
if "ko" in type_mods:
text = ''.join(contents)
- text = re.sub(r'\$(Id|Header):[^$]*\$', r'$\1$', text)
+ text = re.sub(r'\$(Id|Header)[^$]*\$', r'$\1$', text)
contents = [ text ]
elif "k" in type_mods:
text = ''.join(contents)
- text = re.sub(r'\$(Id|Header|Author|Date|DateTime|Change|File|Revision):[^$]*\$', r'$\1$', text)
+ text = re.sub(r'\$(Id|Header|Author|Date|DateTime|Change|File|Revision)[^$]*\$', r'$\1$', text)
contents = [ text ]
self.gitStream.write("M %s inline %s\n" % (git_mode, relPath))
diff --git a/t/t9810-git-p4-rcs.sh b/t/t9810-git-p4-rcs.sh
index bad6272..dc38dcc 100755
--- a/t/t9810-git-p4-rcs.sh
+++ b/t/t9810-git-p4-rcs.sh
@@ -49,6 +49,7 @@ test_expect_failure 'cope with rcs keyword expansion damage' '
"$GITP4" clone --dest="$git" //depot &&
cd "$git" &&
git config git-p4.skipSubmitEdit true &&
+ git config git-p4.attemptRCSCleanup true &&
(cd ../cli && p4_append_to_file kwfile1.c) &&
perl -n -i -e "print unless m/Revision:/" kwfile1.c &&
git add kwfile1.c &&
--
1.7.9.rc2.128.gfce41.dirty
^ permalink raw reply related
* [PATCHv4 1/2] git-p4: add test case for RCS keywords
From: Luke Diamand @ 2012-02-09 11:03 UTC (permalink / raw)
To: git; +Cc: Pete Wyckoff, Eric Scouten, Luke Diamand
In-Reply-To: <1328785409-30936-1-git-send-email-luke@diamand.org>
RCS keywords cause problems for git-p4 as perforce always
expands them (if +k is set) and so when applying the patch,
git reports that the files have been modified by both sides,
when in fact they haven't.
This adds a failing test case to demonstrate the problem.
Signed-off-by: Luke Diamand <luke@diamand.org>
---
t/t9810-git-p4-rcs.sh | 81 +++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 81 insertions(+), 0 deletions(-)
create mode 100755 t/t9810-git-p4-rcs.sh
diff --git a/t/t9810-git-p4-rcs.sh b/t/t9810-git-p4-rcs.sh
new file mode 100755
index 0000000..bad6272
--- /dev/null
+++ b/t/t9810-git-p4-rcs.sh
@@ -0,0 +1,81 @@
+#!/bin/sh
+
+test_description='git-p4 rcs keywords'
+
+. ./lib-git-p4.sh
+
+test_expect_success 'start p4d' '
+ start_p4d
+'
+
+create_kw_file() {
+ cat <<'EOF' > $1
+/* A file
+ Id: $Id$
+ Revision: $Revision$
+ File: $File$
+ */
+int main(int argc, const char **argv) {
+ return 0;
+}
+EOF
+}
+
+test_expect_success 'init depot' '
+ (
+ cd "$cli" &&
+ echo file1 >file1 &&
+ p4 add file1 &&
+ p4 submit -d "change 1" &&
+ create_kw_file kwfile1.c &&
+ p4 add kwfile1.c &&
+ p4 submit -d "Add rcw kw file" kwfile1.c
+ )
+'
+
+p4_append_to_file() {
+ f=$1
+ p4 edit -t ktext $f &&
+ echo "/* $(date) */" >> $f &&
+ p4 submit -d "appending a line in p4" &&
+ cat $f
+}
+
+# Create some files with RCS keywords. If they get modified
+# elsewhere then the version number gets bumped which then
+# results in a merge conflict if we touch the RCS kw lines,
+# even though the change itself would otherwise apply cleanly.
+test_expect_failure 'cope with rcs keyword expansion damage' '
+ "$GITP4" clone --dest="$git" //depot &&
+ cd "$git" &&
+ git config git-p4.skipSubmitEdit true &&
+ (cd ../cli && p4_append_to_file kwfile1.c) &&
+ perl -n -i -e "print unless m/Revision:/" kwfile1.c &&
+ git add kwfile1.c &&
+ git commit -m "Zap an RCS kw line" &&
+ "$GITP4" submit &&
+ "$GITP4" rebase &&
+ git diff p4/master &&
+ "$GITP4" commit &&
+ echo "try modifying in both" &&
+ cd "$cli" &&
+ p4 edit kwfile1.c &&
+ echo "line from p4" >> kwfile1.c &&
+ p4 submit -d "add a line in p4" kwfile1.c &&
+ cd "$git" &&
+ echo "line from git at the top" | cat - kwfile1.c > kwfile1.c.new &&
+ mv kwfile1.c.new kwfile1.c &&
+ git commit -m "Add line in git at the top" kwfile1.c &&
+ "$GITP4" rebase &&
+ "$GITP4" submit &&
+
+ cd "$TRASH_DIRECTORY" &&
+ rm -rf "$git" && mkdir "$git"
+'
+
+
+test_expect_success 'kill p4d' '
+ kill_p4d
+'
+
+test_done
--
1.7.9.rc2.128.gfce41.dirty
^ permalink raw reply related
* [RFC/PATCHv1 0/2] git-p4: possible RCS keyword fixes
From: Luke Diamand @ 2012-02-09 11:03 UTC (permalink / raw)
To: git; +Cc: Pete Wyckoff, Eric Scouten, Luke Diamand
This contains a possible way to fixup RCS keyword woes in git-p4.
The first patch adds a test case to demonstrate the problem. It would
be useful to get this into git proper.
The second patch shows a possible way to solve the problem, by
patching up the RCS keywords in the p4 checked-out tree. This
patch does not cover all cases and is poorly tested. I'd like to
see if this seems like a plausible approach.
Luke Diamand (2):
git-p4: add test case for RCS keywords
git-p4: initial demonstration of possible RCS keyword fixup
contrib/fast-import/git-p4 | 43 ++++++++++++++++++++++-
t/t9810-git-p4-rcs.sh | 82 ++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 123 insertions(+), 2 deletions(-)
create mode 100755 t/t9810-git-p4-rcs.sh
--
1.7.9.rc2.128.gfce41.dirty
^ permalink raw reply
* Re: git-subtree Ready for Inspection
From: Jakub Narebski @ 2012-02-09 10:07 UTC (permalink / raw)
To: David A. Greene; +Cc: Jan, git
In-Reply-To: <87liocoayz.fsf@smith.obbligato.org>
greened@obbligato.org (David A. Greene) writes:
> Jan <jk@jk.gs> writes:
>> On 02/08/2012 04:49 AM, David A. Greene wrote:
>>>
>>> I've put up a branch containing git-subtree at:
>>>
>>> gitolite@sources.obbligato.org:git.git
>>
>> A publicly accessible URL would be much more helpful. :-)
>
> Do you mean running gitweb? Are you not able to access the above
> repository?
Nope, the git:// URL or http:// URL -- anonymous unathenticated access.
SSH needs authorization (password or public-key based authenthication).
--
Jakub Narebski
^ permalink raw reply
* Merging tags does not fast-forward with git 1.7.9
From: Domenico Andreoli @ 2012-02-09 9:54 UTC (permalink / raw)
To: git
Hi,
with the recent changes in tag merging (I updated git to 1.7.9),
my usual "git merge v3.X-rcY" command does not fast-forward any more.
Of course the initial head is something like "v3.X-rcZ" without any
change so that it should (and usually did) fast-forward to the new head.
The editor is instead fired off and I have to fill the details of a
merge commit, diverging from mainline as soon as I save and exit.
Is there any simple and clear explanation for this? Thank you.
cheers,
Domenico
ps: I admit I didn't follow the details about tag signatures so probably
I missed something that I shouldn't.
^ permalink raw reply
* Re: [StGit PATCH] Parse commit object header correctly
From: Catalin Marinas @ 2012-02-09 9:38 UTC (permalink / raw)
To: Junio C Hamano
Cc: Karl Hasselström, Andy Green (林安廸), git
In-Reply-To: <7vd39pzsmq.fsf_-_@alter.siamese.dyndns.org>
Hi Junio,
On 8 February 2012 07:33, Junio C Hamano <gitster@pobox.com> wrote:
> To allow parsing the header produced by versions of Git newer than the
> code written to parse it, all commit parsers are expected to skip unknown
> header lines, so that newer types of header lines can be added safely.
> The only three things that are promised are:
>
> (1) the header ends with an empty line (just an LF, not "a blank line"),
> (2) unknown lines can be skipped, and
> (3) a header "field" begins with the field name, followed by a single SP
> followed by the value.
Thanks for looking into this. Is this the same as an email header? If
yes, we could just use the python's email.Header.decode_header()
function (I haven't tried yet).
BTW, does Git allow custom headers to be inserted by tools like StGit?
--
Catalin
^ permalink raw reply
* Re: [PATCH] Fix build problems related to profile-directed optimization
From: Johannes Sixt @ 2012-02-09 8:22 UTC (permalink / raw)
To: Ted Ts'o; +Cc: Junio C Hamano, git
In-Reply-To: <20120208185319.GB9397@thunk.org>
Am 2/8/2012 19:53, schrieb Ted Ts'o:
> Junio, any comments on my most recent spin of this patch? Any changes
> you'd like to see?
I need the following to unbreak my build on Windows.
--- >8 ---
From: Johannes Sixt <j6t@kdbg.org>
Subject: [PATCH] Makefile: fix syntax for older make
It is necessary to write the else branch as a nested conditional. Also,
write the conditions with parentheses because we use them throughout the
Makefile.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
Makefile | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index bfc5daa..01a3c77 100644
--- a/Makefile
+++ b/Makefile
@@ -1784,16 +1784,18 @@ endif
# data gathering
PROFILE_DIR := $(CURDIR)
-ifeq "$(PROFILE)" "GEN"
+ifeq ("$(PROFILE)","GEN")
CFLAGS += -fprofile-generate=$(PROFILE_DIR) -DNO_NORETURN=1
EXTLIBS += -lgcov
export CCACHE_DISABLE=t
V=1
-else ifneq "$(PROFILE)" ""
+else
+ifneq ("$(PROFILE)","")
CFLAGS += -fprofile-use=$(PROFILE_DIR) -fprofile-correction -DNO_NORETURN=1
export CCACHE_DISABLE=t
V=1
endif
+endif
# Shell quote (do not use $(call) to accommodate ancient setups);
--
1.7.9.1420.gae2d6
^ permalink raw reply related
* [PATCH v2 2/2] submodules: always use a relative path from gitdir to work tree
From: Jens Lehmann @ 2012-02-09 8:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, Antony Male, Phil Hord
In-Reply-To: <4F32F465.7090401@web.de>
Since recently a submodule with name <name> has its git directory in the
.git/modules/<name> directory of the superproject while the work tree
contains a gitfile pointing there. To make that work the git directory has
the core.worktree configuration set in its config file to point back to
the work tree.
That core.worktree is an absolute path set by the initial clone of the
submodule. A relative path is preferable here because it allows the
superproject to be moved around without invalidating that setting, so
compute and set that relative path after cloning or reactivating the
submodule.
This also fixes a bug when moving a submodule around inside the
superproject, as the current code forgot to update the setting to the new
submodule work tree location.
Enhance t7400 to ensure that future versions won't re-add absolute paths
by accident and that moving a superproject won't break submodules.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
---
The first version was whitespace damaged, please use this instead.
git-submodule.sh | 9 +++++++++
t/t7400-submodule-basic.sh | 20 ++++++++++++++++++++
2 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index 2a93c61..3463d6d 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -169,6 +169,15 @@ module_clone()
fi
echo "gitdir: $rel_gitdir" >"$path/.git"
+
+ a=$(cd "$gitdir" && pwd)
+ b=$(cd "$path" && pwd)
+ while [ "$b" ] && [ "${a%%/*}" = "${b%%/*}" ]
+ do
+ a=${a#*/} b=${b#*/};
+ done
+ rel=$(echo $a | sed -e 's|[^/]*|..|g')
+ (clear_local_git_env; cd "$path" && git config core.worktree "$rel/$b")
}
#
diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh
index 2b70b22..b377a7a 100755
--- a/t/t7400-submodule-basic.sh
+++ b/t/t7400-submodule-basic.sh
@@ -81,6 +81,13 @@ test_expect_success 'submodule add' '
test ! -s actual &&
echo "gitdir: ../.git/modules/submod" >expect &&
test_cmp expect submod/.git &&
+ (
+ cd submod &&
+ git config core.worktree >actual &&
+ echo "../../../submod" >expect &&
+ test_cmp expect actual &&
+ rm -f actual expect
+ ) &&
git submodule init
) &&
@@ -500,4 +507,17 @@ test_expect_success 'relative path works with user@host:path' '
)
'
+test_expect_success 'moving the superproject does not break submodules' '
+ (
+ cd addtest &&
+ git submodule status >expect
+ )
+ mv addtest addtest2 &&
+ (
+ cd addtest2 &&
+ git submodule status >actual &&
+ test_cmp expect actual
+ )
+'
+
test_done
--
1.7.9.190.g0a6c2
^ permalink raw reply related
* [PATCH v2 1/2] submodules: always use a relative path to gitdir
From: Jens Lehmann @ 2012-02-09 8:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, Antony Male, Phil Hord
In-Reply-To: <4F32F2F6.6040006@web.de>
Since recently a submodule with name <name> has its git directory in the
.git/modules/<name> directory of the superproject while the work tree
contains a gitfile pointing there. When the submodule git directory needs
to be cloned because it is not found in .git/modules/<name> the clone
command will write an absolute path into the gitfile. When no clone is
necessary the git directory will be reactivated by the git-submodule.sh
script by writing a relative path into the gitfile.
This is inconsistent, as the behavior depends on the submodule having been
cloned before into the .git/modules of the superproject. A relative path
is preferable here because it allows the superproject to be moved around
without invalidating the gitfile. We do that by always writing the
relative path into the gitfile, which overwrites the absolute path the
clone command may have written there.
This is only the first step to make superprojects movable again like they
were before the separate-git-dir approach was introduced. The second step
is to use a relative path in core.worktree too.
Enhance t7400 to ensure that future versions won't re-add absolute paths
by accident.
While at it also replace an if/else construct evaluating the presence
of the 'reference' option with a single line of bash code.
Reported-by: Antony Male <antony.male@gmail.com>
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
---
The first version was whitespace damaged, please use this one instead.
git-submodule.sh | 11 ++++-------
t/t7400-submodule-basic.sh | 2 ++
2 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index 9bb2e13..2a93c61 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -160,18 +160,15 @@ module_clone()
if test -d "$gitdir"
then
mkdir -p "$path"
- echo "gitdir: $rel_gitdir" >"$path/.git"
rm -f "$gitdir/index"
else
mkdir -p "$gitdir_base"
- if test -n "$reference"
- then
- git-clone $quiet "$reference" -n "$url" "$path" --separate-git-dir "$gitdir"
- else
- git-clone $quiet -n "$url" "$path" --separate-git-dir "$gitdir"
- fi ||
+ git clone $quiet -n ${reference:+"$reference"} \
+ --separate-git-dir "$gitdir" "$url" "$path" ||
die "$(eval_gettext "Clone of '\$url' into submodule path '\$path' failed")"
fi
+
+ echo "gitdir: $rel_gitdir" >"$path/.git"
}
#
diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh
index 695f7af..2b70b22 100755
--- a/t/t7400-submodule-basic.sh
+++ b/t/t7400-submodule-basic.sh
@@ -79,6 +79,8 @@ test_expect_success 'submodule add' '
cd addtest &&
git submodule add -q "$submodurl" submod >actual &&
test ! -s actual &&
+ echo "gitdir: ../.git/modules/submod" >expect &&
+ test_cmp expect submod/.git &&
git submodule init
) &&
--
1.7.9.190.g0a6c2
^ permalink raw reply related
* Re: ANNOUNCE: Git for Windows 1.7.9
From: Stefan Näwe @ 2012-02-09 8:11 UTC (permalink / raw)
To: Pat Thoyts; +Cc: msysGit, Git Mailing List, Karsten Blees
In-Reply-To: <4F33798F.2010908@atlas-elektronik.com>
Am 09.02.2012 08:45, schrieb Stefan Näwe:
> Am 01.02.2012 12:23, schrieb Pat Thoyts:
>> This release brings the latest release of Git to Windows users.
>>
>> Pre-built installers are available from
>> http://code.google.com/p/msysgit/downloads/list
>>
>> Further details about the Git for Windows project are at
>> http://code.google.com/p/msysgit/
>
> I'm getting errors from 'git repack -Ad' with this version on Windows XP:
>
> $ /bin/git repack -Ad
> Counting objects: 147960, done.
> Delta compression using up to 2 threads.
> Compressing objects: 100% (35552/35552), done.
> Writing objects: 100% (147960/147960), done.
> Total 147960 (delta 110699), reused 147960 (delta 110699)
> Deletion of directory '.git/objects/01/' failed. Should I try again? (y/n)
> Deletion of directory '.git/objects/05/' failed. Should I try again? (y/n) n
> Deletion of directory '.git/objects/07/' failed. Should I try again? (y/n) n
> Deletion of directory '.git/objects/0c/' failed. Should I try again? (y/n) n
> Deletion of directory '.git/objects/10/' failed. Should I try again? (y/n)
> ....
>
>
> A bisection pointed me to this commit (https://github.com/msysgit/git/commit/19d1e75):
>
> "Win32: Unicode file name support (except dirent)"
>
> When I reset "/git" to this commit and recompile, 'git gc' and 'git repack -Ad'
s/this commit/parent of this commit (c5d4ecfe)/
> don't raise this error anymore.
>
> Any ideas ?
>
>
> Thanks,
> Stefan
--
----------------------------------------------------------------
/dev/random says: Take two crows and caw me in the morning
python -c "print '73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')"
^ permalink raw reply
* Re: ANNOUNCE: Git for Windows 1.7.9
From: Stefan Näwe @ 2012-02-09 7:45 UTC (permalink / raw)
To: Pat Thoyts; +Cc: msysGit, Git Mailing List, Karsten Blees
In-Reply-To: <CABNJ2GJ-Jtpg=HsB9TmvLskmB9xXSeshHXz8V9koJfvMp5WNvA@mail.gmail.com>
Am 01.02.2012 12:23, schrieb Pat Thoyts:
> This release brings the latest release of Git to Windows users.
>
> Pre-built installers are available from
> http://code.google.com/p/msysgit/downloads/list
>
> Further details about the Git for Windows project are at
> http://code.google.com/p/msysgit/
I'm getting errors from 'git repack -Ad' with this version on Windows XP:
$ /bin/git repack -Ad
Counting objects: 147960, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (35552/35552), done.
Writing objects: 100% (147960/147960), done.
Total 147960 (delta 110699), reused 147960 (delta 110699)
Deletion of directory '.git/objects/01/' failed. Should I try again? (y/n)
Deletion of directory '.git/objects/05/' failed. Should I try again? (y/n) n
Deletion of directory '.git/objects/07/' failed. Should I try again? (y/n) n
Deletion of directory '.git/objects/0c/' failed. Should I try again? (y/n) n
Deletion of directory '.git/objects/10/' failed. Should I try again? (y/n)
....
A bisection pointed me to this commit (https://github.com/msysgit/git/commit/19d1e75):
"Win32: Unicode file name support (except dirent)"
When I reset "/git" to this commit and recompile, 'git gc' and 'git repack -Ad'
don't raise this error anymore.
Any ideas ?
Thanks,
Stefan
--
----------------------------------------------------------------
/dev/random says: To save trouble later, Joe named his cat Roadkill Fred
python -c "print '73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')"
^ permalink raw reply
* Re: Breakage in master?
From: svnpenn @ 2012-02-09 6:03 UTC (permalink / raw)
To: msysgit; +Cc: Git Mailing List, Ævar Arnfjörð Bjarmason,
kusmabite
In-Reply-To: <CABPQNSbWu0r_gKGvCHk567pUtQiyDOCO8vFfrzPMFW1eUaj1nw@mail.gmail.com>
When I use NO_GETTEXT=YesPlease I lose text coloring. I assume this is expected.
Is there a workaround that doesnt lose text coloring?
^ permalink raw reply
* Re: git-subtree Ready for Inspection
From: Nazri Ramliy @ 2012-02-09 5:17 UTC (permalink / raw)
To: David A. Greene; +Cc: Jan, git
In-Reply-To: <87liocoayz.fsf@smith.obbligato.org>
On Thu, Feb 9, 2012 at 1:02 PM, David A. Greene <greened@obbligato.org> wrote:
> Do you mean running gitweb? Are you not able to access the above
> repository? I can do that if it makes things easier but it will take a
> bit of time.
It asks for password:
$ git clone gitolite@sources.obbligato.org:git.git
Cloning into 'git'...
gitolite@sources.obbligato.org's password:
nazri
^ permalink raw reply
* Re: git-subtree Ready for Inspection
From: David A. Greene @ 2012-02-09 5:02 UTC (permalink / raw)
To: Jan; +Cc: git
Jan <jk@jk.gs> writes:
> On 02/08/2012 04:49 AM, David A. Greene wrote:
>> I've put up a branch containing git-subtree at:
>>
>> gitolite@sources.obbligato.org:git.git
>
> A publicly accessible URL would be much more helpful. :-)
Do you mean running gitweb? Are you not able to access the above
repository? I can do that if it makes things easier but it will take a
bit of time.
-Dave
^ permalink raw reply
* Re: [PATCH 2/3] tag: die when listing missing or corrupt objects
From: Junio C Hamano @ 2012-02-09 4:33 UTC (permalink / raw)
To: Jeff King; +Cc: Tom Grennan, git, jasampler
In-Reply-To: <20120208210156.GA9588@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Since jk/maint-tag-show-fixes is still in pu, perhaps we can squash in
> this test from my 3/3:
Thanks.
^ permalink raw reply
* Re: [PATCH-master] tag: add --points-at list option
From: Junio C Hamano @ 2012-02-09 4:29 UTC (permalink / raw)
To: Jeff King; +Cc: Tom Grennan, git, jasampler
In-Reply-To: <20120209014430.GA21661@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
>> Signed-off-by: Tom Grennan <tmgrennan@gmail.com>
>
> This version looks fine to me. Thanks.
Thanks, both. Will queue.
^ permalink raw reply
* Re: [PATCH] Fix build problems related to profile-directed optimization
From: Junio C Hamano @ 2012-02-09 4:03 UTC (permalink / raw)
To: Ted Ts'o; +Cc: git
In-Reply-To: <20120208185319.GB9397@thunk.org>
Ted Ts'o <tytso@mit.edu> writes:
> Junio, any comments on my most recent spin of this patch? Any changes
> you'd like to see?
Nothing from me; all looked good.
Let's cook it in 'next' for a few days to give developers a chance to play
with it and merge down to 'master'.
Thanks.
^ permalink raw reply
* Re: [StGit PATCH] Parse commit object header correctly
From: Junio C Hamano @ 2012-02-09 3:58 UTC (permalink / raw)
To: Frans Klaver
Cc: Michael Haggerty, Karl Hasselström, Catalin Marinas,
Andy Green (林安廸), git
In-Reply-To: <op.v9dl1e0v0aolir@keputer.lokaal>
"Frans Klaver" <fransklaver@gmail.com> writes:
>>>> for line in lines:
>>>> try:
>>>> key, value = line.rstrip('\n').split(' ', 1)
>>>> except ValueError:
>>>> continue
>>>
>>> This is generally considered more pythonic: "It's easier to ask for
>>> forgiveness than to get permission".
>>
>> Given that Junio explicitly wanted to allow lines with no spaces, I
>> assume that lack of a space is not an error but rather a conceivable
>> future extension. If my assumption is correct, then it is misleading
>> (and inefficient) to handle it via an exception.
>
> I find the documenting more convincing than the efficiency, but from
> the phrasing I think you do too.
A line that consists entirely of non-SP may or may not a conceivable
future extension, but the point is to "skip without barfing anything you
do not understand".
I wouldn't oppose the rewrite that uses try/except ValueError if
"everything in this try block will parse what I understand correctly, and
any ValueError exception this try block throws is an indication that I
encountered what I do not understand and I must skip" is the more pythonic
way to express that principle. Python is not my primary language as I
said, and in addition StGit may have its own style I haven't learned.
^ 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