* Re: [RFC PATCH 00/12] Sparse checkout
From: Nguyen Thai Ngoc Duy @ 2008-07-24 23:21 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Johannes Schindelin
In-Reply-To: <200807242201.23991.jnareb@gmail.com>
On 7/25/08, Jakub Narebski <jnareb@gmail.com> wrote:
> On Thu, 24 Jul 2008, Nguyen Thai Ngoc Duy wrote:
>
> > On 7/24/08, Jakub Narebski <jnareb@gmail.com> wrote:
> > >
> > > Second, I think you can simply special case .git* files (.gitignore,
> > > .gitattributes, .gitmodules), and always check them out for all
> > > intermediate directories (unless configured otherwise, of course).
> > > So for example if you have the following directory structure:
> > >
> > > A/.gitignore
> > > A/a
> > > A/B1/.gitignore
> > > A/B1/b
> > > A/B2/.gitignore
> > > A/B2/c
> > >
> > > and you are checking out only subdirectory 'B1' (and all files in it;
> > > if subdirectories are checked out recursively it depends on
> > > configuration), and if for example there is .gitignore in every
> > > directory, then checked out tree would look like this:
> > >
> > > A/.gitignore
> > > A/B1/.gitignore
> > > A/B1/b
> > >
> > > The ability to do this is one of advantages of 'sparse' checkout over
> > > 'subtree' checkout.
> >
> > Or teach git to use index version of those files. Or collect all those
> > files, combine them and put the result to .git/info/exclude (and
> > similar places). Anyway well organized repos won't have this problem.
> >
> > Checking some files out as read-only (like this case) may be
> > interesting. Though I do not how much complicated it can be.
>
>
> I think teaching git to use index version of .git* files (.gitignore,
> .gitattributes, .gitmodules) would be much more work than adding
> default rule that .git* files in leading directories are by default
> checked out, just like leading directories are checked out. This
> would limit modifying git code, I think, and chances for errors.
>
> Having "leading" directories and files read-only would be a good idea,
> I think.
>
> I don't understand the sentence "well organized repos won't have this
> problem". I think well organized repos _would_ have this problem,
> because of maintained and distributed top-level .gitignore and
> .gitattributes.
I wrote that with svn repos in mind. If those repos are to be
partially checked out, .svnignore would be in subdirectories rather
than at toplevel. Anyway that may not be true.
> P.S. I hope that 'sparse checkout' feature would be ready for 1.7.0
>
> --
> Jakub Narebski
> Poland
>
--
Duy
^ permalink raw reply
* Re: [RFC PATCH 00/12] Sparse checkout
From: Nguyen Thai Ngoc Duy @ 2008-07-24 23:23 UTC (permalink / raw)
To: James Pickens; +Cc: git
In-Reply-To: <loom.20080724T171151-310@post.gmane.org>
On 7/25/08, James Pickens <jepicken@gmail.com> wrote:
> > You can do that with "git checkout --path" (non-recursive checkout aside):
> >
> > $ git checkout --path=A # checkout full A
> > $ git checkout --path=A/B1/C1 # no, limit to A/B1/C1 only
> > $ git checkout --path=A/B1/C1:A/B2 # extend to A/B2 too
>
>
> My point was not that incremental checkout is impossible, just that it
> would be easier if I didn't have to re-type the full path list again.
> Suppose I had 9 directories (A/B1 through A/B9) in my sparse checkout,
> and I wanted to add a 10th directory (A/B10). It would be much easier
> to type something like
>
> $ cd A
> $ git checkout B10
>
> instead of
>
> $ git checkout --path=A/B1:A/B2:A/B3:A/B4:A/B5:A/B6:A/B7:A/B8:A/B9:A/B10
"git checkout B10" form has already been taken. How about "git
checkout --add-path" and "git checkout --remove-path"?
--
Duy
^ permalink raw reply
* Re: Submodules: Publishing a locally created submodule.
From: Mark Levedahl @ 2008-07-24 23:30 UTC (permalink / raw)
To: git; +Cc: git mailing list
In-Reply-To: <18071eea0807240840g79da962ci8fbc65546d496323@mail.gmail.com>
Thomas Adam wrote:
> Hello all,
>
>
> Now: I want to make mysubmoduleB a submodule which I can publish to
> the shared repository and when others pull, to see that submodule and
> be able to treat it as such.
>
> But I can't see how to do that. Can someone help?
>
> Many thanks in advance.
>
> -- Thomas Adam
git submodule add <URL where this will exist> ./mysubmoduleB
will recognize that mysubmoduleB is already a valid git repo and add it as is at
the current location to the superproject.
Mark
^ permalink raw reply
* Stitching together two split segments from svn
From: Liam Healy @ 2008-07-24 23:33 UTC (permalink / raw)
To: git
Hi,
I have a project whose history is stored in two separate svn
repositories. The first repository I kept privately during initial
development, the second started when I posted it publicly and does not
have the history of the first. I am trying to reunite them under git.
The development of the first was linear, so after using git svn, the
history looks like:
a - b - ... - c - d = HEAD (old repository)
and the second has one branch "ffa":
(new repository)
T - d - e - ... - f - g - h - ... - j master
\
k - l - .... - m ffa
Note that T is the "trunk" initial commit on the svn repo that has no
files. The second commit d is identical to the HEAD of old, as
verified by git diff.
However, when I remote add these two into a single repository, they
show up as two detached chains, with no connection between them. I
thought git rebase would reconnect them. However, when I do that on
each branch (master and ffa), I get the following:
a - b - ... - c - d - e - ... - f - g - h - ... - j master
\
e - ... -f - g - k - l - .... - m ffa
instead of what I would like
a - b - ... - c - d - e - ... - f - g - h - ... - j master
\
k - l - .... - m ffa
That is to say, those commits from the new repository that have a
common history for the two branches are duplicated. The commits are
listed separately and have different SHA IDs, but they are clearly the
same commits (same comments, same svn version number). Is there any
way to do what I want? Really, all I want to do is change the parent
of "e" to be the HEAD of the old repository.
Thank you.
Liam
^ permalink raw reply
* Re: [RFC PATCH 00/12] Sparse checkout
From: James Pickens @ 2008-07-24 23:38 UTC (permalink / raw)
To: git
In-Reply-To: <fcaeb9bf0807241623m3fbd476dyc41990d8ef0888e6@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds <at> gmail.com> writes:
> "git checkout B10" form has already been taken. How about "git
> checkout --add-path" and "git checkout --remove-path"?
That would be fine. The specific syntax is not that important to me, as long as
the capability exists.
James
^ permalink raw reply
* Re: Stitching together two split segments from svn
From: Jakub Narebski @ 2008-07-24 23:48 UTC (permalink / raw)
To: Liam Healy; +Cc: git
In-Reply-To: <654935030807241633g763e622br4feb8b4e23ee64e2@mail.gmail.com>
"Liam Healy" <lnp@healy.washington.dc.us> writes:
> I have a project whose history is stored in two separate svn
> repositories. The first repository I kept privately during initial
> development, the second started when I posted it publicly and does not
> have the history of the first. I am trying to reunite them under git.
> The development of the first was linear, so after using git svn, the
> history looks like:
>
> a - b - ... - c - d = HEAD (old repository)
>
> and the second has one branch "ffa":
>
> (new repository)
> T - d - e - ... - f - g - h - ... - j master
> \
> k - l - .... - m ffa
>
> Note that T is the "trunk" initial commit on the svn repo that has no
> files. The second commit d is identical to the HEAD of old, as
> verified by git diff.
> However, when I remote add these two into a single repository, they
> show up as two detached chains, with no connection between them. I
> thought git rebase would reconnect them. However, when I do that on
> each branch (master and ffa), I get the following:
>
> a - b - ... - c - d - e - ... - f - g - h - ... - j master
> \
> e - ... -f - g - k - l - .... - m ffa
>
> instead of what I would like
>
> a - b - ... - c - d - e - ... - f - g - h - ... - j master
> \
> k - l - .... - m ffa
>
> That is to say, those commits from the new repository that have a
> common history for the two branches are duplicated. The commits are
> listed separately and have different SHA IDs, but they are clearly the
> same commits (same comments, same svn version number). Is there any
> way to do what I want? Really, all I want to do is change the parent
> of "e" to be the HEAD of the old repository.
If this is initial import, and not published anywhere, the simplest (I
think) solution would be to use grafts file (.git/info/grafts) to
change parent of 'k' from 'g' in ffa to 'g' in master, by adding the
line with:
<sha1 of 'k'> <sha1 of 'g' on master>
to .git/info/grafts. Then examine history if everything is now all
right (for example using gitk), and if everything is O.K. run
git-filter-branch.
See documentation for details.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Respect crlf attribute in "git add" even if core.autocrlf has not been set
From: Johannes Schindelin @ 2008-07-24 23:58 UTC (permalink / raw)
To: Robin Rosenberg
Cc: Steffen Prohaska, Dmitry Potapov, Junio C Hamano,
Git Mailing List
In-Reply-To: <200807242244.04799.robin.rosenberg.lists@dewire.com>
Hi,
On Thu, 24 Jul 2008, Robin Rosenberg wrote:
> torsdagen den 24 juli 2008 18.45.07 skrev Johannes Schindelin:
> > However, I see Junio's point: on sane platforms you have to work hard
> > to get CR-damaged files. And the regular sane platform user should
> > not be punished for the brain/CR damage a certain monopolist has
> > brought over this planet.
>
> That wasn't hard at all :) Eclipse did it all by itself for JEE
> MANIFEST.MF files. We got into some strange problems on windows with
> msysgit after that where git (status) detected the files as changed, but
> no actual content change and refused to change it's mind. I think we had
> actually fixed the files on Windows prior to that. Only after converting
> the checkout to autocrlf=input did msysgit enter a sane state again. I
> was not able to repeat the problem at the time.
>
> Maybe I'll try again in a few weeks time.
That would be rather useful, because without a way to reproduce, you leave
me with a rather frustrating situation.
Hth,
Dscho
^ permalink raw reply
* Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set
From: Johannes Schindelin @ 2008-07-25 0:01 UTC (permalink / raw)
To: Eyvind Bernhardsen; +Cc: Avery Pennarun, Joshua Jensen, Junio C Hamano, git
In-Reply-To: <3B9933A6-9637-41AE-9133-9B6EA9204E6B@orakel.ntnu.no>
Hi,
On Thu, 24 Jul 2008, Eyvind Bernhardsen wrote:
> On 23. juli. 2008, at 21.44, Johannes Schindelin wrote:
>
> [...]
>
> >I deem it not, uhm, magical. By your reasoning there should be a way
> >for Git to convert a file to UTF-8 when some entertaining person
> >converted the working directory file to ISO-8859-15.
>
> Um, what? This discussion is about figuring out when Git should mess
> with the line endings a user is trying to commit.
This discusion is about when Git should mess with _content_ at all.
It is not limited to line endings.
Ciao,
Dscho "who personally could not care less about CR if it was not for M$'
stupidity"
^ permalink raw reply
* Re: Submodules: Publishing a locally created submodule.
From: Thomas Adam @ 2008-07-25 0:05 UTC (permalink / raw)
To: Mark Levedahl; +Cc: git mailing list
In-Reply-To: <48891088.40709@gmail.com>
Hello --
2008/7/25 Mark Levedahl <mlevedahl@gmail.com>:
> git submodule add <URL where this will exist> ./mysubmoduleB
>
> will recognize that mysubmoduleB is already a valid git repo and add it as
> is at the current location to the superproject.
Ah -- now that was missing from the documentation (the syntax; not the
intention.) Thanks.
It seems my brain has turned to mush so I need to go back to square
one and verify the steps for this are accurate. If I am doing this
arse-about-face, do say. ;)
I've mentioned I am using a bare repository which is shared amongst
developers. We've been using one fine for normal development and for
various reaons I am creating a new repository to be filled with
submodules. I shall call this "SM".
Our "superproject" is a directory hierarchy with interspersed files.
On the server I did this:
server% cd /usr/src/SM
server% git init
server% cd ./superproject
server% git init
server% git add .
server% git commit -m "Initial checkin"
server% cd ..
server% git submodule add /path/to/usr/src/SM
server% git commit -a -m "Submodules..."
Then cloned a bare repo from that which I was able to clone locally
and do stuff in. I could push stuff out too for that one project.
But how from this clone do I then publish any further submodules I
might create locally? I can't very well do so directly in my checkout
-- it has no concept of where the submodules are. I could go to the
server, add another directory as a submodule (as I've done with
"superproject" above --- but then any changes under /usr/src/SM on the
server are local -- the bare repo has no knowledge of any changes made
there.
Does this even make sense? ;)
Thanks in advance.
-- Thomas Adam
^ permalink raw reply
* Re: [RFC PATCH 00/12] Sparse checkout
From: Johannes Schindelin @ 2008-07-25 0:07 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Nguyen Thai Ngoc Duy, git
In-Reply-To: <200807242201.23991.jnareb@gmail.com>
Hi,
On Thu, 24 Jul 2008, Jakub Narebski wrote:
> I think teaching git to use index version of .git* files (.gitignore,
> .gitattributes, .gitmodules) would be much more work than adding
> default rule that .git* files in leading directories are by default
> checked out, just like leading directories are checked out.
"Teaching" Git that would also directly contradict Git's primary motto:
"Content is king".
Oh, by some convoluted reasoning you could argue that "content" hidden
somewhere else than the working directory is "content", but nobody in her
right mind would buy into that.
Ciao,
Dscho
^ permalink raw reply
* Re: sparse fetch, was Re: [PATCH 08/12] git-clone: support --path to do sparse clone
From: Johannes Schindelin @ 2008-07-25 0:09 UTC (permalink / raw)
To: Jeff King; +Cc: Nguyễn Thái Ngọc Duy, git
In-Reply-To: <20080724182813.GA21186@sigill.intra.peff.net>
Hi,
On Thu, 24 Jul 2008, Jeff King wrote:
> On Thu, Jul 24, 2008 at 06:41:03PM +0100, Johannes Schindelin wrote:
>
> > > As a user, I would expect "sparse clone" to also be sparse on the
> > > fetching. That is, to not even bother fetching tree objects that we
> > > are not going to check out. But that is a whole other can of worms
> > > from local sparseness, so I think it is worth saving for a different
> > > series.
> >
> > I think this is not even worth of a series. Sure, it would have
> > benefits for those who want sparse checkouts. But it comes for a high
> > price on everyone else:
>
> I agree there are a lot of issues. I am just thinking of the person who
> said they had a >100G repository. But I am also not volunteering to do
> it, so I will let somebody who really cares about it try to defend the
> idea.
I never said that there were no benefits. I argued that there are too
many _downsides_ to those who _don't_ benefit.
Ciao,
Dscho
^ permalink raw reply
* Re: sparse fetch, was Re: [PATCH 08/12] git-clone: support --path to do sparse clone
From: Johannes Schindelin @ 2008-07-25 0:12 UTC (permalink / raw)
To: sverre; +Cc: Petr Baudis, Jeff King, Nguy?n Thái Ng?c Duy, git
In-Reply-To: <bd6139dc0807241201v50cd5ef2m58ee7efc05119e20@mail.gmail.com>
Hi,
On Thu, 24 Jul 2008, Sverre Rabbelier wrote:
> On Thu, Jul 24, 2008 at 8:53 PM, Petr Baudis <pasky@suse.cz> wrote:
> > I don't follow how these two issues arise, if the server will do the
> > pruning for you. It will just skip entering some tree objects when
> > doing object traversal; why opening the git protocol or faking
> > commits? This would be a simple extra capability in the protocol.
>
> Wouldn't that be as simple as passing a pathspec to git-rev-list? Not a
> lot of overhead there I reckon.
So the server would _not_ have to deflate the objects to inspect them? I
thought you knew more about Git's object database.
> > One question is what to do with delta chains including unwanted
> > objects, but I think that given the objects' associativity for delta
> > chains, this shouldn't be huge practical issues and it could be
> > affordable in principle to include even unwanted objects.
>
> Just keep them?
You'd still have to inspect the objects, which is way more work than the
current code has to do. Remember: in the optimal case, upload-pack does
not more than just serve the existing deltas/base objects.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Teach fsck and prune about the new location of temporary objects
From: Johannes Schindelin @ 2008-07-25 0:33 UTC (permalink / raw)
To: Brandon Casey; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <6ruv3Y98_kSSVnJFTkV0PNdiNcQ3g-a3M4BhGoT7S1PorElp5tJAkw@cipher.nrlssc.navy.mil>
Hi,
On Thu, 24 Jul 2008, Brandon Casey wrote:
> Since 5723fe7e, temporary objects are now created in their final destination
> directories, rather than in .git/objects/. Teach fsck to recognize and
> ignore the temporary objects it encounters,
It somehow feels wrong for fsck to ignore anything that could be used.
Ciao,
Dscho
^ permalink raw reply
* Re: sparse fetch, was Re: [PATCH 08/12] git-clone: support --path to do sparse clone
From: Petr Baudis @ 2008-07-25 0:42 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: sverre, Jeff King, Nguy?n Thái Ng?c Duy, git
In-Reply-To: <alpine.DEB.1.00.0807250210090.4140@eeepc-johanness>
Hi,
On Fri, Jul 25, 2008 at 02:12:31AM +0200, Johannes Schindelin wrote:
> On Thu, 24 Jul 2008, Sverre Rabbelier wrote:
>
> > On Thu, Jul 24, 2008 at 8:53 PM, Petr Baudis <pasky@suse.cz> wrote:
> > > I don't follow how these two issues arise, if the server will do the
> > > pruning for you. It will just skip entering some tree objects when
> > > doing object traversal; why opening the git protocol or faking
> > > commits? This would be a simple extra capability in the protocol.
> >
> > Wouldn't that be as simple as passing a pathspec to git-rev-list? Not a
> > lot of overhead there I reckon.
>
> So the server would _not_ have to deflate the objects to inspect them? I
> thought you knew more about Git's object database.
..snip..
> You'd still have to inspect the objects, which is way more work than the
> current code has to do. Remember: in the optimal case, upload-pack does
> not more than just serve the existing deltas/base objects.
then right now, exactly how does the server decide that the blob
7a7ff130 should be served along git.git HEAD? I still see upload-pack.c
calling traverse_commit_list() that does process_tree() on every tree,
etc. But the code is not straightforward, maybe I'm missing some
shortcut?
--
Petr "Pasky" Baudis
As in certain cults it is possible to kill a process if you know
its true name. -- Ken Thompson and Dennis M. Ritchie
^ permalink raw reply
* Re: sparse fetch, was Re: [PATCH 08/12] git-clone: support --path to do sparse clone
From: James Pickens @ 2008-07-25 0:46 UTC (permalink / raw)
To: git
In-Reply-To: <20080724182813.GA21186@sigill.intra.peff.net>
Jeff King <peff <at> peff.net> writes:
> I agree there are a lot of issues. I am just thinking of the person who
> said they had a >100G repository. But I am also not volunteering to do
> it, so I will let somebody who really cares about it try to defend the
> idea.
If you're referring to me (I mentioned a 144G CVS repo), then let me
clarify a couple of things:
1. Probably more than 50% of the 144G is crud that should never have
been checked in, but I have some undisciplined coworkers who like to
blindly check in everything in their work trees. If/when we moved to
git, I would get rid of all that crud. I'm also thinking about throwing
out a lot of the history, since those same undisciplined coworkers like
to use empty and/or useless log messages, so a lot of the history isn't
very valuable anyways.
2. Git of course will store the remaining ~70G much more efficiently
than CVS. I think git will be especially better than CVS for this repo,
because it contains many instances of the same file(s) being checked in
in multiple directories.
I expect the git repo size to be less than 7G. In addition, all our
work is done on site on nfs, so we can use clone -s to avoid copying the
whole 7G.
To sum it up, sparse cloning would not be important to me.
James
^ permalink raw reply
* [StGit PATCH] Fix some remaining old-style stg id calls
From: Karl Hasselström @ 2008-07-25 0:47 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20080713114047.18845.34899.stgit@localhost.localdomain>
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
You'll want to add this (just squash it into your patch). The calls
were failing, but since both sides produced the empty string on
stdout, the test was happy anyway.
t/t1300-uncommit.sh | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/t/t1300-uncommit.sh b/t/t1300-uncommit.sh
index a906d13..472baa4 100755
--- a/t/t1300-uncommit.sh
+++ b/t/t1300-uncommit.sh
@@ -42,7 +42,7 @@ test_expect_success \
'Uncommit the patches using names' \
'
stg uncommit bar foo &&
- [ "$(stg id foo//top)" = "$(stg id bar//bottom)" ] &&
+ [ "$(stg id foo)" = "$(stg id bar^)" ] &&
stg commit --all
'
@@ -50,7 +50,7 @@ test_expect_success \
'Uncommit the patches using prefix' \
'
stg uncommit --number=2 foobar &&
- [ "$(stg id foobar1//top)" = "$(stg id foobar2//bottom)" ] &&
+ [ "$(stg id foobar1)" = "$(stg id foobar2^)" ] &&
stg commit --all
'
@@ -58,7 +58,7 @@ test_expect_success \
'Uncommit the patches using auto names' \
'
stg uncommit --number=2 &&
- [ "$(stg id foo-patch//top)" = "$(stg id bar-patch//bottom)" ] &&
+ [ "$(stg id foo-patch)" = "$(stg id bar-patch^)" ] &&
stg commit --all
'
@@ -67,14 +67,14 @@ test_expect_success \
'
stg uncommit &&
stg uncommit &&
- [ "$(stg id foo-patch//top)" = "$(stg id bar-patch//bottom)" ] &&
+ [ "$(stg id foo-patch)" = "$(stg id bar-patch^)" ] &&
stg commit --all
'
test_expect_success \
'Uncommit the patches with --to' '
stg uncommit --to HEAD^ &&
- [ "$(stg id foo-patch//top)" = "$(stg id bar-patch//bottom)" ] &&
+ [ "$(stg id foo-patch)" = "$(stg id bar-patch^)" ] &&
stg commit --all
'
^ permalink raw reply related
* Re: sparse fetch, was Re: [PATCH 08/12] git-clone: support --path?to do sparse clone
From: Jeff King @ 2008-07-25 0:49 UTC (permalink / raw)
To: James Pickens; +Cc: git
In-Reply-To: <loom.20080725T004541-298@post.gmane.org>
On Fri, Jul 25, 2008 at 12:46:52AM +0000, James Pickens wrote:
> If you're referring to me (I mentioned a 144G CVS repo), then let me
> clarify a couple of things:
> [...]
> To sum it up, sparse cloning would not be important to me.
I was referring to you, so thanks for the clarification.
-Peff
^ permalink raw reply
* [StGit PATCH 0/3] Fix uncommit with top != head
From: Karl Hasselström @ 2008-07-25 0:52 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git, Erik Sandberg
See http://gna.org/bugs/?12043
---
Karl Hasselström (3):
Make sure that stg uncommit doesn't touch the branch head
stg uncommit should never touch the branch head
Test for exit code with command_error()
stgit/commands/uncommit.py | 2 +-
stgit/lib/transaction.py | 19 ++++++++++---------
t/t1300-uncommit.sh | 13 ++++++++++++-
t/t1303-commit.sh | 20 ++++++++++++++++++++
4 files changed, 43 insertions(+), 11 deletions(-)
create mode 100755 t/t1303-commit.sh
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* [StGit PATCH 1/3] Test for exit code with command_error()
From: Karl Hasselström @ 2008-07-25 0:52 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git, Erik Sandberg
In-Reply-To: <20080725005154.13006.8908.stgit@yoghurt>
The helper function was made for occasions such as this, so use it.
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
t/t1300-uncommit.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/t/t1300-uncommit.sh b/t/t1300-uncommit.sh
index a906d13..a657ead 100755
--- a/t/t1300-uncommit.sh
+++ b/t/t1300-uncommit.sh
@@ -79,7 +79,7 @@ test_expect_success \
'
test_expect_success 'Uncommit a commit with not precisely one parent' '
- stg uncommit -n 5 ; [ $? = 2 ] &&
+ command_error stg uncommit -n 5 &&
[ "$(echo $(stg series))" = "" ]
'
^ permalink raw reply related
* [StGit PATCH 2/3] stg uncommit should never touch the branch head
From: Karl Hasselström @ 2008-07-25 0:53 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git, Erik Sandberg
In-Reply-To: <20080725005154.13006.8908.stgit@yoghurt>
However, currently, it will set head to top, potentially losing data
(which can always be recovered via the reflog, but still). See
https://gna.org/bugs/index.php?12043. Add a test to demonstrate the
bad behavior. (Bug discovered by Erik Sandberg
<mandolaerik@gmail.com>.)
stg commit, on the other hand, should refuse to run if top != head,
since the committed patches might otherwise be lost. Add a test to
demonstrate that this is the case.
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
t/t1300-uncommit.sh | 11 +++++++++++
t/t1303-commit.sh | 20 ++++++++++++++++++++
2 files changed, 31 insertions(+), 0 deletions(-)
create mode 100755 t/t1303-commit.sh
diff --git a/t/t1300-uncommit.sh b/t/t1300-uncommit.sh
index a657ead..d01eaaa 100755
--- a/t/t1300-uncommit.sh
+++ b/t/t1300-uncommit.sh
@@ -83,4 +83,15 @@ test_expect_success 'Uncommit a commit with not precisely one parent' '
[ "$(echo $(stg series))" = "" ]
'
+# stg uncommit should work even when top != head, and should not touch
+# the head.
+test_expect_failure 'Uncommit when top != head' '
+ stg new -m foo &&
+ git reset --hard HEAD^ &&
+ h=$(git rev-parse HEAD)
+ stg uncommit bar &&
+ test $(git rev-parse HEAD) = $h &&
+ test "$(echo $(stg series))" = "+ bar > foo"
+'
+
test_done
diff --git a/t/t1303-commit.sh b/t/t1303-commit.sh
new file mode 100755
index 0000000..d53b9f2
--- /dev/null
+++ b/t/t1303-commit.sh
@@ -0,0 +1,20 @@
+#!/bin/sh
+test_description='Test stg commit'
+. ./test-lib.sh
+
+test_expect_success 'Initialize the StGIT repository' '
+ stg init
+'
+
+# stg commit with top != head should not succeed, since the committed
+# patches are poptentially lost.
+test_expect_success 'Commit when top != head (should fail)' '
+ stg new -m foo &&
+ git reset --hard HEAD^ &&
+ h=$(git rev-parse HEAD)
+ command_error stg commit &&
+ test $(git rev-parse HEAD) = $h &&
+ test "$(echo $(stg series))" = "> foo"
+'
+
+test_done
^ permalink raw reply related
* [StGit PATCH 3/3] Make sure that stg uncommit doesn't touch the branch head
From: Karl Hasselström @ 2008-07-25 0:53 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git, Erik Sandberg
In-Reply-To: <20080725005154.13006.8908.stgit@yoghurt>
Even if top != head. It used to set head to top; but with this patch,
it doesn't anymore.
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
stgit/commands/uncommit.py | 2 +-
stgit/lib/transaction.py | 19 ++++++++++---------
t/t1300-uncommit.sh | 2 +-
3 files changed, 12 insertions(+), 11 deletions(-)
diff --git a/stgit/commands/uncommit.py b/stgit/commands/uncommit.py
index eb39fcc..9d2dba9 100644
--- a/stgit/commands/uncommit.py
+++ b/stgit/commands/uncommit.py
@@ -136,5 +136,5 @@ def func(parser, options, args):
for commit, pn in zip(commits, patchnames):
trans.patches[pn] = commit
trans.applied = list(reversed(patchnames)) + trans.applied
- trans.run()
+ trans.run(set_head = False)
out.done()
diff --git a/stgit/lib/transaction.py b/stgit/lib/transaction.py
index e47997e..23321c7 100644
--- a/stgit/lib/transaction.py
+++ b/stgit/lib/transaction.py
@@ -138,21 +138,22 @@ class StackTransaction(object):
# The only state we need to restore is index+worktree.
if iw:
self.__checkout(self.__stack.head.data.tree, iw)
- def run(self, iw = None):
+ def run(self, iw = None, set_head = True):
"""Execute the transaction. Will either succeed, or fail (with an
exception) and do nothing."""
self.__check_consistency()
new_head = self.__head
# Set branch head.
- if iw:
- try:
- self.__checkout(new_head.data.tree, iw)
- except git.CheckoutException:
- # We have to abort the transaction.
- self.abort(iw)
- self.__abort()
- self.__stack.set_head(new_head, self.__msg)
+ if set_head:
+ if iw:
+ try:
+ self.__checkout(new_head.data.tree, iw)
+ except git.CheckoutException:
+ # We have to abort the transaction.
+ self.abort(iw)
+ self.__abort()
+ self.__stack.set_head(new_head, self.__msg)
if self.__error:
out.error(self.__error)
diff --git a/t/t1300-uncommit.sh b/t/t1300-uncommit.sh
index d01eaaa..4a955f6 100755
--- a/t/t1300-uncommit.sh
+++ b/t/t1300-uncommit.sh
@@ -85,7 +85,7 @@ test_expect_success 'Uncommit a commit with not precisely one parent' '
# stg uncommit should work even when top != head, and should not touch
# the head.
-test_expect_failure 'Uncommit when top != head' '
+test_expect_success 'Uncommit when top != head' '
stg new -m foo &&
git reset --hard HEAD^ &&
h=$(git rev-parse HEAD)
^ permalink raw reply related
* Re: git newbie - cloning / check out help
From: Donald Brady @ 2008-07-24 23:55 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20080724231531.GS32184@machine.or.cz>
Hi Peter.
I got it working now thanks to your pointer.
Donald
On Jul 24, 2008, at 4:15 PM, Petr Baudis wrote:
> Hi,
>
> On Thu, Jul 24, 2008 at 09:24:34PM +0000, Donald Brady wrote:
>> I am just ramping up on git and have the following scenario / issue:
>>
>> I have a git repository on server A.
>>
>> I clone it onto my machine B.
>>
>> In my local copy/repository on machine B I clone a repository on
>> some
>> third party server C.
>>
>> I commit my changes into B and push them to A.
>>
>> Now if I clone my repository from Server A onto my local machine
>> in a different location I see all the source as normal but only the
>> top
>> level directory of C. Any source under that is not present.
>>
>> What is the magic git incantation to make sure that I check out
>> not only the code from my repository but any repositories that
>> are cloned into it (recursive clone?)
>
> we call this functionality "submodules" and the quickstart howto is:
>
> You have git repository on A
>
> You clone it onto your machine B
>
> git submodule add url directoryC
>
> You commit your changes into B and push them to A
>
> You do another clone of A and then within the clone
>
> git submodule update --init
>
> For further details, see git-submodule(1).
>
> --
> Petr "Pasky" Baudis
> As in certain cults it is possible to kill a process if you know
> its true name. -- Ken Thompson and Dennis M. Ritchie
^ permalink raw reply
* StGit: kha/{stable,safe,experimental} updated
From: Karl Hasselström @ 2008-07-25 1:39 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git, Samuel Tardieu
The big update since last time is support (in kha/experimental) for
hidden patches in the new-infrastructure commands and stack log.
Unless more problems are uncovered, I'll soon move all patches in
experimental to safe (which means I'll be recommending that Catalin
merge them).
-+-
The following changes since commit a6c4be12abcf0906a63de8a72c887c360f89ea82:
Karl Hasselström (1):
Don't allow extra diff options with "stg status"
are available in the git repository at:
git://repo.or.cz/stgit/kha.git stable
Daniel White (1):
Fixed default install location
Karl Hasselström (1):
Test that we can add a new file to a non-topmost patch with refresh -p
Miklos Vajna (2):
setup.py: don't try to import stgit.run before the python version check
setup.py: fix error message when running with python-2.3
setup.cfg | 2 +-
setup.py | 4 ++--
t/t2701-refresh-p.sh | 46 ++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 49 insertions(+), 3 deletions(-)
create mode 100755 t/t2701-refresh-p.sh
-+-
The following changes since commit 2e37b61d886ef21200007b57f496aaf182f42705:
Karl Hasselström (1):
Test for "stg edit"
are available in the git repository at:
git://repo.or.cz/stgit/kha.git safe
Daniel White (1):
Fixed default install location
Karl Hasselström (19):
Test that we can add a new file to a non-topmost patch with refresh -p
Merge branch 'stable'
Test for exit code with command_error()
stg uncommit should never touch the branch head
Make sure that stg uncommit doesn't touch the branch head
Fix uncommit status message
Discard stderr output from git apply if the caller wants
Do simple in-index merge with diff+apply instead of read-tree
Reuse the same temp index in a transaction
Library functions for tree and blob manipulation
Teach stgit.lib.transaction about hidden patches
Test operations on hidden patches
stg goto: Handle hidden patches more gracefully
Add utility function for reordering patches
Add some performance testing scripts
Log subprocess activity to a file
Show full command in subprocess profiling
Log subprocess calls during performance testing
Global performance logging
Miklos Vajna (2):
setup.py: don't try to import stgit.run before the python version check
setup.py: fix error message when running with python-2.3
perf/.gitignore | 2 +
perf/create_synthetic_repo.py | 61 +++++++++
perf/find_patchbomb.py | 31 +++++
perf/perftest.py | 96 ++++++++++++++
perf/setup.sh | 52 ++++++++
setup.cfg | 2 +-
setup.py | 4 +-
stgit/commands/edit.py | 2 +-
stgit/commands/goto.py | 2 +
stgit/commands/uncommit.py | 6 +-
stgit/lib/git.py | 274 +++++++++++++++++++++++++++++++++--------
stgit/lib/transaction.py | 61 +++++++--
stgit/main.py | 10 ++-
stgit/out.py | 11 +-
stgit/run.py | 59 +++++++--
t/t1206-push-hidden.sh | 28 ++++
t/t1300-uncommit.sh | 13 ++-
t/t1303-commit.sh | 20 +++
t/t1701-goto-hidden.sh | 23 ++++
t/t2701-refresh-p.sh | 46 +++++++
t/t2900-rename.sh | 7 +
t/t3300-edit.sh | 16 ++-
22 files changed, 731 insertions(+), 95 deletions(-)
create mode 100644 perf/.gitignore
create mode 100644 perf/create_synthetic_repo.py
create mode 100644 perf/find_patchbomb.py
create mode 100644 perf/perftest.py
create mode 100644 perf/setup.sh
create mode 100755 t/t1206-push-hidden.sh
create mode 100755 t/t1303-commit.sh
create mode 100755 t/t1701-goto-hidden.sh
create mode 100755 t/t2701-refresh-p.sh
-+-
The following changes since commit 36a06e0194e013552499677e431e528ecb2faee9:
Karl Hasselström (1):
Global performance logging
are available in the git repository at:
git://repo.or.cz/stgit/kha.git experimental
Karl Hasselström (16):
Write to a stack log when stack is modified
New command: stg reset
Log conflicts separately
Log conflicts separately for all commands
Add a --hard flag to stg reset
Don't write a log entry if there were no changes
Move stack reset function to a shared location
New command: stg undo
New command: stg redo
Log and undo external modifications
Make "stg log" show stack log instead of patch log
Convert "stg refresh" to the new infrastructure
New refresh tests
Remove --undo flags from stg commands and docs
Refactor stgit.commands.edit
Implement "stg refresh --edit" again
Documentation/tutorial.txt | 4 +-
TODO | 2 -
stgit/commands/branch.py | 19 +-
stgit/commands/clone.py | 2 +-
stgit/commands/coalesce.py | 2 +-
stgit/commands/common.py | 18 ++-
stgit/commands/diff.py | 6 +-
stgit/commands/edit.py | 82 +------
stgit/commands/export.py | 2 +-
stgit/commands/files.py | 6 +-
stgit/commands/float.py | 2 +-
stgit/commands/fold.py | 2 +-
stgit/commands/goto.py | 3 +-
stgit/commands/hide.py | 2 +-
stgit/commands/id.py | 2 +-
stgit/commands/imprt.py | 4 +-
stgit/commands/log.py | 169 +++++----------
stgit/commands/mail.py | 8 +-
stgit/commands/new.py | 3 +-
stgit/commands/patches.py | 2 +-
stgit/commands/pick.py | 2 +-
stgit/commands/pop.py | 4 +-
stgit/commands/pull.py | 2 +-
stgit/commands/push.py | 31 +--
stgit/commands/rebase.py | 4 +-
stgit/commands/redo.py | 52 ++++
stgit/commands/refresh.py | 338 ++++++++++++++++++---------
stgit/commands/rename.py | 2 +-
stgit/commands/repair.py | 11 +-
stgit/commands/reset.py | 57 +++++
stgit/commands/resolved.py | 2 +-
stgit/commands/show.py | 2 +-
stgit/commands/sink.py | 2 +-
stgit/commands/status.py | 3 +-
stgit/commands/sync.py | 26 +--
stgit/commands/undo.py | 49 ++++
stgit/commands/unhide.py | 2 +-
stgit/git.py | 4 -
stgit/lib/edit.py | 99 ++++++++
stgit/lib/git.py | 74 ++++++-
stgit/lib/log.py | 524 ++++++++++++++++++++++++++++++++++++++++++
stgit/lib/stack.py | 25 ++
stgit/lib/transaction.py | 125 +++++++----
stgit/main.py | 8 +
stgit/stack.py | 45 +----
stgit/utils.py | 18 +-
t/t1200-push-modified.sh | 2 +-
t/t1201-pull-trailing.sh | 2 +-
t/t1202-push-undo.sh | 8 +-
t/t1400-patch-history.sh | 103 --------
t/t2300-refresh-subdir.sh | 29 +++-
t/t2701-refresh-p.sh | 2 +-
t/t3100-reset.sh | 160 +++++++++++++
t/t3101-reset-hard.sh | 56 +++++
t/t3102-undo.sh | 86 +++++++
t/t3103-undo-hard.sh | 56 +++++
t/t3104-redo.sh | 122 ++++++++++
t/t3105-undo-external-mod.sh | 68 ++++++
t/t3300-edit.sh | 4 +-
59 files changed, 1936 insertions(+), 613 deletions(-)
create mode 100644 stgit/commands/redo.py
create mode 100644 stgit/commands/reset.py
create mode 100644 stgit/commands/undo.py
create mode 100644 stgit/lib/edit.py
create mode 100644 stgit/lib/log.py
delete mode 100755 t/t1400-patch-history.sh
create mode 100755 t/t3100-reset.sh
create mode 100755 t/t3101-reset-hard.sh
create mode 100755 t/t3102-undo.sh
create mode 100755 t/t3103-undo-hard.sh
create mode 100755 t/t3104-redo.sh
create mode 100755 t/t3105-undo-external-mod.sh
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH] Build configuration to skip ctime for modification test
From: Linus Torvalds @ 2008-07-25 2:00 UTC (permalink / raw)
To: Alex Riesen; +Cc: Johannes Schindelin, Junio C Hamano, Johannes Sixt, git
In-Reply-To: <20080723191647.GF5283@blimp.local>
On Wed, 23 Jul 2008, Alex Riesen wrote:
>
> It is not that it is broken. We just don't need it, because the st_mode
> is not used, and the rest of inode information is not used anyway.
That is NOT why git checks the ctime.
Git checks the ctime not because it cares about the inode state being
modified per se: since it can see that _directly_ - so why should it care
about inode state like st_mode?
No, git checks ctime because it in general tries to make it VERY VERY hard
for people to try to "fake out" git and replace files from underneath it
without git noticing.
It's much easier and much more common for tools to restore 'mtime' when
they do some operation on a file than it is for them to restore 'ctime'.
For example, if you rsync files between two hosts, the '-t' flag will make
rsync try to keep the mtimes in sync (and it's part of '-a', which is the
common form that you'd use for rsync). So if you only look at mtime and
size, you often miss the fact that the file has actually been messed with!
Looking at ctime gets around a number of those things. Of course, it can
cause git to be _too_ eager in thinking that a file is modified, and an
example of that is the insane indexing that 'beagle' does, which actually
modifies the files by adding inode extended attributes to them and thus
changes ctime due to the indexing. But in general it's a lot better to be
too careful than to miss the fact that somebody changed the file.
Linus
^ permalink raw reply
* Re: Stitching together two split segments from svn
From: Liam Healy @ 2008-07-25 2:41 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3ljzqvo6i.fsf@localhost.localdomain>
Jakub,
Thanks for the advice -- this did exactly what I wanted.
For anyone else wanting to do this: one thing that threw me for a
while was that .git/info/grafts does not accept an abbreviated SHA,
the full 40 hex digits is needed. I would see "bad graft data" from
gitk with no other explanation. There is very little documentation
that I could find on the grafts file; the best I could find was in the
man page for git-filter branch,
http://www.kernel.org/pub/software/scm/git/docs/git-filter-branch.html.
Liam
On Thu, Jul 24, 2008 at 7:48 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> "Liam Healy" <lnp@healy.washington.dc.us> writes:
>
>> I have a project whose history is stored in two separate svn
>> repositories. The first repository I kept privately during initial
>> development, the second started when I posted it publicly and does not
>> have the history of the first. I am trying to reunite them under git.
>> The development of the first was linear, so after using git svn, the
>> history looks like:
>>
>> a - b - ... - c - d = HEAD (old repository)
>>
>> and the second has one branch "ffa":
>>
>> (new repository)
>> T - d - e - ... - f - g - h - ... - j master
>> \
>> k - l - .... - m ffa
>>
>> Note that T is the "trunk" initial commit on the svn repo that has no
>> files. The second commit d is identical to the HEAD of old, as
>> verified by git diff.
>> However, when I remote add these two into a single repository, they
>> show up as two detached chains, with no connection between them. I
>> thought git rebase would reconnect them. However, when I do that on
>> each branch (master and ffa), I get the following:
>>
>> a - b - ... - c - d - e - ... - f - g - h - ... - j master
>> \
>> e - ... -f - g - k - l - .... - m ffa
>>
>> instead of what I would like
>>
>> a - b - ... - c - d - e - ... - f - g - h - ... - j master
>> \
>> k - l - .... - m ffa
>>
>> That is to say, those commits from the new repository that have a
>> common history for the two branches are duplicated. The commits are
>> listed separately and have different SHA IDs, but they are clearly the
>> same commits (same comments, same svn version number). Is there any
>> way to do what I want? Really, all I want to do is change the parent
>> of "e" to be the HEAD of the old repository.
>
> If this is initial import, and not published anywhere, the simplest (I
> think) solution would be to use grafts file (.git/info/grafts) to
> change parent of 'k' from 'g' in ffa to 'g' in master, by adding the
> line with:
>
> <sha1 of 'k'> <sha1 of 'g' on master>
>
> to .git/info/grafts. Then examine history if everything is now all
> right (for example using gitk), and if everything is O.K. run
> git-filter-branch.
>
> See documentation for details.
>
> --
> Jakub Narebski
> Poland
> ShadeHawk on #git
>
^ 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