* Re: Git/Mercurial interoperability (and what about bzr?)
From: Theodore Tso @ 2008-11-02 1:13 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Florian Weimer, Jakub Narebski, git
In-Reply-To: <alpine.LFD.2.00.0811011047050.3483@nehalem.linux-foundation.org>
On Sat, Nov 01, 2008 at 10:51:51AM -0700, Linus Torvalds wrote:
>
>
> On Sat, 1 Nov 2008, Theodore Tso wrote:
> >
> > .hgtags is stored as a versioned file in Mercurial. That's one of the
> > problems, and it leads to no shortage of headaches.
>
> I told people this was insane long long ago, and I thought the hg people
> had learnt to use local tags. They act sanely, as far as I know (ie they
> act the same way git tags do).
>
> Of course, the problem with hg local tags is that hg apparently has no
> sane way to _propagate_ such local tag-space information from one
> repository to another. But that's purely a problem with hg itself. I don't
> know why that hasn't gotten fixed.
Yeah, well, hg calls them _local_ tags, and so people consider that by
design, they aren't supposed to be propagated outside of the local
repository. As I recall, hg doesn't support GPG signing local tags,
for the same reason.
- Ted
^ permalink raw reply
* [RFC/PATCH 1/2] bisect: add "git bisect replace" subcommand
From: Christian Couder @ 2008-11-02 1:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This new subcommand should be used when you have a branch or a part of
a branch that isn't easily bisectable because at some point, say A, a
bug as been introduced. The bug has been fixed latter at another point,
say B, but between these points the code is not easily testable because
of the bug, so it's not easy to bisect between these points.
In this case you can create a branch starting at the parent of A, say
O, that has a fixed history. In this fixed history for example, there
could be first a commit C that is the result of squashing A and B
together and then all the commit between A and B that have been
cherry picked.
For example, let's say the commits between A and B are X1, X2, ... Xn
and they have been cherry picked after C as Y1, Y2, ... Yn:
C--Y1--Y2--...--Yn
/
...--O--A--X1--X2--...--Xn--B--...
By design, the last cherry picked commit (Yn) should point to the same
tree as commit B.
So in this case you can say:
$ git bisect replace B Yn
and commit B will be tagged with a special name like:
"bisect-replace-with-Yn"
When bisecting, commit with those tags will be grafted so that their
parents will be replaced by the commit specified in the tag.
In the example above that means that instead of the above graph, the
following graph will be bisected:
C--Y1--Y2--...--Yn
/ \
...--O B--...
This means that the bisections on this branch will be much easier
because the bug introduced by commit A and fixed by commit B will not
annoy you anymore.
---
builtin-rev-list.c | 29 ++++++++++++++++++++++++++++-
git-bisect.sh | 40 +++++++++++++++++++++++++++++++++++++++-
2 files changed, 67 insertions(+), 2 deletions(-)
Thank you Junio for your help in designing this during the GitTogether,
especially for the trick to change the parents of the commit fixing the
bug.
I know this is lacking documentation but I plan to work on it soon and
send a documentation patch. The tests (in the following patch) are also
a bit lacking, so I will improve them too.
diff --git a/builtin-rev-list.c b/builtin-rev-list.c
index 06cdeb7..5569bb2 100644
--- a/builtin-rev-list.c
+++ b/builtin-rev-list.c
@@ -529,6 +529,30 @@ static struct commit_list *do_find_bisection(struct commit_list *list,
return best_bisection_sorted(list, nr);
}
+static int bisect_replace(const char *refname, const unsigned char *sha1,
+ int flag, void *cb_data)
+{
+ struct commit_graft *graft;
+
+ if (prefixcmp(refname, "bisect-replace-with-"))
+ return 0;
+
+ /* Create a graft to replace current commit */
+
+ graft = xmalloc(sizeof(*graft) + 20);
+
+ hashcpy(graft->sha1, sha1);
+ graft->nr_parent = 1;
+ if (get_sha1_hex(refname + 20, graft->parent[0])) {
+ free(graft);
+ return 0;
+ }
+
+ register_commit_graft(graft, 1);
+
+ return 0;
+}
+
static struct commit_list *find_bisection(struct commit_list *list,
int *reaches, int *all,
int find_all)
@@ -646,8 +670,11 @@ int cmd_rev_list(int argc, const char **argv, const char *prefix)
save_commit_buffer = revs.verbose_header ||
revs.grep_filter.pattern_list;
- if (bisect_list)
+
+ if (bisect_list) {
+ for_each_tag_ref(bisect_replace, NULL);
revs.limited = 1;
+ }
if (prepare_revision_walk(&revs))
die("revision walk setup failed");
diff --git a/git-bisect.sh b/git-bisect.sh
index 0d0e278..245435c 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -1,6 +1,6 @@
#!/bin/sh
-USAGE='[help|start|bad|good|skip|next|reset|visualize|replay|log|run]'
+USAGE='[help|start|bad|good|skip|next|reset|visualize|replay|log|run|replace]'
LONG_USAGE='git bisect help
print this long help message.
git bisect start [<bad> [<good>...]] [--] [<pathspec>...]
@@ -23,6 +23,8 @@ git bisect log
show bisect log.
git bisect run <cmd>...
use <cmd>... to automatically bisect.
+git bisect replace <rev> [<rev>]
+ use another branch for bisection.
Please use "git help bisect" to get the full man page.'
@@ -618,6 +620,40 @@ bisect_run () {
done
}
+bisect_replace() {
+ test "$#" -ge 1 -a "$#" -le 2 ||
+ die "'git bisect replace' accept one or two arguments"
+
+ source="$1"
+ target="${2:-HEAD}"
+
+ # Check arguments
+ src_commit=$(git rev-parse --verify "$source^{commit}") ||
+ die "Bad rev input: $source"
+ tgt_commit=$(git rev-parse --verify "$target^{commit}") ||
+ die "Bad rev input: $target"
+
+ test "$src_commit" != "tgt_commit" ||
+ die "source and target should be different commits"
+
+ # Check that trees from source and target are identical
+ src_tree=$(git rev-parse --verify "$src_commit^{tree}") ||
+ die "Could not get tree for source: $source"
+ tgt_tree=$(git rev-parse --verify "$tgt_commit^{tree}") ||
+ die "Could not get tree for target: $target"
+
+ test "$src_tree" = "$tgt_tree" ||
+ die "source and target should point to the same tree"
+
+ # Tag the source commit
+ src_tag="bisect-replace-with-$tgt_commit"
+ git tag "$src_tag" "$src_commit" || exit
+
+ # Create branch for the target commit
+ tgt_branch="bisect-replace-$src_commit"
+ git branch "$tgt_branch" "$tgt_commit" || exit
+}
+
case "$#" in
0)
@@ -645,6 +681,8 @@ case "$#" in
cat "$GIT_DIR/BISECT_LOG" ;;
run)
bisect_run "$@" ;;
+ replace)
+ bisect_replace "$@" ;;
*)
usage ;;
esac
--
1.6.0.3.531.gd12eb.dirty
^ permalink raw reply related
* [RFC/PATCH 2/2] bisect: add test case for "git bisect replace"
From: Christian Couder @ 2008-11-02 1:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
---
t/t6035-bisect-replace.sh | 89 +++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 89 insertions(+), 0 deletions(-)
create mode 100755 t/t6035-bisect-replace.sh
diff --git a/t/t6035-bisect-replace.sh b/t/t6035-bisect-replace.sh
new file mode 100755
index 0000000..ed2061e
--- /dev/null
+++ b/t/t6035-bisect-replace.sh
@@ -0,0 +1,89 @@
+#!/bin/sh
+#
+# Copyright (c) 2008 Christian Couder
+#
+test_description='Test git bisect replace functionality'
+
+exec </dev/null
+
+. ./test-lib.sh
+
+add_and_commit_file()
+{
+ _file="$1"
+ _msg="$2"
+
+ git add $_file || return $?
+ test_tick || return $?
+ git commit --quiet -m "$_file: $_msg"
+}
+
+HASH1=
+HASH2=
+HASH3=
+HASH4=
+HASH5=
+HASH6=
+
+test_expect_success 'set up buggy branch' '
+ echo "line 1" >> hello &&
+ echo "line 2" >> hello &&
+ echo "line 3" >> hello &&
+ echo "line 4" >> hello &&
+ add_and_commit_file hello "4 lines" &&
+ HASH1=$(git rev-parse --verify HEAD) &&
+ echo "line BUG" >> hello &&
+ echo "line 6" >> hello &&
+ echo "line 7" >> hello &&
+ echo "line 8" >> hello &&
+ add_and_commit_file hello "4 more lines with a BUG" &&
+ HASH2=$(git rev-parse --verify HEAD) &&
+ echo "line 9" >> hello &&
+ echo "line 10" >> hello &&
+ add_and_commit_file hello "2 more lines" &&
+ HASH3=$(git rev-parse --verify HEAD) &&
+ echo "line 11" >> hello &&
+ add_and_commit_file hello "1 more line" &&
+ HASH4=$(git rev-parse --verify HEAD) &&
+ sed -e "s/BUG/5/" hello > hello.new &&
+ mv hello.new hello &&
+ add_and_commit_file hello "BUG fixed" &&
+ HASH5=$(git rev-parse --verify HEAD) &&
+ echo "line 12" >> hello &&
+ echo "line 13" >> hello &&
+ add_and_commit_file hello "2 more lines" &&
+ HASH6=$(git rev-parse --verify HEAD)
+'
+
+HASHFIX2=
+HASHFIX3=
+HASHFIX4=
+
+test_expect_success 'set up fixed branch' '
+ git checkout $HASH1 &&
+ echo "line 5" >> hello &&
+ echo "line 6" >> hello &&
+ echo "line 7" >> hello &&
+ echo "line 8" >> hello &&
+ add_and_commit_file hello "4 more lines with no BUG" &&
+ HASHFIX2=$(git rev-parse --verify HEAD) &&
+ git cherry-pick $HASH3 &&
+ HASHFIX3=$(git rev-parse --verify HEAD) &&
+ git cherry-pick $HASH4 &&
+ HASHFIX4=$(git rev-parse --verify HEAD)
+'
+
+test_expect_success '"git bisect replace" buggy branch with fixed one' '
+ git bisect replace $HASH5 HEAD &&
+ git rev-list --bisect-all $HASH6 > rev_list.txt &&
+ grep $HASHFIX2 rev_list.txt &&
+ grep $HASHFIX3 rev_list.txt &&
+ grep $HASHFIX4 rev_list.txt &&
+ test_must_fail grep $HASH2 rev_list.txt &&
+ test_must_fail grep $HASH3 rev_list.txt &&
+ test_must_fail grep $HASH4 rev_list.txt
+'
+
+#
+#
+test_done
--
1.6.0.3.531.gd12eb.dirty
^ permalink raw reply related
* Re: libgit2 - a true git library
From: Shawn O. Pearce @ 2008-11-02 1:36 UTC (permalink / raw)
To: Scott Chacon; +Cc: Nicolas Pitre, Pierre Habouzit, david, git
In-Reply-To: <d411cc4a0811011807g229f8becs9f411d6e19fb6c12@mail.gmail.com>
Scott Chacon <schacon@gmail.com> wrote:
> > On Sat, Nov 1, 2008 at 3:57 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
> >>
> >> Headers updated. Its now GPL+gcc library exception.
>
> I personally would rather see it BSD or something more permissive so
> that no human has to waste even a second of their valuable time
> figuring out if they can work with it or not, but I understand that
> many people here are much more protective of their code. I simply
> think that LGPL is a much more widely used and understood compromise
> that affords nearly the same protectionism.
Apparently BSD won't fly, as you have already seen on the list.
If we did put the library under a BSD license we'd lose some core
contributors. Or they at least wouldn't improve the library code,
even if git.git linked to it in the future. I don't want to lose
these folks.
IANAL, but from what I can tell the main difference between LGPL
and GPL+"gcc library exception" is that the LGPL requires that
the end-user must be able to relink the derived executable with
their own replacement library. The GPL+"gcc library exception"
makes no such requirement.
If you read the exception clause it practically makes the library
even easier to use commerically than the BSD license does, however
modifications to the library sources must still be distributed.
Isn't that actually somewhat close to the Mozilla Public License?
--
Shawn.
^ permalink raw reply
* Re: libgit2 - a true git library
From: Shawn O. Pearce @ 2008-11-02 1:50 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Pierre Habouzit, git, Scott Chacon
In-Reply-To: <490CD101.1030604@op5.se>
Andreas Ericsson <ae@op5.se> wrote:
> Shawn O. Pearce wrote:
>>
>> Eh, I disagree here. In git.git today "struct commit" exposes its
>> buffer with the canonical commit encoding. Having that visible
>> wrecks what Nico and I were thinking about doing with pack v4 and
>> encoding commits in a non-canonical format when stored in packs.
>> Ditto with trees.
>
> Err... isn't that backwards?
No.
> Surely you want to store stuff in the
> canonical format so you're forced to do as few translations as
> possible?
No. We suspect that canonical format is harder to decompress and
parse during revision traversal. Other encodings in the pack file
may produce much faster runtime performance, and reduce page faults
(due to smaller pack sizes).
We hardly ever use the canonical format for actual output; most
output rips the canonical format apart and then formats the data
the way it was requested. If we have the data *already* parsed in
the pack its much faster to output.
> Or are you trying to speed up packing by skipping the
> canonicalization part?
Wrong; we're trying to speed up reading. Packing may go slower,
especially during the first conversion of v2->v4 for any given
repository, but packing is infrequent so the minor (if any) drop
in performance here is probably worth the reading performance gains.
> Well, if macro usage is adhered to one wouldn't have to worry,
> since the macro can just be rewritten with a function later (if,
> for example, translation or some such happens to be required).
> Older code linking to a newer library would work (assuming the
> size of the commit object doesn't change anyway),
You are assuming too much magic. If the older ABI used a macro
and the newer one (which supports pack v4) organized struct commit
differently and the user upgrades libgit2.so the older applications
just broke, horribly.
We know we want to do pack v4 in the near future. Or at least
experiment with it and see if it works. If it does, we don't
want to have to cause a major ABI breakage across all those newly
installed libgit2s... yikes.
I'm really in favor of accessor functions for the first version of
the library. They can always be converted to macros once someone
shows that their git visualizer program saves 10 ms on a 8,000 ms
render operation by avoiding accessor functions. I'd rather spend
our brain cycles optimizing the runtime and the in-core data so
we spend less time in our tight revision traversal loops.
Seriously. We make at least 10 or 11 function calls *per commit*
that comes out of get_revision(). If the formatting application is
really suffering from its 4 or 5 accessor function calls in order
to get that returned data, we probably should also be looking at
how we can avoid function cals in the library.
Oh, and even with 4 or 5 accessor functions per commit in the
application that is *still* better than the 10 or so calls the
application probably makes today scraping "git log --format=raw"
off a pipe and segment it into the different fields it needs.
Unless pipes in Linux somehow allow negative time warping with
CPU counters. Though on dual-core systems they might, since the
two processes can run on different cores. But oh, you didn't want
to worry about threading support too much in libgit2, so I guess
you also don't want to use multi-core systems.
--
Shawn.
^ permalink raw reply
* Re: libgit2 - a true git library
From: Shawn O. Pearce @ 2008-11-02 1:56 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git, Scott Chacon
In-Reply-To: <20081101173042.GE26229@artemis.corp>
Pierre Habouzit <madcoder@debian.org> wrote:
> On Fri, Oct 31, 2008 at 06:41:54PM +0000, Shawn O. Pearce wrote:
> > How about this?
> >
> > http://www.spearce.org/projects/scm/libgit2/apidocs/CONVENTIONS
>
> FWIW I've read what you say about types, while this is good design to
> make things abstract, accessors are slower _and_ disallow many
> optimizations as it's a function call and that it may clobber all your
> pointers values.
Yea, optimizing C is a bitch.
I'm in favor of accessors *IN THE APPLICATION*.
Within the library's own C code, I think we should expose the struct,
and use its members where it makes sense to. Especially in the
really tight loops where we don't want to introduce more overhead.
My rationale here is that we can change the struct at any time,
and yet not change the ABI.
> For types that _will_ be in the tight loops, we must make the types
> explicit or it'll bite us hard performance-wise. I'm thinking what is
> "struct object" or "struct commit" in git.git. It's likely that we will
> loose a *lot* of those types are opaque.
Yes, but I'm arguing they should be opaque to the application, and
visible to the library. Today the application is suffering from
massive fork+exec overhead. I really don't give a damn if the
application's compiler has to deal with a function call to read
from a private member of an opaque type. Its still thousands of
CPU instructions less per operation.
Come back to me a year after libgit2 has been widely deployed on
Linux distros and we have multiple applications linking to it.
Lets talk then about the harmful performance problems caused by
making these types opaque to the application. About that time
we'll also be talking about how great pack v4 is and why its a good
thing those types were opaque, as we didn't have to break the ABI
to introduce it.
> It's IMNSHO on the matter that core structures of git _will_ have to be
> made explicit. I'm thinking objects and their "subtypes" (commits,
> trees, blobs). Maybe a couple of things on the same vein.
Sure, but in the library only.
--
Shawn.
^ permalink raw reply
* Re: libgit2 - a true git library
From: Johannes Schindelin @ 2008-11-02 2:30 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Andreas Ericsson, git, Scott Chacon
In-Reply-To: <20081101204259.GC15463@spearce.org>
Hi,
On Sat, 1 Nov 2008, Shawn O. Pearce wrote:
> But I was also under the impression that the brilliant engineers who
> work for Microsoft decided that on their platform special annotations
> have to be inserted on functions that a DLL wants to export to
> applications.
Exactly. This is the "good" old __declspec(dllexport) for you. It is a
pain in the butt, but that is what you have to go for if libgit2 is
supposed to be any more portable than ligit.a.
Ciao,
Dscho
^ permalink raw reply
* Re: Git remote status
From: Jeff King @ 2008-11-02 3:30 UTC (permalink / raw)
To: Gonsolo; +Cc: git
In-Reply-To: <490CB390.9000206@gmail.com>
On Sat, Nov 01, 2008 at 08:52:48PM +0100, Gonsolo wrote:
> If I switch branches with "git checkout master" git tells me something
> like "Your branch is ahead of the tracked remote branch 'origin/master'
> by 39 commits".
> Is there a "git remote status" or git-status switch to get the same
> information without switching branches?
"git status" will do this automatically in recent versions of git (as of
1.6.0, I believe).
You can also use "git branch -v" to see a summary of how all branches
relate to their tracked counterparts.
> Sometimes it's valuable whether one should push changes (for example
> before installing a new Ubuntu version ;) ).
For that, I might want to actually _see_ the changes. So I would use:
git shortlog origin/master..
(or "log" with a variety of formatting options to get as much
information as you like). And if the relationship is more complex (i.e.,
I want to see if I need to push _or_ pull):
gitk origin/master...
-Peff
^ permalink raw reply
* Re: git reset --hard w/o touching every file
From: Jeff King @ 2008-11-02 3:33 UTC (permalink / raw)
To: Edward Z. Yang; +Cc: git
In-Reply-To: <geicn8$ss8$1@ger.gmane.org>
On Sat, Nov 01, 2008 at 04:03:50PM -0400, Edward Z. Yang wrote:
> Pierre Habouzit wrote:
> > git checkout HEAD -- <list of the files>
>
> What if I do not know a priori which files *do* need to be updated? Is
> there a command that I can get this information from? Also, I may not
Sorry, I don't quite understand. You want to check out some subset of
files, but you don't know which subset?
Try "git status" or "git diff" to look at which files have changes?
Or maybe we didn't understand your original question.
> necessarily be checking out HEAD.
Doing
git checkout v1.5 -- <list of files>
or using any other ref will work just fine.
-Peff
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Jeff King @ 2008-11-02 3:42 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Sam Vilain, git, Scott Chacon, Tom Preston-Werner, J.H.,
Christian Couder, Kai Blin
In-Reply-To: <alpine.DEB.1.00.0810311745030.22125@pacific.mpi-cbg.de.mpi-cbg.de>
On Fri, Oct 31, 2008 at 05:46:35PM +0100, Johannes Schindelin wrote:
> > > + * 'git branch --switch' : alternative to checkout
> >
> > Blech. I think switching branches is the one thing that checkout does
> > unconfusedly. And this is much more typing. Not to mention that So I
> > would rather see "git switch" if checkout is somehow unpalatable.
>
> You know, I asked for this because a _user_ told me "Guess how long it
> took me to find out how to check out a branch!".
>
> I think if you are not confused by CVS/SVN, the name "checkout" is utterly
> unintuitive.
OK. I am not opposed to such a change as long as:
- this is not just _a_ user, but a _common_ user confusion. IOW, I
don't recall this complaint coming up a lot (or at least not nearly
as often as other ones do). But maybe you have more data.
- it is done consistently.
My initial "blech" was a little premature, as I was thinking "instead
of checkout", though it does clearly say "alternative" there.
However, (and somebody else in the thread very cleverly came up with
this analysis, not me), this is basically going from "verb the noun"
to "noun --verb". And that's reasonable, if users think in terms of
nouns. But we should be consistent in applying that transformation,
and make it available for other nouns that match that verb. In other
words, "git tag --switch". And however one might manipulate remote
tracking branches ("git branch -r --switch", I guess).
Personally I find it somewhat backwards, but I think CVS rotted my
brain long ago.
-Peff
^ permalink raw reply
* [PATCH] t7700: demonstrate mishandling of objects in packs with a .keep file
From: drafnel @ 2008-11-02 3:35 UTC (permalink / raw)
To: git; +Cc: gitster, nico, Brandon Casey
In-Reply-To: <1S3xpaVP1Cy1Rei_ODwlXsBdu64BGiPve-lj_4fN6cA@cipher.nrlssc.navy.mil>
From: Brandon Casey <drafnel@gmail.com>
Objects residing in pack files that have an associated .keep file are not
supposed to be repacked into new pack files, but they are.
Signed-off-by: Brandon Casey <drafnel@gmail.com>
---
t/t7700-repack.sh | 38 ++++++++++++++++++++++++++++++++++++++
1 files changed, 38 insertions(+), 0 deletions(-)
create mode 100755 t/t7700-repack.sh
diff --git a/t/t7700-repack.sh b/t/t7700-repack.sh
new file mode 100755
index 0000000..1489e68
--- /dev/null
+++ b/t/t7700-repack.sh
@@ -0,0 +1,38 @@
+#!/bin/sh
+
+test_description='git repack works correctly'
+
+. ./test-lib.sh
+
+test_expect_failure 'objects in packs marked .keep are not repacked' '
+ echo content1 > file1 &&
+ echo content2 > file2 &&
+ git add . &&
+ git commit -m initial_commit &&
+ # Create two packs
+ # The first pack will contain all of the objects except one
+ git rev-list --objects --all | head -n -1 |
+ git pack-objects pack > /dev/null &&
+ # The second pack will contain the excluded object
+ packsha1=$(git rev-list --objects --all | tail -n 1 |
+ git pack-objects pack) &&
+ touch -r pack-$packsha1.pack pack-$packsha1.keep &&
+ objsha1=$(git verify-pack -v pack-$packsha1.idx | head -n 1 |
+ sed -e "s/^\([0-9a-f]\{40\}\).*/\1/") &&
+ mv pack-* .git/objects/pack/ &&
+ git repack -A -d -l &&
+ git prune-packed &&
+ for p in .git/objects/pack/*.idx; do
+ idx=$(basename $p)
+ test "pack-$packsha1.idx" = "$idx" && continue
+ if git verify-pack -v $p | egrep "^$objsha1"; then
+ found_duplicate_object=1
+ echo "DUPLICATE OBJECT FOUND"
+ break
+ fi
+ done &&
+ test -z "$found_duplicate_object"
+'
+
+test_done
+
--
1.6.0.2.588.g3102
^ permalink raw reply related
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Jeff King @ 2008-11-02 3:53 UTC (permalink / raw)
To: Tom Preston-Werner; +Cc: git
In-Reply-To: <20081031003154.GA5745@sigill.intra.peff.net>
On Thu, Oct 30, 2008 at 08:31:54PM -0400, Jeff King wrote:
> So think of us as having three "spots": the HEAD (H), the "stage"[1] (S),
> and the working tree (W). And we want commands for moving content
Re-reading this, I realized I forgot to fill in my footnote. But it was
going to be:
[1] Actually, the term "the stage" is growing on me.
-Peff
^ permalink raw reply
* Re: [RFC/PATCH 1/2] bisect: add "git bisect replace" subcommand
From: Johannes Schindelin @ 2008-11-02 4:16 UTC (permalink / raw)
To: Christian Couder; +Cc: Junio C Hamano, git
In-Reply-To: <20081102021910.fef1532e.chriscool@tuxfamily.org>
Hi,
On Sun, 2 Nov 2008, Christian Couder wrote:
> This new subcommand should be used when you have a branch or a part of a
> branch that isn't easily bisectable because at some point, say A, a bug
> as been introduced. The bug has been fixed latter at another point, say
> B, but between these points the code is not easily testable because of
> the bug, so it's not easy to bisect between these points.
Would it not be more intuitive to have support for
git bisect skip A..B
?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Jeff King @ 2008-11-02 4:18 UTC (permalink / raw)
To: Sam Vilain
Cc: Sam Vilain, git, Johannes Schindelin, Scott Chacon,
Tom Preston-Werner, J.H., Christian Couder, Kai Blin
In-Reply-To: <1225435238.20883.18.camel@maia.lan>
On Thu, Oct 30, 2008 at 11:40:38PM -0700, Sam Vilain wrote:
> > I notice the commit template message getting longer and longer. Maybe it
> > is time for status.verbosetemplate (which could default to true, I just
> > want to be able to turn it off).
> Right. We'll have to work through that when we look at how 'git status'
> output is displayed. There may be some people who parse the existing
> output, but they should get to read the release notes about the proper
> ways to do that. I think the whole output could do with a shake-up.
Maybe I am wrong, but I thought at some point we decided that parsing
the output of "git status" was insane and wrong, since it's porcelain.
OTOH, it is also an easy way for editors to see what is happening in a
commit whose message you are editing (and to do, for example, syntax
highlighting on it). So it may be that it is getting parsed anyway.
> [moving content from HEAD or index to working tree]
> I still think it's OK to use 'git revert-files' for this; it just seems
> so long. Switches could specify where to and from.
Yeah, revert-files is pretty painful to type. And I'm not looking
forward to fielding UI questions about "why isn't it just revert?" :)
Somebody suggested "clobber", which I think is a bit _too_ intense.
I guess something like "retrieve" is too ambiguous. You really need
something that implies movement of content, and something that implies
the working directory. "Checkout" is actually not a bad name; if only we
had "git switch" instead of "git checkout" for switching branches, it
would be perfect.
So I am a bit stumped. Maybe "clobber" is not so bad. ;)
> Again interesting, you could look at the stash as a whole bunch of
> staged commits yet to happen. Of course, adding a file when the version
> in HEAD doesn't match the version in the base of the stash is a bit
> insane, so should probably be an error.
>
> I'll have a ponder over this and whether there is a simple word for this
> all.
Whether or not we come up with a simple word, I think it makes sense to
expose this through "git stash -i" (since, after all, we are just
putting stuff into an index there).
> You're right with all that. I don't think that it is necessarily wrong
> to have two ways to get at functionality, depending on whether you start
> with the noun or the verb first; so long as it doesn't introduce
> confusion. And if anything, I think --switch is wrong; --checkout is
> probably more consistent.
Agreed on --checkout. I think your "noun or verb" comment hits the nail
right on the head. I wonder if there are other places where
functionality can be exposed in either direction (I think we already
have some in "git fetch <remote>" versus "git remote update").
> > There was a thread between me and Junio some months ago that touched on
> > this. I don't remember all of the arguments, but it was resolved to keep
> > the current behavior. Any proposal along these lines should at least
> > revisit and respond to those arguments.
>
> Right. So, before round 2, I'll read and attempt to summarise that
> thread - assuming I can find it! :)
I think it was "Minor annoyance with git push" from this past February.
Quite a long thread, but there is some in this subthread:
http://thread.gmane.org/gmane.comp.version-control.git/73038/focus=73208
> Another command people often want is 'git info' to tell them stuff like
> they might get from 'git status' or 'git remote' but without all the
> file details...
Yeah, I don't know if you have followed the other threads in the past
month or so, but I think there is some desire for a "new" status with
a nicer format.
And I think it might be nice to structure it as a long list of things it
_can_ report on, and then let you tweak those with command-line options
and config settings. E.g., I might set info.currentbranch, info.staged,
and info.untracked because that is what _I_ like to see to get a sense
of what is happening in the repo.
And I will get around to designing that after I clear the other 100
things off my todo list. ;)
> > > + * 'git tag -l' should show more information
> > I remember somebody talking about this, but not the details. Which
> > information?
> Oh, good point. Basically the same stuff that 'git branch -v' shows; in
> any case, its behaviour should be relatively consistent compared to 'git
> branch'.
OK, that makes sense to me. I think of "git tag -l" as plumbing-ish,
though, so we might be breaking people's scripts (yes, I know the "real"
plumbing for this is for-each-ref, but it really is a pain to parse the
tags out of that versus "for i in `git tag -l`").
-Peff
^ permalink raw reply
* Re: Using the --track option when creating a branch
From: Jeff King @ 2008-11-02 4:23 UTC (permalink / raw)
To: Samuel Tardieu; +Cc: Andreas Ericsson, Bill Lear, git
In-Reply-To: <2008-10-30-14-52-52+trackit+sam@rfc1149.net>
On Thu, Oct 30, 2008 at 02:52:52PM +0100, Samuel Tardieu wrote:
> The current behaviour made me remove the branches I was not actively
> on locally, because I would get errors from "git push" all the time
> saying that I was not up-to-date in those branches.
Not triggering an error on these branches has been discussed a few times
before, but I'm not sure we ever reached a conclusion of what the ideal
behavior would be.
Try this thread:
http://thread.gmane.org/gmane.comp.version-control.git/85469
which points to a few others. Comments welcome.
-Peff
^ permalink raw reply
* Re: [PATCH 1/3] git send-email: avoid leaking directory file descriptors.
From: Jeff King @ 2008-11-02 4:31 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <1225450632-7230-2-git-send-email-madcoder@debian.org>
On Fri, Oct 31, 2008 at 11:57:10AM +0100, Pierre Habouzit wrote:
> + closedir(DH);
Ugh. This is a great reason to use a scoped variable (like "my $dh),
which will close automatically. Once upon a time I think you _had_ to
use globs for this, but I think it has not been the case for some time
(and I think we only support back to perl 5.6 these days). Can any perl
gurus comment?
-Peff
^ permalink raw reply
* Re: [PATCH] git send-email: allow any rev-list option as an argument.
From: Jeff King @ 2008-11-02 4:35 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <1225471925-2750-1-git-send-email-madcoder@debian.org>
On Fri, Oct 31, 2008 at 05:52:05PM +0100, Pierre Habouzit wrote:
> Signed-off-by: Pierre Habouzit <madcoder@debian.org>
> ---
>
> One can consider to squash that on top of
> <1225450632-7230-3-git-send-email-madcoder@debian.org> to be able to pass
> all non path arguments before a possible '--' to git format-patch.
Personally, I think the other patch is not useful without this. I often
pull out funny subsets of patches if I know it is safe to do so (e.g., I
collect small, unrelated bugfixes directly onto a single branch, but I
send them separately).
With this patch, I might even find send-email usable. :)
-Peff
^ permalink raw reply
* Re: git reset --hard w/o touching every file
From: Edward Z. Yang @ 2008-11-02 4:36 UTC (permalink / raw)
To: git
In-Reply-To: <20081102033313.GB4936@coredump.intra.peff.net>
Jeff King wrote:
> Sorry, I don't quite understand. You want to check out some subset of
> files, but you don't know which subset?
Yeah, I should elaborate a little.
I'm using a script to automatically update a website with the contents
of a Git repository at a specified interval. While I could use git pull,
I've been told that it's safer to do a git fetch, and then a git reset
--hard remotes/master, because the former could trigger a merge and on a
live website that is NOT desirable.
Unfortunately, since Git touches all files on a reset --hard, it's
causing problems with the smart cache system, which checks whether or
not the cache file is older than the source file, and regenerating if it is.
Cheers,
Edward
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Elijah Newren @ 2008-11-02 4:41 UTC (permalink / raw)
To: Theodore Tso; +Cc: Sam Vilain, git, Sam Vilain
In-Reply-To: <20081102010634.GF8134@mit.edu>
On Sat, Nov 1, 2008 at 7:06 PM, Theodore Tso <tytso@mit.edu> wrote:
> In my opinion, that is a Really Bad Idea from a usability and UI
> design point of view. Each command should do one and only one thing,
> and not do different things depending on what options you give it.
> Git violates this rules in a number of places already, What you call
> "revert-since" and "revert-in" are so different that using the same
> subcommand is just going to horribly confuse users.
>
> Better to have "git revert" print a message explining that it is
> deprecated, and to tell users that they probably want either "git
> cherry-pick --revert" or "git revert-file", depending on whether they
> are an experienced git user (in which case they probably want git
> cherry-pick --revert"), or if that person who is familiar svn or hg's
> "svn revert" or "hg revert", they probably want "git revert-file".
Yeah, good points. I guess I could just make --no-commit the default
in all cases to remove the "magic", but then it's too much typing for
the revert-in case ("eg revert --commit --in REVISION" vs. "git revert
REVISION"). Two separate commands may make more sense, but then
there's the naming issue (I had difficulty coming up with a different
name that I liked, and it appears others are having a little trouble
with the naming too). Tough nut to crack from any angle. :-(
^ permalink raw reply
* Re: [PATCH] prepare deprecation of git-revert
From: Jeff King @ 2008-11-02 4:41 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <1225468527-29694-1-git-send-email-madcoder@debian.org>
On Fri, Oct 31, 2008 at 04:55:27PM +0100, Pierre Habouzit wrote:
> I've not kept the auto-edit feature of git-revert for the git-cherry-pick -R
> case as I don't believe it makes a lot of sense. But if people are unhappy
> with that, I can easily "fix" it.
I disagree. I write a new commit message for every revert I do.
When you cherry-pick, you are pulling a good commit from somewhere else.
So its commit message should suffice to explain why you are making the
change (and infrequently, you might want to give more context or say
"and here is where this comes from").
But when you revert, you are saying "this other commit was bad, so let's
reverse it." So you can look at the other commit to see what it did, but
you still don't know _why_ it was bad. A revert should always give
information about what you know _now_ that you didn't know when you
made the commit originally.
-Peff
^ permalink raw reply
* Re: libgit2 - a true git library
From: David Brown @ 2008-11-02 5:09 UTC (permalink / raw)
To: Scott Chacon; +Cc: Shawn O. Pearce, Nicolas Pitre, Pierre Habouzit, david, git
In-Reply-To: <d411cc4a0811011807g229f8becs9f411d6e19fb6c12@mail.gmail.com>
On Sat, Nov 01, 2008 at 06:07:04PM -0700, Scott Chacon wrote:
>Think about trying to incorporate this into something proprietary,
>Shawn - how much of a pain is it going to be to get that license
>reviewed in Google? However, LGPL I'm sure there is already a
>reviewed policy. Now, since that may be a pain, time that Shawn could
>have been spending being paid to work on the library is lost because
>they can't use it, or it takes weeks/months to review it. That's my
>concern.
The gcc exception license should have been reviewed by anyone who has
ever build anything proprietary out of gcc.
GPL+link exception is a very common license. It's most common use is
for runtime libraries for various programming languages.
Lawyers I know are significantly less fearful of the GPL+exception
than the LGPL. The exception basically says that if you use it in a
certain way, then none of the GPL applies.
David
^ permalink raw reply
* Re: git reset --hard w/o touching every file
From: Jeff King @ 2008-11-02 5:52 UTC (permalink / raw)
To: Edward Z. Yang; +Cc: git
In-Reply-To: <gejanr$os$1@ger.gmane.org>
On Sun, Nov 02, 2008 at 12:36:09AM -0400, Edward Z. Yang wrote:
> I'm using a script to automatically update a website with the contents
> of a Git repository at a specified interval. While I could use git pull,
> I've been told that it's safer to do a git fetch, and then a git reset
> --hard remotes/master, because the former could trigger a merge and on a
> live website that is NOT desirable.
Well, there will never be a merge if you aren't making local changes
(and your upstream is not doing silly things like rewinding the history of
what it gives you). But if you aren't making local changes, then doing a
reset is "safe" in the sense that you will have nothing to throw away.
> Unfortunately, since Git touches all files on a reset --hard, it's
> causing problems with the smart cache system, which checks whether or
> not the cache file is older than the source file, and regenerating if
> it is.
Ah, OK. I see what you want.
Git usually tries very hard not to touch files that don't need to be
touched. So that sounds like a bug. However, I can't reproduce it with
this test case:
mkdir repo && cd repo && git init &&
touch a b && git add a b && git commit -m added &&
echo changes >a && git commit -a -m 'changed a' &&
touch -d 1979-10-12 a b && echo before reset && ls -l a b &&
git update-index --refresh &&
git reset --hard HEAD^ && echo after reset && ls -l a b
I end up with:
before reset
-rw-r--r-- 1 peff peff 8 1979-10-12 00:00 a
-rw-r--r-- 1 peff peff 0 1979-10-12 00:00 b
HEAD is now at d7fd84e added
after reset
-rw-r--r-- 1 peff peff 0 2008-11-02 01:46 a
-rw-r--r-- 1 peff peff 0 1979-10-12 00:00 b
which makes sense. The only tricky thing is the "update-index --refresh"
call, which basically tells git "update your cache with the new mtime
value", which is necessary because of the contrived use of "touch". But
if you are manipulating these files only through "git reset", it should
Just Work.
-Peff
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Junio C Hamano @ 2008-11-02 6:08 UTC (permalink / raw)
To: Theodore Tso; +Cc: Pierre Habouzit, Sam Vilain, git, Sam Vilain
In-Reply-To: <20081030163056.GA8899@mit.edu>
Theodore Tso <tytso@mit.edu> writes:
> On Thu, Oct 30, 2008 at 03:43:21PM +0100, Pierre Habouzit wrote:
>>
>> git format-patch origin/next.. works already. I'm used to the asymetric
>> git format-patch origin/next syntax, and I would be sorry if it
>> disappeared though, and I see no really good reason to get rid of it.
>
> The reason why it annoys me is because I often what to cherry-pick a
> single patch to send to someone, and so while "git show 332d2e78"
> shows me the patch, but if I want to use git-send-email for that
> particular patch, "git format-patch 332d2e78" doesn't DTRT. I have to
> type "git format-patch 332d2e78^..332d2e78" instead.
> ...
> (And I get annoyed when I want to run git format-patch on a single
> patch not at the tip of the tree; but if it's just me, I can write a
> "git format-single-patch" wrapper script to get around it.)
Huh? I am so used to "git format-patch -1 HEAD" (or "332d2e78") that I am
very surprised.
^ permalink raw reply
* Re: [PATCH 1/3] git send-email: make the message file name more specific.
From: Junio C Hamano @ 2008-11-02 6:18 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <1225456609-694-2-git-send-email-madcoder@debian.org>
Pierre Habouzit <madcoder@debian.org> writes:
> This helps editors choosing their syntax hilighting properly.
Even though I agree this is the right direction to go, unfortunately this
can break people's existing setup.
Having said that, if we were to do this, let's do it the right way and put
these "temporary" files under $GIT_DIR.
>
> Signed-off-by: Pierre Habouzit <madcoder@debian.org>
> ---
> git-send-email.perl | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/git-send-email.perl b/git-send-email.perl
> index 65c254d..4ca571f 100755
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -127,7 +127,7 @@ sub unique_email_list(@);
> sub cleanup_compose_files();
>
> # Constants (essentially)
> -my $compose_filename = ".msg.$$";
> +my $compose_filename = ".gitsendemail.msg.$$";
>
> # Variables we fill in automatically, or via prompting:
> my (@to,@cc,@initial_cc,@bcclist,@xh,
> --
> 1.6.0.3.763.g0275.dirty
>
> --
> 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 3/3] git send-email: add --annotate option
From: Junio C Hamano @ 2008-11-02 6:23 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <1225450632-7230-4-git-send-email-madcoder@debian.org>
Pierre Habouzit <madcoder@debian.org> writes:
> This allows to review every patch (and fix various aspects of them, or
> comment them) in an editor just before being sent. Combined to the fact
> that git send-email can now process revision lists, this makes git
> send-email and efficient way to review and send patches interactively.
Without your patches, you run format-patch (with or without cover), you
use the editor of your choice to massage them and feed the resulting files
to send-email.
Only because you wanted to allow format-patch parameters to be given to
send-email, you now need to also allow the messages to be massaged before
they are sent out.
Is it only me who finds that this series creates its own problem and then
has to solve it? What are we getting in return?
^ 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