* [PATCH] t7501: always use test_cmp instead of diff
From: Miklos Vajna @ 2008-09-10 17:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <7vljy03m2m.fsf@gitster.siamese.dyndns.org>
This should make the output more readable (by default using diff -u)
when some tests fail.
Also changed the diff order from "current expected" to "expected
current".
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
On Tue, Sep 09, 2008 at 05:02:09PM -0700, Junio C Hamano <gitster@pobox.com> wrote:
> > We seem to use the convention of
> >
> > test_cmp <expected> <actual>
> >
> > elsewhere, rather than
> >
> > test_cmp <actual> <expected>
> >
> > as you have here. Most noticeably, that means the diff will show
> > deviations from expected, rather "what should be done to make this
> > as expected".
>
> Yes, please.
Here is an updated patch that does this as well.
t/t7501-commit.sh | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/t/t7501-commit.sh b/t/t7501-commit.sh
index 469bff8..63bfc6d 100755
--- a/t/t7501-commit.sh
+++ b/t/t7501-commit.sh
@@ -141,7 +141,7 @@ EOF
test_expect_success \
'validate git rev-list output.' \
- 'diff current expected'
+ 'test_cmp expected current'
test_expect_success 'partial commit that involves removal (1)' '
@@ -151,7 +151,7 @@ test_expect_success 'partial commit that involves removal (1)' '
git commit -m "Partial: add elif" elif &&
git diff-tree --name-status HEAD^ HEAD >current &&
echo "A elif" >expected &&
- diff expected current
+ test_cmp expected current
'
@@ -160,7 +160,7 @@ test_expect_success 'partial commit that involves removal (2)' '
git commit -m "Partial: remove file" file &&
git diff-tree --name-status HEAD^ HEAD >current &&
echo "D file" >expected &&
- diff expected current
+ test_cmp expected current
'
@@ -171,7 +171,7 @@ test_expect_success 'partial commit that involves removal (3)' '
git commit -m "Partial: modify elif" elif &&
git diff-tree --name-status HEAD^ HEAD >current &&
echo "M elif" >expected &&
- diff expected current
+ test_cmp expected current
'
@@ -187,7 +187,7 @@ test_expect_success 'amend commit to fix author' '
expected &&
git commit --amend --author="$author" &&
git cat-file -p HEAD > current &&
- diff expected current
+ test_cmp expected current
'
@@ -256,7 +256,7 @@ test_expect_success 'amend commit to fix author' '
expected &&
git commit --amend --author="$author" &&
git cat-file -p HEAD > current &&
- diff expected current
+ test_cmp expected current
'
--
1.6.0.1
^ permalink raw reply related
* Re: [RFC] origin link for cherry-pick and revert
From: Petr Baudis @ 2008-09-10 16:40 UTC (permalink / raw)
To: Stephen R. van den Berg; +Cc: Theodore Tso, git
In-Reply-To: <20080910141630.GB7397@cuci.nl>
On Wed, Sep 10, 2008 at 04:16:30PM +0200, Stephen R. van den Berg wrote:
> Theodore Tso wrote:
> > And the maintenance of this database
> >is purely optional; you only need it if you care about efficiently
> >looking up UUID's, and given "time git log > /dev/null" on the kernel
> >tree only takes six seconds on my laptop, and "git log > /dev/null"
> >only takes 0.148 seconds for e2fsprogs, for many projects you might
> >not even need the database to accelerate lookups via UUID.
>
> The database needs to be available to anyone doing a clone of the
> repository, which implies that:
> - It needs to be network based.
> - It needs controlled write access (which is a mess).
> - It is slow during blame/gitk operations.
> - It is rather nontrivial to get things setup such that someone (after
> cloning the repository) is able to run cherry-pick/gitk/blame/revert
> and have those commands use the database transparently.
The database can just live in a special branch, with trees organized the
same way the object database is, possibly in a more optimized way
(having the HEAD trees cached around inside Git, etc.). This should be
no rocked science if the design is given a little thought, and should be
fairly fast afterwards.
I'm not endorsing assigning UUIDs to commits now at all (but I don't
have time to formulate a comprehensive argument against that either).
However, having a commit -> nonessential_volatile_metadata database
would be useful for many other things as well! For example amending
commit messages later, maintaining general linkage between related
commits, tracking explicit rename hints for Git (like the Samba guys
would appreciate right now, and me many times in the past - note that
this is NOT the same as directly tricking renames within Git history)
or caching expensive computations with mostly static results (like the
rename detection or maybe pickaxe indexes - that could be quite large,
so we might want to actually separate different kinds of data to
separate branches).
--
Petr "Pasky" Baudis
The next generation of interesting software will be done
on the Macintosh, not the IBM PC. -- Bill Gates
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Jakub Narebski @ 2008-09-10 16:23 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Paolo Bonzini, Stephen R. van den Berg, git
In-Reply-To: <alpine.LFD.1.10.0809100844040.3384@nehalem.linux-foundation.org>
Linus Torvalds wrote:
> On Wed, 10 Sep 2008, Linus Torvalds wrote:
> >
> > Sure. I don't use them either. But because I don't use them, it doesn't
> > affect me. It also doesn't change the core git data structures in any way
> > to introduce any new problems.
>
> Btw, so far nobody has even _explained_ what the advantage of the origin
> link is. It apparently has no effect for most things, and for other things
> it has some (unspecified) effect when it can be resolved.
>
> Apart from the "dotted line" in graphical history viewers, I haven't
> actually heard any single concrete example of exactly what it would *do*.
>
> And that dotted line really does sound like something you could do with
> just the existing "hyperlink" functionality in the commit message.
As far as I understand (note: I'm neither for, nor against the proposal;
although I think it has thin chance to be accepted, especially soon),
it is for graphical history viewers, for git-cherry to make it more
precise (to detect duplicated/cherry-picked changes better), and in
the future possibly to help history-aware merge strategies. And probably
help patch management interfaces.
On the theoretical front it looks like extension/generalization of
a parent link, marking given commit do be derivative not only some
set of trees, or some line of history, but also on some changeset.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Theodore Tso @ 2008-09-10 16:18 UTC (permalink / raw)
To: Stephen R. van den Berg; +Cc: Petr Baudis, git
In-Reply-To: <20080910141630.GB7397@cuci.nl>
On Wed, Sep 10, 2008 at 04:16:30PM +0200, Stephen R. van den Berg wrote:
> The renumbering is not a problem, renumbering is a rare operation since
> a project's history is supposed to be stable. And even if renumbering
> is performed, it is a well understood operation of which the renumbering
> of the origin links imposes a negligible overhead on top of the existing
> renumbering overhead.
Well *you* were the one using this as an argument for using the origin
link. But I'll note that in some workflows, rebasing happens all the
time when a patch is being developed and moved around. Sometimes
patches are created in git, exported as a patch, and then it re-enters
git again later (which is another reason why using an external UUID or
bug tracking identifier is a good thing).
> >Addresses-Bug: Red_Hat/149480, Sourceforge_Feature/120167
> >or
> >Addresses-Bug: Debian/432865, Launchpad/203323, Sourceforge_Bug/1926023
>
> >Once you have this information, it is not difficult to maintain a
> >berk_db database which maps a particular Bug identifier (i.e.,
> >Red_Hat/149480, or Debian/471977, or Launchpad/203323) to a series of
> >commits.
>
> This is nice, I admit, but it has the following downsides:
> - It is nontrivial to automate this on execution of "git cherry-pick".
It's trivial if it's in the free-form text. In fact, it happens
automatically. If it's stored within the git commit object, then it
will be done in the C code (if you've updated to the latest git;
again, one of the advantages of doing it in free-form text).
> - In a distributed environment this requires a network-reachable bug
> database.
> - A network-reachable bug database means that suddenly git needs network
> access for e.g. cherry-pick, revert, gitk, log --graph, blame.
> - Network queries for commits containing references kind of kills
> performance.
No, because you don't need to look up the bug identifier unless you
want to, you know, actually look at the bug. Otherwise, we are just
using something like "debian/432865" as an identifier; you only need
to look them up if you want to look up the bug. Any time you have a
collaborative development environment, you will need either a
centralized, network accessible bug tracking system, or use a
distributed bug tracking system. Either way, though, if it's just
matter of seeing whether or not a bug fix such as debian/432865 is
fixed by some commit in some branch, using the bug identifier actually
makes this *easier*, not harder.
> - Some backports don't have entries in a bug database because they
> weren't bugs to begin with, in which case it becomes impossible to add
> an identifier to the commit message after the fact.
This is true. The transition is a little easier if you are pointing
to a pre-existing commit, whereas if you need some kind of rendevous
identifer (whether it is a bug ID or some UUID). On the other hand,
you've cherry-picked some bug fix using a git that didn't support the
origin link, you'd also be screwed, so
> - It relies heavily on tools outside of git-core, which raises the
> threshold for using it.
Well, it relies on changes to git --- just like the origin link
requires changes to git. If the it is implemented using free-form
text, which is a great way to prototype it, you have the *option* of
implementing it via either git porcelain changes or outside tools like
emacs or vi macros (just as most of us who are kernel developers have
editor macros that insert Signed-off-by: into git commit messages, as
well as changes in git porcelain such that "git am -s" automatically
adds the Signed-off-by header). But given the wildly successful use
of Signed-off-by in the kernel sources, this objection seems not very
credible, to say the least.
> The recommended practice here is quite simple:
>
> - Origin links should only be created pointing to stable commits (i.e.
> commits which you'd be willing to publish or already have published).
>
> - This implies that pointing an origin link at a commit in a strain that
> you still want to rebase is asking for trouble. Doing this is akin to
> doing a merge between two branches and then you start rebasing 4
> commits *below* the mergepoint. Don't do that.
Right. And if we use a UUID to identify commits, then we don't have
to have these restrictions.
> - The only special case I'd allow is if you rebase a strain and the
> origin link points from one of the commits in the strain to be rebased
> back *into* the same strain being rebased (most likely a revert).
> Rebase can be bothered to renumber the origin link in this case.
Nope, because you might have a branch to the original origin link, and
some body else may have already done a cherry-pick to the original
origin commit. You've hand-waved around the problem by saying, "don't
do that", but it just points out how **fragile** the origin link
scheme really is. It's just not robust.
In contrast, generating a UUID per commit is much more robust, since
you can now export it out of git in a patch, and then re-import it
later, and have the right thing happen.
> >(and I am not convinced that you do), the ***much*** better approach
> >is to use the same approach as the bug tracking identifier, and add a
> >level of indirection. How would that work in practice? Whenever you
> >create a new commit, create a UUID which is assigned to the patch.
>
> This only works if you know at time of commit that you want to backport
> it at some later date.
I'm suggesting that all commits (once you upgrade to a version of git
that supports this --- and you've already handwaved away the question
on whether you can get all of developers for a project to upgrade to
the latest git, remember) would have a UUID generated. That UUID
could be stored internal to git, or (perhaps as an initial prototyping
as a proof of concept, before we add something into the git commit
record **forever**) could be in the free-form text.
> >Yes, it means that you have to maintain a separate database so you can
> >easily find the list of commits that contain a particular UUID, but I
> >suspect you would need this in the case of the origin link concept
> >anyway, since sooner or later some of the more useful uses of said
> >link would require you to be able to find the commits which had origin
> >links to the original commit, which means you would need to create and
> >maintain this database anyway.
>
> That isn't true. Finding commits which have origin links to a certain
> commit is just as hard as finding all children of a certain commit.
> It's not exactly instant, but it is not a big problem, and depending on
> the amount of repositorytraversal you already are doing, it might even
> be a negligible amount of extra overhead.
My point is you'll need this separate database anyway, in order to
deal with the cases where you have two commits that point to the same
(non-existent) origin link, one in maint1, and one in maint2, and
given the commit in the maint1 branch, you want to see if there is
related comit in the maint2 branch you'll need this database anyway
(or you do a brute force search of the repository, which isn't too bad
for modest datbases). It's identical in both cases --- but having a
UUID field in the commit is much *cleaner*, since it merely states
that these two commits introduce the same semantic change; it doesn't
imply some kind of parent/child relationship which an origin link
implies.
> The database needs to be available to anyone doing a clone of the
> repository, which implies that:
> - It needs to be network based.
> - It needs controlled write access (which is a mess).
> - It is slow during blame/gitk operations.
> - It is rather nontrivial to get things setup such that someone (after
> cloning the repository) is able to run cherry-pick/gitk/blame/revert
> and have those commands use the database transparently.
No it doesn't, since the database can be inferred from the objects in
the repository. So you can generate it locally if you need it, merely
as an optimization. The same is true for the origin link proposal, as
I've said.
- Ted
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Paolo Bonzini @ 2008-09-10 15:57 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Stephen R. van den Berg, Jakub Narebski, git
In-Reply-To: <alpine.LFD.1.10.0809100844040.3384@nehalem.linux-foundation.org>
> Btw, so far nobody has even _explained_ what the advantage of the origin
> link is. It apparently has no effect for most things, and for other things
> it has some (unspecified) effect when it can be resolved.
>
> Apart from the "dotted line" in graphical history viewers, I haven't
> actually heard any single concrete example of exactly what it would *do*.
I mentioned git-cherry as an additional use case. Automatic rename
detection works because it might have the occasional false negative, but
it has practically no false positive, and those are what screws up
merges. But automatic changeset detection a la git-patch-id has too
many false negatives to make the current implementation of git-cherry
practical, and here's when the origin link comes in. Also, automatic
changeset detection does not work with reverts, only with cherry-picks.
Blame could also use the origin link to go backwards in the history and
find the origin of the code, without being fooled by reverts.
I'll quote another message I sent in the thread:
>> And why are the notes created by git cherry-pick -x insufficient for that?
>
> For example, these notes (or the ones created by "git revert") are
> *wrong* because they talk about commits instead of changesets (deltas
> between two commits).
>
> Why is only one commit present? Because these messages are meant for
> users, not for programs. That's easy to see: users think of commits as
> deltas anyway, even though git stores them as snapshots---"git show
> HEAD" shows a delta, not a snapshot.
>
> And what does this mean for programs? That they must resort to
> commit-message scraping to distinguish the two cases. (*)
>
> (*) A GUI blame program, for example, would need to distinguish
> whether code added by a commit is taken from commit 4329bd8, or is
> reverting commit 4329bd8. (In the first case, the author of that
> code is whoever was responsible for that code in 4329bd8; in the
> second case, it is whoever was responsible for that code in
> 4329bd8^). If recording changesets, you see 4329bd8^..4329bd8 in
> the first case, and 4329bd8..4329bd8^ in the second, so it is trivial
> to follow the chain.
>
> And scraping is bad. Imagine people that are writing commit messages in
> their native language. What if they patch git to translate the magic
> notes created by "git cherry-pick -x" or "git revert" (maybe a future
> version of git will do that automatically)? Should they translate also
> every program that scrapes the messages?
>
>
> Whenever there is a piece of data that could be useful to programs (no
> matter if plumbing or porcelain), I consider free form notes to be bad.
> Because data is data, and metadata is metadata.
>
> If there was a generic way to put porcelain-level metadata in commit
> messages (e.g. Signed-Off-By and Acknowledged-By can be already
> considered metadata), I would not be so much in favor of "origin" links
> being part of the commit object's format. Now if you think about it,
> commit references within this kind of metadata would have mostly the
> properties that Stephen explained in his first message:
>
> 1) they would be rewritten by git-filter-branch
>
> 2) these references, albeit weak by default
(Note to Linus: reinforcement of your disagreement will be implicitly
assumed :-)
> could optionally be
> followed when fetching (either with command-line or configuration options)
>
> 3) they would not be pruned by git-gc, unlike notes
>
> 4) possibly, git rev-list --topo-order would sort commits by taking into
> account metadata references too.
>
> So the implementation effort would be roughly the same.
>
> But, can you think of any other such metadata? Personally I can't, so
> while I understand the opposition to a new commit header field that
> would be there from here to eternity (or until the LHC starts), I do
> think it is the simplest thing that can possibly work.
Paolo
^ permalink raw reply
* [PATCH] git wrapper: also uses aliases to suggest mistyped commands
From: Pieter de Bie @ 2008-09-10 15:54 UTC (permalink / raw)
To: Git Mailinglist, Junio C Hamano; +Cc: Pieter de Bie
Signed-off-by: Pieter de Bie <pdebie@ai.rug.nl>
---
help.c | 15 +++++++++++++++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/help.c b/help.c
index 300cd38..24904d4 100644
--- a/help.c
+++ b/help.c
@@ -262,11 +262,15 @@ int is_in_cmdlist(struct cmdnames *c, const char *s)
}
static int autocorrect;
+static struct cmdnames aliases;
static int git_unknown_cmd_config(const char *var, const char *value, void *cb)
{
if (!strcmp(var, "help.autocorrect"))
autocorrect = git_config_int(var,value);
+ /* Also use aliases for command lookup */
+ if (!prefixcmp(var, "alias."))
+ add_cmdname(&aliases, var + 6, strlen(var + 6));
return git_default_config(var, value, cb);
}
@@ -280,6 +284,15 @@ static int levenshtein_compare(const void *p1, const void *p2)
return l1 != l2 ? l1 - l2 : strcmp(s1, s2);
}
+static void add_cmd_list(struct cmdnames *cmds, struct cmdnames *old)
+{
+ int i;
+ ALLOC_GROW(cmds->names, cmds->cnt + old->cnt, cmds->alloc);
+
+ for (i = 0; i < old->cnt; i++)
+ cmds->names[cmds->cnt++] = old->names[i];
+}
+
const char *help_unknown_cmd(const char *cmd)
{
int i, n, best_similarity = 0;
@@ -287,11 +300,13 @@ const char *help_unknown_cmd(const char *cmd)
memset(&main_cmds, 0, sizeof(main_cmds));
memset(&other_cmds, 0, sizeof(main_cmds));
+ memset(&aliases, 0, sizeof(aliases));
git_config(git_unknown_cmd_config, NULL);
load_command_list("git-", &main_cmds, &other_cmds);
+ add_cmd_list(&main_cmds, &aliases);
ALLOC_GROW(main_cmds.names, main_cmds.cnt + other_cmds.cnt,
main_cmds.alloc);
memcpy(main_cmds.names + main_cmds.cnt, other_cmds.names,
--
1.6.0.1.346.g880d9.dirty
^ permalink raw reply related
* Re: [RFC] origin link for cherry-pick and revert
From: Linus Torvalds @ 2008-09-10 15:46 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: Stephen R. van den Berg, Jakub Narebski, git
In-Reply-To: <alpine.LFD.1.10.0809100841080.3384@nehalem.linux-foundation.org>
On Wed, 10 Sep 2008, Linus Torvalds wrote:
>
> Sure. I don't use them either. But because I don't use them, it doesn't
> affect me. It also doesn't change the core git data structures in any way
> to introduce any new problems.
Btw, so far nobody has even _explained_ what the advantage of the origin
link is. It apparently has no effect for most things, and for other things
it has some (unspecified) effect when it can be resolved.
Apart from the "dotted line" in graphical history viewers, I haven't
actually heard any single concrete example of exactly what it would *do*.
And that dotted line really does sound like something you could do with
just the existing "hyperlink" functionality in the commit message.
Linus
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Linus Torvalds @ 2008-09-10 15:43 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: Stephen R. van den Berg, Jakub Narebski, git
In-Reply-To: <48C7E9A1.5080409@gnu.org>
On Wed, 10 Sep 2008, Paolo Bonzini wrote:
>
> I think that shallow clones are not any different from this. If the
> required piece of history is there, cool. If they're not there, no big
> deal.
Sure. I don't use them either. But because I don't use them, it doesn't
affect me. It also doesn't change the core git data structures in any way
to introduce any new problems.
Also, if there isn't a required piece of history, things generally break
very loudly. IOW, there are only certain things you can do with a shallow
repo. In general it's absolutely _not_ a "no big deal" issue, quite the
reverse - it's a deal-breaker.
Linus
^ permalink raw reply
* Re: Commit 140b378d07229e breaks gitk highlighting
From: Karl Hasselström @ 2008-09-10 16:01 UTC (permalink / raw)
To: Mark Levedahl; +Cc: Git Mailing List, Paul Mackerras
In-Reply-To: <30e4a070809090531i6c6dd2c8r189e70927b5444c9@mail.gmail.com>
On 2008-09-09 08:31:19 -0400, Mark Levedahl wrote:
> gitk since the above commit ("Teach git diff-tree --stdin to diff
> trees") fails to reliably highlight commits matching a given path
> specification.
Hmmm, not good. Any idea of what git commands gitk actually runs in
your example? Would be nice to be able to diff the output before and
after the change.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Paolo Bonzini @ 2008-09-10 15:37 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Stephen R. van den Berg, Jakub Narebski, git
In-Reply-To: <alpine.LFD.1.10.0809100830570.3384@nehalem.linux-foundation.org>
Linus Torvalds wrote:
>
> On Wed, 10 Sep 2008, Paolo Bonzini wrote:
>> Not really local data. More like _weakly referenced_ data. If it is
>> there, cool. If it is not there, no big deal.
>
> You think it's "cool".
>
> I think it is "unreliable, random, and depends on the phase of the moon".
I think that shallow clones are not any different from this. If the
required piece of history is there, cool. If they're not there, no big
deal.
I understood the hyperbole, but I think that it's not unreliable,
because all it relies on is the uniqueness of SHA1 values.
Paolo
^ permalink raw reply
* Re: [StGit PATCH] Add support for initializing a branch for stgit from Emacs.
From: Karl Hasselström @ 2008-09-10 15:58 UTC (permalink / raw)
To: David Kågedal; +Cc: Catalin Marinas, Git Mailing List
In-Reply-To: <878wu1904l.fsf@lysator.liu.se>
Thanks, that's a nice addition. (I haven't had the chance to try it
out yet, though.)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [StGit PATCH] Fixes for auto-generation of man pages
From: Karl Hasselström @ 2008-09-10 15:56 UTC (permalink / raw)
To: Daniel White; +Cc: Catalin Marinas, git
In-Reply-To: <20080909171721.2c7974a1@whitehouse.id.au>
On 2008-09-09 17:17:21 +1000, Daniel White wrote:
> stg.txt is the only man page not generated by stg-build --commands.
> Provide this page explicitly instead of including all other commands
> twice.
>
> stg-cmd-list.txt is only a template for inclusion in other man
> pages, so rename to stop it being built along with other stg-*
> files.
Thanks, this makes sense.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Linus Torvalds @ 2008-09-10 15:32 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: Stephen R. van den Berg, Jakub Narebski, git
In-Reply-To: <48C785C3.9010204@gnu.org>
On Wed, 10 Sep 2008, Paolo Bonzini wrote:
>
> Not really local data. More like _weakly referenced_ data. If it is
> there, cool. If it is not there, no big deal.
You think it's "cool".
I think it is "unreliable, random, and depends on the phase of the moon".
My definition of "cool" is a totally different thing. What you describe is
the very anti-thesis of cool.
If you want unreliable and random, use CVS. Please.
Linus
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Linus Torvalds @ 2008-09-10 15:30 UTC (permalink / raw)
To: Stephen R. van den Berg; +Cc: Jakub Narebski, git
In-Reply-To: <20080910054244.GB15715@cuci.nl>
On Wed, 10 Sep 2008, Stephen R. van den Berg wrote:
>
> But then how would someone who clones the repository get at the information?
You just said it wouldn't get there with fetches.
If clone acts differently from a "full" fetch, something is really really
wrong.
> The information is essential to understand backports between the various
> stable branches.
No it's not. You can mention the backport explicitly in the commit
message, and then you get hyperlinks in the graphical viewers. That works
when people _want_ it to work, instead of in some hidden automatic manner
that does entirely the wrong thing in all the common cases.
What more do you want?
Linus
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert, and more about porcelain-level metadata
From: Paolo Bonzini @ 2008-09-10 15:24 UTC (permalink / raw)
To: Stephen R. van den Berg; +Cc: Dmitry Potapov, git
In-Reply-To: <20080910151542.GA10523@cuci.nl>
> > > fork topic branches off the older branch [and merge them]
>
> Could you explain how the above mechanisms work based on the following
> cherry-pick action:
>
> A -- B -- C -- D -- L
> \ /
> E -- F -- G -- H -- K
>
> D is the stable branch.
> K is the development branch.
> G is cherry-picked and applied to D producing L.
> The origin link of L would have contained (G, F).
>
> How would such a workflow be implemented using the temporary branches
> you describe?
You don't. You do everything in topic branches based off the stable
branch, and you merge them. That's the other way round, compared to
what you (and I) are used to.
Paolo
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert, and more about porcelain-level metadata
From: Stephen R. van den Berg @ 2008-09-10 15:15 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: Paolo Bonzini, Petr Baudis, git
In-Reply-To: <20080910143329.GE28210@dpotapov.dyndns.org>
Dmitry Potapov wrote:
>On Wed, Sep 10, 2008 at 11:35:18AM +0200, Paolo Bonzini wrote:
>> Another problem is that in some projects actually there are two "maint"
>> branches (e.g. currently GCC 4.2 and GCC 4.3), and most developers do
>> not care about what goes in the older "maint" branch; they develop for
>> trunk and for the newer "maint" branch, and then one person comes and
>> cherry-picks into the older "maint" branch. This has two problems:
>> 1) Having to fork topic branches off the older branch would force extra
>> testing on the developers.
>If a branch is meant to included in the oldest version, it must be
>tested with that version anyway, and it is better when it is written for
>the old version, because functions tend to be more backward compatible
>than forward compatible. In other words, functions may often acquire
>some extra functionality over time without changing their signature, so
>the code written for a new version will merge without any conflict to
>the old one, but it won't work correctly under some conditions. It is
>certainly possible to have a problem in the opposite direction, but it
>is much less likely, and usually bugs introduced in the development
>version are not as bad as destabilizing a stable branch. Thus starting
>branch that is clearly meant for inclusion to the old version from that
>version is the right thing do.
>Of course, if you have more than one stable branch for a long time then
>you may want some branches forked from the new stable. You can do that
>by merging uninteresting changes from the new stable with the 'ours'
>strategy (so they will be ignored), and after that merging actually
>interesting features from the new stable.
>In contrast to cherry-picking, the real merge creates the history that
>can be easily visualized and understood.
Could you explain how the above mechanisms work based on the following
cherry-pick action:
A -- B -- C -- D -- L
\ /
E -- F -- G -- H -- K
D is the stable branch.
K is the development branch.
G is cherry-picked and applied to D producing L.
The origin link of L would have contained (G, F).
How would such a workflow be implemented using the temporary branches
you describe?
>If you clearly mark all bugs in the commit message, there will be no
>problem to find them by grepping log. There is a lot of potentially
Sometimes they're not bugs, yet they still are backported and thus carry
no special marks.
>useful information, and the 'origin' link is just one of many. It may
True, but it's one of the few machine-useable ones.
>be okay to do some general mechanism for custom commit attributes (if
>it's really necessary),
That's the problem, a general mechanism is undesirable, that we already
have the free-form textfield for.
> but making a hack for one specific item of
>information feels very wrong.
It's a rather well-defined usefull property (which precludes it from
being a hack, I suppose).
--
Sincerely,
Stephen R. van den Berg.
"Am I paying for this abuse or is it extra?"
^ permalink raw reply
* Re: [PATCH] git-svn: Fixes my() parameter list syntax error in pre-5.8 Perl
From: Marcus Griep @ 2008-09-10 15:11 UTC (permalink / raw)
To: Git Mailing List; +Cc: Eric Wong, Junio C Hamano, Tom G. Christensen
In-Reply-To: <1221059386-3972-1-git-send-email-marcus@griep.us>
Sorry:
Signed-off-by: Marcus Griep <marcus@griep.us>
Marcus Griep wrote:
> ---
>
> Per Tom G. Christensen's commentary on a breaking test in git-svn.
>
> git-svn.perl | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/git-svn.perl b/git-svn.perl
> index ecacf74..a97e1ca 100755
> --- a/git-svn.perl
> +++ b/git-svn.perl
> @@ -4425,7 +4425,7 @@ sub config_pager {
>
> sub run_pager {
> return unless -t *STDOUT && defined $pager;
> - pipe my $rfd, my $wfd or return;
> + pipe my ($rfd, $wfd) or return;
> defined(my $pid = fork) or ::fatal "Can't fork: $!";
> if (!$pid) {
> open STDOUT, '>&', $wfd or
--
Marcus Griep
GPG Key ID: 0x5E968152
——
http://www.boohaunt.net
את.ψο´
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Jeff King @ 2008-09-10 15:10 UTC (permalink / raw)
To: Stephen R. van den Berg; +Cc: Theodore Tso, Petr Baudis, git
In-Reply-To: <20080910141630.GB7397@cuci.nl>
On Wed, Sep 10, 2008 at 04:16:30PM +0200, Stephen R. van den Berg wrote:
> >Once you have this information, it is not difficult to maintain a
> >berk_db database which maps a particular Bug identifier (i.e.,
> >Red_Hat/149480, or Debian/471977, or Launchpad/203323) to a series of
> >commits.
>
> This is nice, I admit, but it has the following downsides:
> - It is nontrivial to automate this on execution of "git cherry-pick".
Maybe a cherry-picking hook?
> - In a distributed environment this requires a network-reachable bug
> database.
Use a distributed bug tracking system (DBTS).
> - A network-reachable bug database means that suddenly git needs network
> access for e.g. cherry-pick, revert, gitk, log --graph, blame.
Use a DBTS.
> - Network queries for commits containing references kind of kills
> performance.
Use a DBTS.
> - Some backports don't have entries in a bug database because they
> weren't bugs to begin with, in which case it becomes impossible to add
> an identifier to the commit message after the fact.
Use a DBTS, since then you can generally make up a new UUID on the spot.
> - It relies heavily on tools outside of git-core, which raises the
> threshold for using it.
True.
But maybe Ted is on to something here. Rather than adding the
information to the commit object itself, why not maintain a separate
mapping, but keep it _within git_. That is how most of the DBTS's work
that I have seen. Maybe it is possible to implement some subset of the
features in a tool that could become part of core git.
There was a proposal at some point for a "notes" feature which would
allow after-the-fact annotation of commits. I don't recall the exact
details, but I think it stored its information as a git tree of blobs.
You could choose whether or not to transfer the notes based on
transferring a ref pointing to the notes tree.
I'm not sure how applicable this is to your problem, but if you want to
investigate you can find discussion in the list archive under the name
"notes".
-Peff
^ permalink raw reply
* [PATCH] git-svn: Fixes my() parameter list syntax error in pre-5.8 Perl
From: Marcus Griep @ 2008-09-10 15:09 UTC (permalink / raw)
To: Git Mailing List
Cc: Eric Wong, Junio C Hamano, Tom G. Christensen, Marcus Griep
In-Reply-To: <48C7745F.1070008@statsbiblioteket.dk>
---
Per Tom G. Christensen's commentary on a breaking test in git-svn.
git-svn.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index ecacf74..a97e1ca 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -4425,7 +4425,7 @@ sub config_pager {
sub run_pager {
return unless -t *STDOUT && defined $pager;
- pipe my $rfd, my $wfd or return;
+ pipe my ($rfd, $wfd) or return;
defined(my $pid = fork) or ::fatal "Can't fork: $!";
if (!$pid) {
open STDOUT, '>&', $wfd or
--
1.6.0.1.415.g7bb82
^ permalink raw reply related
* Re: [RFC] origin link for cherry-pick and revert, and more about porcelain-level metadata
From: Dmitry Potapov @ 2008-09-10 14:33 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: Petr Baudis, Stephen R. van den Berg, git
In-Reply-To: <48C794D6.20001@gnu.org>
On Wed, Sep 10, 2008 at 11:35:18AM +0200, Paolo Bonzini wrote:
>
> Junio explained that the way achieves the same effect in git is by
> forking the topic branch off the "oldest" branch where the patch will
> possibly be of interest. Then he can merge it in that branch and all
> the newest ones. That's great, but not all people are as
> forward-looking (he did say that sometimes he needs to cherrypick).
Those who base their work on the newest ones must be very forward-
looking :) but, seriously, cherry-picking is *not* a normal workflow
with Git. Git is optimized for easy merging while cherry-picking is
a rare operation reserved for correcting some past mistakes.
>
> Another problem is that in some projects actually there are two "maint"
> branches (e.g. currently GCC 4.2 and GCC 4.3), and most developers do
> not care about what goes in the older "maint" branch; they develop for
> trunk and for the newer "maint" branch, and then one person comes and
> cherry-picks into the older "maint" branch. This has two problems:
>
> 1) Having to fork topic branches off the older branch would force extra
> testing on the developers.
If a branch is meant to included in the oldest version, it must be
tested with that version anyway, and it is better when it is written for
the old version, because functions tend to be more backward compatible
than forward compatible. In other words, functions may often acquire
some extra functionality over time without changing their signature, so
the code written for a new version will merge without any conflict to
the old one, but it won't work correctly under some conditions. It is
certainly possible to have a problem in the opposite direction, but it
is much less likely, and usually bugs introduced in the development
version are not as bad as destabilizing a stable branch. Thus starting
branch that is clearly meant for inclusion to the old version from that
version is the right thing do.
Of course, if you have more than one stable branch for a long time then
you may want some branches forked from the new stable. You can do that
by merging uninteresting changes from the new stable with the 'ours'
strategy (so they will be ignored), and after that merging actually
interesting features from the new stable.
In contrast to cherry-picking, the real merge creates the history that
can be easily visualized and understood.
>
> 2) Besides this, topic branches are not cloned, so if I am the
> integrator on the older "maint" branch, I need to dig manually in the
> commits to find bugfixes. True, I could use Bugzilla, but what if I
> want to use git instead? There is "git cherry -v ... | grep -w ^+.*PR",
> except that it has too many false negatives (fixes that have already
> been backported, but do show up in the list).
If you clearly mark all bugs in the commit message, there will be no
problem to find them by grepping log. There is a lot of potentially
useful information, and the 'origin' link is just one of many. It may
be okay to do some general mechanism for custom commit attributes (if
it's really necessary), but making a hack for one specific item of
information feels very wrong. In fact, I have not convinced at all
that the free-form text is not suitable to store this information.
Dmitry
^ permalink raw reply
* Re: [guilt] Bug with guilt patchbomb
From: Josef 'Jeff' Sipek @ 2008-09-10 14:18 UTC (permalink / raw)
To: Thomas Petazzoni; +Cc: git
In-Reply-To: <20080909101234.070f2fdd@surf>
On Tue, Sep 09, 2008 at 10:12:34AM +0200, Thomas Petazzoni wrote:
> Hi,
>
> I'm using guilt 0.28-1 (Ubuntu package) and git-core 1.5.4.3-1ubuntu2.
> When I use guilt patchbomb, I get some scary output from git-rev-list:
How exactly did you invoke patchbomb?
Is this still a problem with a more recent guilt? (e.g., 0.31.1)
Thanks,
Josef 'Jeff' Sipek.
--
The box said "Windows XP or better required". So I installed Linux.
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Stephen R. van den Berg @ 2008-09-10 14:16 UTC (permalink / raw)
To: Theodore Tso; +Cc: Petr Baudis, git
In-Reply-To: <20080910122118.GI21071@mit.edu>
Theodore Tso wrote:
>On Wed, Sep 10, 2008 at 12:56:03AM +0200, Stephen R. van den Berg wrote:
>use. One of the problems with the origin link is that it is only a
>one way pointer. Given a newer commit, you know that it is (somehow)
>weekly related to a older commit. So your proposed workflow only
>works if cherry-picks only happen in one direction. That isn't always
>true, especially in distributed environments where the bugfix might
>happen on someone else's development branch, and then it gets pulled
>in, or perhaps rebased in, and you want to know they are related.
Well, the definition of the origin link (and a back/forwardport) is that:
- You (as a developer) consider the link relevant for posterity (IOW,
you consider it to be a proper back/forwardport which should be
recognisable as such).
- The back/forwardport always has to reference some existing (stable) commit.
Especially the second condition always holds at the time of creation of
the backport (or forwardport, for that matter). I'm not quite sure
which circumstances you allude to above which would violate this
requirement, can you elaborate on that?
>I would argue the best way to do that is to store (either in the
>object or in the free-form text area) not the link, which would have
>to get renumbered but rather the identifier for the bug(s) that this
The renumbering is not a problem, renumbering is a rare operation since
a project's history is supposed to be stable. And even if renumbering
is performed, it is a well understood operation of which the renumbering
of the origin links imposes a negligible overhead on top of the existing
renumbering overhead.
>commit fixes. So for example, consider a convention where in the body
>of the free-form text area, before the Signed-off-by:, Acked-by:, and
>CC: headers for those projects that use them, we add something like
>the following:
>Addresses-Bug: Red_Hat/149480, Sourceforge_Feature/120167
>or
>Addresses-Bug: Debian/432865, Launchpad/203323, Sourceforge_Bug/1926023
>Once you have this information, it is not difficult to maintain a
>berk_db database which maps a particular Bug identifier (i.e.,
>Red_Hat/149480, or Debian/471977, or Launchpad/203323) to a series of
>commits.
This is nice, I admit, but it has the following downsides:
- It is nontrivial to automate this on execution of "git cherry-pick".
- In a distributed environment this requires a network-reachable bug
database.
- A network-reachable bug database means that suddenly git needs network
access for e.g. cherry-pick, revert, gitk, log --graph, blame.
- Network queries for commits containing references kind of kills
performance.
- Some backports don't have entries in a bug database because they
weren't bugs to begin with, in which case it becomes impossible to add
an identifier to the commit message after the fact.
- It relies heavily on tools outside of git-core, which raises the
threshold for using it.
>The advantage of this scheme is that if a bug has been fixed in
>multiple branches, you can see the association between two commits in
>two different branches very easily. Furthermore, you get a link back
>to the actual bug in one or more bug tracking systems, which the some
>porcelain program could use to transform into a hot-link which when
>clicked opens up a browser window to the bug in question.
I'm not opposed to links like this, but I consider them a useful extra.
The link back is computationally of the same order of magnitude to find
all existing children of a certain commit; which is well understood and
within reach in most cases.
>In contrast, using your proposed origin scheme, if the bug was
>originally created in some development branch, and then cherry picked
>into two separate maintenance branches, if you don't have the
>development branch in your repository (maybe for some reason that
>development branch wasn't kept for some reason), the origin link in
>the two maintenance branches would point to a non-existent commit ID,
>and you wouldn't be able to estabish a linkage between them. By using
Yes, you would. You'd notice that either:
- One origin will point to the other commit (recommended practice,
cherry-pick ripple-through, so to speak).
- Both origin links point to the same non-existent commit.
>In terms of your arguments about why free-form is bad, in another message:
>>- No strict definition of what it means.
>>- Diverging porcelain implementations making use of the field in ever so
>> slightly changing ways over the years.
>This can be a problem regardless of where you store the information.
True. The point is that specifying a definition for a origin
headerfield will narrow down how it is and can be used. Free-form is
just that, free-form, and merely defines things by convention.
>Whether you store it in the free-form text or in the git object
>header, if you don't make sure it is well-defined, you're in trouble.
Free form can take the form of plaintext explanations detailing the
relationship in a foreign language (worst case example).
>>- You cannot rely on the field being always available.
>This is true regardless of where you store it; older versions of git
>won't store the git origin link, for example, unless you plan to break
>backwards compatibility with all existing git repositories, which
>would be a bad idea. :-)
True. What I was alluding to, is that if someone includes a
back/forwardport link in the free-form part of the commit message, then
you cannot predict how they'll do that. In case of the origin link,
*if* it is used, it will always look the same.
>One nice thing of using text in free-form text fields is that anyone
>can enter it without needing a new version of git. The downside is
Git is rather portable, I'd say, so anyone wanting to use the new
feature can be bothered to upgrade.
>that people could typo the header in some fashion. But that can be
>dealt with in a newer version of the git porcelain validates the bug
>identifier and/or checks for obvious spelling mistakes and issues a
>warning ("Looks like you may have mispelled 'Adresses-Bug'; perhaps
>you should fix this via git commit --amend?").
You mean you'd prefer some kind of AI solution to aid the user in
writing misspelling-free bug identifiers over a simple clean origin link
in the header of a commit message?
>In contrast, if you put it in the git object header, there is no
>possibility of using the field at all until you update to a version of
>git that supports it. And some developer on your project is using an
>older version of git when they rebase or cherry-pick a commit, the
>origin header will be completely lost; but if it is stored in the
>free-form area, the information will be brought along for the ride for
>free.
Same as above:
If developers care about the backport information, they *can* be
bothered to upgrade git. It's not rocketscience.
>>- Automated "renumbering" becomes difficult at best.
>This is actually one of the reasons why I don't like the origin link.
>If you use the origin link, it's *still* not obvious whether you
>should rewrite the commit ID or not. For example, in some workflows,
>you have two branches pointing to the same commit before you do the
>rebase, where the rebase will only update the current branch pointer,
>but there is another branch still pointing at the original series of
>commits. Worse yet, someone may have done a cherry-pick *before* the
>rebase. Hence, the only thing you can do is keep *both* commit ID's.
>This means that over time, you can't get rid of any commit ID's when
>you do a rebase, which means the number of commit ID's in the origin
>link will always increase whenever you do a rebase or a cherry-pick.
The recommended practice here is quite simple:
- Origin links should only be created pointing to stable commits (i.e.
commits which you'd be willing to publish or already have published).
- This implies that pointing an origin link at a commit in a strain that
you still want to rebase is asking for trouble. Doing this is akin to
doing a merge between two branches and then you start rebasing 4
commits *below* the mergepoint. Don't do that.
- The only special case I'd allow is if you rebase a strain and the
origin link points from one of the commits in the strain to be rebased
back *into* the same strain being rebased (most likely a revert).
Rebase can be bothered to renumber the origin link in this case.
And when you stick to those rules, the problem you're describing doesn't
happen.
>This is why for the use case where you are trying to figure out
>whether a bug exists in a particular branch, it is ***much*** better
>to rendevous using a bug identifier; it provides an extra layer of
>indirection which results in a much more stable identifer that is
>guaranteed to work.
Unless that commit already lies in the past, and you have no way to
actually add the bugid to the commit.
>(and I am not convinced that you do), the ***much*** better approach
>is to use the same approach as the bug tracking identifier, and add a
>level of indirection. How would that work in practice? Whenever you
>create a new commit, create a UUID which is assigned to the patch.
This only works if you know at time of commit that you want to backport
it at some later date.
>Now, whether you store this UUID in the free-form text area, or in the
>git object header, in the long run really doesn't matter. You can
>just as easily have porcelein suppress a line in the free-form text
>area, as you can have the procelain print the UUID when it is stored
>in the object header.
True. It's almost as much work. Though it seems rather silly to start
suppressing lines in the free-form text area, if one can add a proper
headerfield.
>Yes, it means that you have to maintain a separate database so you can
>easily find the list of commits that contain a particular UUID, but I
>suspect you would need this in the case of the origin link concept
>anyway, since sooner or later some of the more useful uses of said
>link would require you to be able to find the commits which had origin
>links to the original commit, which means you would need to create and
>maintain this database anyway.
That isn't true. Finding commits which have origin links to a certain
commit is just as hard as finding all children of a certain commit.
It's not exactly instant, but it is not a big problem, and depending on
the amount of repositorytraversal you already are doing, it might even
be a negligible amount of extra overhead.
> And the maintenance of this database
>is purely optional; you only need it if you care about efficiently
>looking up UUID's, and given "time git log > /dev/null" on the kernel
>tree only takes six seconds on my laptop, and "git log > /dev/null"
>only takes 0.148 seconds for e2fsprogs, for many projects you might
>not even need the database to accelerate lookups via UUID.
The database needs to be available to anyone doing a clone of the
repository, which implies that:
- It needs to be network based.
- It needs controlled write access (which is a mess).
- It is slow during blame/gitk operations.
- It is rather nontrivial to get things setup such that someone (after
cloning the repository) is able to run cherry-pick/gitk/blame/revert
and have those commands use the database transparently.
--
Sincerely,
Stephen R. van den Berg.
"Am I paying for this abuse or is it extra?"
^ permalink raw reply
* Re: [PATCH 0/3] git-svn-externals PoC (in a sh script)
From: Eddy Petrișor @ 2008-09-10 13:59 UTC (permalink / raw)
To: git
In-Reply-To: <60381eeb0809100656u1117cfb6i72e327495d513f9c@mail.gmail.com>
2008/9/10 Eddy Petrișor <eddy.petrisor@gmail.com>:
> (Please keep the CC. Thanks)
> I already have/wrote some code that follows the remote HEAD or a
> specific for the necessary, but I am unsure if is still present in the
That was supposed to be:
> specific revision for such cases, but I am unsure if is still present in the
--
Regards,
EddyP
=============================================
"Imagination is more important than knowledge" A.Einstein
^ permalink raw reply
* Re: [PATCH 0/3] git-svn-externals PoC (in a sh script)
From: Eddy Petrișor @ 2008-09-10 13:56 UTC (permalink / raw)
To: git
In-Reply-To: <20080829092927.GA7500@yp-box.dyndns.org>
(Please keep the CC. Thanks)
2008/8/29 Eric Wong <normalperson@yhbt.net>:
> Eddy Petrișor <eddy.petrisor@gmail.com> wrote:
>> Hello,
>
> Hi Eddy,
Hello and sorry for the late reply.
(I was on a small vacation away from the computer in the last two weeks.)
>> I have started a while back working on support for svn:externals
>> support for git-svn, but since I'm not that satisfied with the current
>> status of the patch, I haven't modified git-svn itself and just left
>> the sh script I made as a PoC as it was.
>>
>> There's still work to be done to it, but I the current version is
>> functional enough to be probably found useful by more people than
>> myself.
>
> Cool.
>
> I definitely like the separate script approach. Not sure if you read my
> posts, your PoC seems inline with my thoughts on handling externals be
> seen here:
>
> http://article.gmane.org/gmane.comp.version-control.git/91283
> http://article.gmane.org/gmane.comp.version-control.git/91293
WRT the revision pinning, it seems to me that is enough to locate that
revision on the URI in question and checkout that revision. Still I am
unsure if it would be wise to (stash +) svn rebase + checkout the
pinned version (+ stash pop), since one would needlessly pull newer
stuff as the remote svn HEAD advances, but the pinned version might
simply stagnate.
I already have/wrote some code that follows the remote HEAD or a
specific for the necessary, but I am unsure if is still present in the
PoC script, is not that hard (in sh - a "svn info" on the URI, not on
the local copy would reveal the real revision of the HEAD).
>> Current status follows:
>>
>> Current functionality:
>> - fetches all the externals of an already svn-fetched repo
>> - support for svn:externals refresh
>> - if the location of the external has changed, the current working
>> copy will be placed aside and a new directory will be created
>> instead
>> - if the remote URI is the same (maybe a verison bump, there will
>> be a 'git svn rebase'
>> - remove support (useful for testing purposes or clean restarts)
>> - avoid zombie externals at all costs - in some repos empty
>> svn:externals might exist; svn ignores such externals, so git should
>> do the same
>>
>> TODO:
>> - take into account the revision of an external, if it exists
>> - do not do deep svn cloning, to avoid legthy operations, just pull HEAD
>> (this actually needs changes in git-svn itself)
>
> git svn clone -r<latest_revision_number> URL should work if you extract
> the revision number easily.
Why was I under the impression that this wasn't working? Or was I
expecting a shallow repo?
> Specifying "-rHEAD" will only work if the
> branch of the external you're tracking was the last modified revision in
> the repository, so it's not very useful.
as I already said, "svn info URI" can return the real revision, no
need to ness with the pseudo-revision HEAD.
> "svn log" seems to have the
> same semantics as git-svn as far as -rHEAD being useful or not...
>
>> - use/create shallow copies to git svn repos (one revision should be enough
>> for most externals)
>> - use submodules for externals
>
> I'm not sure if mapping submodules to externals is a good idea
> because externals don't require exact revisions and submodules do.
I don't think I can follow you. Externals actually require exact
revisions or can be made to pretend as if they do in git-svn context
with continuous HEAD refresh.
> There's also an issue I was just made aware of two days ago with
> submodules and git-svn that I haven't had time to work on.
>
> Another user also privately reported a bug to me about git-svn having
> trouble dcommitting when using submodules. I've attached the test case
> here in case you have any thoughts on how to handle this (I think the
> easiest would be to ignore submodules on dcommit entirely).
Probably, and try later to tackle the problem.
>> Any comments are welcome.
>
> Also some small portability issues: "grep -q" is definitely unportable
> in my experience. There are probably some more that I am missing my eye
> at this time of night...
Will fix it.
--
Regards,
EddyP
=============================================
"Imagination is more important than knowledge" A.Einstein
^ permalink raw reply
* Re: rsync vs. git-push/pull ? (+kudus)
From: david @ 2008-09-10 13:27 UTC (permalink / raw)
To: Ramagudi Naziir; +Cc: git
In-Reply-To: <dfb262380809092331i3399731cqdec3b2bb79d2fcdd@mail.gmail.com>
On Wed, 10 Sep 2008, Ramagudi Naziir wrote:
> Hi David,
>
> On Sun, Sep 7, 2008 at 9:27 AM, <david@lang.hm> wrote:
>> On Sun, 7 Sep 2008, Ramagudi Naziir wrote:
>>
>>> Hi all,
>>>
>>> I have several local git repositories on my machine. I'm the only
>>> user, and use them only locally. Now, sometimes when I need to work
>>> remotely, I just rsync my repositories to my laptop, and keep working
>>> there. When I finish (few hours, days or sometimes weeks later), I
>>> just rsync everything back to my local git repositories on my main
>>> workstation, and continue working there.
>>>
>>> Now I was wondering whether it's OK or whether there are bad
>>> implication I might not think of working this way. For example, maybe
>>> some of these little git files are named differently on each machine,
>>> and rsyncing them back and forth makes me piling a lot of clutter (in
>>> that case maybe git-gc will clean up everything). Or maybe something
>>> else horrid is going on and I really should just use git-push or pull.
>>
>> the git files are names by their content so you don't need to worry about
>> them being named differently
>
> But can I end up having a lot of clutter ? e.g. if these files change,
> then rsync will copy the new files, and the old ones will still be
> kept, piling up like crud. is this correct ? is it problematic ? will
> git-gc fix it ?
git keeps copies of all the old files around anyway (that's it's purpose
after all ;-)
when git gc runs it creates pack files to replace the individual files,
but unless you run git gc --prune it does not remove anything and the
individual files hang around.
so when you do the rsync back and forth you should have it delete files
from the target that aren't on the source (or run git gc --prune
afterwords)
David Lang
^ 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