Re: [PATCH v7 0/7] git-p4: add support for large file systems
On 25/09/15 09:35, Lars Schneider wrote: size: 3 flags: 0 What's going on? I believe this is correct. Git-LFS uses the clean/smudge filter to replace the LFS pointer with the actual file on checkout. Therefore you see the actual file! You can find details here: https://github.com/github/git-lfs/blob/master/docs/spec.md#intercepting-git Can you run `du -hs .git/objects` in your Git repository? This should report a value well below 16 MB. It does, thanks! -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 0/7] git-p4: add support for large file systems
On 24 Sep 2015, at 22:44, Luke Diamand wrote: > On 23 September 2015 at 12:42, Lars Schneider > wrote: >> >> On 23 Sep 2015, at 13:25, Luke Diamand wrote: >> >>> Adding back git@vger.kernel.org, which I inadvertently dropped off the >>> thread. >>> >>> On 23 September 2015 at 12:22, Luke Diamand wrote: On 23 September 2015 at 11:09, Lars Schneider wrote: > > On 23 Sep 2015, at 11:22, Luke Diamand wrote: > >> On 23 September 2015 at 09:50, Lars Schneider >> wrote: >>> >>> On 23 Sep 2015, at 10:18, Lars Schneider >>> wrote: >> >> >> >>> >>> I think I found an easy fix. Can you try it? >>> >>> (in case my mail app messes something up: I changed line 2240 in >>> git-p4.py to 'self.cloneDestination = os.getcwd()’) >> >> It fixes the problem, but in re-running the tests, I'm seeing t9808 >> fail which doesn't happen on next. > Confirmed. I fixed it. > Do you think it makes sense to create a new roll v8 for Junio? How about we leave it a day or two in case anything else crawls out of the woodwork? Thanks! Luke >> sounds good to me! > > OK, not sure if I'm just doing something daft herebut it seems to > be ignoring the size limit! > > I've got the version from the branch: > > 8fee565 git-p4: add Git LFS backend for large file system > > Plus the couple of oneliner fixes for cloneDestination. > > I've created a repo with a file called foo, size 16MB, and another > file called foo.mp4, which is just a symlink to foo. > > I then do: > > $ mkdir a > $ cd a > $ git init . > $ git config git-p4.largeFileSystem GitLFS > $ git config git-p4.largeFileExtensions mp4 > $ git config git-p4.largeFileThreshold 100k > $ git-p4.py sync -v //depot > > That reports that both foo and foo.mp4 have been pushed into LFS: > > //depot/foo --> foo (16 MB) > Reading pipe: ['git', 'config', '--bool', 'git-p4.pushLargeFiles'] > foo moved to large file system > (/home/lgd/git/git/x/git/a/.git/lfs/objects/08/0a/080acf35a507ac9849cfcba47dc2ad83e01b75663a516279c8b9d243b719643e) > //depot/foo.mp4 --> foo.mp4 (0 MB) > foo.mp4 moved to large file system > (/home/lgd/git/git/x/git/a/.git/lfs/objects/2c/26/2c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e886266e7ae) > > But the file system says otherwise: > > $ ls -l > -rw-r--r-- 1 lgd lgd 16777216 Sep 24 21:38 foo > -rw-r--r-- 1 lgd lgd3 Sep 24 21:38 foo.mp4 > > As does git: > > git ls-files --debug > .gitattributes > ctime: 1443127106:535552029 > mtime: 1443127106:535552029 > dev: 65025ino: 13638459 > uid: 1000 gid: 1000 > size: 94 flags: 0 > foo > ctime: 1443127106:579552030 > mtime: 1443127106:579552030 > dev: 65025ino: 13638462 > uid: 1000 gid: 1000 > size: 16777216flags: 0< Quite large! > foo.mp4 > ctime: 1443127106:599552030 > mtime: 1443127106:599552030 > dev: 65025ino: 13638463 > uid: 1000 gid: 1000 > size: 3 flags: 0 > > What's going on? I believe this is correct. Git-LFS uses the clean/smudge filter to replace the LFS pointer with the actual file on checkout. Therefore you see the actual file! You can find details here: https://github.com/github/git-lfs/blob/master/docs/spec.md#intercepting-git Can you run `du -hs .git/objects` in your Git repository? This should report a value well below 16 MB. Cheers, Lars -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 0/7] git-p4: add support for large file systems
On 23 September 2015 at 12:42, Lars Schneider wrote: > > On 23 Sep 2015, at 13:25, Luke Diamand wrote: > >> Adding back git@vger.kernel.org, which I inadvertently dropped off the >> thread. >> >> On 23 September 2015 at 12:22, Luke Diamand wrote: >>> On 23 September 2015 at 11:09, Lars Schneider >>> wrote: On 23 Sep 2015, at 11:22, Luke Diamand wrote: > On 23 September 2015 at 09:50, Lars Schneider > wrote: >> >> On 23 Sep 2015, at 10:18, Lars Schneider >> wrote: > > > >> >> I think I found an easy fix. Can you try it? >> >> (in case my mail app messes something up: I changed line 2240 in >> git-p4.py to 'self.cloneDestination = os.getcwd()’) > > It fixes the problem, but in re-running the tests, I'm seeing t9808 > fail which doesn't happen on next. Confirmed. I fixed it. Do you think it makes sense to create a new roll v8 for Junio? >>> >>> How about we leave it a day or two in case anything else crawls out of >>> the woodwork? >>> >>> Thanks! >>> Luke > sounds good to me! OK, not sure if I'm just doing something daft herebut it seems to be ignoring the size limit! I've got the version from the branch: 8fee565 git-p4: add Git LFS backend for large file system Plus the couple of oneliner fixes for cloneDestination. I've created a repo with a file called foo, size 16MB, and another file called foo.mp4, which is just a symlink to foo. I then do: $ mkdir a $ cd a $ git init . $ git config git-p4.largeFileSystem GitLFS $ git config git-p4.largeFileExtensions mp4 $ git config git-p4.largeFileThreshold 100k $ git-p4.py sync -v //depot That reports that both foo and foo.mp4 have been pushed into LFS: //depot/foo --> foo (16 MB) Reading pipe: ['git', 'config', '--bool', 'git-p4.pushLargeFiles'] foo moved to large file system (/home/lgd/git/git/x/git/a/.git/lfs/objects/08/0a/080acf35a507ac9849cfcba47dc2ad83e01b75663a516279c8b9d243b719643e) //depot/foo.mp4 --> foo.mp4 (0 MB) foo.mp4 moved to large file system (/home/lgd/git/git/x/git/a/.git/lfs/objects/2c/26/2c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e886266e7ae) But the file system says otherwise: $ ls -l -rw-r--r-- 1 lgd lgd 16777216 Sep 24 21:38 foo -rw-r--r-- 1 lgd lgd3 Sep 24 21:38 foo.mp4 As does git: git ls-files --debug .gitattributes ctime: 1443127106:535552029 mtime: 1443127106:535552029 dev: 65025ino: 13638459 uid: 1000 gid: 1000 size: 94 flags: 0 foo ctime: 1443127106:579552030 mtime: 1443127106:579552030 dev: 65025ino: 13638462 uid: 1000 gid: 1000 size: 16777216flags: 0< Quite large! foo.mp4 ctime: 1443127106:599552030 mtime: 1443127106:599552030 dev: 65025ino: 13638463 uid: 1000 gid: 1000 size: 3 flags: 0 What's going on? Thanks! Luke -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 0/7] git-p4: add support for large file systems
On 23 Sep 2015, at 13:25, Luke Diamand wrote: > Adding back git@vger.kernel.org, which I inadvertently dropped off the thread. > > On 23 September 2015 at 12:22, Luke Diamand wrote: >> On 23 September 2015 at 11:09, Lars Schneider >> wrote: >>> >>> On 23 Sep 2015, at 11:22, Luke Diamand wrote: >>> On 23 September 2015 at 09:50, Lars Schneider wrote: > > On 23 Sep 2015, at 10:18, Lars Schneider wrote: > > I think I found an easy fix. Can you try it? > > (in case my mail app messes something up: I changed line 2240 in > git-p4.py to 'self.cloneDestination = os.getcwd()’) It fixes the problem, but in re-running the tests, I'm seeing t9808 fail which doesn't happen on next. >>> Confirmed. I fixed it. >>> Do you think it makes sense to create a new roll v8 for Junio? >> >> How about we leave it a day or two in case anything else crawls out of >> the woodwork? >> >> Thanks! >> Luke sounds good to me! Thanks, Lars-- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 0/7] git-p4: add support for large file systems
Adding back git@vger.kernel.org, which I inadvertently dropped off the thread. On 23 September 2015 at 12:22, Luke Diamand wrote: > On 23 September 2015 at 11:09, Lars Schneider > wrote: >> >> On 23 Sep 2015, at 11:22, Luke Diamand wrote: >> >>> On 23 September 2015 at 09:50, Lars Schneider >>> wrote: On 23 Sep 2015, at 10:18, Lars Schneider wrote: >>> >>> >>> I think I found an easy fix. Can you try it? (in case my mail app messes something up: I changed line 2240 in git-p4.py to 'self.cloneDestination = os.getcwd()’) >>> >>> It fixes the problem, but in re-running the tests, I'm seeing t9808 >>> fail which doesn't happen on next. >> Confirmed. I fixed it. >> Do you think it makes sense to create a new roll v8 for Junio? > > How about we leave it a day or two in case anything else crawls out of > the woodwork? > > Thanks! > Luke -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 0/7] git-p4: add support for large file systems
On 23 Sep 2015, at 10:18, Lars Schneider wrote:
>
> On 23 Sep 2015, at 09:58, Luke Diamand wrote:
>
>> On 21 September 2015 at 23:41, wrote:
>>> From: Lars Schneider
>>>
>>> diff to v6:
>>> * fix spaces in .gitattributes for Git-LFS files (old "[:space:]", new
>>> "[[:space:]]")
>>> * generated patch on top of next (95c4325) to resolve merge conflicts
>>
>> Trying this out by hand (rather than using the test cases) it crashes
>> for me. Am I doing something wrong?
>>
>> - I've got the version of git-p4.py from
>> ef93b8df71f6d8a7936786c989714868c2d3540c in Junio's ls/p4-lfs branch.
>> - I have git-lfs v0.60 (just downloaded the binary distribution).
>>
>> Then I created a p4 repo, and added two files in Perforce, small.txt
>> and bigfile. bigfile is 400k.
>>
>> Doing a regular git clone works fine:
>>
>> $ mkdir depot
>> $ cd depot
>> $ git init .
>> $ git p4 sync //depot
>> $ git checkout p4/master
>>
>> (I'm using git init + git sync rather than git clone so that I can
>> setup the git config variables I need in the next step).
>>
>> Doing a clone with LFS support though doesn't work:
>>
>> $ mkdir depot2
>> $ cd depot2
>> $ git init
>> $ git config git-p4.largeFileSystem GitLFS
>> $ git config git-p4.largeFileThreshold 100k
>> $ git p4 sync //depot
>> Doing initial import of //depot/ from revision #head into
>> refs/remotes/p4/master
>> Traceback (most recent call last):
>> File "/home/ldiamand/git/git/git-p4.py", line 3624, in
>> main()
>> File "/home/ldiamand/git/git/git-p4.py", line 3618, in main
>> if not cmd.run(args):
>> File "/home/ldiamand/git/git/git-p4.py", line 3298, in run
>> self.importHeadRevision(revision)
>> File "/home/ldiamand/git/git/git-p4.py", line 3085, in importHeadRevision
>> self.commit(details, self.extractFilesFromCommit(details), self.branch)
>> File "/home/ldiamand/git/git/git-p4.py", line 2651, in commit
>> self.streamP4Files(new_files)
>> File "/home/ldiamand/git/git/git-p4.py", line 2565, in streamP4Files
>> cb=streamP4FilesCbSelf)
>> File "/home/ldiamand/git/git/git-p4.py", line 501, in p4CmdList
>> cb(entry)
>> File "/home/ldiamand/git/git/git-p4.py", line 2559, in streamP4FilesCbSelf
>> self.streamP4FilesCb(entry)
>> File "/home/ldiamand/git/git/git-p4.py", line 2501, in streamP4FilesCb
>> self.streamOneP4File(self.stream_file, self.stream_contents)
>> File "/home/ldiamand/git/git/git-p4.py", line 2451, in streamOneP4File
>> (git_mode, contents) =
>> self.largeFileSystem.processContent(self.cloneDestination, git_mode,
>> relPath, contents)
>> File "/home/ldiamand/git/git/git-p4.py", line , in processContent
>> return LargeFileSystem.processContent(self, cloneDestination,
>> git_mode, relPath, contents)
>> File "/home/ldiamand/git/git/git-p4.py", line 1004, in processContent
>> (git_mode, contents, localLargeFile) =
>> self.generatePointer(cloneDestination, contentTempFile)
>> File "/home/ldiamand/git/git/git-p4.py", line 1068, in generatePointer
>> oid,
>> File "/usr/lib/python2.7/posixpath.py", line 70, in join
>> elif path == '' or path.endswith('/'):
>> AttributeError: 'NoneType' object has no attribute 'endswith'
>>
> Confirmed. This is a bug!
>
> Can you try the following sequence of commands?
>
> $ mkdir depot2
> $ cd depot2
> $ git init
> $ git config git-p4.largeFileSystem GitLFS
> $ git config git-p4.largeFileThreshold 100k
> $ git p4 clone --destination=. //depot
>
> I’ve always used “clone” and all test cases uses “clone”. I will fix it for
> “sync”.
>
> Thanks for reporting,
> Lars
I think I found an easy fix. Can you try it?
(in case my mail app messes something up: I changed line 2240 in git-p4.py to
'self.cloneDestination = os.getcwd()’)
Thanks,
Lars
diff --git a/git-p4.py b/git-p4.py
index 8c7496d..1d1bb87 100755
--- a/git-p4.py
+++ b/git-p4.py
@@ -2237,7 +2237,7 @@ class P4Sync(Command, P4UserMap):
self.tempBranches = []
self.tempBranchLocation = "git-p4-tmp"
self.largeFileSystem = None
-self.cloneDestination = None
+self.cloneDestination = os.getcwd()
if gitConfig('git-p4.largeFileSystem'):
largeFileSystemConstructor =
globals()[gitConfig('git-p4.largeFileSystem')]
diff --git a/t/t9824-git-p4-git-lfs.sh b/t/t9824-git-p4-git-lfs.sh
index 7385a2b..6d374c0 100755
--- a/t/t9824-git-p4-git-lfs.sh
+++ b/t/t9824-git-p4-git-lfs.sh
@@ -86,6 +86,35 @@ test_expect_success 'Store files in LFS based on size (>24
bytes)' '
)
'
+test_expect_success 'Store files in LFS based on size (>24 bytes) and use git
p4 sync and no client spec' '
+ test_when_finished cleanup_git &&
+ (
+ cd "$git" &&
+ git init . &&
+ git config git-p4.largeFileSystem GitLFS &&
+ git config git-p4.largeFileThreshold 24 &&
+ git p4 sync //depot &&
+ git checkout p4/master
+ test_file_in_lfs file2.dat 25 "content 2-3 bin 25 bytes" &&
+
Re: [PATCH v7 0/7] git-p4: add support for large file systems
On 23 Sep 2015, at 09:58, Luke Diamand wrote:
> On 21 September 2015 at 23:41, wrote:
>> From: Lars Schneider
>>
>> diff to v6:
>> * fix spaces in .gitattributes for Git-LFS files (old "[:space:]", new
>> "[[:space:]]")
>> * generated patch on top of next (95c4325) to resolve merge conflicts
>
> Trying this out by hand (rather than using the test cases) it crashes
> for me. Am I doing something wrong?
>
> - I've got the version of git-p4.py from
> ef93b8df71f6d8a7936786c989714868c2d3540c in Junio's ls/p4-lfs branch.
> - I have git-lfs v0.60 (just downloaded the binary distribution).
>
> Then I created a p4 repo, and added two files in Perforce, small.txt
> and bigfile. bigfile is 400k.
>
> Doing a regular git clone works fine:
>
> $ mkdir depot
> $ cd depot
> $ git init .
> $ git p4 sync //depot
> $ git checkout p4/master
>
> (I'm using git init + git sync rather than git clone so that I can
> setup the git config variables I need in the next step).
>
> Doing a clone with LFS support though doesn't work:
>
> $ mkdir depot2
> $ cd depot2
> $ git init
> $ git config git-p4.largeFileSystem GitLFS
> $ git config git-p4.largeFileThreshold 100k
> $ git p4 sync //depot
> Doing initial import of //depot/ from revision #head into
> refs/remotes/p4/master
> Traceback (most recent call last):
> File "/home/ldiamand/git/git/git-p4.py", line 3624, in
>main()
> File "/home/ldiamand/git/git/git-p4.py", line 3618, in main
>if not cmd.run(args):
> File "/home/ldiamand/git/git/git-p4.py", line 3298, in run
>self.importHeadRevision(revision)
> File "/home/ldiamand/git/git/git-p4.py", line 3085, in importHeadRevision
>self.commit(details, self.extractFilesFromCommit(details), self.branch)
> File "/home/ldiamand/git/git/git-p4.py", line 2651, in commit
>self.streamP4Files(new_files)
> File "/home/ldiamand/git/git/git-p4.py", line 2565, in streamP4Files
>cb=streamP4FilesCbSelf)
> File "/home/ldiamand/git/git/git-p4.py", line 501, in p4CmdList
>cb(entry)
> File "/home/ldiamand/git/git/git-p4.py", line 2559, in streamP4FilesCbSelf
>self.streamP4FilesCb(entry)
> File "/home/ldiamand/git/git/git-p4.py", line 2501, in streamP4FilesCb
>self.streamOneP4File(self.stream_file, self.stream_contents)
> File "/home/ldiamand/git/git/git-p4.py", line 2451, in streamOneP4File
>(git_mode, contents) =
> self.largeFileSystem.processContent(self.cloneDestination, git_mode,
> relPath, contents)
> File "/home/ldiamand/git/git/git-p4.py", line , in processContent
>return LargeFileSystem.processContent(self, cloneDestination,
> git_mode, relPath, contents)
> File "/home/ldiamand/git/git/git-p4.py", line 1004, in processContent
>(git_mode, contents, localLargeFile) =
> self.generatePointer(cloneDestination, contentTempFile)
> File "/home/ldiamand/git/git/git-p4.py", line 1068, in generatePointer
>oid,
> File "/usr/lib/python2.7/posixpath.py", line 70, in join
>elif path == '' or path.endswith('/'):
> AttributeError: 'NoneType' object has no attribute 'endswith'
>
Confirmed. This is a bug!
Can you try the following sequence of commands?
$ mkdir depot2
$ cd depot2
$ git init
$ git config git-p4.largeFileSystem GitLFS
$ git config git-p4.largeFileThreshold 100k
$ git p4 clone --destination=. //depot
I’ve always used “clone” and all test cases uses “clone”. I will fix it for
“sync”.
Thanks for reporting,
Lars
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 0/7] git-p4: add support for large file systems
On 21 September 2015 at 23:41, wrote:
> From: Lars Schneider
>
> diff to v6:
> * fix spaces in .gitattributes for Git-LFS files (old "[:space:]", new
> "[[:space:]]")
> * generated patch on top of next (95c4325) to resolve merge conflicts
Trying this out by hand (rather than using the test cases) it crashes
for me. Am I doing something wrong?
- I've got the version of git-p4.py from
ef93b8df71f6d8a7936786c989714868c2d3540c in Junio's ls/p4-lfs branch.
- I have git-lfs v0.60 (just downloaded the binary distribution).
Then I created a p4 repo, and added two files in Perforce, small.txt
and bigfile. bigfile is 400k.
Doing a regular git clone works fine:
$ mkdir depot
$ cd depot
$ git init .
$ git p4 sync //depot
$ git checkout p4/master
(I'm using git init + git sync rather than git clone so that I can
setup the git config variables I need in the next step).
Doing a clone with LFS support though doesn't work:
$ mkdir depot2
$ cd depot2
$ git init
$ git config git-p4.largeFileSystem GitLFS
$ git config git-p4.largeFileThreshold 100k
$ git p4 sync //depot
Doing initial import of //depot/ from revision #head into refs/remotes/p4/master
Traceback (most recent call last):
File "/home/ldiamand/git/git/git-p4.py", line 3624, in
main()
File "/home/ldiamand/git/git/git-p4.py", line 3618, in main
if not cmd.run(args):
File "/home/ldiamand/git/git/git-p4.py", line 3298, in run
self.importHeadRevision(revision)
File "/home/ldiamand/git/git/git-p4.py", line 3085, in importHeadRevision
self.commit(details, self.extractFilesFromCommit(details), self.branch)
File "/home/ldiamand/git/git/git-p4.py", line 2651, in commit
self.streamP4Files(new_files)
File "/home/ldiamand/git/git/git-p4.py", line 2565, in streamP4Files
cb=streamP4FilesCbSelf)
File "/home/ldiamand/git/git/git-p4.py", line 501, in p4CmdList
cb(entry)
File "/home/ldiamand/git/git/git-p4.py", line 2559, in streamP4FilesCbSelf
self.streamP4FilesCb(entry)
File "/home/ldiamand/git/git/git-p4.py", line 2501, in streamP4FilesCb
self.streamOneP4File(self.stream_file, self.stream_contents)
File "/home/ldiamand/git/git/git-p4.py", line 2451, in streamOneP4File
(git_mode, contents) =
self.largeFileSystem.processContent(self.cloneDestination, git_mode,
relPath, contents)
File "/home/ldiamand/git/git/git-p4.py", line , in processContent
return LargeFileSystem.processContent(self, cloneDestination,
git_mode, relPath, contents)
File "/home/ldiamand/git/git/git-p4.py", line 1004, in processContent
(git_mode, contents, localLargeFile) =
self.generatePointer(cloneDestination, contentTempFile)
File "/home/ldiamand/git/git/git-p4.py", line 1068, in generatePointer
oid,
File "/usr/lib/python2.7/posixpath.py", line 70, in join
elif path == '' or path.endswith('/'):
AttributeError: 'NoneType' object has no attribute 'endswith'
The test cases work fine, t9823 and t9824.
Thanks
Luke
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 0/7] git-p4: add support for large file systems
On 23 Sep 2015, at 00:03, Junio C Hamano wrote: > larsxschnei...@gmail.com writes: > >> From: Lars Schneider >> >> diff to v6: >> * fix spaces in .gitattributes for Git-LFS files (old "[:space:]", new >> "[[:space:]]") >> * generated patch on top of next (95c4325) to resolve merge conflicts >> >> I am sorry about the "[:space:]" bug this late. I had the fix in my >> development >> branch but missed to apply it in this patch series. >> >> @Junio: >> Your conflict resolution in pu looks good. Nevertheless, I made this patch on >> top of next to ease the integration. I hope this is ok. > > Please don't rebase without a good reason, especially after you > checked the conflict resolution is OK and your reroll does not > affect the way the conflicts are resolved. If you based your > v6 patch on v2.6.0-rc0 and then your v7 patch needs to use something > that did not exist v2.6.0-rc3, you cannot avoid rebasing on top of > that newer codebase to use that new feature, but otherwise, no. > > This is because I prefer to apply the new series to the same base > version so that each step can be compared with the corresponding > step in the previous round. > > I even try hard to keep the commits from the older round if the > patch text and log message are unchanged. This time, I had to > backport [v7 6/7] to apply to the same base before noticing and > verifying that [v7 7/7] is the only thing that was changed in this > round. All the other ones turned out to be identical. > > Hence, the end result for me was > >$ git checkout ls/p4-lfs >$ git reset --hard HEAD^ >$ git am -s git-p4-lfs-7-of-7.mbox > > but it took me a lot longer than necessary because of the rebase. > Understood. Thanks for taking the time and explaining me your workflow. That helps a lot as my intention was to save your time, not waste it. Sorry, Lars -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 0/7] git-p4: add support for large file systems
larsxschnei...@gmail.com writes: > From: Lars Schneider > > diff to v6: > * fix spaces in .gitattributes for Git-LFS files (old "[:space:]", new > "[[:space:]]") > * generated patch on top of next (95c4325) to resolve merge conflicts > > I am sorry about the "[:space:]" bug this late. I had the fix in my > development > branch but missed to apply it in this patch series. > > @Junio: > Your conflict resolution in pu looks good. Nevertheless, I made this patch on > top of next to ease the integration. I hope this is ok. Please don't rebase without a good reason, especially after you checked the conflict resolution is OK and your reroll does not affect the way the conflicts are resolved. If you based your v6 patch on v2.6.0-rc0 and then your v7 patch needs to use something that did not exist v2.6.0-rc3, you cannot avoid rebasing on top of that newer codebase to use that new feature, but otherwise, no. This is because I prefer to apply the new series to the same base version so that each step can be compared with the corresponding step in the previous round. I even try hard to keep the commits from the older round if the patch text and log message are unchanged. This time, I had to backport [v7 6/7] to apply to the same base before noticing and verifying that [v7 7/7] is the only thing that was changed in this round. All the other ones turned out to be identical. Hence, the end result for me was $ git checkout ls/p4-lfs $ git reset --hard HEAD^ $ git am -s git-p4-lfs-7-of-7.mbox but it took me a lot longer than necessary because of the rebase. Thanks. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
