* 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
* Re: [RFC] origin link for cherry-pick and revert, and more about porcelain-level metadata
From: Stephen R. van den Berg @ 2008-09-10 13:14 UTC (permalink / raw)
To: Petr Baudis; +Cc: Paolo Bonzini, git
In-Reply-To: <20080910123026.GJ10360@machine.or.cz>
Petr Baudis wrote:
>On Wed, Sep 10, 2008 at 01:49:40PM +0200, Stephen R. van den Berg wrote:
>> Maybe we have a misunderstanding about what "follow a link" means and
>> when it is done.
>Oh, I'm sorry. By
> - During fetch/push/pull the full commit including the origin fields is
> transmitted, however, the objects the origin links are referring to
> are not (unless they are being transmitted because of other reasons).
>I have understood that you fetch the origin target but not commits
>referred from it, but instead you meant that you do not follow the
>origin link at all.
Indeed.
--
Sincerely,
Stephen R. van den Berg.
"Am I paying for this abuse or is it extra?"
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert, and more about porcelain-level metadata
From: Petr Baudis @ 2008-09-10 12:30 UTC (permalink / raw)
To: Stephen R. van den Berg; +Cc: Paolo Bonzini, git
In-Reply-To: <20080910114940.GA14127@cuci.nl>
On Wed, Sep 10, 2008 at 01:49:40PM +0200, Stephen R. van den Berg wrote:
> Maybe we have a misunderstanding about what "follow a link" means and
> when it is done.
> During most normal git operation, the origin links are just read, but
> not followed.
> The only commands that I expect to follow them are log --graph, gitk, fsck
> and blame. I may have missed some corner use-cases, but this should
> cover most of it; i.e. most of git ignores them or just makes note of
> the hashvalues provided.
Oh, I'm sorry. By
- During fetch/push/pull the full commit including the origin fields is
transmitted, however, the objects the origin links are referring to
are not (unless they are being transmitted because of other reasons).
I have understood that you fetch the origin target but not commits
referred from it, but instead you meant that you do not follow the
origin link at all.
Petr "Pasky" Baudis
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Theodore Tso @ 2008-09-10 12:21 UTC (permalink / raw)
To: Stephen R. van den Berg; +Cc: Petr Baudis, git
In-Reply-To: <20080909225603.GA7459@cuci.nl>
On Wed, Sep 10, 2008 at 12:56:03AM +0200, Stephen R. van den Berg wrote:
> The purpose I'd use the origin links for is to manage software projects
> that consist of 7 main branches which have branched in (on average) two
> year intervals, which never get merged anymore. The only thing that
> happens is that there are backports amongst the branches about two per
> week.
>
> The only way to perform the backports is by using cherry-pick.
> The history of each backport *is* important though.
> Since all the developers who care about the multiple release branches
> have all the relevant branches in their repository, the presence of
> a origin object is by no means random, it's a certainty.
I'd argue that the origin link is a bit too general for your proposed
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.
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
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.
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.
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
an independent bug identifer as the way of creating the linkage,
you're preserving *much* more useful information, and you can reliably
establish a relationship between two commits.
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.
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.
>- 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. :-)
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
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?").
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.
>- 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.
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.
I understand it won't work for those cases where you don't have a bug
tracking identifer, but in fact, if you need this functionality at all
(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 UUID is not modified by git rebase or git cherry pick, and it
should be optionally kept or modified on a git commit --amend.
Ideally, said UUID would exported via git-format-patch, and imported
via git-am, and via systems that use patches, such as guilt or stg.
This becomes a handy way of recognizing patches even if they aren't
being stored in git --- for example, Andrew Morton's mm patch series.
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.
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. 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.
- Ted
^ permalink raw reply
* Re: [RFC/PATCH] Use compatibility regex library for OSX/Darwin
From: Mike Ralphson @ 2008-09-10 11:53 UTC (permalink / raw)
To: Arjen Laarhoven, Johannes Sixt; +Cc: git
In-Reply-To: <20080910100301.GA27748@regex.yaph.org>
2008/9/10 Arjen Laarhoven <arjen@yaph.org>:
> On Wed, Sep 10, 2008 at 09:03:05AM +0100, Mike Ralphson wrote:
>> 2008/9/7 Arjen Laarhoven <arjen@yaph.org>
>> > The standard libc regex library on OSX does not support alternation
>> > in POSIX Basic Regular Expression mode. This breaks the diff.funcname
>> > functionality on OSX.
>> >
>> > Also, I'm sure the problem occurs on more non-Linux systems (or non
>> > GNU libc systems). If people who have access to those systems (BSD's,
>> > HP-UX, AIX, etc) can test it, I'd be happy to add those systems to the
>> > patch so it can fix for multiple systems at once.
>>
>> I can confirm that the issue shown up by your new testcase is also
>> present in AIX 5.3.
>> Adding -lcompat/regex to COMPAT_CFLAGS as per your Darwin hunk
>> provokes lots of warnings:
>
> I think your problem is a lowercase ell instead of an uppercase i ;-)
Doh. I think my problem is this font! And having not used a language
with a separate linker since last century.
I guess I picked a really bad patch to try and pick up and test direct
from gmail. No reflection on your patch, just my workflow.
Having carefully checked the content of the testcase too, I can now
say this does fix the issue without extra warnings or testcase
failures on AIX 5.3, so for what it's worth:
Tested-by: Mike Ralphson <mike@abacus.co.uk>
Thanks both, and sorry for the noise.
Mike
^ 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 11:49 UTC (permalink / raw)
To: Petr Baudis; +Cc: Paolo Bonzini, git
In-Reply-To: <20080910104424.GH10360@machine.or.cz>
Petr Baudis wrote:
>On Wed, Sep 10, 2008 at 11:35:18AM +0200, Paolo Bonzini wrote:
>But that is irrelevant. If you already have the objects, whether to
>follow the origin link does not matter at all.
>I argue that the following the origin link by one step is harmful as it
>violated the internal Git object model and does not have real benefits.
>If you want to have the origin links, do not follow them at all - the
>commit objects themselves are not useful. (Or, optionally, follow them
>fully - that of course can make sense.)
The origin links are rarely followed, not even by one step. They are
only followed if a certain operation requires them (not a lot do).
>> > 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).
>(BTW, I don't feel strongly enough about the header-freeform distinction
>to argue about it and some of your and others' points are good. But even
>if we have the origin links, I think we should only follow them not at
>all or fully.)
Maybe we have a misunderstanding about what "follow a link" means and
when it is done.
During most normal git operation, the origin links are just read, but
not followed.
The only commands that I expect to follow them are log --graph, gitk, fsck
and blame. I may have missed some corner use-cases, but this should
cover most of it; i.e. most of git ignores them or just makes note of
the hashvalues provided.
--
Sincerely,
Stephen R. van den Berg.
"Am I paying for this abuse or is it extra?"
^ permalink raw reply
* Re: [PATCH 6/6] t9400, t9401: use "git cvsserver" without dash
From: Nanako Shiraishi @ 2008-09-10 11:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vljy13sq0.fsf@gitster.siamese.dyndns.org>
Quoting Junio C Hamano <gitster@pobox.com>:
> * We always install "server side programs" in $(bindir).
>
> I think git-cvsserver is the last one we missed from the set of server
> side programs (git-cvsserver, git-daemon, git-receive-pack,
> git-upload-archive, git-upload-pack).
-- %< --
Subject: [PATCH] Install git-cvsserver in $(bindir)
It is one of the server side programs and needs to be found on usual $PATH.
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
---
Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index f4c31c8..92a109f 100644
--- a/Makefile
+++ b/Makefile
@@ -1368,7 +1368,7 @@ install: all
$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(bindir_SQ)'
$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(gitexec_instdir_SQ)'
$(INSTALL) $(ALL_PROGRAMS) '$(DESTDIR_SQ)$(gitexec_instdir_SQ)'
- $(INSTALL) git$X git-upload-pack$X git-receive-pack$X git-upload-archive$X git-shell$X '$(DESTDIR_SQ)$(bindir_SQ)'
+ $(INSTALL) git$X git-upload-pack$X git-receive-pack$X git-upload-archive$X git-shell$X git-cvsserver$X '$(DESTDIR_SQ)$(bindir_SQ)'
$(MAKE) -C templates DESTDIR='$(DESTDIR_SQ)' install
$(MAKE) -C perl prefix='$(prefix_SQ)' DESTDIR='$(DESTDIR_SQ)' install
ifndef NO_TCLTK
--
1.6.0.1
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply related
* Re: [RFC] origin link for cherry-pick and revert, and more about porcelain-level metadata
From: Petr Baudis @ 2008-09-10 10:44 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: 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:
>
> > Why do you actually *follow* the origin link at all anyway? Without its
> > parents, the associated tree etc., the object is essentially useless for
> > you
>
> Stephen posed the origin links as weak, but it is not necessarily true
> that you don't have the parents and the associated tree. For example,
> if you download a repository that includes a "master" branch and a few
> stable branches, you *will* have the objects cherry-picked into stable
> branches, because they are commits in the master branch.
But that is irrelevant. If you already have the objects, whether to
follow the origin link does not matter at all.
I argue that the following the origin link by one step is harmful as it
violated the internal Git object model and does not have real benefits.
If you want to have the origin links, do not follow them at all - the
commit objects themselves are not useful. (Or, optionally, follow them
fully - that of course can make sense.)
> > 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).
(BTW, I don't feel strongly enough about the header-freeform distinction
to argue about it and some of your and others' points are good. But even
if we have the origin links, I think we should only follow them not at
all or fully.)
--
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: [PATCH v2] Git.pm: Use File::Temp->tempfile instead of ->new
From: Eric Wong @ 2008-09-10 10:09 UTC (permalink / raw)
To: Junio C Hamano
Cc: Marcus Griep, Git Mailing List, Tom G. Christensen,
Abhijit Menon-Sen
In-Reply-To: <7vwshkzmfv.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> Eric Wong <normalperson@yhbt.net> writes:
>
> > Marcus Griep <marcus@griep.us> wrote:
> >> Perl 5.8.0 ships with File::Temp 0.13, which does not have the new()
> >> interface introduced in 0.14, as pointed out by Tom G. Christensen.
> >>
> >> This modifies Git.pm to use the more established tempfile() interface
> >> and updates 'git svn' to match.
> >>
> >> Signed-off-by: Marcus Griep <marcus@griep.us>
> >> ---
> >>
> >> This patch v2 cleans up a few code items, corrects a misspelling,
> >> and ensures that the temp file gets unlinked when we exit, now
> >> that we are requesting the filename. Otherwise, the previous
> >> comments stand:
> >>
> >> Per the earlier patch versions by Abhijit Menon-Sen and Tom G. Christensen.
> >> Both of you may want to run a test and add your 'Tested-by' to the thread
> >> if everything works out before Eric Wong adds his 'Acked-by'.
> >
> > Thanks Marcus, this works for me.
> > (Perl 5.10.0, so no compatibility issues).
> >
> > <bikeshed>
> > Can we rename temp_fname() to temp_path(), though? "fname"
> > just doesn't look right in the API to me...
> > </bikeshed>
>
> Ok, so will you take the patch with bikeshed fixes and feed the result to
> me with a pull-request, or shall I do that myself? I do not mind doing
> this either way --- just trying to avoid duplicated work.
Please do it for me, thanks. I've been preoccuppied offline and need
sleep.
> This is a 'maint' material, right?
Yes, definitely.
--
Eric Wong
^ permalink raw reply
* Re: [RFC/PATCH] Use compatibility regex library for OSX/Darwin
From: Arjen Laarhoven @ 2008-09-10 10:03 UTC (permalink / raw)
To: Mike Ralphson; +Cc: git
In-Reply-To: <e2b179460809100103t4266650bnac00097cfb86c0b1@mail.gmail.com>
On Wed, Sep 10, 2008 at 09:03:05AM +0100, Mike Ralphson wrote:
> 2008/9/7 Arjen Laarhoven <arjen@yaph.org>
> > The standard libc regex library on OSX does not support alternation
> > in POSIX Basic Regular Expression mode. This breaks the diff.funcname
> > functionality on OSX.
> >
> > Also, I'm sure the problem occurs on more non-Linux systems (or non
> > GNU libc systems). If people who have access to those systems (BSD's,
> > HP-UX, AIX, etc) can test it, I'd be happy to add those systems to the
> > patch so it can fix for multiple systems at once.
>
> I can confirm that the issue shown up by your new testcase is also
> present in AIX 5.3.
Ok, I'll add AIX to the fix and a Tested-by: line.
[snip]
> Adding -lcompat/regex to COMPAT_CFLAGS as per your Darwin hunk
> provokes lots of warnings:
I think your problem is a lowercase ell instead of an uppercase i ;-)
Arjen
--
Arjen Laarhoven
The presence of those seeking the truth is infinitely to be preferred to
those who think they've found it.
-- Terry Pratchett, "Monstrous Regiment"
^ permalink raw reply
* Re: [RFH] git cherry-pick takes forever
From: Junio C Hamano @ 2008-09-10 10:00 UTC (permalink / raw)
To: Michal Vitecek; +Cc: git list
In-Reply-To: <20080910082610.GA3144@mageo.cz>
Michal Vitecek <fuf@mageo.cz> writes:
> Hello everyone,
>
> I have two git repositories: one is the origin of the other. However no
> merging is being done as the projects in the repositories quite differ
> but still use the same core. So to propagate changes I cherry-pick
> those which are useful from one repository to another.
>
> however 'git cherry-pick' has lately started to last almost forever:
Can you define "lately"? Is it a function of your git version, or is it a
function of the age of your repositories?
> $ time git cherry-pick b42b77e66a83f1298d9900a9bb1078b9b42e8618
> Finished one cherry-pick.
> Created commit 7caef83: - removed some superfluous newlines
> 2 files changed, 0 insertions(+), 2 deletions(-)
> git cherry-pick b42b77e66a83f1298d9900a9bb1078b9b42e8618 282.97s user 34.69s system 100% cpu 5:17.63 total
>
> Both repositories have approximately 16k commits and their forking
> point (merge base) is 250 to 490 commits far away.
When talking about cherry-pick, the size of the history (unless the
repository has too many objects and badly packed) does not matter; the
operation is purely about your current state, the cherry-picked commit
itself, and the parent commit of the cherry-picked one.
Taking 5 minutes to cherry-pick a change to only two paths, one line
deletion each, is plain ridiculous, but if the tree state of cherry-picked
commit and the tree state of the target is vastly different (e.g. almost
no common pathnames), the behaviour is certainly understandable. Ancient
git used straight three-way merge for cherry-pick, but recent ones use
more expensive "recursive-merge", which tries to detect renames. If the
states of trees are very dissimilar, you can end up wasting a lot of time.
$ H=$(git rev-parse 7caef83^) ;# the commit before cherry-pick
$ C=b42b77e6 ;# the cherry-picked one
cherry-pick operation roughly runs these two diffs:
$ time git diff --shortstat -M $H $C
$ time git diff --shortstat -M $H $C^1
and uses the result to perform its work. Can you clock these?
If you rarely have renames, it may be much more efficient to run "git
format-patch -1 --stdout $C | git am -3" instead of cherry-pick.
^ permalink raw reply
* Re: [RFC/PATCH] Use compatibility regex library for OSX/Darwin
From: Johannes Sixt @ 2008-09-10 9:49 UTC (permalink / raw)
To: Mike Ralphson; +Cc: Arjen Laarhoven, git
In-Reply-To: <e2b179460809100103t4266650bnac00097cfb86c0b1@mail.gmail.com>
Mike Ralphson schrieb:
> 2008/9/7 Arjen Laarhoven <arjen@yaph.org>
>> The standard libc regex library on OSX does not support alternation
>> in POSIX Basic Regular Expression mode. This breaks the diff.funcname
>> functionality on OSX.
>>
>> Also, I'm sure the problem occurs on more non-Linux systems (or non
>> GNU libc systems). If people who have access to those systems (BSD's,
>> HP-UX, AIX, etc) can test it, I'd be happy to add those systems to the
>> patch so it can fix for multiple systems at once.
The MinGW part of this patch works just fine:
Tested-by: Johannes Sixt <johannes.sixt@telecom.at>
> I can confirm that the issue shown up by your new testcase is also
> present in AIX 5.3.
...
> but I'm afraid I don't know how to get the combination of gcc + AIX ld
> to link to this in preference to the system defined regex functions.
Does this patchlet help? It gives no warnings or errors on my AIX 4.3.3
box and passes the new test (which fails without this).
diff --git a/Makefile b/Makefile
index 98d67f1..0637419 100644
--- a/Makefile
+++ b/Makefile
@@ -702,6 +702,8 @@ ifeq ($(uname_S),AIX)
INTERNAL_QSORT = UnfortunatelyYes
NEEDS_LIBICONV=YesPlease
BASIC_CFLAGS += -D_LARGE_FILES
+ COMPAT_CFLAGS += -Icompat/regex
+ COMPAT_OBJS += compat/regex/regex.o
endif
ifeq ($(uname_S),GNU)
# GNU/Hurd
^ permalink raw reply related
* Re: [PATCH v2] git-rebase-interactive: do not squash commits on abort
From: Johannes Schindelin @ 2008-09-10 9:53 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: Junio C Hamano, git
In-Reply-To: <20080909205036.GD28210@dpotapov.dyndns.org>
Hi,
On Wed, 10 Sep 2008, Dmitry Potapov wrote:
> On Tue, Sep 09, 2008 at 04:17:36PM +0200, Johannes Schindelin wrote:
> >_
> > It might be safer to set the variable "amend" to empty before the "if".
>
> OK. I have added it.
>
> git-rebase--interactive.sh | 8 ++++++--
> 1 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
> index 929d681..aaca915 100755
> --- a/git-rebase--interactive.sh
> +++ b/git-rebase--interactive.sh
> @@ -427,14 +427,18 @@ do
> else
> . "$DOTEST"/author-script ||
> die "Cannot find the author identity"
> + amend=""
Sorry, my mistake... I should have been more explicit. In most (if not
all) shell scripts, we prefer to set to the empty string with the
expression
amend=
Sorry to be nitting here, but I think it might be desirable in the long
run to have consistent code style, as it makes it a bigger pleasure to
work with the code.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert, and more about porcelain-level metadata
From: Paolo Bonzini @ 2008-09-10 9:35 UTC (permalink / raw)
To: Petr Baudis; +Cc: Stephen R. van den Berg, git
In-Reply-To: <20080909230525.GC10360@machine.or.cz>
> Why do you actually *follow* the origin link at all anyway? Without its
> parents, the associated tree etc., the object is essentially useless for
> you
Stephen posed the origin links as weak, but it is not necessarily true
that you don't have the parents and the associated tree. For example,
if you download a repository that includes a "master" branch and a few
stable branches, you *will* have the objects cherry-picked into stable
branches, because they are commits in the master branch.
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).
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.
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).
> 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 show: 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, could optionally be
followed when fetching (either with command-line or configuration options)
3) they would not be pruned by git-gc
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
* Re: [PATCH 0/2] Assist installing documentation with incomplete build chain
From: Michael J Gruber @ 2008-09-10 9:16 UTC (permalink / raw)
To: git
In-Reply-To: <cover.1221035620.git.michaeljgruber+gmane@fastmail.fm>
I hate to reply to myself, but I apologize for the failed threading.
That series has Message-Id: and In-Reply-To: fields set up
appropriately, but it doesn't show up threaded, at least not here. It
was an attempt at using Thunderbird, by writing format-patch output to
TB's outbox in mbox format (and adding a few lines). I'll try
differently next time (the approach with external editor + TB-config
changes isn't that comfortable either).
Michael
^ permalink raw reply
* [PATCH 2/2] separate build targets for man and html documentation
From: Michael J Gruber @ 2008-09-10 8:19 UTC (permalink / raw)
To: git
In-Reply-To: <cover.1221035620.git.michaeljgruber+gmane@fastmail.fm>
This introduces new build targets "man" and "html" which allow building
the documentation in the respective formats separately. This helps
people with a partial documentation build chain: html pages can be built
without xmlto.
This is documented in INSTALL now, together with corrections: Before,
instructions in INSTALL would build man+html but install man only. Now
the instructions build and install both, and new and pre-existing
targets are explained.
Note that build targets "doc" and "man" correspond to install targets
"install-doc install-html" and "install-doc" respectively. This
inconsistency is not changed, in order to keep everyone's build scripts
from breaking.
Signed-off-by: Michael J Gruber <michaeljgruber+gmane@fastmail.fm>
---
INSTALL | 15 ++++++++++++---
Makefile | 6 ++++++
2 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/INSTALL b/INSTALL
index 7c13473..a40d77d 100644
--- a/INSTALL
+++ b/INSTALL
@@ -6,7 +6,7 @@ will install the git programs in your own ~/bin/ directory. If you want
to do a global install, you can do
$ make prefix=/usr all doc info ;# as yourself
- # make prefix=/usr install install-doc install-info ;# as root
+ # make prefix=/usr install install-doc install-html install-info ;# as root
(or prefix=/usr/local, of course). Just like any program suite
that uses $prefix, the built results have some paths encoded,
@@ -19,7 +19,7 @@ set up install paths (via config.mak.autogen), so you can write instead
$ make configure ;# as yourself
$ ./configure --prefix=/usr ;# as yourself
$ make all doc ;# as yourself
- # make install install-doc ;# as root
+ # make install install-doc install-html;# as root
Issues of note:
@@ -89,13 +89,22 @@ Issues of note:
inclined to install the tools, the default build target
("make all") does _not_ build them.
+ "make doc" builds documentation in man and html formats; there are
+ also "make man", "make html" and "make info". Note that "make html"
+ requires asciidoc, but not xmlto. "make man" (and thus make doc)
+ requires both.
+
+ "make install-doc" installs documentation in man format only; there
+ are also "make install-man", "make install-html" and "make
+ install-info".
+
Building and installing the info file additionally requires
makeinfo and docbook2X. Version 0.8.3 is known to work.
The documentation is written for AsciiDoc 7, but "make
ASCIIDOC8=YesPlease doc" will let you format with AsciiDoc 8.
- Alternatively, pre-formatted documentation are available in
+ Alternatively, pre-formatted documentation is available in
"html" and "man" branches of the git repository itself. For
example, you could:
diff --git a/Makefile b/Makefile
index eeaf6d4..66e1982 100644
--- a/Makefile
+++ b/Makefile
@@ -1265,6 +1265,12 @@ $(XDIFF_LIB): $(XDIFF_OBJS)
doc:
$(MAKE) -C Documentation all
+man:
+ $(MAKE) -C Documentation man
+
+html:
+ $(MAKE) -C Documentation html
+
info:
$(MAKE) -C Documentation info
--
1.6.0.1.285.g1070
^ permalink raw reply related
* [PATCH 1/2] allow installation of man and html doc from the man and html branches
From: Michael J Gruber @ 2008-09-09 20:44 UTC (permalink / raw)
To: git
In-Reply-To: <cover.1221035620.git.michaeljgruber+gmane@fastmail.fm>
This patch introduces a make target "quick-install-html" which installs
the html documentation from the branch origin/html, without the need for
asciidoc/xmlto. This is analogous to the existing "quick-install-doc"
target for the man pages.
We advertise these targets in the INSTALL file now.
Signed-off-by: Michael J Gruber <michaeljgruber+gmane@fastmail.fm>
---
Documentation/Makefile | 4 ++++
INSTALL | 5 +++++
Makefile | 3 +++
3 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/Documentation/Makefile b/Documentation/Makefile
index 62269e3..ded0e40 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -44,6 +44,7 @@ MANPAGE_XSL = callouts.xsl
INSTALL?=install
RM ?= rm -f
DOC_REF = origin/man
+HTML_REF = origin/html
infodir?=$(prefix)/share/info
MAKEINFO=makeinfo
@@ -222,4 +223,7 @@ install-webdoc : html
quick-install:
sh ./install-doc-quick.sh $(DOC_REF) $(DESTDIR)$(mandir)
+quick-install-html:
+ sh ./install-doc-quick.sh $(HTML_REF) $(DESTDIR)$(htmldir)
+
.PHONY: .FORCE-GIT-VERSION-FILE
diff --git a/INSTALL b/INSTALL
index 2bae53f..7c13473 100644
--- a/INSTALL
+++ b/INSTALL
@@ -117,6 +117,11 @@ Issues of note:
http://www.kernel.org/pub/software/scm/git/docs/
+ There is also "make quick-install-doc" and "make quick-install-html"
+ which installs man pages resp. html documentation from these branches.
+ This does not require asciidoc/xmlto, but it works from within
+ a checkout of git.git only.
+
It has been reported that docbook-xsl version 1.72 and 1.73 are
buggy; 1.72 misformats manual pages for callouts, and 1.73 needs
the patch in contrib/patches/docbook-xsl-manpages-charmap.patch
diff --git a/Makefile b/Makefile
index f4c31c8..eeaf6d4 100644
--- a/Makefile
+++ b/Makefile
@@ -1401,6 +1401,9 @@ install-info:
quick-install-doc:
$(MAKE) -C Documentation quick-install
+quick-install-html:
+ $(MAKE) -C Documentation quick-install-html
+
### Maintainer's dist rules
--
1.6.0.1.285.g1070
^ permalink raw reply related
* [PATCH 0/2] Assist installing documentation with incomplete build chain
From: Michael J Gruber @ 2008-09-10 8:33 UTC (permalink / raw)
To: git
This patch series should clarify make targets for documentation and
help those with partial or no documentation build chain, without breaking
existing behaviour. Therefore, the current inconsistency between "make
doc" (builds man and html doc) and "make install-doc" (installs man) is
preserved.
The INSTALL file documents this now, as well as preexisting and new
targets for building and installing man and html separately or from the
convenience branches origin/{man,html}.
Michael J Gruber (2):
allow installation of man and html doc from the man and html branches
separate build targets for man and html documentation
Documentation/Makefile | 4 ++++
INSTALL | 20 +++++++++++++++++---
Makefile | 9 +++++++++
3 files changed, 30 insertions(+), 3 deletions(-)
^ permalink raw reply
* [RFH] git cherry-pick takes forever
From: Michal Vitecek @ 2008-09-10 8:26 UTC (permalink / raw)
To: git list
Hello everyone,
I have two git repositories: one is the origin of the other. However no
merging is being done as the projects in the repositories quite differ
but still use the same core. So to propagate changes I cherry-pick
those which are useful from one repository to another.
however 'git cherry-pick' has lately started to last almost forever:
$ time git cherry-pick b42b77e66a83f1298d9900a9bb1078b9b42e8618
Finished one cherry-pick.
Created commit 7caef83: - removed some superfluous newlines
2 files changed, 0 insertions(+), 2 deletions(-)
git cherry-pick b42b77e66a83f1298d9900a9bb1078b9b42e8618 282.97s user 34.69s system 100% cpu 5:17.63 total
Both repositories have approximately 16k commits and their forking
point (merge base) is 250 to 490 commits far away. 'git gc' (even
--prune) has been run.
What can I do to make the 'git cherry-pick' instant again?
Thank you,
P.S.: I'm using git-1.6.0.1.
--
Michal Vitecek (fuf@mageo.cz)
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Paolo Bonzini @ 2008-09-10 8:45 UTC (permalink / raw)
To: Petr Baudis; +Cc: Stephen R. van den Berg, git
In-Reply-To: <20080909211355.GB10544@machine.or.cz>
> Having history browsers draw fancy lines is fine but I see nothing wrong
> with them extracting this from the free-form part of the commit message.
> For informative purposes, we don't shy away from heuristics anyway, c.f.
> our renames detection (heck, we are even brave enough to use that for
> merges).
... and it works only because false positives (which make the merge
actively wrong) are extremely rare. If there is the occasional false
negative, well, it just makes merges more complicated and screws up
visualization a bit, so you live with it.
Move/copy detection almost always worked for me, but there are two cases
where it didn't:
1) empty files. Each of them is marked as copied from a
seemingly-picked-at-random one.
2) renaming a Gtk+ class. You rename it (e.g. from gtkclassnamea.c to
gtkclassnameb.c) and at the same time do
s/GtkClassNameA/GtkClassNameB/
s/GTK_CLASS_NAME_A(?:\>|?=_)/GTK_CLASS_NAME_B/
s/gtk_class_name_a(?:\>|?=_)/gtk_class_name_b/
and reindent everything. Guaranteed to have a similarity index around
30-40%, not more.
I don't care much about it, but face it, it is *not* perfect.
Paolo
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Paolo Bonzini @ 2008-09-10 8:30 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Stephen R. van den Berg, Jakub Narebski, git
In-Reply-To: <alpine.LFD.1.10.0809091722010.3384@nehalem.linux-foundation.org>
Linus Torvalds wrote:
>
> On Wed, 10 Sep 2008, Stephen R. van den Berg wrote:
>> As you might have noticed, the actual process of pulling/fetching
>> explicitly does *not* pull in the objects being pointed to.
>
> .. which makes them _local_ data, which in turn means that they should not
> be in the object database at all.
Not really local data. More like _weakly referenced_ data. If it is
there, cool. If it is not there, no big deal.
Paolo
^ permalink raw reply
* Re: [ANNOUNCE] TopGit v0.3
From: Bert Wesarg @ 2008-09-10 8:18 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20080909231009.GD10544@machine.or.cz>
On Wed, Sep 10, 2008 at 01:10, Petr Baudis <pasky@suse.cz> wrote:
> Hi!
Hi,
Thanks for the release. I have some notes:
1. .gitignore is not up-to-date
2. tg tells me v0.2
What do I need to publish my TopGit controlled branches, is it enough
to push with:
push = refs/heads/t/*:refs/heads/t/*
push = refs/top-bases/t/*:refs/top-bases/t/*
Thanks.
> I decided not to consider the 'tg depend' work by Jan Nieuwenhuiz for
> this release yet, since it will probably take me a bit of time yet to
> fully understand his approach; so far, I have an uneasy feel about it.
You may have noticed my problem with this patch, and it seems that he
is working on a new approach/implementation
Regards
Bert
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Paolo Bonzini @ 2008-09-10 8:10 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Jeff King, Junio C Hamano, Stephen R. van den Berg, git
In-Reply-To: <200809100107.44933.jnareb@gmail.com>
> By the way, beside graphical history viewers it would also help rebase
> (and git-cherry) notice when patch was already applied better.
I think that rebase had better not trust the origin links in deciding
whether a patch was already applied; it already does it well enough.
git-cherry is another story, as that tool is not faking "changeset mode"
so well (because it cannot attempt merges, and these are what allows
git-rebase to fake changesets much better).
Paolo
^ permalink raw reply
* Re: [RFC/PATCH] Use compatibility regex library for OSX/Darwin
From: Mike Ralphson @ 2008-09-10 8:03 UTC (permalink / raw)
To: Arjen Laarhoven; +Cc: git
In-Reply-To: <20080907184537.GA4148@regex.yaph.org>
2008/9/7 Arjen Laarhoven <arjen@yaph.org>
> The standard libc regex library on OSX does not support alternation
> in POSIX Basic Regular Expression mode. This breaks the diff.funcname
> functionality on OSX.
>
> Also, I'm sure the problem occurs on more non-Linux systems (or non
> GNU libc systems). If people who have access to those systems (BSD's,
> HP-UX, AIX, etc) can test it, I'd be happy to add those systems to the
> patch so it can fix for multiple systems at once.
I can confirm that the issue shown up by your new testcase is also
present in AIX 5.3.
Doing the mv's and adding regex.o to COMPAT_OBJS works fine and
compat/lib.a is suitably amended
ar -t compat/lib.a
regex.o
...
but I'm afraid I don't know how to get the combination of gcc + AIX ld
to link to this in preference to the system defined regex functions.
At least I guess this is what's happening.
Adding -lcompat/regex to COMPAT_CFLAGS as per your Darwin hunk
provokes lots of warnings:
gcc: -lcompat/regex: linker input file unused because linking not done
... (" for each .c file)
LINK git-fast-import
collect2: library libcompat/regex not found
That said, I'm not specifically arguing in favour of the patch (I
wouldn't know a regex alternation if it bit me), someone writing
regexs on HP-UX might expect them to work like the rest of their OS...
If the shipped java funcname pattern requires alternation then the
testcase should stand though.
Mike
^ permalink raw reply
* [guilt] Bug with guilt patchbomb
From: Thomas Petazzoni @ 2008-09-09 8:12 UTC (permalink / raw)
To: jsipek; +Cc: git
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:
Enter all the Cc: email addresses (separated by space):
usage: git-rev-list [OPTION] <commit-id>... [ -- paths... ]
limiting output:
--max-count=nr
--max-age=epoch
--min-age=epoch
--sparse
--no-merges
--remove-empty
--all
--stdin
--quiet
ordering output:
--topo-order
--date-order
formatting output:
--parents
--objects | --objects-edge
--unpacked
--header | --pretty
--abbrev=nr | --no-abbrev
--abbrev-commit
--left-right
special purpose:
--bisect
--bisect-vars
--bisect-all
/usr/bin/guilt-patchbomb: 98: Bad substitution
Proceed with patchbomb (this is the last chance to abort)? [y/N]
Sincerly,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com
^ 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