* [PATCH] More useful/hinting error messages in git-checkout
From: Josef Weidendorfer @ 2006-02-15 19:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3bilr2zr.fsf@assigned-by-dhcp.cox.net>
Signed-off-by: Josef Weidendorfer <Josef.Weidendorfer@gmx.de>
---
On Tuesday 14 February 2006 23:26, you wrote:
>
> $ git checkout -b test v2.6.10
>
> The user wanted to create a new branch test based on tag
> v2.6.10, alas that tag does not exist. We give quite confusing
> error message because we are confused that the user meant to
> checkout only "./v2.6.10" file and that operation and switching
> branches are incompatible.
Does this patch clarify the error condition?
Josef
git-checkout.sh | 13 ++++++++++---
1 files changed, 10 insertions(+), 3 deletions(-)
d15e024c0bd07a2f0dad6e2729e2681df374c8e6
diff --git a/git-checkout.sh b/git-checkout.sh
index 6a87c71..b7d892d 100755
--- a/git-checkout.sh
+++ b/git-checkout.sh
@@ -22,7 +22,7 @@ while [ "$#" != "0" ]; do
[ -e "$GIT_DIR/refs/heads/$newbranch" ] &&
die "git checkout: branch $newbranch already exists"
git-check-ref-format "heads/$newbranch" ||
- die "we do not like '$newbranch' as a branch name."
+ die "git checkout: we do not like '$newbranch' as a branch name."
;;
"-f")
force=1
@@ -75,9 +75,15 @@ done
if test "$#" -ge 1
then
+ hint=
+ if test "$#" -eq 1
+ then
+ hint="
+Did you intend to checkout '$@' which can not be resolved as commit?"
+ fi
if test '' != "$newbranch$force$merge"
then
- die "updating paths and switching branches or forcing are incompatible."
+ die "git checkout: updating paths is incompatible with switching branches/forcing$hint"
fi
if test '' != "$new"
then
@@ -117,7 +123,8 @@ fi
[ -z "$branch$newbranch" ] &&
[ "$new" != "$old" ] &&
- die "git checkout: you need to specify a new branch name"
+ die "git checkout: to checkout the requested commit you need to specify
+ a name for a new branch which is created and switched to"
if [ "$force" ]
then
--
1.2.0.g719b
^ permalink raw reply related
* Re: [ANNOUNCE] pg - A patch porcelain for GIT
From: Shawn Pearce @ 2006-02-15 17:55 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0602150912h55fb87d0r@mail.gmail.com>
Catalin Marinas <catalin.marinas@gmail.com> wrote:
> > pg resolves this by attempting to automatically fold patches during
> > a pg-rebase (equiv. of stg pull). If a patch fails to push cleanly
> > and there's another patch immediately behind it which also should
> > be reapplied pg aborts and retries pushing the combination of the
> > patches. This fixes my A+B case quite nicely during a rebase. :-)
>
> But what would happen if there was a third-party patch that's
> modifying the same line? A+B application would fail in this case. Does
> pg go back to only apply A and report a conflict?
When this occurs pg just gives up and leaves both patches A and
B unapplied and gives you the list of patches which it couldn't
apply but wanted to. The working directory is left clean; its the
new base plus whatever patches before A that did apply cleanly.
I could have pg go back and try pushing A again and leave the
conflict ready for you to resolve but I don't always want that.
Since the user can have that happen with a quick no-arg `pg-push`
I leave it to the user to retry pushing A if they really think
that's worth trying.
However if the last patch fails to push during a pg-rebase then pg
leaves it alone and your working directory is dirty and you are left
with that last patch partially applied. At which point you can back
it out by popping it off the stack or finish the conflict resolution.
> There is another problem with this approach if you have tens of
> patches. Would pg try to fold all of them?
Yea. Which might not be pretty. 10 patches would cause pg to
attempt applying 11 patches before giving up, but each time the patch
is increased in size to include its predecessors who also didn't
apply cleanly. As soon as a larger cluster applies pg goes back to
trying single patch application. Obviously this could take a while
as the patch size is growing on each attempt and we are duplicating
work every time as pg always starts from a clean working directory.
Example: Say I have A, B, C, D, E, F on the stack. A wasn't provided
by the upstream and pushes down cleanly. B+C+D was given to me
by the upstream so pg first tries B, fails, then B+C, fails, then
B+C+D, succeeds, so it folds B+C+D into D and finishes pushing D.
Then it tries E, if E succeeds it tries F on its own. If E fails it
tries E+F. What's left in the working directory depends on if the
last operation was an auto-fold attempt or not and if it applied
cleanly (or not).
> Some time ago I had a look at Darcs and its patch theory (patch
> commuting). Their approach to conflicts was to include the conflicts
> in patch A and propagate them to the last patch to be merged. It's
> like creating two versions of the conflicting hunk, one of them
> corresponding to the local tree (that in patch A) and the other to the
> upstream tree. Merging patch B is only done in the local hunk in the
> end both conflicting hunks would be identical and one of them removed.
>
> While the above algrithm seems to work OK in Darcs (but quite resource
> intensive), it's pretty hard to implement and I don't think it's worth
> for a small number of cases this could occur.
Hmm. I had looked at Darcs over a year ago and found it to be a
rather interesting idea but at the time it couldn't handle my ~7000
file tree (and GIT wasn't even getting started yet). I was actually
thinking about trying to drag the rejecting hunks forward somehow
when doing the auto-folding but I hadn't quite found a way to do
that easily. I have a gut feeling that most of the time when this
problem occurs its on a subset of the files involved in any given
patch and that if I can push down a patch cleanly for 90+% of the
files while delaying the conflicts forward that might actually be
somewhat reasonable. But maybe not. :-)
--
Shawn.
^ permalink raw reply
* Re: [ANNOUNCE] pg - A patch porcelain for GIT
From: Catalin Marinas @ 2006-02-15 17:25 UTC (permalink / raw)
To: Petr Baudis; +Cc: Chuck Lever, Karl Hasselström, git
In-Reply-To: <20060214222913.GK31278@pasky.or.cz>
On 14/02/06, Petr Baudis <pasky@suse.cz> wrote:
> Dear diary, on Tue, Feb 14, 2006 at 09:58:02PM CET, I got a letter
> where Chuck Lever <cel@citi.umich.edu> said that...
> > my impression of git is that you don't change stuff that's already
> > committed. you revert changes by applying a new commit that backs out
> > the original changes. i'm speculating, but i suspect that's why there's
> > a "stg pick --reverse" and not a "stg uncommit."
>
> It is ok as long as you know what are you doing - if you don't push out
> the commits you've just "undid" (or work on a public accessible
> repository in the first place, but I think that's kind of rare these
> days; quick survey - does anyone reading these lines do that?), there's
> nothing wrong on it, and it gives you nice flexibility.
>
> For example, to import bunch of patches (I guess that's the original
> intention behind this) you just run git-am on them and then stg uncommit
> all of the newly added commits.
This is a sensible way of using an uncommit command but I initially
thought it would be better to make things harder for people wanting to
re-write the history. Anyway, I'll keep this command on my todo list.
--
Catalin
^ permalink raw reply
* Re: [ANNOUNCE] pg - A patch porcelain for GIT
From: Catalin Marinas @ 2006-02-15 17:20 UTC (permalink / raw)
To: git
In-Reply-To: <20060214061406.GA13238@spearce.org>
On 14/02/06, Shawn Pearce <spearce@spearce.org> wrote:
> The diff-tree/apply approach is faster for a single commit then
> read-tree -u -m is; even if totally different files are being
> impacted and thus all stages collapse neatly to stage 0 in the index.
> No wonder StGIT uses diff/apply!
For the simple tests you did the difference is not that big. It
becomes a real problem when there are many file deletions/additions in
the upstream tree since git-read-tree doesn't handle them and
git-merge-index would need to call the external tool for each of them.
To test the above, clone the 2.6.12 kernel version, create some
trivial patches and rebase to 2.6.16-rc3. StGIT was running even for 5
minutes per patch before implementing the diff-tree/apply method.
--
Catalin
^ permalink raw reply
* Re: Handling large files with GIT
From: Linus Torvalds @ 2006-02-15 17:16 UTC (permalink / raw)
To: Junio C Hamano, Ben Clifford; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0602150715470.3691@g5.osdl.org>
Btw, some actual numbers: I did the recent kernel networking merge (which
is a trivial in-index merge) with the standard three-way
git-read-tree -m <base> <branch> <branch>
and with the new git-merge-tree to compare performance.
Doing git-read-tree takes ~0.35s, while git-merge-tree took 0.015s.
Now, that's not a really fair comparison, because the end result is very
different: the git-read-tree has populated the index, ready for a
git-writet-ree, while the git-merge-tree has not.
However, the interesting part is that especially for a trivial merge, we
don't actually _want_ to necessarily populate the index, because doing a
"git-write-tree" is actually a pretty expensive operation (on the kernel,
it will try to write 1000+ directory trees, most of which already exist.
Admittedly we don't actually have to write the objects, since we figure
out that they already exist, but we have to do the SHA1 calculations to
do so).
So if we made the git-merge-tree based merge work entirely on trees all
the way, and never even necessarily populate the index at all (unless it
has to, due to actual data conflicts that want to be fixed up), that would
actually be another performance advantage. The only downside there is that
we would literally have to write the resulting tree objects by hand (ie
we'd need a new helper for doing that, and another thing to validate).
Anyway, that should almost certainly make it possible to scale up git
merges to hundreds of thousands of files without huge performance problems
(still, that depends a bit on layout - again, flat directory structures
won't scale as well, so it might not be enough for maildir handling).
But just at a guess, I think there's at least an order of magnitude to be
had there. So if a maildir merge currently takes an hour, at least we
should be able to get it down to a few minutes.
Ben, are you interested in trying this out in your maildir experiments?
Linus
^ permalink raw reply
* Re: [ANNOUNCE] pg - A patch porcelain for GIT
From: Catalin Marinas @ 2006-02-15 17:12 UTC (permalink / raw)
To: git
In-Reply-To: <20060214045618.GA12844@spearce.org>
On 14/02/06, Shawn Pearce <spearce@spearce.org> wrote:
> Catalin Marinas <catalin.marinas@arm.com> wrote:
> > > - Automatic detection (and cancellation) of returning patches.
[...]
> > StGIT has been doing this from the beginning. You would need to run a
> > 'stg clean' after a rebase (or push). I prefer to run this command
> > manually so that 'stg series -e' would show the empty patches and let
> > me decided what to do with them.
>
> Actually StGIT didn't do this correctly for one of my use cases
> and that's one of the things that drove me to trying to write pg
> (because I wondered if there was a way to resolve it automatically).
> Try building a patch series such as:
[...]
> StGIT seemed to not handle this when it tried to reapply the two
> already applied patches. A won't apply because the file coming
> down is actually A+B, not A's predecessor and not A. B won't apply
> because the file also isn't A (B's predecessor).
You are right, if two patches modify the same line and both were
merged upstream, the three-way merging would report a conflict for the
first patch and maybe the second (depending on how the first conflict
was resolved).
> pg resolves this by attempting to automatically fold patches during
> a pg-rebase (equiv. of stg pull). If a patch fails to push cleanly
> and there's another patch immediately behind it which also should
> be reapplied pg aborts and retries pushing the combination of the
> patches. This fixes my A+B case quite nicely during a rebase. :-)
But what would happen if there was a third-party patch that's
modifying the same line? A+B application would fail in this case. Does
pg go back to only apply A and report a conflict?
There is another problem with this approach if you have tens of
patches. Would pg try to fold all of them?
Some time ago I had a look at Darcs and its patch theory (patch
commuting). Their approach to conflicts was to include the conflicts
in patch A and propagate them to the last patch to be merged. It's
like creating two versions of the conflicting hunk, one of them
corresponding to the local tree (that in patch A) and the other to the
upstream tree. Merging patch B is only done in the local hunk in the
end both conflicting hunks would be identical and one of them removed.
While the above algrithm seems to work OK in Darcs (but quite resource
intensive), it's pretty hard to implement and I don't think it's worth
for a small number of cases this could occur.
--
Catalin
^ permalink raw reply
* Re: [FYI] pack idx format
From: Nicolas Pitre @ 2006-02-15 16:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd5hpm2x0.fsf@assigned-by-dhcp.cox.net>
On Wed, 15 Feb 2006, Junio C Hamano wrote:
> This is still WIP but if anybody is interested... Once done, it
> should become Documentation/technical/pack-format.txt.
>
[...]
>
> Pack file entry: <+
>
> packed object header:
> 1-byte type (upper 4-bit)
Actually the type occupies only 3 bits (bits 4 to 6) as bit 7 is the
size continuation bit.
Nicolas
^ permalink raw reply
* Re: Handling large files with GIT
From: Linus Torvalds @ 2006-02-15 15:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Fredrik Kuivinen, Git Mailing List
In-Reply-To: <7vd5hpj6ab.fsf@assigned-by-dhcp.cox.net>
On Wed, 15 Feb 2006, Junio C Hamano wrote:
>
> I was thinking about implementing mergers as a pipeline:
>
> git-merge-tree O A B |
> git-merge-renaming A |
> git-merge-aggressive A |
> git-merge-filemerge
Great minds think alike.
> git-merge-tree (yours) does not do trivial collapsing, and
> produce raw-diff from A.
(It does _truly_ trivial collapsing, but I think we both agree: it doesn't
do anything that we used to go git-merge-one-file on)
> git-merge-renaming reads it, finds
> copied/renamed entries (maybe reusing parts of diffcore), and
> writes out the results in the same format as merge-tree output
I was considering perhaps doing a first cut at that in git-merge-tree
already. Not sure.
One issue is that I think I may have to change the output format if I do
that. I should anyway.
Why?
It's hard to see where "one event" stops, and another starts. I stupidly
initially thought that you can do it entirely based on looking at the
numbers, but you can't. Right now you have to look at the pathname too,
which is kind of sad, and doesn't work after rename detection (since then
the pathnames won't be sorted any more, and one "event" can have different
pathnames in different stages).
[ Side note: it doesn't even work for file/directory conflicts, which can
have the same name, but are two different "events". So you'd actually
have to look at both mode _and_ filename to sort out if two lines that
start with "1" and "3" respectively are one event (removal in first
branch) or two events ("1" on one file: removal in both branches + "3"
on another file: add in second branch) ]
So to do the rename output, you can't use the same format as merge-tree
uses right _now_. We'd have to add a marker to mark what the event
boundaries are.
The "mark" could be a running "event number", or even as easy as an
alternating character ("#" vs " " as the second character in the line or
similar)
So instead of
2 100644 ff280e2e1613e808e4d7844376134dfa2bb1fc21 Documentation/cputopology.txt
2 100644 28c5b7d1eb90f0ccd8e0307c170f89bd7954dc9c Documentation/hwmon/f71805f
1 100644 b88953dfd58022aef1680c266c7438605b146fc8 Documentation/i2c/busses/i2c-sis69x
3 100644 b88953dfd58022aef1680c266c7438605b146fc8 Documentation/i2c/busses/i2c-sis69x
2 100644 00a009b977e92b1a942d1138afdccf1b725df956 Documentation/i2c/busses/i2c-sis96x
2 100644 90a5e9e5bef1daa9d0f0621e209827f0d180f384 Documentation/unshare.txt
2 100644 5127f39fa9bf9a384a6529c6d5deb1002e945de5 arch/arm/mach-s3c2410/s3c2400-gpio.c
2 100644 8b2394e1ed4088c3b8d38e87e58bde2f38152bf7 arch/arm/mach-s3c2410/s3c2400.h
...
it migth be
2#100644 ff280e2e1613e808e4d7844376134dfa2bb1fc21 Documentation/cputopology.txt
2 100644 28c5b7d1eb90f0ccd8e0307c170f89bd7954dc9c Documentation/hwmon/f71805f
1#100644 b88953dfd58022aef1680c266c7438605b146fc8 Documentation/i2c/busses/i2c-sis69x
3#100644 b88953dfd58022aef1680c266c7438605b146fc8 Documentation/i2c/busses/i2c-sis69x
2 100644 00a009b977e92b1a942d1138afdccf1b725df956 Documentation/i2c/busses/i2c-sis96x
2#100644 90a5e9e5bef1daa9d0f0621e209827f0d180f384 Documentation/unshare.txt
2 100644 5127f39fa9bf9a384a6529c6d5deb1002e945de5 arch/arm/mach-s3c2410/s3c2400-gpio.c
2#100644 8b2394e1ed4088c3b8d38e87e58bde2f38152bf7 arch/arm/mach-s3c2410/s3c2400.h
...
where you can clearly see the "grouping" without having to even look at
the filename.
(The example I show actually has a rename-with-modifications that was made
on the first branch: notice that i2c-sis69x vs i2c-sis96x thing?)
I don't know exactly what the "after rename detection" output format would
be, but it _might_ turn that
...
1#b889... i2c-sis69x
3#b889... i2c-sis69x
2 00a0... i2c-sis96x
...
into one event:
...
1#b889... i2c-sis69x
2#00a0... i2c-sis96x
3#b889... i2c-sis69x
...
and then the actual file-merge logic would have to merge the names as well
as the file contents (and in this case, the final name would thus be
"i2c-sis96x", since one branch hadn't changed it).
Hmm?
Linus
^ permalink raw reply
* Re: Shared repositories and umask
From: Martin Mares @ 2006-02-15 14:06 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060215130538.GO31278@pasky.or.cz>
> Therefore, it shouldn't be actually necessary to meddle with umask
> anymore. The documentation is obsolete; I'll remove the relevant bits
> from Cogito docs.
Thanks for the hint!
Have a nice fortnight
--
Martin `MJ' Mares <mj@ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
First law of socio-genetics: Celibacy is not hereditary.
^ permalink raw reply
* Re: Shared repositories and umask
From: Petr Baudis @ 2006-02-15 13:59 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Martin Mares, git
In-Reply-To: <Pine.LNX.4.63.0602151448590.10593@wbgn013.biozentrum.uni-wuerzburg.de>
Hi,
Dear diary, on Wed, Feb 15, 2006 at 02:51:50PM CET, I got a letter
where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> On Wed, 15 Feb 2006, Petr Baudis wrote:
> > Therefore, it shouldn't be actually necessary to meddle with umask
> > anymore. The documentation is obsolete; I'll remove the relevant bits
> > from Cogito docs.
>
> Basically, if you just want a shared repository, you don't need to set the
> umask. However, if you want to work in the working directory (multiple
> users), you have to set the umask (it is not enough that the git tools do
> that, because you are likely to work with other programs as well).
yes, but that's kind of rare workflow - I guess mostly when you have
your website in GIT and update the working copy in the post-update hook
- but then you can easily setup umask in the hook as well.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply
* Re: Shared repositories and umask
From: Johannes Schindelin @ 2006-02-15 13:51 UTC (permalink / raw)
To: Petr Baudis; +Cc: Martin Mares, git
In-Reply-To: <20060215130538.GO31278@pasky.or.cz>
Hi,
On Wed, 15 Feb 2006, Petr Baudis wrote:
> Dear diary, on Wed, Feb 15, 2006 at 01:19:07PM CET, I got a letter
> where Martin Mares <mj@ucw.cz> said that...
> > I'm playing with a shared repository and I am still unable to get the
> > file and directory permissions kept correctly, that is writeable to
> > a group.
> >
> > Setting the `core.sharedrepository' flag helps a bit, but not completely:
> > the object files and directories are group-writeable, but for example new
> > head refs aren't.
>
> actually, this is not necessary, since when pushing to shared
> repositories, the new ref is created in the directory as a lockfile and
> then moved over the original ref - this makes the ref updating safe and
> raceless, while also making it enough to have the refs directory
> group-writable.
IIRC the relevant discussion was started by this:
http://thread.gmane.org/gmane.comp.version-control.git/13856
> Therefore, it shouldn't be actually necessary to meddle with umask
> anymore. The documentation is obsolete; I'll remove the relevant bits
> from Cogito docs.
Basically, if you just want a shared repository, you don't need to set the
umask. However, if you want to work in the working directory (multiple
users), you have to set the umask (it is not enough that the git tools do
that, because you are likely to work with other programs as well).
Hth,
Dscho
^ permalink raw reply
* Re: Shared repositories and umask
From: Petr Baudis @ 2006-02-15 13:05 UTC (permalink / raw)
To: Martin Mares; +Cc: git
In-Reply-To: <mj+md-20060215.120104.14337.atrey@ucw.cz>
Hi,
Dear diary, on Wed, Feb 15, 2006 at 01:19:07PM CET, I got a letter
where Martin Mares <mj@ucw.cz> said that...
> I'm playing with a shared repository and I am still unable to get the
> file and directory permissions kept correctly, that is writeable to
> a group.
>
> Setting the `core.sharedrepository' flag helps a bit, but not completely:
> the object files and directories are group-writeable, but for example new
> head refs aren't.
actually, this is not necessary, since when pushing to shared
repositories, the new ref is created in the directory as a lockfile and
then moved over the original ref - this makes the ref updating safe and
raceless, while also making it enough to have the refs directory
group-writable.
Therefore, it shouldn't be actually necessary to meddle with umask
anymore. The documentation is obsolete; I'll remove the relevant bits
from Cogito docs.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply
* Shared repositories and umask
From: Martin Mares @ 2006-02-15 12:19 UTC (permalink / raw)
To: git
Hello, world!\n
I'm playing with a shared repository and I am still unable to get the
file and directory permissions kept correctly, that is writeable to
a group.
Setting the `core.sharedrepository' flag helps a bit, but not completely:
the object files and directories are group-writeable, but for example new
head refs aren't.
The documentation hints on setting umask, but I would really like to avoid
doing that globally, because the user accounts are used for many other
things as well where the permissions should be tighter.
It seems that a correct solution would be to add an `umask' option to
the repository config and make enter_repo() adjust the umask accordingly.
I was thinking about doing the same in setup_git_directory() for the
local commands, but that probably doesn't make much sense since many commands
are in fact scripts creating files themselves.
If you agree, I will send a patch.
Have a nice fortnight
--
Martin `MJ' Mares <mj@ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
Q: How many Prolog programmers does it take to change a light bulb? A: No.
^ permalink raw reply
* Re: Use case: GIT to manage transactions in a CMS?
From: Andreas Ericsson @ 2006-02-15 11:45 UTC (permalink / raw)
To: "J. David Ibáñez"; +Cc: git
In-Reply-To: <43F30602.500@itaapy.com>
J. David Ibáñez wrote:
> Hello,
>
> I am working on a project (a content management system) where the data
> is stored as files and folders.
>
> Currently, for persistance and transactions we use the ZODB [1] object
> database. But our goal is to move away from the ZODB and use directly
> the file system, as it will allow us to use all the good unix tools.
>
> We are using git to manage the source code. And now we are exploring git
> to see if it can do the job of transactions, so that each transaction in
> the system will be a git commit.
>
> One problem we have found is that we can not commit empty directories (what
> we need to do). Any idea how to solve or work-around this constraint?
>
$ touch empty/dir/.placeholder
> Any suggestions and input on this exotic use case for git will be very
> welcomed.
>
Sounds cool. I'll have to give it a whirl when you've got something to show.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* [PATCH] Print an error if cloning a http repo and NO_CURL is set
From: Fernando J. Pereda @ 2006-02-15 11:37 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
If Git is compiled with NO_CURL=YesPlease and one tries to
clone a http repository, git-clone tries to call the curl
binary. This trivial patch prints an error instead in such
situation.
Signed-off-by: Fernando J. Pereda <ferdy@gentoo.org>
---
Makefile | 1 +
git-clone.sh | 8 +++++++-
2 files changed, 8 insertions(+), 1 deletions(-)
896d96a92a13848ccce19c2f3dee9b5570ef02a7
diff --git a/Makefile b/Makefile
index d40aa6a..648469e 100644
--- a/Makefile
+++ b/Makefile
@@ -419,6 +419,7 @@ $(patsubst %.sh,%,$(SCRIPT_SH)) : % : %.
rm -f $@
sed -e '1s|#!.*/sh|#!$(call shq,$(SHELL_PATH))|' \
-e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
+ -e 's/@@NO_CURL@@/$(NO_CURL)/g' \
$@.sh >$@
chmod +x $@
diff --git a/git-clone.sh b/git-clone.sh
index 47f3ec9..e192b08 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -206,7 +206,13 @@ yes,yes)
fi
;;
http://*)
- clone_dumb_http "$repo" "$D"
+ if test -z "@@NO_CURL@@"
+ then
+ clone_dumb_http "$repo" "$D"
+ else
+ echo >&2 "http transport not supported, rebuild Git with curl support"
+ exit 1
+ fi
;;
*)
cd "$D" && case "$upload_pack" in
--
1.2.0
^ permalink raw reply related
* Re: [ANNOUNCE] pg - A patch porcelain for GIT
From: Karl Hasselström @ 2006-02-15 11:27 UTC (permalink / raw)
To: git
In-Reply-To: <20060215112502.GC26911@diana.vm.bytemark.co.uk>
On 2006-02-15 12:25:02 +0100, Karl Hasselström wrote:
> However, using git-cherry-pick in this scenario would just recreate
> the initial state exactly, since converting the commits to stgit
> patches was what it was all about.
"since" -> "and"
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [ANNOUNCE] pg - A patch porcelain for GIT
From: Karl Hasselström @ 2006-02-15 11:25 UTC (permalink / raw)
To: git
In-Reply-To: <43F305AF.70808@op5.se>
On 2006-02-15 11:42:55 +0100, Andreas Ericsson wrote:
> Karl Hasselström wrote:
>
> > You can actually do this today; just create a new branch where you
> > want your new stgit stack to be based, and "stg pick" the
> > commits/patches from the old branch:
> >
> > $ git-checkout -b new-branch HEAD^^^
> > $ stg init
> > $ stg pick old-branch^^^ -n create-foo
> > $ stg pick old-branch^^ -n improve-foo
> > $ stg pick old-branch^ -n improve-bar
> > $ git-branch -D old-branch
> > $ git-checkout -b old-branch
> > $ git-branch -d new-branch
> >
> > This series of commands also converts the top three commits to
> > stgit patches, and leaves the user on the same branch where she
> > started (it does _exactly_ the same job as "stg uncommit
> > improve-bar improve-foo create-foo"), but it's a lot of work, and
> > a typo could lose commits.
>
> Isn't this akin to what "git cherry-pick" does, except for the
> "convert to stgit patches" thing?
Yes, "stg pick" and git-cherry-pick are very similar as far as I know,
the only difference being that "stg pick" creates an stgit patch while
git-cherry-pick creates a regular commit. (And an applied stgit patch
is just a regular commit which stgit maintains some metadata about.)
However, using git-cherry-pick in this scenario would just recreate
the initial state exactly, since converting the commits to stgit
patches was what it was all about.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [FYI] pack idx format
From: Johannes Schindelin @ 2006-02-15 11:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd5hpm2x0.fsf@assigned-by-dhcp.cox.net>
Hi,
On Wed, 15 Feb 2006, Junio C Hamano wrote:
> [...]
>
> Before this main table, at the beginning of the idx file, there
> is a table of 256 4-byte network byte order integers. This is
> called "first-level fan-out". N-th entry of this table records
> the offset into the main index for the first object whose object
> name SHA1 starts with N+1. fanout[255] points at the end of
> main index. The offset is expressed in 24-bytes unit.
The description of the n-th entry is not completely correct. How about
something like this:
The fan-out table is sort of an index to the main table: It contains
offsets into the main table, and all SHA1s starting with byte b are
between fanout[b-1] .. fanout[b]-1 (or if b==0 between 0 .. fanout[0]-1).
Comments?
Ciao,
Dscho
^ permalink raw reply
* Use case: GIT to manage transactions in a CMS?
From: "J. David Ibáñez" @ 2006-02-15 10:44 UTC (permalink / raw)
To: git
Hello,
I am working on a project (a content management system) where the data
is stored as files and folders.
Currently, for persistance and transactions we use the ZODB [1] object
database. But our goal is to move away from the ZODB and use directly
the file system, as it will allow us to use all the good unix tools.
We are using git to manage the source code. And now we are exploring git
to see if it can do the job of transactions, so that each transaction in
the system will be a git commit.
One problem we have found is that we can not commit empty directories (what
we need to do). Any idea how to solve or work-around this constraint?
Any suggestions and input on this exotic use case for git will be very
welcomed.
[1] http://www.zope.org/Wikis/ZODB/FrontPage
--
J. David Ibáñez
Itaapy <http://www.itaapy.com> Tel +33 (0)1 42 23 67 45
9 rue Darwin, 75018 Paris Fax +33 (0)1 53 28 27 88
^ permalink raw reply
* Re: [PATCH] Detect misspelled pathspec to git-add
From: Johannes Schindelin @ 2006-02-15 10:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1wy5m19t.fsf@assigned-by-dhcp.cox.net>
Hi,
On Wed, 15 Feb 2006, Junio C Hamano wrote:
> Comments?
I like it.
Ciao,
Dscho
^ permalink raw reply
* Re: [ANNOUNCE] pg - A patch porcelain for GIT
From: Andreas Ericsson @ 2006-02-15 10:42 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20060215101136.GB26911@diana.vm.bytemark.co.uk>
Karl Hasselström wrote:
> On 2006-02-14 15:58:02 -0500, Chuck Lever wrote:
>
>
>>Karl Hasselström wrote:
>>
>>
>>>No, I literally want the opposite of "stg commit", so that the
>>>sequence "stg commit; stg uncommit" has zero net effect.
>>
>>well, that would work OK for maintainers, but would be kind of
>>strange for folks who are pulling from such a repository. how would
>>that work?
>
>
> I didn't plan to publish branches where this kind of history munging
> was being done. It's precisely like "git rebase" in that regard --
> it's a tool for cleaning up history before it is published.
>
>
>>my impression of git is that you don't change stuff that's already
>>committed. you revert changes by applying a new commit that backs
>>out the original changes.
>
>
> You don't change stuff that's already committed _and published_ (well,
> except for pu branches :-). Rewriting history is perfectly OK up until
> the moment someone has pulled your branch.
>
>
>>i'm speculating, but i suspect that's why there's a "stg pick
>>--reverse" and not a "stg uncommit."
>
>
> I don't think I've been very successful in communicating exactly what
> I want "stg uncommit" for. It's not that I want to undo a committed
> change -- what I want is to transform it into an stgit patch so that I
> can edit it with a minimum of effort.
>
> $ edit edit edit
> $ git-commit -a -m "create foo"
> $ edit edit edit
> $ git-commit -a -m "improve foo"
> $ edit edit edit
> $ git-commit -a -m "improve bar"
>
> # Oops, I realize that the "create foo" changeset had a debug
> # printout left in it, and I wasn't already using stgit.
>
> $ stg init
> $ stg uncommit improve-bar improve-foo create-foo
> $ stg stg pop --to=create-foo
> $ edit --remove=debug-printout
> $ stg refresh
> $ stg push --all
>
The same workflow, with less hassle (and already implemented)
$ git format-patch -k HEAD~3
$ edit 0001-*
$ git am -k 000*
> Similar use-cases for e.g. reordering commits, merging commits,
> deleting one commit in the middle of a chain of good ones, etc. are
> easy to come up with. The point is that stgit alreay handles all this,
> _but only if you have been using stgit from the start_. What "stg
> uncommit" does is basically to import (linear) git history into stgit,
> where a powerful toolset exists to edit it.
>
> You can actually do this today; just create a new branch where you
> want your new stgit stack to be based, and "stg pick" the
> commits/patches from the old branch:
>
> $ git-checkout -b new-branch HEAD^^^
> $ stg init
> $ stg pick old-branch^^^ -n create-foo
> $ stg pick old-branch^^ -n improve-foo
> $ stg pick old-branch^ -n improve-bar
> $ git-branch -D old-branch
> $ git-checkout -b old-branch
> $ git-branch -d new-branch
>
> This series of commands also converts the top three commits to stgit
> patches, and leaves the user on the same branch where she started (it
> does _exactly_ the same job as "stg uncommit improve-bar improve-foo
> create-foo"), but it's a lot of work, and a typo could lose commits.
>
Isn't this akin to what "git cherry-pick" does, except for the "convert
to stgit patches" thing?
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [ANNOUNCE] pg - A patch porcelain for GIT
From: Karl Hasselström @ 2006-02-15 10:11 UTC (permalink / raw)
To: git
In-Reply-To: <43F2445A.6020109@citi.umich.edu>
On 2006-02-14 15:58:02 -0500, Chuck Lever wrote:
> Karl Hasselström wrote:
>
> > No, I literally want the opposite of "stg commit", so that the
> > sequence "stg commit; stg uncommit" has zero net effect.
>
> well, that would work OK for maintainers, but would be kind of
> strange for folks who are pulling from such a repository. how would
> that work?
I didn't plan to publish branches where this kind of history munging
was being done. It's precisely like "git rebase" in that regard --
it's a tool for cleaning up history before it is published.
> my impression of git is that you don't change stuff that's already
> committed. you revert changes by applying a new commit that backs
> out the original changes.
You don't change stuff that's already committed _and published_ (well,
except for pu branches :-). Rewriting history is perfectly OK up until
the moment someone has pulled your branch.
> i'm speculating, but i suspect that's why there's a "stg pick
> --reverse" and not a "stg uncommit."
I don't think I've been very successful in communicating exactly what
I want "stg uncommit" for. It's not that I want to undo a committed
change -- what I want is to transform it into an stgit patch so that I
can edit it with a minimum of effort.
$ edit edit edit
$ git-commit -a -m "create foo"
$ edit edit edit
$ git-commit -a -m "improve foo"
$ edit edit edit
$ git-commit -a -m "improve bar"
# Oops, I realize that the "create foo" changeset had a debug
# printout left in it, and I wasn't already using stgit.
$ stg init
$ stg uncommit improve-bar improve-foo create-foo
$ stg stg pop --to=create-foo
$ edit --remove=debug-printout
$ stg refresh
$ stg push --all
Similar use-cases for e.g. reordering commits, merging commits,
deleting one commit in the middle of a chain of good ones, etc. are
easy to come up with. The point is that stgit alreay handles all this,
_but only if you have been using stgit from the start_. What "stg
uncommit" does is basically to import (linear) git history into stgit,
where a powerful toolset exists to edit it.
You can actually do this today; just create a new branch where you
want your new stgit stack to be based, and "stg pick" the
commits/patches from the old branch:
$ git-checkout -b new-branch HEAD^^^
$ stg init
$ stg pick old-branch^^^ -n create-foo
$ stg pick old-branch^^ -n improve-foo
$ stg pick old-branch^ -n improve-bar
$ git-branch -D old-branch
$ git-checkout -b old-branch
$ git-branch -d new-branch
This series of commands also converts the top three commits to stgit
patches, and leaves the user on the same branch where she started (it
does _exactly_ the same job as "stg uncommit improve-bar improve-foo
create-foo"), but it's a lot of work, and a typo could lose commits.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: Handling large files with GIT
From: Junio C Hamano @ 2006-02-15 9:54 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Fredrik Kuivinen, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0602141953081.3691@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> As far as I can tell, the output from git-merge-tree with that fix to only
> simplify subdirectories that match exactly in all of base/branch1/branch2
> is precisely the output that git-merge-recursive actually wants.
The matches the recollection I had last time I mucked with the
code. Currently it is set up to do one path at a time in both
index and working tree, so it would not be a trivial rewrite,
but merge-tree based approach would speed things up quite a
bit.
I was thinking about implementing mergers as a pipeline:
git-merge-tree O A B |
git-merge-renaming A |
git-merge-aggressive A |
git-merge-filemerge
git-merge-tree (yours) does not do trivial collapsing, and
produce raw-diff from A. git-merge-renaming reads it, finds
copied/renamed entries (maybe reusing parts of diffcore), and
writes out the results in the same format as merge-tree output
(that's why I am giving A on the command line -- so it can also
read A if it wanted to. it may need to talk about what a path in
A was even when merge-tree did not say anything about that
path). Then git-merge-aggressive (bad naming, I know, it only
corresponds to the flag of the same name in read-tree) will
collapse git-merge-one-file equivalent stage collapsing. The
remainder is fed to file-level merger for postprocessing.
Everything except the last step would work on a data format that
merge-tree outputs.
^ permalink raw reply
* [RFC] So... are people happy with commit/status -v?
From: Junio C Hamano @ 2006-02-15 9:41 UTC (permalink / raw)
To: git
I usually never do commits from a subdirectory, also I rarely do
partial commits, so this is not a big issue to me, but are
people happy with the current commit/status?
Regardless of where you started, status is a preview of the next
commit with the same set of flags and arguments, so inherently
that is a whole-tree operation.
One thing that _might_ be better, however, is to shorten certain
parts of the status output when deliberately doing a partial
commit. No matter where you are, "Updated but not checked in --
will commit" section should stay whole-tree, because it is _the_
preview of the next commit. However, "Changed but not updated"
and "Untracked" section are different story.
When committing from a subdirectory with "git commit paths...",
It is likely a user forgets about paths that are changed in the
directory and forgets to list them on the command line, so the
same directory and below should be listed, but it might not be
needed to show files outside the current directory. "Untracked"
files outside the current directory are even less interesting.
Even when committing from a subdirectory with "git commit",
which is "commit the current index contents", the story is the
same. The user could have forgot to add files in the same
directory or below, but it is less likely that things outside
current directory need to draw attention to prevent mistakes.
"Untracked" outside are less interesting in this case as well.
In either partial or whole commit case, however, "Changed but
not updated" part can be argued important and should be kept
whole-tree (myself, I am slightly in favor of keeping this part
whole-tree). After all, the user has changed files in the
directory she happens to be in and outside, and reminding she
has something outstanding while previewing the next commit would
help prevent mistakes, whether that modified files are in the
current directory or outside.
So, I'm wondering. I have a feeling that we might be better of
limiting "Untracked" part to the current directory and below,
while keeping "Updated -- will commit" and "Changed but not
updated" part whole-tree. OTOH, I do not have strong need
_myself_ to change the current setup.
Comments? Opinions?
^ permalink raw reply
* Re: several quick questions
From: Junio C Hamano @ 2006-02-15 9:21 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <43F2EF09.5060603@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> The good thing about being past 1.0 in a project is that it's
> feature-complete, or close to. The bad thing is that bloat usually
> starts to happen around 1.1.
Thanks -- be kind and stop me whenever somebody else tempts me
to add excess things to the core, please. Always good to have
adult supervision ;-), eh, voice of sanity.
^ 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