* Re: [PATCH] git-cget: prints elements of C code in the git repository
From: roel kluin @ 2009-03-27 9:22 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0903241257430.7493@intel-tinevez-2-302>
Hi Johannes,
> - it misdetects functions: trying
>
> $ ./git-cget -f get_sha1.*
The .* is not strict enough. What you want to do instead is:
$ ./git-cget -f "get_sha1[A-Za-z0-9_]*"
and that will give correct matches.
Roel
^ permalink raw reply
* Re: On git 1.6 (novice's opinion)
From: Ulrich Windl @ 2009-03-27 9:50 UTC (permalink / raw)
To: H.Merijn Brand; +Cc: git
In-Reply-To: <20090327090554.5d6160f2@pc09.procura.nl>
On 27 Mar 2009 at 9:05, H.Merijn Brand wrote:
> On Fri, 27 Mar 2009 08:21:36 +0100, "Ulrich Windl"
> <ulrich.windl@rz.uni-regensburg.de> wrote:
>
> > What I'd like to see in git (My apologies if some were already discussed to
> > death):
> >
> > 1) The ability to use the file's time at the time of add/commit instead of
> > the current time, and the ability tho check outfiles with the times stored
> > in the repository.
> >
> > 2) Keyword substitution. I know it's controverse (dealing with binary files),
> > but I'd like to have some automatic version numbering keyword at least:
> > Initial idea is that every commit with a change increments the number by
> > one, and when merging numbers a and b, the resulting number is max(a, b) + 1.
>
> impossible. Even with checkin- and checkout hooks, you won't get that
> SCCS behaviour. They have to be better in something too :)
> /me still misses that but got used to it
Hi,
what made me wonder is this (about item 1): I thought I've read that blobs store
content and attributes, so very obviously I wondered why not store thr "right
attributes" (i.e. the time of the file). My reasoning: You make some changes, then
test them (which might last several hours or days). The if I'm happy I'll
"commit". Naturally I want to see the time of change for each file when the change
had been actually made, not when the change was committed. Likewise when checking
out, I want to be able to see the time of modification, not the time of commit.
I'm aware that many people don't care about such differences...
>
> > 3) "git undo": If possible undo the effects of the last command.
If impossible, add confirmations for some "dangerous" (non-obvious) commands
before doing possibly harmful things. Maybe adding a kind of "user-level setting"
(novice, expert, guro) could control such confirmations.
> >
> > Following are some random remarks from a first-time git user, regarding the
> > buld/install:
> >
> > Notes on building git-1.6.1.3 on openSUSE 11.0:
> > There is no "asciidoc"; the INSTALL should be more verbose on special
> > requirements (i.e. additional packages needed, and where to get them).
>
> # zypper in asciidoc libcurl-devel
"asciidoc" doesn't seem a popular package on some distributions; mine lacks it...
>
> (yes, 'make install-man' should stop soon after detecting asciidoc is
> not installed
Regards,
Ulrich
^ permalink raw reply
* Re: Improve tags
From: Etienne Vallette d'Osia @ 2009-03-27 10:05 UTC (permalink / raw)
To: git
In-Reply-To: <20090327065356.6117@nanako3.lavabit.com>
Nanako Shiraishi a écrit :
> Quoting "Etienne Vallette d'Osia" <dohzya@gmail.com>:
>
>> In addition, branches are a way to specify streams,
>> not a way to specify an aim for a commit.
>> (like in ruby a class is a method container, not a type)
>> So branch names are often like next, pu, dev, test, stupid-idea, etc.
>> They are totally useless for tracking aims.
>
> Why should that be? 'next' clearly states the aim (it is to serve as an
> integration testing area for the possible new features for the next
> release).
>
It is not an aim (maybe "aim" is not the right term ?), it a status.
For me the aim is 'this commit is related to the documentation', 'this
commit is related to test and to the debugger'.
^ permalink raw reply
* Re: git-push on packed refs via HTTP
From: Steve @ 2009-03-27 10:20 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.DEB.1.00.0903201341220.6865@intel-tinevez-2-302>
Hi Dscho
Thanks for your snippet, that did the trick. I only had to alter it slightly
because the repo on the server is bare:
git show-ref |
while read sha1 name
do
mkdir -p $(dirname $name) &&
echo $sha1 > $name
done
Just for understanding: Why is this step necessary? Does it have anything to do
with serving the repo over HTTP at all?
Cheers, Steve
^ permalink raw reply
* Re: Improve tags
From: Etienne Vallette d'Osia @ 2009-03-27 10:30 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Etienne Vallette d'Osia, git
In-Reply-To: <49CBA713.4040605@drmicha.warpmail.net>
> You described your motivation and use case very clearly!
>
> Maybe "label" would be an appropriate name for "non-unique tags". I
> assume they should be local and non-versioned. It sounds as if a file
> storing a list of sha1s could be the simplest approach (one file per
> label in a new subdir of .git), although this may not scale well. A
> first step could be implementing a command "git label" in shell which
> sets and displays labels. Later on, various builtins would need to be
> taught about it if you want labels displayed in log etc.
>
> Michael
Thanks a lot
"label" is perfect !
In fact, I was thinking about non-local labels.
But keeping information in a separate file and not in commit directly is
a very nice idea (and closer than the current tag implementation).
I love your approach, you have just make this idea realizable
^ permalink raw reply
* Re: On git 1.6 (novice's opinion)
From: Etienne Vallette d'Osia @ 2009-03-27 10:57 UTC (permalink / raw)
To: git; +Cc: H.Merijn Brand, git
In-Reply-To: <49CCAF5D.21814.24B4DE63@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de>
Ulrich Windl a écrit :
>>> 3) "git undo": If possible undo the effects of the last command.
>
> If impossible, add confirmations for some "dangerous" (non-obvious) commands
> before doing possibly harmful things. Maybe adding a kind of "user-level setting"
> (novice, expert, guro) could control such confirmations.
>
Why ?
All objects stored are immutable, and some tools keep informations
(ORIGIN_HEAD, refs/original) to allow a undo hand-made.
Moreover the reflog (and stash if you want to use it for this use) store
informations during time...
So it's possible to provide a generic undo for all commands that change
refs.
Maybe an "undo" directory in $GIT_DIR, which will a keep a copy version
of all refs. Every commands store the current refs in this folder _before_
to change anything, and the undo restore them all.
At least, a "lastcmd" (for example) file could be added in this
directory to allow an more clever undo.
^ permalink raw reply
* Re: svn clone Checksum mismatch question
From: Anton Gyllenberg @ 2009-03-27 11:18 UTC (permalink / raw)
To: git; +Cc: Eric Wong
In-Reply-To: <83dfc36c0903260735q3231ce96h5949d1123858995f@mail.gmail.com>
I hope I didn't hijack the thread with an unrelated issue.
2009/3/26 Anton Gyllenberg <anton@iki.fi>:
> I don't know if this is the same issue, but the I get a similar error
> on the public twisted-python repository on both windows and linux,
> with several different versions and plenty of free disk space. As this
> is a publicly accessible repository it should be easy to reproduce:
>
> git svn init -s svn://svn.twistedmatrix.com/svn/Twisted twisted
> cd twisted
> git svn fetch -r 13611:HEAD
>
> This ultimately dies with the following error:
> W: +empty_dir: trunk/doc/core/howto/listings/finger/finger
> r13612 = f6d995ac255e3dfa08a517a6e72fbcfe63feaaa0 (trunk)
> Checksum mismatch:
> branches/foom/--omg-optimized/twisted/internet/cdefer/cdefer.pyx
> 264b0c5f7b3a00d401d1a5dcce67a3734f0eede3
> expected: c7ccddd195f132926e20bab573da7ef3
> got: f006323ff4714ca52c0228ce6390d415
Looking into this, the mentioned blob
264b0c5f7b3a00d401d1a5dcce67a3734f0eede3 with md5sum
f006323ff4714ca52c0228ce6390d415 is not at path
branches/foom/--omg-optimized/twisted/internet/cdefer/cdefer.pyx. The
contents of the blob is the seemingly totally unrelated LICENSE file
that is found at trunk/LICENSE and
branches/foom/--omg-optimized/LICENSE. cdefer.pyx does have the md5sum
c7ccddd195f132926e20bab573da7ef3. Note that the branch root directory
is branches/foom/--omg-optimized (like with the branch name being
foom/--omg-optimized), not just branches/foom. Is think git-svn relies
on the standard layout being branches directly under the branches/
directory, but I don't see how this would get the paths mixed up like
this.
Looking at what was done around this commit one finds odd stuff, like
deleting directories in trunk and then copying from a previous
revision of trunk to under the branch:
http://twistedmatrix.com/trac/changeset/13611
I created a local test svn repository and tried to do something
similar but git-svn had no problem with my test.
This is issue is not critical for me in any way but if somebody wants
to look into it I am happy to help out.
Anton
^ permalink raw reply
* Re: [PATCH] git-cget: prints elements of C code in the git repository
From: Johannes Schindelin @ 2009-03-27 11:26 UTC (permalink / raw)
To: roel kluin; +Cc: git
In-Reply-To: <25e057c00903270222v7acad9ebxf2ed4242570f3de5@mail.gmail.com>
Hi,
On Fri, 27 Mar 2009, roel kluin wrote:
> Hi Johannes,
>
> > - it misdetects functions: trying
> >
> > $ ./git-cget -f get_sha1.*
>
> The .* is not strict enough. What you want to do instead is:
>
> $ ./git-cget -f "get_sha1[A-Za-z0-9_]*"
>
> and that will give correct matches.
No, the problem was that it did not show a function _definition_, but
mistook a function _call_ for a definition.
Ciao,
Dscho
^ permalink raw reply
* Re: On git 1.6 (novice's opinion)
From: Etienne Vallette d'Osia @ 2009-03-27 11:30 UTC (permalink / raw)
Cc: git, H.Merijn Brand
In-Reply-To: <49CCB129.1070606@gmail.com>
Etienne Vallette d'Osia a écrit :
> Ulrich Windl a écrit :
>>>> 3) "git undo": If possible undo the effects of the last command.
>>
>> If impossible, add confirmations for some "dangerous" (non-obvious)
>> commands before doing possibly harmful things. Maybe adding a kind of
>> "user-level setting" (novice, expert, guro) could control such
>> confirmations.
>>
> Why ?
Oops, I have readed "it is impossible"
^ permalink raw reply
* Re: On git 1.6 (novice's opinion)
From: Dmitry Potapov @ 2009-03-27 12:24 UTC (permalink / raw)
To: Ulrich Windl; +Cc: git
In-Reply-To: <49CC8C90.12268.242CEFCE@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de>
On Fri, Mar 27, 2009 at 10:21 AM, Ulrich Windl
<ulrich.windl@rz.uni-regensburg.de> wrote:
>
> 1) The ability to use the file's time at the time of add/commit instead of the
> current time, and the ability tho check outfiles with the times stored in the
> repository.
To check out with the times stored in repository is a a bad idea, because it
will screw up 'make'.
>
> 2) Keyword substitution. I know it's controverse (dealing with binary files),
> but I'd like to have some automatic version numbering keyword at least:
> Initial idea is that every commit with a change increments the number by one,
> and when merging numbers a and b, the resulting number is max(a, b) + 1.
I am not sure what you want to achieve by having this number. Also, take
a look at "git describe", it may be close to what you want (or may be not).
Dmitry
^ permalink raw reply
* Re: On git 1.6 (novice's opinion)
From: Dmitry Potapov @ 2009-03-27 12:24 UTC (permalink / raw)
To: Ulrich Windl; +Cc: H.Merijn Brand, git
In-Reply-To: <49CCAF5D.21814.24B4DE63@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de>
On Fri, Mar 27, 2009 at 12:50 PM, Ulrich Windl
<ulrich.windl@rz.uni-regensburg.de> wrote:
>
> what made me wonder is this (about item 1): I thought I've read that blobs store
> content and attributes, so very obviously I wondered why not store thr "right
> attributes" (i.e. the time of the file). My reasoning: You make some changes, then
> test them (which might last several hours or days). The if I'm happy I'll
> "commit".
With Git, you usually commit your changes immediately (without waiting
the result
of testing), because you can always undo commit until you publish your changes.
Dmitry
^ permalink raw reply
* Re: On git 1.6 (novice's opinion)
From: Michael J Gruber @ 2009-03-27 12:49 UTC (permalink / raw)
To: Ulrich Windl; +Cc: git
In-Reply-To: <49CC8C90.12268.242CEFCE@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de>
Ulrich Windl venit, vidit, dixit 27.03.2009 08:21:
> Hello everybody,
>
> [About my experience on version control systems: I started out with SCCS in
> the eighties, and I thought it must be cool as the UNIX guys used it to
> maintain their sources. Some times later I was using Emacs' numbered backup
> files as a poor substiutute for nothing else. Then I came across RCS, and I
> liked it soon ,because it was fully documented and well-written. I even ported
> it to MS-DOS (whew!). I was attaching tags to individual files to mark
> "releases" at those times. Then I heard about CVS. It seemed to help with the
> tagging, so I used it for the mopre complex projects. I even did branches and
> merging with it for the Linux sources. I spontaneously diskliked Bitkeeper,
> because it would not work off-line. I heard about Git some time ago, but using
> it seems very non-obvious. After having read the tutorial, and playing some
> simple scenarios, I must admit that I really like the fully distributed nature
> of it. However some commands seem to be a bit strange (e.g. "git add" is
> almost, but quite a "commit" (if you come from CVS)), and sources are quite
> complex. Also some seemingly dangerous commands that cannot easily be undone
> should ask safety questions ("cvs merge (-j)" would also fall into that
> category.]
>
> What I'd like to see in git (My apologies if some were already discussed to
> death):
>
> 1) The ability to use the file's time at the time of add/commit instead of the
> current time, and the ability tho check outfiles with the times stored in the
> repository.
>
> 2) Keyword substitution. I know it's controverse (dealing with binary files),
> but I'd like to have some automatic version numbering keyword at least:
> Initial idea is that every commit with a change increments the number by one,
> and when merging numbers a and b, the resulting number is max(a, b) + 1.
Keyword substitution and cvs/svn style version numbers are independent
issues. The sha1 describes a commit uniquely, one could use that as a
keyword.
Increasing version numbers are meaningless in a true DVCS world. What is
your 100th commit may not be someone else's, even if both your master's
heads are the same! This is why hg version numbers are a local thing.
They are merely a local shortcut for specifying a revision and serve the
same purpose as git's "backward" counts like HEAD~3 etc. Neither of them
work permanently, not even in a local repo, if you allow rebasing.
git rev-list HEAD|wc may produce something like it, but be sure to read
up on --sparse and --full-history.
> 3) "git undo": If possible undo the effects of the last command.
>
> Following are some random remarks from a first-time git user, regarding the
> buld/install:
>
> Notes on building git-1.6.1.3 on openSUSE 11.0:
> There is no "asciidoc"; the INSTALL should be more verbose on special
> requirements (i.e. additional packages needed, and where to get them).
> LANG= make configure
> /bin/sh: curl-config: command not found
> make: `configure' is up to date.
>
> make[2]: Entering directory `/git/git-1.6.1.3'
> make[2]: `GIT-VERSION-FILE' is up to date.
> make[2]: Leaving directory `/git/git-1.6.1.3'
> rm -f git-add.html+ git-add.html
> asciidoc -b xhtml11 -d manpage -f asciidoc.conf \
> -agit_version=1.6.1.3 -o git-add.html+ git-add.txt
> make[1]: asciidoc: Command not found
> make[1]: *** [git-add.html] Error 127
> make[1]: Leaving directory `/git/git-1.6.1.3/Documentation'
> make: *** [doc] Error 2
>
> Some parts of the make process may look like an error if they pass by quickly:
>
> [...]
> GEN git-request-pull
> GEN git-sh-setup
> GEN git-stash
> GEN git-submodule
> GEN git-web--browse
> SUBDIR perl
> /usr/bin/perl Makefile.PL PREFIX='/home/windl/Projects/git/inst'
> Writing perl.mak for Git
> GEN git-add--interactive
> GEN git-archimport
> GEN git-cvsexportcommit
> GEN git-cvsimport
> [...]
>
> Same is true for the install process:
> make[1]: Leaving directory `/home/windl/Projects/git/git-1.6.1.3/git-gui'
> bindir=$(cd '/home/windl/Projects/git/inst/bin' && pwd) && \
> execdir=$(cd '/home/windl/Projects/git/inst/libexec/git-core/' && pwd) &&
> \
> { rm -f "$execdir/git-add" && \
> ln git-add "$execdir/git-add" 2>/dev/null || \
> cp git-add "$execdir/git-add"; } && \
> { rm -f "$execdir/git-annotate" && ln "$execdir/git-add" "$execdir/git-
> annotate" 2>/dev/null || ln -s "git-add" "$execdir/git-annotate" 2>/dev/null || cp
> "$execdir/git-add" "$execdir/git-annotate" || exit; rm -f "$execdir/git-apply" &&
> ln "$execdir/git-add" "$execdir/git-apply" 2>/dev/null || ln -s "git-add"
> "$execdir/git-apply" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-apply" ||
> exit; rm -f "$execdir/git-archive" && ln "$execdir/git-add" "$execdir/git-
> archive" 2>/dev/null || ln -s "git-add" "$execdir/git-archive" 2>/dev/null || cp
> "$execdir/git-add" "$execdir/git-archive" || exit; rm -f "$execdir/git-blame" &&
> ln "$execdir/git-add" "$execdir/git-blame" 2>/dev/null || ln -s "git-add"
> "$execdir/git-blame" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-blame" ||
> exit; rm -f "$execdir/git-branch" && ln "$execdir/git-add" "$execdir/git-branch"
> 2>/dev/null || ln -s "git-add" "$execdir/git-branch" 2>/dev/null || cp
> "$execdir/git-add" "$execdir/git-branch" || exit; rm -f "$execdir/git-bundle" &&
> ln "$execdir/git-add" "$execdir/git-bundle" 2>/dev/null || ln -s "git-add"
> "$execdir/git-bundle" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-bundle"
> || exit; rm -f "$execdir/git-cat-file" && ln "$execdir/git-add" "$execdir/git-
> cat-file" 2>/dev/null || ln -s "git-add" "$execdir/git-cat-file" 2>/dev/null || cp
> "$execdir/git-add" "$execdir/git-cat-file" || exit; rm -f "$execdir/git-check-
> attr" && ln "$execdir/git-add" "$execdir/git-check-attr" 2>/dev/null || ln -s
> "git-add" "$execdir/git-check-attr" 2>/dev/null || cp "$execdir/git-add"
> "$execdir/git-check-attr" || exit; rm -f "$execdir/git-check-ref-format" && ln
> "$execdir/git-add" "$execdir/git-check-ref-format" 2>/dev/null || ln -s "git-add"
> "$execdir/git-check-ref-format" 2>/dev/null || cp "$execdir/git-add"
> "$execdir/git-check-ref-format" || exit; rm -f "$execdir/git-checkout-index" &&
> ln "$execdir/git-add" "$execdir/git-checkout-index" 2>/dev/null || ln -s "git-add"
> "$execdir/git-checkout-index" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-
> checkout-index" || exit; rm -f "$execdir/git-checkout" && ln "$execdir/git-add"
> "$execdir/git-checkout" 2>/dev/null || ln -s "git-add" "$execdir/git-checkout"
> 2>/dev/null || cp "$execdir/git-add" "$execdir/git-checkout" || exit; rm -f
> "$execdir/git-clean" && ln "$execdir/git-add" "$execdir/git-clean" 2>/dev/null ||
> ln -s "git-add" "$execdir/git-clean" 2>/dev/null || cp "$execdir/git-add"
> "$execdir/git-clean" || exit; rm -f "$execdir/git-clone" && ln "$execdir/git-add"
> "$execdir/git-clone" 2>/dev/null || ln -s "git-add" "$execdir/git-clone"
> 2>/dev/null || cp "$execdir/git-add" "$execdir/git-clone" || exit; rm -f
> "$execdir/git-commit-tree" && ln "$execdir/git-add" "$execdir/git-commit-tree"
> 2>/dev/null || ln -s "git-add" "$execdir/git-commit-tree" 2>/dev/null || cp
> "$execdir/git-add" "$execdir/git-commit-tree" || exit; rm -f "$execdir/git-
> commit" && ln "$execdir/git-add" "$execdir/git-commit" 2>/dev/null || ln -s "git-
> add" "$execdir/git-commit" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-
> commit" || exit; rm -f "$execdir/git-config" && ln "$execdir/git-add"
> "$execdir/git-config" 2>/dev/null || ln -s "git-add" "$execdir/git-config"
> 2>/dev/null || cp "$execdir/git-add" "$execdir/git-config" || exit; rm -f
> "$execdir/git-count-objects" && ln "$execdir/git-add" "$execdir/git-count-objects"
> 2>/dev/null || ln -s "git-add" "$execdir/git-count-objects" 2>/dev/null || cp
> "$execdir/git-add" "$execdir/git-count-objects" || exit; rm -f "$execdir/git-
> describe" && ln "$execdir/git-add" "$execdir/git-describe" 2>/dev/null || ln -s
> "git-add" "$execdir/git-describe" 2>/dev/null || cp "$execdir/git-add"
> "$execdir/git-describe" || exit; rm -f "$execdir/git-diff-files" && ln
> "$execdir/git-add" "$execdir/git-diff-files" 2>/dev/null || ln -s "git-add"
> "$execdir/git-diff-files" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-diff-
> files" || exit; rm -f "$execdir/git-diff-index" && ln "$execdir/git-add"
> "$execdir/git-diff-index" 2>/dev/null || ln -s "git-add" "$execdir/git-diff-index"
> 2>/dev/null || cp "$execdir/git-add" "$execdir/git-diff-index" || exit; rm -f
> "$execdir/git-diff-tree" && ln "$execdir/git-add" "$execdir/git-diff-tree"
> 2>/dev/null || ln -s "git-add" "$execdir/git-diff-tree" 2>/dev/null || cp
> "$execdir/git-add" "$execdir/git-diff-tree" || exit; rm -f "$execdir/git-diff" &&
> ln "$execdir/git-add" "$execdir/git-diff" 2>/dev/null || ln -s "git-add"
> "$execdir/git-diff" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-diff" ||
> exit; rm -f "$execdir/git-fast-export" && ln "$execdir/git-add" "$execdir/git-
> fast-export" 2>/dev/null || ln -s "git-add" "$execdir/git-fast-export" 2>/dev/null
> || cp "$execdir/git-add" "$execdir/git-fast-export" || exit; rm -f "$execdir/git-
> fetch--tool" && ln "$execdir/git-add" "$execdir/git-fetch--tool" 2>/dev/null || ln
> -s "git-add" "$execdir/git-fetch--tool" 2>/dev/null || cp "$execdir/git-add"
> "$execdir/git-fetch--tool" || exit; rm -f "$execdir/git-fetch-pack" && ln
> "$execdir/git-add" "$execdir/git-fetch-pack" 2>/dev/null || ln -s "git-add"
> "$execdir/git-fetch-pack" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-
> fetch-pack" || exit; rm -f "$execdir/git-fetch" && ln "$execdir/git-add"
> "$execdir/git-fetch" 2>/dev/null || ln -s "git-add" "$execdir/git-fetch"
> 2>/dev/null || cp "$execdir/git-add" "$execdir/git-fetch" || exit; rm -f
> "$execdir/git-fmt-merge-msg" && ln "$execdir/git-add" "$execdir/git-fmt-merge-msg"
> 2>/dev/null || ln -s "git-add" "$execdir/git-fmt-merge-msg" 2>/dev/null || cp
> "$execdir/git-add" "$execdir/git-fmt-merge-msg" || exit; rm -f "$execdir/git-for-
> each-ref" && ln "$execdir/git-add" "$execdir/git-for-each-ref" 2>/dev/null || ln -
> s "git-add" "$execdir/git-for-each-ref" 2>/dev/null || cp "$execdir/git-add"
> "$execdir/git-for-each-ref" || exit; rm -f "$execdir/git-fsck" && ln
> "$execdir/git-add" "$execdir/git-fsck" 2>/dev/null || ln -s "git-add"
> "$execdir/git-fsck" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-fsck" ||
> exit; rm -f "$execdir/git-gc" && ln "$execdir/git-add" "$execdir/git-gc"
> 2>/dev/null || ln -s "git-add" "$execdir/git-gc" 2>/dev/null || cp "$execdir/git-
> add" "$execdir/git-gc" || exit; rm -f "$execdir/git-grep" && ln "$execdir/git-
> add" "$execdir/git-grep" 2>/dev/null || ln -s "git-add" "$execdir/git-grep"
> 2>/dev/null || cp "$execdir/git-add" "$execdir/git-grep" || exit; rm -f
> "$execdir/git-help" && ln "$execdir/git-add" "$execdir/git-help" 2>/dev/null || ln
> -s "git-add" "$execdir/git-help" 2>/dev/null || cp "$execdir/git-add"
> "$execdir/git-help" || exit; rm -f "$execdir/git-init-db" && ln "$execdir/git-
> add" "$execdir/git-init-db" 2>/dev/null || ln -s "git-add" "$execdir/git-init-db"
> 2>/dev/null || cp "$execdir/git-add" "$execdir/git-init-db" || exit; rm -f
> "$execdir/git-log" && ln "$execdir/git-add" "$execdir/git-log" 2>/dev/null || ln -
> s "git-add" "$execdir/git-log" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-
> log" || exit; rm -f "$execdir/git-ls-files" && ln "$execdir/git-add"
> "$execdir/git-ls-files" 2>/dev/null || ln -s "git-add" "$execdir/git-ls-files"
> 2>/dev/null || cp "$execdir/git-add" "$execdir/git-ls-files" || exit; rm -f
> "$execdir/git-ls-remote" && ln "$execdir/git-add" "$execdir/git-ls-remote"
> 2>/dev/null || ln -s "git-add" "$execdir/git-ls-remote" 2>/dev/null || cp
> "$execdir/git-add" "$execdir/git-ls-remote" || exit; rm -f "$execdir/git-ls-tree"
> && ln "$execdir/git-add" "$execdir/git-ls-tree" 2>/dev/null || ln -s "git-add"
> "$execdir/git-ls-tree" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-ls-tree"
> || exit; rm -f "$execdir/git-mailinfo" && ln "$execdir/git-add" "$execdir/git-
> mailinfo" 2>/dev/null || ln -s "git-add" "$execdir/git-mailinfo" 2>/dev/null || cp
> "$execdir/git-add" "$execdir/git-mailinfo" || exit; rm -f "$execdir/git-
> mailsplit" && ln "$execdir/git-add" "$execdir/git-mailsplit" 2>/dev/null || ln -s
> "git-add" "$execdir/git-mailsplit" 2>/dev/null || cp "$execdir/git-add"
> "$execdir/git-mailsplit" || exit; rm -f "$execdir/git-merge" && ln "$execdir/git-
> add" "$execdir/git-merge" 2>/dev/null || ln -s "git-add" "$execdir/git-merge"
> 2>/dev/null || cp "$execdir/git-add" "$execdir/git-merge" || exit; rm -f
> "$execdir/git-merge-base" && ln "$execdir/git-add" "$execdir/git-merge-base"
> 2>/dev/null || ln -s "git-add" "$execdir/git-merge-base" 2>/dev/null || cp
> "$execdir/git-add" "$execdir/git-merge-base" || exit; rm -f "$execdir/git-merge-
> file" && ln "$execdir/git-add" "$execdir/git-merge-file" 2>/dev/null || ln -s
> "git-add" "$execdir/git-merge-file" 2>/dev/null || cp "$execdir/git-add"
> "$execdir/git-merge-file" || exit; rm -f "$execdir/git-merge-ours" && ln
> "$execdir/git-add" "$execdir/git-merge-ours" 2>/dev/null || ln -s "git-add"
> "$execdir/git-merge-ours" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-
> merge-ours" || exit; rm -f "$execdir/git-merge-recursive" && ln "$execdir/git-
> add" "$execdir/git-merge-recursive" 2>/dev/null || ln -s "git-add" "$execdir/git-
> merge-recursive" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-merge-
> recursive" || exit; rm -f "$execdir/git-mv" && ln "$execdir/git-add"
> "$execdir/git-mv" 2>/dev/null || ln -s "git-add" "$execdir/git-mv" 2>/dev/null ||
> cp "$execdir/git-add" "$execdir/git-mv" || exit; rm -f "$execdir/git-name-rev" &&
> ln "$execdir/git-add" "$execdir/git-name-rev" 2>/dev/null || ln -s "git-add"
> "$execdir/git-name-rev" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-name-
> rev" || exit; rm -f "$execdir/git-pack-objects" && ln "$execdir/git-add"
> "$execdir/git-pack-objects" 2>/dev/null || ln -s "git-add" "$execdir/git-pack-
> objects" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-pack-objects" || exit;
> rm -f "$execdir/git-pack-refs" && ln "$execdir/git-add" "$execdir/git-pack-refs"
> 2>/dev/null || ln -s "git-add" "$execdir/git-pack-refs" 2>/dev/null || cp
> "$execdir/git-add" "$execdir/git-pack-refs" || exit; rm -f "$execdir/git-prune-
> packed" && ln "$execdir/git-add" "$execdir/git-prune-packed" 2>/dev/null || ln -s
> "git-add" "$execdir/git-prune-packed" 2>/dev/null || cp "$execdir/git-add"
> "$execdir/git-prune-packed" || exit; rm -f "$execdir/git-prune" && ln
> "$execdir/git-add" "$execdir/git-prune" 2>/dev/null || ln -s "git-add"
> "$execdir/git-prune" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-prune" ||
> exit; rm -f "$execdir/git-push" && ln "$execdir/git-add" "$execdir/git-push"
> 2>/dev/null || ln -s "git-add" "$execdir/git-push" 2>/dev/null || cp
> "$execdir/git-add" "$execdir/git-push" || exit; rm -f "$execdir/git-read-tree" &&
> ln "$execdir/git-add" "$execdir/git-read-tree" 2>/dev/null || ln -s "git-add"
> "$execdir/git-read-tree" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-read-
> tree" || exit; rm -f "$execdir/git-receive-pack" && ln "$execdir/git-add"
> "$execdir/git-receive-pack" 2>/dev/null || ln -s "git-add" "$execdir/git-receive-
> pack" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-receive-pack" || exit;
> rm -f "$execdir/git-reflog" && ln "$execdir/git-add" "$execdir/git-reflog"
> 2>/dev/null || ln -s "git-add" "$execdir/git-reflog" 2>/dev/null || cp
> "$execdir/git-add" "$execdir/git-reflog" || exit; rm -f "$execdir/git-remote" &&
> ln "$execdir/git-add" "$execdir/git-remote" 2>/dev/null || ln -s "git-add"
> "$execdir/git-remote" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-remote"
> || exit; rm -f "$execdir/git-rerere" && ln "$execdir/git-add" "$execdir/git-
> rerere" 2>/dev/null || ln -s "git-add" "$execdir/git-rerere" 2>/dev/null || cp
> "$execdir/git-add" "$execdir/git-rerere" || exit; rm -f "$execdir/git-reset" &&
> ln "$execdir/git-add" "$execdir/git-reset" 2>/dev/null || ln -s "git-add"
> "$execdir/git-reset" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-reset" ||
> exit; rm -f "$execdir/git-rev-list" && ln "$execdir/git-add" "$execdir/git-rev-
> list" 2>/dev/null || ln -s "git-add" "$execdir/git-rev-list" 2>/dev/null || cp
> "$execdir/git-add" "$execdir/git-rev-list" || exit; rm -f "$execdir/git-rev-
> parse" && ln "$execdir/git-add" "$execdir/git-rev-parse" 2>/dev/null || ln -s
> "git-add" "$execdir/git-rev-parse" 2>/dev/null || cp "$execdir/git-add"
> "$execdir/git-rev-parse" || exit; rm -f "$execdir/git-revert" && ln
> "$execdir/git-add" "$execdir/git-revert" 2>/dev/null || ln -s "git-add"
> "$execdir/git-revert" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-revert"
> || exit; rm -f "$execdir/git-rm" && ln "$execdir/git-add" "$execdir/git-rm"
> 2>/dev/null || ln -s "git-add" "$execdir/git-rm" 2>/dev/null || cp "$execdir/git-
> add" "$execdir/git-rm" || exit; rm -f "$execdir/git-send-pack" && ln
> "$execdir/git-add" "$execdir/git-send-pack" 2>/dev/null || ln -s "git-add"
> "$execdir/git-send-pack" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-send-
> pack" || exit; rm -f "$execdir/git-shortlog" && ln "$execdir/git-add"
> "$execdir/git-shortlog" 2>/dev/null || ln -s "git-add" "$execdir/git-shortlog"
> 2>/dev/null || cp "$execdir/git-add" "$execdir/git-shortlog" || exit; rm -f
> "$execdir/git-show-branch" && ln "$execdir/git-add" "$execdir/git-show-branch"
> 2>/dev/null || ln -s "git-add" "$execdir/git-show-branch" 2>/dev/null || cp
> "$execdir/git-add" "$execdir/git-show-branch" || exit; rm -f "$execdir/git-show-
> ref" && ln "$execdir/git-add" "$execdir/git-show-ref" 2>/dev/null || ln -s "git-
> add" "$execdir/git-show-ref" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-
> show-ref" || exit; rm -f "$execdir/git-stripspace" && ln "$execdir/git-add"
> "$execdir/git-stripspace" 2>/dev/null || ln -s "git-add" "$execdir/git-stripspace"
> 2>/dev/null || cp "$execdir/git-add" "$execdir/git-stripspace" || exit; rm -f
> "$execdir/git-symbolic-ref" && ln "$execdir/git-add" "$execdir/git-symbolic-ref"
> 2>/dev/null || ln -s "git-add" "$execdir/git-symbolic-ref" 2>/dev/null || cp
> "$execdir/git-add" "$execdir/git-symbolic-ref" || exit; rm -f "$execdir/git-tag"
> && ln "$execdir/git-add" "$execdir/git-tag" 2>/dev/null || ln -s "git-add"
> "$execdir/git-tag" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-tag" ||
> exit; rm -f "$execdir/git-tar-tree" && ln "$execdir/git-add" "$execdir/git-tar-
> tree" 2>/dev/null || ln -s "git-add" "$execdir/git-tar-tree" 2>/dev/null || cp
> "$execdir/git-add" "$execdir/git-tar-tree" || exit; rm -f "$execdir/git-unpack-
> objects" && ln "$execdir/git-add" "$execdir/git-unpack-objects" 2>/dev/null || ln
> -s "git-add" "$execdir/git-unpack-objects" 2>/dev/null || cp "$execdir/git-add"
> "$execdir/git-unpack-objects" || exit; rm -f "$execdir/git-update-index" && ln
> "$execdir/git-add" "$execdir/git-update-index" 2>/dev/null || ln -s "git-add"
> "$execdir/git-update-index" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-
> update-index" || exit; rm -f "$execdir/git-update-ref" && ln "$execdir/git-add"
> "$execdir/git-update-ref" 2>/dev/null || ln -s "git-add" "$execdir/git-update-ref"
> 2>/dev/null || cp "$execdir/git-add" "$execdir/git-update-ref" || exit; rm -f
> "$execdir/git-upload-archive" && ln "$execdir/git-add" "$execdir/git-upload-
> archive" 2>/dev/null || ln -s "git-add" "$execdir/git-upload-archive" 2>/dev/null
> || cp "$execdir/git-add" "$execdir/git-upload-archive" || exit; rm -f
> "$execdir/git-verify-pack" && ln "$execdir/git-add" "$execdir/git-verify-pack"
> 2>/dev/null || ln -s "git-add" "$execdir/git-verify-pack" 2>/dev/null || cp
> "$execdir/git-add" "$execdir/git-verify-pack" || exit; rm -f "$execdir/git-
> verify-tag" && ln "$execdir/git-add" "$execdir/git-verify-tag" 2>/dev/null || ln -
> s "git-add" "$execdir/git-verify-tag" 2>/dev/null || cp "$execdir/git-add"
> "$execdir/git-verify-tag" || exit; rm -f "$execdir/git-write-tree" && ln
> "$execdir/git-add" "$execdir/git-write-tree" 2>/dev/null || ln -s "git-add"
> "$execdir/git-write-tree" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-
> write-tree" || exit; rm -f "$execdir/git-cherry-pick" && ln "$execdir/git-add"
> "$execdir/git-cherry-pick" 2>/dev/null || ln -s "git-add" "$execdir/git-cherry-
> pick" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-cherry-pick" || exit; rm
> -f "$execdir/git-cherry" && ln "$execdir/git-add" "$execdir/git-cherry"
> 2>/dev/null || ln -s "git-add" "$execdir/git-cherry" 2>/dev/null || cp
> "$execdir/git-add" "$execdir/git-cherry" || exit; rm -f "$execdir/git-format-
> patch" && ln "$execdir/git-add" "$execdir/git-format-patch" 2>/dev/null || ln -s
> "git-add" "$execdir/git-format-patch" 2>/dev/null || cp "$execdir/git-add"
> "$execdir/git-format-patch" || exit; rm -f "$execdir/git-fsck-objects" && ln
> "$execdir/git-add" "$execdir/git-fsck-objects" 2>/dev/null || ln -s "git-add"
> "$execdir/git-fsck-objects" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-
> fsck-objects" || exit; rm -f "$execdir/git-get-tar-commit-id" && ln
> "$execdir/git-add" "$execdir/git-get-tar-commit-id" 2>/dev/null || ln -s "git-add"
> "$execdir/git-get-tar-commit-id" 2>/dev/null || cp "$execdir/git-add"
> "$execdir/git-get-tar-commit-id" || exit; rm -f "$execdir/git-init" && ln
> "$execdir/git-add" "$execdir/git-init" 2>/dev/null || ln -s "git-add"
> "$execdir/git-init" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-init" ||
> exit; rm -f "$execdir/git-merge-subtree" && ln "$execdir/git-add" "$execdir/git-
> merge-subtree" 2>/dev/null || ln -s "git-add" "$execdir/git-merge-subtree"
> 2>/dev/null || cp "$execdir/git-add" "$execdir/git-merge-subtree" || exit; rm -f
> "$execdir/git-peek-remote" && ln "$execdir/git-add" "$execdir/git-peek-remote"
> 2>/dev/null || ln -s "git-add" "$execdir/git-peek-remote" 2>/dev/null || cp
> "$execdir/git-add" "$execdir/git-peek-remote" || exit; rm -f "$execdir/git-repo-
> config" && ln "$execdir/git-add" "$execdir/git-repo-config" 2>/dev/null || ln -s
> "git-add" "$execdir/git-repo-config" 2>/dev/null || cp "$execdir/git-add"
> "$execdir/git-repo-config" || exit; rm -f "$execdir/git-show" && ln
> "$execdir/git-add" "$execdir/git-show" 2>/dev/null || ln -s "git-add"
> "$execdir/git-show" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-show" ||
> exit; rm -f "$execdir/git-stage" && ln "$execdir/git-add" "$execdir/git-stage"
> 2>/dev/null || ln -s "git-add" "$execdir/git-stage" 2>/dev/null || cp
> "$execdir/git-add" "$execdir/git-stage" || exit; rm -f "$execdir/git-status" &&
> ln "$execdir/git-add" "$execdir/git-status" 2>/dev/null || ln -s "git-add"
> "$execdir/git-status" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-status"
> || exit; rm -f "$execdir/git-whatchanged" && ln "$execdir/git-add" "$execdir/git-
> whatchanged" 2>/dev/null || ln -s "git-add" "$execdir/git-whatchanged" 2>/dev/null
> || cp "$execdir/git-add" "$execdir/git-whatchanged" || exit; } && \
> ./check_bindir "z$bindir" "z$execdir" "$bindir/git-add"
>
> There's a problem with "make quick-install-man":
> LANG= make quick-install-man
> make -C Documentation quick-install-man
> make[1]: Entering directory `/git/git-1.6.1.3/Documentation'
> make -C ../ GIT-VERSION-FILE
> make[2]: Entering directory `/git/git-1.6.1.3'
> make[2]: `GIT-VERSION-FILE' is up to date.
> make[2]: Leaving directory `/git/git-1.6.1.3'
> sh ./install-doc-quick.sh origin/man /git/inst/share/man
> ./install-doc-quick.sh: line 9: /git/inst/libexec/git-sh-setup: No such file or
> directory
> make[1]: *** [quick-install-man] Error 1
> make[1]: Leaving directory `/git/git-1.6.1.3/Documentation'
> make: *** [quick-install-man] Error 2
>
> Regards,
> Ulrich Windl
>
^ permalink raw reply
* [PATCH] Two RPM building improvements
From: Niels Basjes @ 2009-03-27 12:32 UTC (permalink / raw)
To: git; +Cc: Niels Basjes
Two RPM building improvements:
- Building the RPMs can now be done by a non-root user.
- The additional target all-rpms now builds the RPMs for a multitude of target platforms.
Signed-off-by: Niels Basjes <Niels@Basjes.nl>
---
.gitignore | 1 +
Makefile | 26 ++++++++++++++++++++++++--
2 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/.gitignore b/.gitignore
index 1c57d4c..2f2554b 100644
--- a/.gitignore
+++ b/.gitignore
@@ -173,3 +173,4 @@ configure
tags
TAGS
cscope*
+RPM_BUILDING
diff --git a/Makefile b/Makefile
index 7867eac..d9f5e04 100644
--- a/Makefile
+++ b/Makefile
@@ -1564,7 +1564,29 @@ dist: git.spec git-archive$(X) configure
gzip -f -9 $(GIT_TARNAME).tar
rpm: dist
- $(RPMBUILD) -ta $(GIT_TARNAME).tar.gz
+ -@mkdir -p RPM_BUILDING/{BUILD,RPMS,SOURCES,SPECS,SRPMS}
+ $(RPMBUILD) --define="_topdir `pwd`/RPM_BUILDING" -ta $(GIT_TARNAME).tar.gz
+ -@echo ""
+ -@echo "================================================================="
+ -@echo "Generated RPMS and SRPMS:"
+ -@find `pwd`/RPM_BUILDING/ -type f -name '$(distdir)*.rpm' | xargs -n 1 -iXXX echo "- XXX"
+ -@echo "================================================================="
+ -@echo ""
+
+all-rpms: dist
+ -@mkdir -p RPM_BUILDING/{BUILD,RPMS,SOURCES,SPECS,SRPMS}
+ $(RPMBUILD) --define="_topdir `pwd`/RPM_BUILDING" -ta $(GIT_TARNAME).tar.gz --target i386
+ $(RPMBUILD) --define="_topdir `pwd`/RPM_BUILDING" -ta $(GIT_TARNAME).tar.gz --target i686
+ $(RPMBUILD) --define="_topdir `pwd`/RPM_BUILDING" -ta $(GIT_TARNAME).tar.gz --target x86_64
+ $(RPMBUILD) --define="_topdir `pwd`/RPM_BUILDING" -ta $(GIT_TARNAME).tar.gz --target ia32
+ $(RPMBUILD) --define="_topdir `pwd`/RPM_BUILDING" -ta $(GIT_TARNAME).tar.gz --target ppc
+ -@echo ""
+ -@echo "================================================================="
+ -@echo "Generated RPMS and SRPMS:"
+ -@find `pwd`/RPM_BUILDING/ -type f -name '$(distdir)*.rpm' | xargs -n 1 -iXXX echo "- XXX"
+ -@echo "================================================================="
+ -@echo ""
+
htmldocs = git-htmldocs-$(GIT_VERSION)
manpages = git-manpages-$(GIT_VERSION)
@@ -1613,7 +1635,7 @@ ifndef NO_TCLTK
endif
$(RM) GIT-VERSION-FILE GIT-CFLAGS GIT-GUI-VARS GIT-BUILD-OPTIONS
-.PHONY: all install clean strip
+.PHONY: all install clean strip rpm all-rpms
.PHONY: shell_compatibility_test please_set_SHELL_PATH_to_a_more_modern_shell
.PHONY: .FORCE-GIT-VERSION-FILE TAGS tags cscope .FORCE-GIT-CFLAGS
.PHONY: .FORCE-GIT-BUILD-OPTIONS
--
1.6.2
^ permalink raw reply related
* problems syncing with svn
From: Jeff Brown @ 2009-03-27 13:17 UTC (permalink / raw)
To: git
I have found numerous folks having a similar problem but have not
found a solution that works for me. This is what I have:
I have svn clone'd a repo. I have added a git remote to the project.
I have pulled from the git repo. When I attempt to "svn dcommit", the
commit fails with...
Unable to extract revision information from commit
26c8e90f67d40d9193fe276f3bcbfdd4e9161730~1
What I really want to do is move our primary development support to
git (github in particular right now). I want to setup a job that will
periodically grab the latest code from github and push those changes
to our svn repo. These will be the only commits made to svn.
Developers will no longer be committing to svn. We need the svn repo
kept up to date for a few reasons but do not want to do development
against svn directly.
Any advice would be much appreciated.
Thanks in advance.
jeff
--
Jeff Brown
SpringSource
http://www.springsource.com/
Autism Strikes 1 in 166
Find The Cause ~ Find The Cure
http://www.autismspeaks.org/
^ permalink raw reply
* Re: On git 1.6 (novice's opinion)
From: Ulrich Windl @ 2009-03-27 13:35 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: git
In-Reply-To: <37fcd2780903270524x1987a622wb9e693be41fc02c4@mail.gmail.com>
On 27 Mar 2009 at 15:24, Dmitry Potapov wrote:
> On Fri, Mar 27, 2009 at 10:21 AM, Ulrich Windl
> <ulrich.windl@rz.uni-regensburg.de> wrote:
> >
> > 1) The ability to use the file's time at the time of add/commit instead of the
> > current time, and the ability tho check outfiles with the times stored in the
> > repository.
>
> To check out with the times stored in repository is a a bad idea, because it
> will screw up 'make'.
Hi,
I don't understand:
If I modify files, then do a make, then do check-in/check-out (and the file times
are unchanged), how would that affect make?
If I do an "update/merge from remote" (there is no total ordering of release
numbers anyway) without a "make clean" before, I'm having a problem anyway.
>
> >
> > 2) Keyword substitution. I know it's controverse (dealing with binary files),
> > but I'd like to have some automatic version numbering keyword at least:
> > Initial idea is that every commit with a change increments the number by one,
> > and when merging numbers a and b, the resulting number is max(a, b) + 1.
>
> I am not sure what you want to achieve by having this number. Also, take
> a look at "git describe", it may be close to what you want (or may be not).
Basically I want to support my laziness: The system will increment some number and
maybe change some text automatically that I'm to lazy to do. OK, there are still
many commands I'll have to learn. Unfortunately some command names are not as
"crispy" as they could be (i.e. you cannot easily find the right command name if
you know what you are looking for, and if you have a command name, it's not very
clear what it really does). That makes it hard for the beginners.
Regards,
Ulrich
^ permalink raw reply
* Re: On git 1.6 (novice's opinion)
From: Ulrich Windl @ 2009-03-27 13:39 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: H.Merijn Brand, git
In-Reply-To: <37fcd2780903270524y39456c5fre0a2f8f9c5f4d160@mail.gmail.com>
On 27 Mar 2009 at 15:24, Dmitry Potapov wrote:
> On Fri, Mar 27, 2009 at 12:50 PM, Ulrich Windl
> <ulrich.windl@rz.uni-regensburg.de> wrote:
> >
> > what made me wonder is this (about item 1): I thought I've read that blobs store
> > content and attributes, so very obviously I wondered why not store thr "right
> > attributes" (i.e. the time of the file). My reasoning: You make some changes, then
> > test them (which might last several hours or days). The if I'm happy I'll
> > "commit".
>
> With Git, you usually commit your changes immediately (without waiting
> the result
> of testing), because you can always undo commit until you publish your changes.
Hi!
AFAIK, "committing" in git is "kind of publishing your work" (others may pull it).
I don't like publishing my mistakes ;-) Even if no-one pulls the commit, your
"undo" refers to "committing a fix for the last committed mistake", right? Again,
I don't really want to document/archive (i.e. commit) my mistake. Or did I miss
something here?
I know: Other's opinions are quite different on these issues.
Regards,
Ulrich
^ permalink raw reply
* Re: On git 1.6 (novice's opinion)
From: Etienne Vallette d'Osia @ 2009-03-27 13:47 UTC (permalink / raw)
To: Ulrich Windl; +Cc: Dmitry Potapov, H.Merijn Brand, git
In-Reply-To: <49CCE520.17260.2586E134@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de>
Ulrich Windl a écrit :
> AFAIK, "committing" in git is "kind of publishing your work" (others may pull it).
> I don't like publishing my mistakes ;-) Even if no-one pulls the commit, your
> "undo" refers to "committing a fix for the last committed mistake", right? Again,
> I don't really want to document/archive (i.e. commit) my mistake. Or did I miss
> something here?
> I know: Other's opinions are quite different on these issues.
commit is local.
The good way is to commit in your local and private repository.
Then you can do anything, reset commit you have just done, etc
When all is ok, you push in a public repository.
With this workflow, no one see your local work and you can commit very
often, undo commit, rebase a lot etc.
The only result of a such job is a large number of useless objects in
your local repository. They will be delete automatically by git, so it's
not a problem.
Regard,
Etienne
^ permalink raw reply
* Re: On git 1.6 (novice's opinion)
From: Matthieu Moy @ 2009-03-27 13:44 UTC (permalink / raw)
To: Ulrich Windl; +Cc: Dmitry Potapov, git
In-Reply-To: <49CCE421.16918.2582FE84@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de>
"Ulrich Windl" <ulrich.windl@rz.uni-regensburg.de> writes:
> I don't understand:
> If I modify files, then do a make, then do check-in/check-out (and the file times
> are unchanged), how would that affect make?
>From "make"'s point of view, chechout is just a modification of the
file (as any other modification you would do with a text editor). If
you compile foo.c to foo.o, then checkout another version of foo.c,
then you want foo.c to be recompiled. If checkout modifies the
timestamp to pretend it was modified before foo.o, then make thinks
the file is up to date.
> If I do an "update/merge from remote" (there is no total ordering of release
> numbers anyway) without a "make clean" before, I'm having a problem
> anyway.
No, you don't have a problem. Recompiling files after they're modified
is the job of make, and it just does it. make doesn't know about
revision numbers or identifiers, just timestamps.
--
Matthieu
^ permalink raw reply
* Re: On git 1.6 (novice's opinion)
From: Matthieu Moy @ 2009-03-27 13:45 UTC (permalink / raw)
To: Ulrich Windl; +Cc: Dmitry Potapov, H.Merijn Brand, git
In-Reply-To: <49CCE520.17260.2586E134@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de>
"Ulrich Windl" <ulrich.windl@rz.uni-regensburg.de> writes:
> Hi!
>
> AFAIK, "committing" in git is "kind of publishing your work"
It's not. It's "take a snapshot". Publish is "push" (to a public
place).
> (others may pull it). I don't like publishing my mistakes ;-) Even
> if no-one pulls the commit, your "undo" refers to "committing a fix
> for the last committed mistake", right? Again, I don't really want
> to document/archive (i.e. commit) my mistake. Or did I miss
> something here?
git commit --amend
git reset HEAD^ and friends (to uncommit something)
--
Matthieu
^ permalink raw reply
* Re: On git 1.6 (novice's opinion)
From: Ulrich Windl @ 2009-03-27 13:48 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <49CCCB3D.8010706@drmicha.warpmail.net>
On 27 Mar 2009 at 13:49, Michael J Gruber wrote:
> Ulrich Windl venit, vidit, dixit 27.03.2009 08:21:
[...]
> Keyword substitution and cvs/svn style version numbers are independent
> issues. The sha1 describes a commit uniquely, one could use that as a
> keyword.
However version numbers and time stamps have the property of being at least
partially ordered in respect of "newer/older". That property does not hold for
SHA-1 checksums. Just imagine suggesting users to upgrade from Microsoft
Word/004765c2a1e9771e886f0dbe87d4f89643cd6f70 to Microsoft
Word/00b7e6f51130f234a969c84ee9231a5ff7fc8a82 ;-)
>
> Increasing version numbers are meaningless in a true DVCS world. What is
> your 100th commit may not be someone else's, even if both your master's
> heads are the same! This is why hg version numbers are a local thing.
> They are merely a local shortcut for specifying a revision and serve the
> same purpose as git's "backward" counts like HEAD~3 etc. Neither of them
> work permanently, not even in a local repo, if you allow rebasing.
Maybe I didn't fully understand, but having a version number that is larger than
any parent's version numbers when doing a merge/commit doesn't look wrong to me.
>
> git rev-list HEAD|wc may produce something like it, but be sure to read
> up on --sparse and --full-history.
I'm not deep enough into it, yet.
[...]
Regards,
Ulrich
^ permalink raw reply
* Re: [PATCH] Two RPM building improvements
From: Jakub Narebski @ 2009-03-27 13:50 UTC (permalink / raw)
To: Niels Basjes; +Cc: git
In-Reply-To: <1238157134-27558-1-git-send-email-Niels@Basjes.nl>
Niels Basjes <Niels@Basjes.nl> writes:
> Two RPM building improvements:
Two _unrelated_ RPM building improvements squashed in one commit.
> - Building the RPMs can now be done by a non-root user.
It was always possible, you only have to configure rpm / rpmbuild,
namely put path to where you want your RPM_BUILDING directory in
~/.rpmmacros as %_topdir, for example:
$ cat ~/.rpmmacros
%_topdir /home/local/builddir
Please RTFM first, before going to solve non-problem in (ugh) fairly
complicated way.
> - The additional target all-rpms now builds the RPMs for a multitude of target platforms.
Please wrap commit messages at 72-76 columns, at most at 80 columns.
No such overly long lines, please.
But the all-rpms target looks like a good idea
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: problems syncing with svn
From: Jeff Brown @ 2009-03-27 13:58 UTC (permalink / raw)
To: git
In-Reply-To: <bbd12f0f0903270617m3c2233b2g6c6e8c3d9a9b50a4@mail.gmail.com>
On Fri, Mar 27, 2009 at 9:17 AM, Jeff Brown <jeff@jeffandbetsy.net> wrote:
> I have found numerous folks having a similar problem but have not
> found a solution that works for me. This is what I have:
>
> I have svn clone'd a repo. I have added a git remote to the project.
> I have pulled from the git repo. When I attempt to "svn dcommit", the
> commit fails with...
>
> Unable to extract revision information from commit
> 26c8e90f67d40d9193fe276f3bcbfdd4e9161730~1
>
> What I really want to do is move our primary development support to
> git (github in particular right now). I want to setup a job that will
> periodically grab the latest code from github and push those changes
> to our svn repo. These will be the only commits made to svn.
> Developers will no longer be committing to svn. We need the svn repo
> kept up to date for a few reasons but do not want to do development
> against svn directly.
>
> Any advice would be much appreciated.
>
> Thanks in advance.
>
If repo details will help, the git repo is at
http://github.com/grails/grails/tree/master and the original svn repo
which that came from is at https://svn.codehaus.org/grails/trunk/.
Thanks again.
Jeff
--
Jeff Brown
SpringSource
http://www.springsource.com/
Autism Strikes 1 in 166
Find The Cause ~ Find The Cure
http://www.autismspeaks.org/
^ permalink raw reply
* Re: On git 1.6 (novice's opinion)
From: Jakub Narebski @ 2009-03-27 14:09 UTC (permalink / raw)
To: Ulrich Windl; +Cc: Michael J Gruber, git
In-Reply-To: <49CCE72E.20081.258EE61F@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de>
"Ulrich Windl" <ulrich.windl@rz.uni-regensburg.de> writes:
> On 27 Mar 2009 at 13:49, Michael J Gruber wrote:
> > Ulrich Windl venit, vidit, dixit 27.03.2009 08:21:
>
> [...]
>
> > Keyword substitution and cvs/svn style version numbers are independent
> > issues. The sha1 describes a commit uniquely, one could use that as a
> > keyword.
>
> However version numbers and time stamps have the property of being at least
> partially ordered in respect of "newer/older". That property does not hold for
> SHA-1 checksums. Just imagine suggesting users to upgrade from Microsoft
> Word/004765c2a1e9771e886f0dbe87d4f89643cd6f70 to Microsoft
> Word/00b7e6f51130f234a969c84ee9231a5ff7fc8a82 ;-)
That is why people use output of git-describe and _tag_ their releases,
and make embedding version number in released version (tarball / binary)
the job of make: see GIT-VERSION-GEN script in git sources, and how it
is used in Makefile.
>
> >
> > Increasing version numbers are meaningless in a true DVCS world. What is
> > your 100th commit may not be someone else's, even if both your master's
> > heads are the same! This is why hg version numbers are a local thing.
> > They are merely a local shortcut for specifying a revision and serve the
> > same purpose as git's "backward" counts like HEAD~3 etc. Neither of them
> > work permanently, not even in a local repo, if you allow rebasing.
>
> Maybe I didn't fully understand, but having a version number that is larger than
> any parent's version numbers when doing a merge/commit doesn't look wrong to me.
I'm sorry to dissapoint you, but without central server assigning
numbers to commits it wouldn't simply work in distributed version
control world. Take for example the following situation: somebody
clones your repository, and creates new commit on 'master' (trunk) and
it gets version number N. Meanwhile you also independently create new
commit on 'master'... and without central authority it would also get
version number N. Then you would merge (pull) his/her changes, and
you would have two commits with the same number; not something you want.
Not to mention that you can have multiple roots (multiple commits with
no parent) in git repository; besides independent branches (like
'man', 'html' or 'todo') it is usually result of absorbing or
subtree-merging other projects. In 'master' branch there are 5 roots
or more: joined 'git-tools' (mailinfo / mailsplit), absorbed gitweb,
and subtree-merged gitk and git-gui. And here you would again have
multiple commits with the same number...
The idea of generation numbers was discussed on git mailing list, but
rather as mechanism helping in faster topological ordering of commits
(--topo-sort)... but it was dropped.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Improve tags
From: Jakub Narebski @ 2009-03-27 14:15 UTC (permalink / raw)
To: Etienne Vallette d'Osia; +Cc: Michael J Gruber, git
In-Reply-To: <49CCAAD3.4070104@gmail.com>
"Etienne Vallette d'Osia" <dohzya@gmail.com> writes:
> > You described your motivation and use case very clearly!
> >
> > Maybe "label" would be an appropriate name for "non-unique tags". I
> > assume they should be local and non-versioned. It sounds as if a file
> > storing a list of sha1s could be the simplest approach (one file per
> > label in a new subdir of .git), although this may not scale well. A
> > first step could be implementing a command "git label" in shell which
> > sets and displays labels. Later on, various builtins would need to be
> > taught about it if you want labels displayed in log etc.
>
> Thanks a lot
>
> "label" is perfect !
>
> In fact, I was thinking about non-local labels.
> But keeping information in a separate file and not in commit directly
> is a very nice idea (and closer than the current tag implementation).
> I love your approach, you have just make this idea realizable
This is a bit argument for (abandoned / dropped) 'notes' commit header
idea... But only a tiny bit.
More seriously: take a look at 'notes' idea; I'm not sure what state
they are currently, but they are in active (more or less) development.
They are extension of tags, allowing post-fact annotation of commits.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Improve tags
From: Etienne Vallette d'Osia @ 2009-03-27 14:39 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Etienne Vallette d'Osia, Michael J Gruber, git
In-Reply-To: <m3bprn2gs7.fsf@localhost.localdomain>
on 27.03.2009 15:15, Jakub Narebski wrote:
> More seriously: take a look at 'notes' idea; I'm not sure what state
> they are currently, but they are in active (more or less) development.
> They are extension of tags, allowing post-fact annotation of commits.
>
git notes store a message related to _a specific_ commit.
It doesn't allow to find some commits.
In my mind, the best way to bind labels and notes (which would be great)
is to allow to create a note related to a label.
Regards,
--
Etienne Vallette d'Osia
^ 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