* [RFC PATCH v4 00/19] Sparse checkout
From: Nguyễn Thái Ngọc Duy @ 2009-08-20 13:46 UTC (permalink / raw)
To: git; +Cc: Nguyễn Thái Ngọc Duy
Welcome to the fourth round of sparse checkout this year, dubbed "The
mummy^W^W^W^W^Wno-checkout returns", although the bit now comes under
a new name "skip-worktree" [1]. This series has two parts: sparse
worktree and sparse checkout. Details will be given below.
For brave users of this series: I have pushed it to my sparse-checkout
branch [2] so you can just clone it and test away. Visible changes:
- the spec is now .git/info/sparse-checkout
- the spec is positive matching, that is it matches what _is_ in
worktree, not what is out of worktree like the last series
- you need to set core.sparsecheckout no additional command argument
is needed.
Except from running tests, I have only used it a little bit, so be
careful, it may burn your trees.
Nguyá»…n Thái Ngá»c Duy (8):
update-index: refactor mark_valid() in preparation for new options
Add test-index-version
Introduce "skip-worktree" bit in index, teach Git to get/set this bit
Teach Git to respect skip-worktree bit (reading part)
Teach Git to respect skip-worktree bit (writing part)
Avoid writing to buffer in add_excludes_from_file_1()
Read .gitignore from index if it is skip-worktree
unpack-trees(): carry skip-worktree bit over in merged_entry()
The three main patches in this part are 3, 4 and 5, which define how
"skip-worktree" should work (and I'd love to have feedback whether I
get it right) and implement it.
.gitignore patches are from last series and do not change much.
Nguyá»…n Thái Ngá»c Duy (11):
excluded_1(): support exclude files in index
dir.c: export excluded_1() and add_excludes_from_file_1()
Introduce "sparse checkout"
unpack-trees(): add CE_WT_REMOVE to remove on worktree alone
unpack-trees.c: generalize verify_* functions
unpack-trees(): "enable" sparse checkout and load
$GIT_DIR/info/sparse-checkout
unpack_trees(): apply $GIT_DIR/info/sparse-checkout to the final
index
unpack-trees(): ignore worktree check outside checkout area
read-tree: add --no-sparse-checkout to disable sparse checkout
support
Add tests for sparse checkout
sparse checkout: inhibit empty worktree
The recent assume-unchanged "breakage" that lets Git overwrite
assume-unchanged files worried me. I sat back, checked and wrote tests
to catch similar situations. As a result, core sparse checkout code
becomes more complicated and is splitted into smaller parts for easier
read.
Interesting patches are 11/19 (OK not that interesting, it's just
boring text), 14/19-16/19. Patch 18/19 also covers "foo" vs "foo/"
matching bug in tests.
[1] There are a few reasons behind this rename:
- there is nothing about "checkout" in the first part, it's about
"sparse worktree"
- the double negation issue with "no-" part of "no-checkout"
- new name makes cache.h diff align beautifully
[2] http://repo.or.cz/w/git/pclouds.git?a=shortlog;h=refs/heads/sparse-checkout
.gitignore | 1 +
Documentation/config.txt | 4 +
Documentation/git-ls-files.txt | 1 +
Documentation/git-read-tree.txt | 52 ++++++-
Documentation/git-update-index.txt | 29 ++++
Documentation/technical/api-directory-listing.txt | 3 +
Makefile | 1 +
builtin-clean.c | 4 +-
builtin-commit.c | 5 +
builtin-grep.c | 2 +-
builtin-ls-files.c | 11 +-
builtin-read-tree.c | 4 +-
builtin-update-index.c | 78 ++++++----
cache.h | 8 +-
config.c | 5 +
diff-lib.c | 5 +-
diff.c | 2 +-
dir.c | 100 ++++++++----
dir.h | 4 +
environment.c | 1 +
read-cache.c | 8 +-
t/t1009-read-tree-sparse-checkout.sh | 150 ++++++++++++++++++
t/t2104-update-index-skip-worktree.sh | 57 +++++++
t/t3001-ls-files-others-exclude.sh | 22 +++
t/t7011-skip-worktree-reading.sh | 163 +++++++++++++++++++
t/t7012-skip-worktree-writing.sh | 146 +++++++++++++++++
t/t7300-clean.sh | 19 +++
test-index-version.c | 14 ++
unpack-trees.c | 175 +++++++++++++++++++--
unpack-trees.h | 6 +
30 files changed, 983 insertions(+), 97 deletions(-)
create mode 100755 t/t1009-read-tree-sparse-checkout.sh
create mode 100755 t/t2104-update-index-skip-worktree.sh
create mode 100755 t/t7011-skip-worktree-reading.sh
create mode 100755 t/t7012-skip-worktree-writing.sh
create mode 100644 test-index-version.c
^ permalink raw reply
* Re: [PATCH] Fix symlink __stdcall problem at MSVC
From: Johannes Schindelin @ 2009-08-20 13:47 UTC (permalink / raw)
To: Frank Li; +Cc: git, msysgit
In-Reply-To: <1250774680-4720-1-git-send-email-lznuaa@gmail.com>
Hi,
On Thu, 20 Aug 2009, Frank Li wrote:
> MSVC requires that __stdcall be between return value and function name.
> Further, all Win32 API definitions look like this:
>
> Signed-off-by: Frank Li <lznuaa@gmail.com>
> ---
Like what? Seems you did not paste my complete commit message.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Fix symlink __stdcall problem at MSVC
From: Frank Li @ 2009-08-20 13:24 UTC (permalink / raw)
To: git, msysgit; +Cc: Frank Li
MSVC requires that __stdcall be between return value and function name.
Further, all Win32 API definitions look like this:
Signed-off-by: Frank Li <lznuaa@gmail.com>
---
compat/mingw.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/compat/mingw.c b/compat/mingw.c
index fd642e4..4256243 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -1421,7 +1421,7 @@ int link(const char *oldpath, const char *newpath)
int symlink(const char *oldpath, const char *newpath)
{
- typedef BOOL WINAPI (*symlink_fn)(const char*, const char*, DWORD);
+ typedef BOOL (WINAPI *symlink_fn)(const char*, const char*, DWORD);
static symlink_fn create_symbolic_link = NULL;
if (!create_symbolic_link) {
create_symbolic_link = (symlink_fn) GetProcAddress(
--
1.6.4.msysgit.0
^ permalink raw reply related
* question concerning branches
From: Ingo Brueckl @ 2009-08-20 12:46 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <alpine.LFD.2.01.0908191441070.3158@localhost.localdomain>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> branches have always been pointers to the top-of-commit
Obviously I expected them to be pointers on trees.
A kind of automatical starting commit in a newly created branch would at
least warn if one has begun changing files and wants to checkout back.
(Is this a feature worth of discussion?)
> the git behavior explicitly _encourages_ you to not have to decide
> before-the-fact to create a branch
Thanks for the explanation which help me to understand why git works like it
does.
I'm able to follow your examples, but what I had it mind when I started the
topic and my example was:
Assume a project is released (i.e. no more open bugs we know about) - I know
we're drifting towards fantasy now. ;-)
On the one hand, I want to add single new features (such as other developers
do) which will be written, tested and committed. I want to push/pull
frequently to be up to date all the time. (master branch)
On the other hand, I want to completely rewrite the core of the program.
(test or rewrite branch)
What is the git way to do this in a the right (and clever) manner?
In a branch, I learned, I have to commit or stash before I return to master
for push/pull to follow the project. If I forget, I'm screwed, because files
have changed due to the rewrite (in that branch), I won't get a warning until
my first commit (in that branch) and commits (in master) will conflict.
Ingo
^ permalink raw reply
* Re: [PATCH 6/6 (v4)] support for path name caching in rev-cache
From: Nick Edelen @ 2009-08-20 12:43 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Junio C Hamano, Johannes Schindelin, Sam Vilain, Michael J Gruber,
Jeff King, Shawn O. Pearce, Andreas Ericsson, Christian Couder,
git@vger.kernel.org
In-Reply-To: <alpine.LFD.2.00.0908182313100.6044@xanadu.home>
> Result with the rev-cache populated returns the same number of
> revisions, but not the same amount of data.
> [...]
> So... Why is the leading path component dropped sometimes? That
> explains the output size difference. And the drop is not coherent
> either:
It looks like I didn't realize that tree_entry() returns only the
entry name, and not the full path, which seems like a case of not
thinking, just being logical. The unit tests didn't catch it b/c it
only occurs for root commits, and none of the root commits in the test
had directories involved.
> The object order appears to be rather different. Why so?
The non-commit object order has to be different because they're added
in a different way. It's sorta like vanilla rev-list ordering, except
objects are /only/ appended that are introduced per current commit,
rather than all that haven't been seen yet. It's still a coherent
ordering, and despite the different mechanism I've still enforced the
tag-tree-blob ordering of the normal rev-list.
I've fixed the name issue and added that scenario to the unit tests.
I'll re-upload this last patch in a bit (either minutes if my flight
dosn't leave soon or hours if so).
- Nick
^ permalink raw reply
* Re: [PATCH next] t7407: use 'cut' utility rather than bash's substring expansion notation
From: Johan Herland @ 2009-08-20 9:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Brandon Casey, Brandon Casey
In-Reply-To: <7vskfnq6q5.fsf@alter.siamese.dyndns.org>
On Thursday 20 August 2009, Junio C Hamano wrote:
> Johan Herland <johan@herland.net> writes:
> >> - $sub1sha1 sub1 (${sub1sha1:0:7})
> >> - $sub2sha1 sub2 (${sub1sha1:0:7})
> >> + $sub1sha1 sub1 ($(echo $sub1sha1 | cut -c 1-7))
> >> + $sub2sha1 sub2 ($(echo $sub1sha1 | cut -c 1-7))
> >
> > Typo (both in the original, and the patch), should be:
> > $sub2sha1 sub2 ($(echo $sub2sha1 | cut -c 1-7))
> >
> >> $sub3sha1 sub3 (heads/master)
> >> EOF
> >
> > Otherwise:
> >
> > Acked-by: Johan Herland <johan@herland.net>
>
> Hmm, what does the command use to shorten these object names? It may be
> safer and more correct to use "rev-parse --short" in case these object
> names were ambigous in their first 7 hexdigits.
git submodule status (which is what we're testing here) uses
'git describe' to generate the short object name (see
set_name_rev in git-submodule.sh). In this case, it falls back
to 'git describe --all --always', which calls find_unique_abbrev()
on the SHA1. 'git rev-parse --short' ends up calling the same
find_unique_abbrev(), so I guess it is better to use it here.
Try this instead:
From: Johan Herland <johan@herland.net>
Subject: [PATCH] t7407: Use 'rev-parse --short' rather than bash's substring expansion notation
The substring expansion notation is a bashism that we have not so far
adopted. Use 'git rev-parse --short' instead, as this also handles
the case where the unique abbreviation is longer than 7 characters.
Suggested-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Johan Herland <johan@herland.net>
---
t/t7407-submodule-foreach.sh | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/t/t7407-submodule-foreach.sh b/t/t7407-submodule-foreach.sh
index 25ec281..2a52775 100755
--- a/t/t7407-submodule-foreach.sh
+++ b/t/t7407-submodule-foreach.sh
@@ -201,14 +201,16 @@ submodulesha1=$(cd clone3/nested1/nested2/nested3/submodule && git rev-parse HEA
sub1sha1=$(cd clone3/sub1 && git rev-parse HEAD)
sub2sha1=$(cd clone3/sub2 && git rev-parse HEAD)
sub3sha1=$(cd clone3/sub3 && git rev-parse HEAD)
+sub1sha1_short=$(cd clone3/sub1 && git rev-parse --short HEAD)
+sub2sha1_short=$(cd clone3/sub2 && git rev-parse --short HEAD)
cat > expect <<EOF
$nested1sha1 nested1 (heads/master)
$nested2sha1 nested1/nested2 (heads/master)
$nested3sha1 nested1/nested2/nested3 (heads/master)
$submodulesha1 nested1/nested2/nested3/submodule (heads/master)
- $sub1sha1 sub1 (${sub1sha1:0:7})
- $sub2sha1 sub2 (${sub1sha1:0:7})
+ $sub1sha1 sub1 ($sub1sha1_short)
+ $sub2sha1 sub2 ($sub2sha1_short)
$sub3sha1 sub3 (heads/master)
EOF
--
1.6.4.304.g1365c.dirty
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply related
* Re: Continue git clone after interruption
From: Jakub Narebski @ 2009-08-20 8:23 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy
Cc: Nicolas Pitre, Tomasz Kontusz, git, Johannes Schindelin
In-Reply-To: <fcaeb9bf0908200048v4c918a16o6c0e0fb545742f2@mail.gmail.com>
Dnia czwartek 20. sierpnia 2009 09:48, Nguyen Thai Ngoc Duy napisał:
> On Thu, Aug 20, 2009 at 2:37 PM, Jakub Narebski<jnareb@gmail.com> wrote:
> > *NEW IDEA*
> >
> > Another solution would be to try to come up with some sort of stable
> > sorting of objects so that packfile generated for the same parameters
> > (endpoints) would be always byte-for-byte the same. But that might be
> > difficult, or even impossible.
>
> Isn't it the idea of commit reels [1] from git-torrent?
>
> [1] http://gittorrent.utsl.gen.nz/rfc.html#org-reels
Well, I didn't thought that this idea didn't occur to anybody else.
What I meant here was that it is a new idea mentioned in this subthread.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: question concerning branches
From: Matthieu Moy @ 2009-08-20 7:57 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Ingo Brueckl, Jakub Narebski, git
In-Reply-To: <32541b130908191250w79461592vf1bed7874aa4138b@mail.gmail.com>
Avery Pennarun <apenwarr@gmail.com> writes:
> This is a big difference from how centralized VCSs work: there, a
> commit is a major operation that you're afraid to do in case you make
> someone else mad. In git, commits are cheap, you just need to be
> careful about pushing.
I second this. "commit" is indeed a bad name in decentralized VCSs.
There's no commitment from the developer, you don't commit to swear
the code is good, but you commit just to record a set of changes, and
attach a descriptive message to it.
In Git, a commit takes usually a fraction of a second, and can be
modified later easily until it's pushed.
'git commit --amend' will allow you to change either the changes or
the message associated to a commit.
'git reset HEAD^' will just undo the commit, turning your commited
changes into uncommited ones.
'git rebase --interactive' will allow you another bunch of cool
things.
So, keeping your changes uncommited has very few advantage, and indeed
has one big drawback: uncommited changes have no descriptive message
associated, so if you leave a branch for some time, it makes it more
difficult for you to remember what you were doing on it when you
switch back to it:
git checkout -b topic-branch
# edit foo.bar
git checkout master
# hack
git commit
# go on holiday
# come back
git checkout topic-branch
git status
# err, what is this all about?
OTOH:
git checkout -b topic-branch
# edit foo.bar
git commit -m "started feature foo, but bar is still to be done"
git checkout master
# hack
git commit
# go on holiday
# come back
git checkout topic-branch
git show
# Ah, I remember!
Actually, all the VCSs I know about (Mercurial, Bazaar, Subversion,
and IIRC GNU Arch) deal with this the way Git does. Hey! there must be
a reason ;-).
--
Matthieu
^ permalink raw reply
* Re: Continue git clone after interruption
From: Nguyen Thai Ngoc Duy @ 2009-08-20 7:48 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Nicolas Pitre, Tomasz Kontusz, git, Johannes Schindelin
In-Reply-To: <200908200937.05412.jnareb@gmail.com>
On Thu, Aug 20, 2009 at 2:37 PM, Jakub Narebski<jnareb@gmail.com> wrote:
> *NEW IDEA*
>
> Another solution would be to try to come up with some sort of stable
> sorting of objects so that packfile generated for the same parameters
> (endpoints) would be always byte-for-byte the same. But that might be
> difficult, or even impossible.
Isn't it the idea of commit reels [1] from git-torrent?
[1] http://gittorrent.utsl.gen.nz/rfc.html#org-reels
--
Duy
^ permalink raw reply
* Re: Continue git clone after interruption
From: Jakub Narebski @ 2009-08-20 7:37 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Tomasz Kontusz, git, Johannes Schindelin
In-Reply-To: <alpine.LFD.2.00.0908191552020.6044@xanadu.home>
On Wed, 19 Aug 2009, Nicolas Pitre wrote:
> On Wed, 19 Aug 2009, Jakub Narebski wrote:
> >
> > On Wed, 19 Aug 2009, Nicolas Pitre wrote:
> > > On Wed, 19 Aug 2009, Jakub Narebski wrote:
[...]
> > > Yet, that bundle would probably not contain the latest revision if it is
> > > only periodically updated, even less so if it is shared between multiple
> > > repositories as outlined above. And what people with slow/unreliable
> > > network links are probably most interested in is the latest revision and
> > > maybe a few older revisions, but probably not the whole repository as
> > > that is simply too long to wait for. Hence having a big bundle is not
> > > flexible either with regards to the actual data transfer size.
> >
> > I agree that bundle would be useful for restartable clone, and not
> > useful for restartable fetch. Well, unless you count (non-existing)
> > GitTorrent / git-mirror-sync as this solution... ;-)
>
> I don't think fetches after a clone are such an issue. They are
> typically transfers being orders of magnitude smaller than the initial
> clone. Same goes for fetches to deepen a shallow clone which are in
> fact fetches going back in history instead of forward. I still stands
> by my assertion that bundles are suboptimal for a restartable clone.
They are good as a workaround for lack of resumable clone in a pinch,
but I agree that because a) like packfile they cannot guarantee that
for the same arguments (endpoints) they would generate the same file,
b) you can't generate currently resume pat of bundle only (and it would
be probably difficult to add it) they are not optimal solution.
> As for GitTorrent / git-mirror-sync... those are still vaporwares to me
> and I therefore have doubts about their actual feasability. So no, I
> don't count on them.
Well... there is _some_ code.
> > > Hence having a restartable git-archive service to create the top
> > > revision with the ability to cheaply (in terms of network bandwidth)
> > > deepen the history afterwards is probably the most straight forward way
> > > to achieve that. The server needs no be aware of separate bundles, etc.
> > > And the shared object store still works as usual with the same cached IO
> > > whether the data is needed for a traditional fetch or a "git archive"
> > > operation.
> >
> > It's the "cheaply deepen history" that I doubt would be easy. This is
> > the most difficult part, I think (see also below).
>
> Don't think so. Try this:
>
> mkdir test
> cd test
> git init
> git fetch --depth=1 git://git.kernel.org/pub/scm/git/git.git
>
> Result:
>
> remote: Counting objects: 1824, done.
> remote: Compressing objects: 100% (1575/1575), done.
> Receiving objects: 100% (1824/1824), 3.01 MiB | 975 KiB/s, done.
> remote: Total 1824 (delta 299), reused 1165 (delta 180)
> Resolving deltas: 100% (299/299), done.
> From git://git.kernel.org/pub/scm/git/git
> * branch HEAD -> FETCH_HEAD
>
> You'll get the very latest revision for HEAD, and only that. The size
> of the transfer will be roughly the size of a daily snapshot, except it
> is fully up to date. It is however non resumable in the event of a
> network outage. My proposal is to replace this with a "git archive"
> call. It won't get all branches, but for the purpose of initialising
> one's repository that should be good enough. And the "git archive" can
> be fully resumable as I explained.
It is however only 2.5 MB out of 37 MB that are resumable, which is 7%
(well, that of course depends on repository). Not that much that is
resumable.
> Now to deepen that history. Let's say you want 10 more revisions going
> back then you simply perform the fetch again with a --depth=10. Right
> now it doesn't seem to work optimally, but the pack that is then being
> sent could be made of deltas against objects found in the commits we
> already have. Currently it seems that a pack that also includes those
> objects we already have in addition to those we want is created, which
> is IMHO a flaw in the shallow support that shouldn't be too hard to fix.
> Each level of deepening should then be as small as standard fetches
> going forward when updating the repository with new revisions.
You would have the same (or at least quite similar) problems with
deepening part (the 'incrementals' transfer part) as you found with my
first proposal of server bisection / division of rev-list, and serving
1/Nth of revisions (where N is selected so packfile is reasonable) to
client as incrementals. Yours is top-down, mine was bottom-up approach
to sending series of smaller packs. The problem is how to select size
of incrementals, and that incrementals are all-or-nothing (but see also
comment below).
In proposal using git-archive and shallow clone deepening as incrementals
you have this small seed (how small it depends on repository: 50% - 5%)
which is resumable. And presumably with deepening you can somehow make
some use from incomplete packfile, only part of which was transferred
before network error / disconnect. And even tell server about objects
which you managed to extract from *.pack.part.
> > > Why "git archive"? Because its content is well defined. So if you give
> > > it a commit SHA1 you will always get the same stream of bytes (after
> > > decompression) since the way git sort files is strictly defined. It is
> > > therefore easy to tell a remote "git archive" instance that we want the
> > > content for commit xyz but that we already got n files already, and that
> > > the last file we've got has m bytes. There is simply no confusion about
> > > what we've got already, unlike with a partial pack which might need
> > > yet-to-be-received objects in order to make sense of what has been
> > > already received. The server simply has to skip that many files and
> > > resume the transfer at that point, independently of the compression or
> > > even the archive format.
> >
> > Let's reiterate it to check if I understand it correctly:
> >
> > Any "restartable clone" / "resumable fetch" solution must begin with
> > a file which is rock-solid stable wrt. reproductability given the same
> > parameters. git-archive has this feature, packfile doesn't (so I guess
> > that bundle also doesn't, unless it was cached / saved on disk).
>
> Right.
*NEW IDEA*
Another solution would be to try to come up with some sort of stable
sorting of objects so that packfile generated for the same parameters
(endpoints) would be always byte-for-byte the same. But that might be
difficult, or even impossible.
Well, we could send the list of objects in pack in order used later by
pack creation to client (non-resumable but small part), and if packfile
transport was interrupted in the middle client would compare list of
complete objects in part of packfile against this manifest, and sent
request to server with *sorted* list of object it doesn't have yet.
Server would probably have to check validity of objects list first (the
object list might be needed to be more than just object list; it might
need to specify topology of deltas, i.e. which objects are base for which
ones). Then it would generate rest of packfile.
> > It would be useful if it was possible to generate part of this rock-solid
> > file for partial (range, resume) request, without need to generate
> > (calculate) parts that client already downloaded. Otherwise server has
> > to either waste disk space and IO for caching, or waste CPU (and IO)
> > on generating part which is not needed and dropping it to /dev/null.
> > git-archive you say has this feature.
>
> "Could easily have" is more appropriate.
O.K. And I can see how this can be easy done.
> > Next you need to tell server that you have those objects got using
> > resumable download part ("git archive HEAD" in your proposal), and
> > that it can use them and do not include them in prepared file/pack.
> > "have" is limited to commits, and "have <sha1>" tells server that
> > you have <sha1> and all its prerequisites (dependences). You can't
> > use "have <sha1>" with git-archive solution. I don't know enough
> > about 'shallow' capability (and what it enables) to know whether
> > it can be used for that. Can you elaborate?
>
> See above, or Documentation/technical/shallow.txt.
Documentation/technical/shallow.txt doesn't cover "shallow", "unshallow"
and "deepen" commands from 'shallow' capability extension to git pack
protocol (http://git-scm.com/gitserver.txt).
> > Then you have to finish clone / fetch. All solutions so far include
> > some kind of incremental improvements. My first proposal of bisect
> > fetching 1/nth or predefined size pack is buttom-up solution, where
> > we build full clone from root commits up. You propose, from what
> > I understand build full clone from top commit down, using deepening
> > from shallow clone. In this step you either get full incremental
> > or not; downloading incremental (from what I understand) is not
> > resumable / they do not support partial fetch.
>
> Right. However, like I said, the incremental part should be much
> smaller and therefore less susceptible to network troubles.
If you have 7% total pack size of git-archive resumable part, how small
do you plan to have those incremental deepening? Besides in my 1/Nth
proposal those bottom-up packs werealso meant to be sufficiently small
to avoid network troubles.
P.S. As you can see implementing resumable clone isn't easy...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH next] t7407: use 'cut' utility rather than bash's substring expansion notation
From: Junio C Hamano @ 2009-08-20 7:34 UTC (permalink / raw)
To: Johan Herland; +Cc: git, Brandon Casey, Brandon Casey
In-Reply-To: <200908200856.30359.johan@herland.net>
Johan Herland <johan@herland.net> writes:
>> - $sub1sha1 sub1 (${sub1sha1:0:7})
>> - $sub2sha1 sub2 (${sub1sha1:0:7})
>> + $sub1sha1 sub1 ($(echo $sub1sha1 | cut -c 1-7))
>> + $sub2sha1 sub2 ($(echo $sub1sha1 | cut -c 1-7))
>
> Typo (both in the original, and the patch), should be:
> $sub2sha1 sub2 ($(echo $sub2sha1 | cut -c 1-7))
>
>> $sub3sha1 sub3 (heads/master)
>> EOF
>
> Otherwise:
>
> Acked-by: Johan Herland <johan@herland.net>
Hmm, what does the command use to shorten these object names? It may be
safer and more correct to use "rev-parse --short" in case these object
names were ambigous in their first 7 hexdigits.
^ permalink raw reply
* Re: question concerning branches
From: Andreas Ericsson @ 2009-08-20 7:33 UTC (permalink / raw)
To: Ingo Brueckl; +Cc: Junio C Hamano, git
In-Reply-To: <4a8c4ece@wupperonline.de>
Ingo Brueckl wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> This is one of the most useful features.
>
> Wow. I'm sursprised to hear that, because I consider it at the moment as a
> very strange one.
>
>> For example, it is an essential
>> part of supporting the workflow described here:
>> http://gitster.livejournal.com/25892.html
>
> Here is what I'd expect to do with git (described with my own words, not in
> git commands):
>
> 1. commit the quick fix to the release branch
> 2. push this single commit to origin and master
>
> Now that all branches have the commit a later push and pull should notice
> this and "skip" it.
>
> This leads to a second question I have. Assuming I have three patches in my
> repo (#1, #2 and #3), is it possible to push only #2 (because it is a
> quick fix) and later, maybe after I committed #4, the rest, i.e. #1, #2 and
> #4?
>
If they're on different branches, yes. If they're on the same branch, no.
This is because a commit in git is named uniquely not only by its contents,
but also by its ancestry.
You can, however, run "git rebase --interactive" and re-order the commits
before you push them, so that #2 becomes #1 and vice versa. Then you can
push only #1 (the old #2) while leaving #2 (the old #1), #3 and #4 on
your machine only. This involves knowing the commit identifier of #1
though. Assuming it's "deadbeef", you can update the remote branch "foo"
to hold your new commit by running the following command:
git push <remote> deadbeef:refs/heads/foo
HTH
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
^ permalink raw reply
* Re: [PATCH next] t7407: use 'cut' utility rather than bash's substring expansion notation
From: Johan Herland @ 2009-08-20 6:56 UTC (permalink / raw)
To: git; +Cc: Brandon Casey, gitster, Brandon Casey
In-Reply-To: <QHfHFS_5JGiL-O8GMDfdfscFUdxV1xVObzr6e5LPleagDRd7bCg8I9YUwL9xkbgM64vyf_EVLLg@cipher.nrlssc.navy.mil>
On Thursday 20 August 2009, Brandon Casey wrote:
> From: Brandon Casey <drafnel@gmail.com>
>
> The substring expansion notation is a bashism that we have not so far
> adopted. There is precedence for using the 'cut' utility for extracting
> a substring. So do so here.
>
> Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
> ---
> t/t7407-submodule-foreach.sh | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/t/t7407-submodule-foreach.sh b/t/t7407-submodule-foreach.sh
> index de1730d..44ea8ac 100755
> --- a/t/t7407-submodule-foreach.sh
> +++ b/t/t7407-submodule-foreach.sh
> @@ -207,8 +207,8 @@ cat > expect <<EOF
> $nested2sha1 nested1/nested2 (heads/master)
> $nested3sha1 nested1/nested2/nested3 (heads/master)
> $submodulesha1 nested1/nested2/nested3/submodule (heads/master)
> - $sub1sha1 sub1 (${sub1sha1:0:7})
> - $sub2sha1 sub2 (${sub1sha1:0:7})
> + $sub1sha1 sub1 ($(echo $sub1sha1 | cut -c 1-7))
> + $sub2sha1 sub2 ($(echo $sub1sha1 | cut -c 1-7))
Typo (both in the original, and the patch), should be:
$sub2sha1 sub2 ($(echo $sub2sha1 | cut -c 1-7))
> $sub3sha1 sub3 (heads/master)
> EOF
Otherwise:
Acked-by: Johan Herland <johan@herland.net>
Thanks,
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: [PATCH] Add test case for rev-list --parents --show-all
From: Junio C Hamano @ 2009-08-20 4:13 UTC (permalink / raw)
To: Adam Simpkins; +Cc: Santi Béjar, Git Mailing List
In-Reply-To: <20090819225852.GA21187@facebook.com>
Adam Simpkins <simpkins@facebook.com> writes:
> This test case ensures that rev-list --parents --show-all gets the
> parent history correct. Normally, --parents rewrites parent history to
> skip TREESAME parents. However, --show-all causes TREESAME parents to
> still be included in the revision list, so the parents should still be
> included too.
>
> Signed-off-by: Adam Simpkins <simpkins@facebook.com>
> ---
>
> Looking through the code, I believe TREESAME commits are the only ones
> affected by my earlier bug in simplify_commit().
What I meant was actually a test for the graph part (i.e. the problem we
would see if we did not apply your update to graph_is_interesting()), but
protecting the simplify_commit() logic with test from breakage is a good
thing to do as well.
Thanks.
^ permalink raw reply
* Re: question concerning branches
From: Randal L. Schwartz @ 2009-08-20 3:01 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Ingo Brueckl, Jakub Narebski, git
In-Reply-To: <alpine.LFD.2.01.0908191441070.3158@localhost.localdomain>
>>>>> "Linus" == Linus Torvalds <torvalds@linux-foundation.org> writes:
Linus> git branch new-feature
Linus> git checkout new-feature
Or my favorite: "git checkout -b new-feature".
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
^ permalink raw reply
* Re: [PATCH] block-sha1: Windows declares ntohl() in winsock2.h
From: Brandon Casey @ 2009-08-20 2:45 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Junio C Hamano, Sebastian Schuberth, Artur Skawina, Johannes Sixt,
msysGit, Linus Torvalds, Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0908192201180.6044@xanadu.home>
Nicolas Pitre wrote:
> On Tue, 18 Aug 2009, Brandon Casey wrote:
>
>> The SUNWspro compiler doesn't set __i386__. Instead it sets __i386, and
>> I think __x86_64 and __amd64 where appropriate. So, compilation with
>> the SUNWspro compiler on x86 is currently unaffected by these changes and
>> falls back to the generic routines.
>>
>> It seems that v5.10 of the compiler can grok both the __asm__ statements
>> and the ({...}) naked block notation and passes all of the tests when the
>> block_sha1 code is modified to add defined(__i386) to each of the macro
>> statements.
>>
>> The 5.8 version cannot grok the naked block, and requires spelling __asm__
>> as __asm for inline assembly. Even then it appears that there is a bug in
>> the assembly that is produced (a google search told me so), so the assembly
>> code does not successfully compile.
>>
>> I haven't had much time to think about how or whether to address this.
>>
>> Adding something like the following would get ugly real quick:
>>
>> (defined(__i386) && defined(__SUNPRO_C) && (__SUNPRO_C >= 0x5100))
>
> I think the best solution in this case might simply be to add something
> like this somewhere at the top of git-compat-util.h after the system
> includes:
>
> /*
> * The SUNWspro compiler uses different symbols than gcc.
> * Let's standardize on the gcc flavor.
> */
> #if defined(__i386) && !defined(__i386__)
> #define __i386__
> #endif
> #if (defined(__x86_64) || defined(__amd64)) && !defined(__x86_64__)
> #define __x86_64__
> #endif
Yes, I had this idea too.
> /*
> * SUNWspro from version 5.10 supports gcc extensions such as gcc's
> * statement expressions and extended inline asm, so let's pretend...
> */
> #if defined(__SUNPRO_C) && (__SUNPRO_C >= 0x5100))
> #define __GNUC__
> #endif
I hadn't thought of this. I'll test to make sure the other statements
that are protected by ifdef __GNUC__ work correctly with SUNWspro v5.10.
-brandon
^ permalink raw reply
* Re: gitweb and symbolic links
From: Changsheng Jiang @ 2009-08-20 2:32 UTC (permalink / raw)
To: Marco Gualtieri; +Cc: git
In-Reply-To: <2367E9DF-6FB1-48E6-AC9A-73E84C9D54E1@math.utoronto.ca>
Most WEB servers disable following link for security reasons. Check
it's disabled first.
Changsheng Jiang
On Thu, Aug 20, 2009 at 09:15, Marco Gualtieri<mgualt@math.utoronto.ca> wrote:
> Hello,
>
> I am wondering about a possibly easy bug which you may be aware of.
>
> For some reason if I place a symbolic link in a directory under the project
> root, gitweb is no longer able to find the project. I was looking through
> the .cgi file but I don't know enough perl to fix the problem myself.
>
> Let me know if this makes sense.
> Cheers
> Marco
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH] block-sha1: Windows declares ntohl() in winsock2.h
From: Linus Torvalds @ 2009-08-20 2:30 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Brandon Casey, Junio C Hamano, Sebastian Schuberth, Artur Skawina,
Johannes Sixt, msysGit, Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0908192201180.6044@xanadu.home>
On Wed, 19 Aug 2009, Nicolas Pitre wrote:
>
> I think the best solution in this case might simply be to add something
> like this somewhere at the top of git-compat-util.h after the system
> includes:
I think we can just test __i386.
Gcc defines that one too (in fact, in general, gcc always defines both the
__x and the __x__ versions, although I'm sure there are exceptions)
Linus
^ permalink raw reply
* Re: [PATCH] block-sha1: Windows declares ntohl() in winsock2.h
From: Nicolas Pitre @ 2009-08-20 2:26 UTC (permalink / raw)
To: Brandon Casey
Cc: Junio C Hamano, Sebastian Schuberth, Artur Skawina, Johannes Sixt,
msysGit, Linus Torvalds, Git Mailing List
In-Reply-To: <XJM0H8pTiCJpryS-arPltHCHwsm0djqVixaH1NwBqT2pci2MA9karw@cipher.nrlssc.navy.mil>
On Tue, 18 Aug 2009, Brandon Casey wrote:
> The SUNWspro compiler doesn't set __i386__. Instead it sets __i386, and
> I think __x86_64 and __amd64 where appropriate. So, compilation with
> the SUNWspro compiler on x86 is currently unaffected by these changes and
> falls back to the generic routines.
>
> It seems that v5.10 of the compiler can grok both the __asm__ statements
> and the ({...}) naked block notation and passes all of the tests when the
> block_sha1 code is modified to add defined(__i386) to each of the macro
> statements.
>
> The 5.8 version cannot grok the naked block, and requires spelling __asm__
> as __asm for inline assembly. Even then it appears that there is a bug in
> the assembly that is produced (a google search told me so), so the assembly
> code does not successfully compile.
>
> I haven't had much time to think about how or whether to address this.
>
> Adding something like the following would get ugly real quick:
>
> (defined(__i386) && defined(__SUNPRO_C) && (__SUNPRO_C >= 0x5100))
I think the best solution in this case might simply be to add something
like this somewhere at the top of git-compat-util.h after the system
includes:
/*
* The SUNWspro compiler uses different symbols than gcc.
* Let's standardize on the gcc flavor.
*/
#if defined(__i386) && !defined(__i386__)
#define __i386__
#endif
#if (defined(__x86_64) || defined(__amd64)) && !defined(__x86_64__)
#define __x86_64__
#endif
/*
* SUNWspro from version 5.10 supports gcc extensions such as gcc's
* statement expressions and extended inline asm, so let's pretend...
*/
#if defined(__SUNPRO_C) && (__SUNPRO_C >= 0x5100))
#define __GNUC__
#endif
Nicolas
^ permalink raw reply
* Re: difftool, open all diff files immediately, not in serial
From: Seba Illingworth @ 2009-08-20 1:39 UTC (permalink / raw)
To: git
In-Reply-To: <200908042347.48705.trast@student.ethz.ch>
Thomas Rast <trast <at> student.ethz.ch> writes:
> I posted the script below on IRC the other week[1] in reply to someone
> looking for a way to do this for 'meld'. I'm not sure this is the
> *fastest* way to do this, but I'm at least trying to take a few
> shortcuts...
I've come up with a simple script that diffs the files in a background task:
for name in $(git diff --name-only $1); do git difftool $1 $name & done
Then aliased the script for usage:
git diffall [--staged]
Being a bash newbie, I'd appreciate any feedback on what seems to be
a simple solution...??
^ permalink raw reply
* gitweb and symbolic links
From: Marco Gualtieri @ 2009-08-20 1:15 UTC (permalink / raw)
To: git
Hello,
I am wondering about a possibly easy bug which you may be aware of.
For some reason if I place a symbolic link in a directory under the
project root, gitweb is no longer able to find the project. I was
looking through the .cgi file but I don't know enough perl to fix the
problem myself.
Let me know if this makes sense.
Cheers
Marco
^ permalink raw reply
* [PATCH] git-compat-util.h: remove superfluous test for __sun__
From: Brandon Casey @ 2009-08-20 1:27 UTC (permalink / raw)
To: gitster; +Cc: git, Brandon Casey
From: Brandon Casey <drafnel@gmail.com>
This 'ifndef' macro is entered only when __sun__ is not defined. This test
will never fail since it is located inside of the 'else' branch of an 'if'
macro which tests whether __sun__ is defined. It has had no effect since
the merge at 436f66b7.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
git-compat-util.h | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/git-compat-util.h b/git-compat-util.h
index 9f941e4..71b5acb 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -57,10 +57,8 @@
# endif
#elif !defined(__APPLE__) && !defined(__FreeBSD__) && !defined(__USLC__) && !defined(_M_UNIX) && !defined(sgi)
#define _XOPEN_SOURCE 600 /* glibc2 and AIX 5.3L need 500, OpenBSD needs 600 for S_ISLNK() */
-#ifndef __sun__
#define _XOPEN_SOURCE_EXTENDED 1 /* AIX 5.3L needs this */
#endif
-#endif
#define _ALL_SOURCE 1
#define _GNU_SOURCE 1
#define _BSD_SOURCE 1
--
1.6.4
^ permalink raw reply related
* [PATCH next] t7407: use 'cut' utility rather than bash's substring expansion notation
From: Brandon Casey @ 2009-08-20 1:24 UTC (permalink / raw)
To: gitster; +Cc: git, Brandon Casey
From: Brandon Casey <drafnel@gmail.com>
The substring expansion notation is a bashism that we have not so far
adopted. There is precedence for using the 'cut' utility for extracting
a substring. So do so here.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
t/t7407-submodule-foreach.sh | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/t/t7407-submodule-foreach.sh b/t/t7407-submodule-foreach.sh
index de1730d..44ea8ac 100755
--- a/t/t7407-submodule-foreach.sh
+++ b/t/t7407-submodule-foreach.sh
@@ -207,8 +207,8 @@ cat > expect <<EOF
$nested2sha1 nested1/nested2 (heads/master)
$nested3sha1 nested1/nested2/nested3 (heads/master)
$submodulesha1 nested1/nested2/nested3/submodule (heads/master)
- $sub1sha1 sub1 (${sub1sha1:0:7})
- $sub2sha1 sub2 (${sub1sha1:0:7})
+ $sub1sha1 sub1 ($(echo $sub1sha1 | cut -c 1-7))
+ $sub2sha1 sub2 ($(echo $sub1sha1 | cut -c 1-7))
$sub3sha1 sub3 (heads/master)
EOF
--
1.6.4
^ permalink raw reply related
* Re: Continue git clone after interruption
From: Sam Vilain @ 2009-08-20 0:26 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Jakub Narebski, Tomasz Kontusz, git, Johannes Schindelin
In-Reply-To: <alpine.LFD.2.00.0908191552020.6044@xanadu.home>
On Wed, 2009-08-19 at 17:13 -0400, Nicolas Pitre wrote:
> > It's the "cheaply deepen history" that I doubt would be easy. This is
> > the most difficult part, I think (see also below).
>
> Don't think so. Try this:
>
> mkdir test
> cd test
> git init
> git fetch --depth=1 git://git.kernel.org/pub/scm/git/git.git
>
> REsult:
>
> remote: Counting objects: 1824, done.
> remote: Compressing objects: 100% (1575/1575), done.
> Receiving objects: 100% (1824/1824), 3.01 MiB | 975 KiB/s, done.
> remote: Total 1824 (delta 299), reused 1165 (delta 180)
> Resolving deltas: 100% (299/299), done.
> From git://git.kernel.org/pub/scm/git/git
> * branch HEAD -> FETCH_HEAD
>
> You'll get the very latest revision for HEAD, and only that. The size
> of the transfer will be roughly the size of a daily snapshot, except it
> is fully up to date. It is however non resumable in the event of a
> network outage. My proposal is to replace this with a "git archive"
> call. It won't get all branches, but for the purpose of initialising
> one's repository that should be good enough. And the "git archive" can
> be fully resumable as I explained.
>
> Now to deepen that history. Let's say you want 10 more revisions going
> back then you simply perform the fetch again with a --depth=10. Right
> now it doesn't seem to work optimally, but the pack that is then being
> sent could be made of deltas against objects found in the commits we
> already have. Currently it seems that a pack that also includes those
> objects we already have in addition to those we want is created, which
> is IMHO a flaw in the shallow support that shouldn't be too hard to fix.
> Each level of deepening should then be as small as standard fetches
> going forward when updating the repository with new revisions.
Nicholas, apart from starting with most recent commits and working
backwards, this is very similar to the "bundle slicing" idea defined in
GitTorrent. What the GitTorrent research project has so far achieved is
defining a slicing algorithm, and figuring out how well slicing works,
in terms of wasted bandwidth.
If you do it right, then you can support download spreading across
mirrors, too. Eg, given a starting point, a 'slice size' - which I
based on uncompressed object size but could as well be based on commit
count - and a slice number to fetch, you should be able to look up in
the revision list index the revisions to select and then make a thin
pack corresponding to those commits. Currently creating this index is
the slowest part of creating bundle fragments in my Perl implementation.
Once Nick Edelen's project is mergeable, we have a mechanism for being
able to relatively quickly draw a manifest of objects for these slices.
So how much bandwidth is lost?
Eg, for git.git, taking the complete object list, slicing it into 1024k
(uncompressed) bundle slices, and making thin packs from those slices we
get:
Generating index...
Length is 1291327524, 1232 blocks
Slice #0: 1050390 => 120406 (11%)
Slice #1: 1058162 => 124978 (11%)
Slice #2: 1049858 => 104363 (9%)
...
Slice #51: 1105090 => 43140 (3%)
Slice #52: 1091282 => 45367 (4%)
Slice #53: 1067675 => 39792 (3%)
...
Slice #211: 1086238 => 25451 (2%)
Slice #212: 1055705 => 31294 (2%)
Slice #213: 1059460 => 7767 (0%)
...
Slice #1129: 1109209 => 38182 (3%)
Slice #1130: 1125925 => 29829 (2%)
Slice #1131: 1120203 => 14446 (1%)
Final slice: 623055 => 49345
Overall compressed: 39585851
Calculating Repository bundle size...
Counting objects: 107369, done.
Compressing objects: 100% (28059/28059), done.
Writing objects: 100% (107369/107369), 29.20 MiB | 48321 KiB/s, done.
Total 107369 (delta 78185), reused 106770 (delta 77609)
Bundle size: 30638967
Overall inefficiency: 29%
In the above output, the first figure is the complete un-delta'd,
uncompressed size of the slice - that is, the size of all of the new
objects that the commit introduces. The second figure is the full size
of a thin pack with those objects in it. ie the above tells me that in
git.git there are 1.2GB of uncompressed objects. Each slice ends up
varying in size between about 10k and 200k, but most of the slices end
up between 15k and 50k.
Actually the test script was thrown off by a loose root and that added
about 3MB to the compressed size, so the overall inefficiency with this
block size is actually more like 20%. I think I am running into the
flaw you mention above, too, especially when I do a larger block size
run:
Generating index...
Length is 1291327524, 62 blocks
Slice #0: 21000218 => 1316165 (6%)
Slice #1: 20988208 => 1107636 (5%)
...
Slice #59: 21102776 => 1387722 (6%)
Slice #60: 20974960 => 876648 (4%)
Final slice: 6715954 => 261218
Overall compressed: 50071857
Calculating Repository bundle size...
Counting objects: 107369, done.
Compressing objects: 100% (28059/28059), done.
Writing objects: 100% (107369/107369), 29.20 MiB | 48353 KiB/s, done.
Total 107369 (delta 78185), reused 106770 (delta 77609)
Bundle size: 30638967
Overall inefficiency: 63%
Somehow we made larger packs but the total packed size was larger.
Trying with 100MB "blocks" I get:
Generating index...
Length is 1291327524, 13 blocks
Slice #0: 104952661 => 4846553 (4%)
Slice #1: 104898188 => 2830056 (2%)
Slice #2: 105007998 => 2856535 (2%)
Slice #3: 104909972 => 2583402 (2%)
Slice #4: 104909440 => 2187708 (2%)
Slice #5: 104859786 => 2555686 (2%)
Slice #6: 104873317 => 2358914 (2%)
Slice #7: 104881597 => 2183894 (2%)
Slice #8: 104863418 => 3555224 (3%)
Slice #9: 104896599 => 3192564 (3%)
Slice #10: 104876697 => 3895707 (3%)
Slice #11: 104903491 => 3731555 (3%)
Final slice: 32494360 => 1270887
Overall compressed: 38048685
Calculating Repository bundle size...
Counting objects: 107369, done.
Compressing objects: 100% (28059/28059), done.
Writing objects: 100% (107369/107369), 29.20 MiB | 48040 KiB/s, done.
Total 107369 (delta 78185), reused 106770 (delta 77609)
Bundle size: 30638967
Overall inefficiency: 24%
In the above, we broke the git.git download into 13 partial downloads of
a few meg each, at the expense of an extra 24% of download.
Anyway I've hopefully got more to add to this but this will do for a
starting point.
Sam
^ permalink raw reply
* What's a good setup for submitting patches to the list properly?
From: Thell Fowler @ 2009-08-20 0:09 UTC (permalink / raw)
To: git
Sorry for once again.
I haven't been able to figure out a good setup for posting patches to the
list correctly, perhaps someone could tell me where I'm going wrong.
Alpine is setup to access git @ tbfowler.name with the 'postpone' folder
being the 'Drafts' folder on the remote mail host, and a local mbox folder
~/mail/git
Locally I prepped the emails using:
git format-patch --cover-letter --full-index -n
--in-reply-to=1249428804.2774.52.camel@GWPortableVCS --thread --signoff -6
--stdout>>~/mail/git
http://article.gmane.org/gmane.comp.version-control.git/124834
Thinking that the cover letter would be in reply to a previous thread, and
that the rest would show as a reply to that. After doing the
format-patch, I went into Alpine's git folder selected the messages and
saved them to the Drafts folder, then did 'compose' for each one, filling
in the information I thought was needed.
At that point, the msg list looked flat, so I opened Evolution Mail and
looked at them there, they cascaded properly, so I sent them. Yet, now,
looking on gmane each of the patch msgs is a top level post and the cover
letter correctly posted as a reply to the previous thread.
What could I have done/checked before sending to make sure that these
would have posted properly?
--
Thell
^ 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