* Re: combine git repo historically
From: Jakub Narebski @ 2009-10-11 14:29 UTC (permalink / raw)
To: Christian Couder; +Cc: Johannes Sixt, bill lam, git, Christian Couder
In-Reply-To: <200910111543.39327.chriscool@tuxfamily.org>
Dnia niedziela 11. października 2009 15:43, Christian Couder napisał:
> On Sunday 11 October 2009, Johannes Sixt wrote:
> > There is no way to retrieve the original commit using plumbing
> > unless the replacement is removed. Am I right?
>
> I think you are right, but a flag could be easily added to some commands to
> retreive original objects. Or you can remove the replacement, retrieve the
> object and then put back the replacement.
Wouldn't it be better for this option to be option for git wrapper,
i.e.
$ git --no-replace cat-file -p N
and not
$ git cat-file --no-replace -p N
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Merging non-git releases of a project
From: Avery Pennarun @ 2009-10-11 15:32 UTC (permalink / raw)
To: Howard Miller; +Cc: git
In-Reply-To: <26ae428a0910100158s5233841byd303377aa20eb45f@mail.gmail.com>
On Sat, Oct 10, 2009 at 4:58 AM, Howard Miller
<howard@e-learndesign.co.uk> wrote:
> I don't have cp -a (on a mac) but, IIRC, that's just -rp or somesuch?
You can obtain a non-stupid version of 'cp' (as well as 'ls' and
'grep' and 'find' and other useful tools) for your mac by using fink.
But yes.
Have fun,
Avery
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.6.5
From: Steven Noonan @ 2009-10-11 16:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <f488382f0910110930u1af92299ld5d72dbb31ed1914@mail.gmail.com>
On Sun, Oct 11, 2009 at 9:30 AM, Steven Noonan <steven@uplinklabs.net> wrote:
> Uh-oh.
>
> Alcarin:crisscross steven$ git remote update
> Updating origin
> fatal: 'git@github.com/tycho/crisscross.git' does not appear to be a
> git repository
> fatal: The remote end hung up unexpectedly
> error: Could not fetch origin
>
> Alcarin:crisscross steven$ nano -w .git/config
> Alcarin:crisscross steven$ git remote update
> Updating origin
Er, meant to say before this that I edited the URI to include the
'ssh://' and then it worked fine.
>
> The 'ssh://' part is omitted in numerous places on github.com. I
> realize github.com isn't the final authority on the syntax of the URI,
> but was this an intentional change or a regression?
>
> - Steven
>
> On Sun, Oct 11, 2009 at 1:40 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> The latest feature release GIT 1.6.5 is available at the usual
>> places:
>>
>> http://www.kernel.org/pub/software/scm/git/
>>
>> git-1.6.5.tar.{gz,bz2} (source tarball)
>> git-htmldocs-1.6.5.tar.{gz,bz2} (preformatted docs)
>> git-manpages-1.6.5.tar.{gz,bz2} (preformatted docs)
>>
>> The RPM binary packages for a few architectures are found in:
>>
>> RPMS/$arch/git-*-1.6.5-1.fc9.$arch.rpm (RPM)
>>
>> This cycle took a bit longer than I hoped, but here it is. We already
>> have some new features cooking in 'next', and I expect we may be able to
>> have 1.6.6 by the end of the year.
>>
>> Enjoy.
>>
>> ----------------------------------------------------------------
>>
>> GIT v1.6.5 Release Notes
>> ========================
>>
>> In git 1.7.0, which was planned to be the release after 1.6.5, "git
>> push" into a branch that is currently checked out will be refused by
>> default.
>>
>> You can choose what should happen upon such a push by setting the
>> configuration variable receive.denyCurrentBranch in the receiving
>> repository.
>>
>> Also, "git push $there :$killed" to delete the branch $killed in a remote
>> repository $there, when $killed branch is the current branch pointed at by
>> its HEAD, will be refused by default.
>>
>> You can choose what should happen upon such a push by setting the
>> configuration variable receive.denyDeleteCurrent in the receiving
>> repository.
>>
>> To ease the transition plan, the receiving repository of such a
>> push running this release will issue a big warning when the
>> configuration variable is missing. Please refer to:
>>
>> http://git.or.cz/gitwiki/GitFaq#non-bare
>> http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007
>>
>> for more details on the reason why this change is needed and the
>> transition plan.
>>
>> Updates since v1.6.4
>> --------------------
>>
>> (subsystems)
>>
>> * various updates to gitk, git-svn and gitweb.
>>
>> (portability)
>>
>> * more improvements on mingw port.
>>
>> * mingw will also give FRSX as the default value for the LESS
>> environment variable when the user does not have one.
>>
>> * initial support to compile git on Windows with MSVC.
>>
>> (performance)
>>
>> * On major platforms, the system can be compiled to use with Linus's
>> block-sha1 implementation of the SHA-1 hash algorithm, which
>> outperforms the default fallback implementation we borrowed from
>> Mozilla.
>>
>> * Unnecessary inefficiency in deepening of a shallow repository has
>> been removed.
>>
>> * "git clone" does not grab objects that it does not need (i.e.
>> referenced only from refs outside refs/heads and refs/tags
>> hierarchy) anymore.
>>
>> * The "git" main binary used to link with libcurl, which then dragged
>> in a large number of external libraries. When using basic plumbing
>> commands in scripts, this unnecessarily slowed things down. We now
>> implement http/https/ftp transfer as a separate executable as we
>> used to.
>>
>> * "git clone" run locally hardlinks or copies the files in .git/ to
>> newly created repository. It used to give new mtime to copied files,
>> but this delayed garbage collection to trigger unnecessarily in the
>> cloned repository. We now preserve mtime for these files to avoid
>> this issue.
>>
>> (usability, bells and whistles)
>>
>> * Human writable date format to various options, e.g. --since=yesterday,
>> master@{2000.09.17}, are taught to infer some omitted input properly.
>>
>> * A few programs gave verbose "advice" messages to help uninitiated
>> people when issuing error messages. An infrastructure to allow
>> users to squelch them has been introduced, and a few such messages
>> can be silenced now.
>>
>> * refs/replace/ hierarchy is designed to be usable as a replacement
>> of the "grafts" mechanism, with the added advantage that it can be
>> transferred across repositories.
>>
>> * "git am" learned to optionally ignore whitespace differences.
>>
>> * "git am" handles input e-mail files that has CRLF line endings sensibly.
>>
>> * "git am" learned "--scissors" option to allow you to discard early part
>> of an incoming e-mail.
>>
>> * "git archive -o output.zip" works without being told what format to
>> use with an explicit "--format=zip".option.
>>
>> * "git checkout", "git reset" and "git stash" learned to pick and
>> choose to use selected changes you made, similar to "git add -p".
>>
>> * "git clone" learned a "-b" option to pick a HEAD to check out
>> different from the remote's default branch.
>>
>> * "git clone" learned --recursive option.
>>
>> * "git clone" from a local repository on a different filesystem used to
>> copy individual object files without preserving the old timestamp, giving
>> them extra lifetime in the new repository until they gc'ed.
>>
>> * "git commit --dry-run $args" is a new recommended way to ask "what would
>> happen if I try to commit with these arguments."
>>
>> * "git commit --dry-run" and "git status" shows conflicted paths in a
>> separate section to make them easier to spot during a merge.
>>
>> * "git cvsimport" now supports password-protected pserver access even
>> when the password is not taken from ~/.cvspass file.
>>
>> * "git fast-export" learned --no-data option that can be useful when
>> reordering commits and trees without touching the contents of
>> blobs.
>>
>> * "git fast-import" has a pair of new front-end in contrib/ area.
>>
>> * "git init" learned to mkdir/chdir into a directory when given an
>> extra argument (i.e. "git init this").
>>
>> * "git instaweb" optionally can use mongoose as the web server.
>>
>> * "git log --decorate" can optionally be told with --decorate=full to
>> give the reference name in full.
>>
>> * "git merge" issued an unnecessarily scary message when it detected
>> that the merge may have to touch the path that the user has local
>> uncommitted changes to. The message has been reworded to make it
>> clear that the command aborted, without doing any harm.
>>
>> * "git push" can be told to be --quiet.
>>
>> * "git push" pays attention to url.$base.pushInsteadOf and uses a URL
>> that is derived from the URL used for fetching.
>>
>> * informational output from "git reset" that lists the locally modified
>> paths is made consistent with that of "git checkout $another_branch".
>>
>> * "git submodule" learned to give submodule name to scripts run with
>> "foreach" subcommand.
>>
>> * various subcommands to "git submodule" learned --recursive option.
>>
>> * "git submodule summary" learned --files option to compare the work
>> tree vs the commit bound at submodule path, instead of comparing
>> the index.
>>
>> * "git upload-pack", which is the server side support for "git clone" and
>> "git fetch", can call a new post-upload-pack hook for statistics purposes.
>>
>> (developers)
>>
>> * With GIT_TEST_OPTS="--root=/p/a/t/h", tests can be run outside the
>> source directory; using tmpfs may give faster turnaround.
>>
>> * With NO_PERL_MAKEMAKER set, DESTDIR= is now honoured, so you can
>> build for one location, and install into another location to tar it
>> up.
>>
>> Fixes since v1.6.4
>> ------------------
>>
>> All of the fixes in v1.6.4.X maintenance series are included in this
>> release, unless otherwise noted.
>> --
>> To unsubscribe from this list: send the line "unsubscribe git" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.6.5
From: Steven Noonan @ 2009-10-11 16:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8wfi1fya.fsf@alter.siamese.dyndns.org>
Uh-oh.
Alcarin:crisscross steven$ git remote update
Updating origin
fatal: 'git@github.com/tycho/crisscross.git' does not appear to be a
git repository
fatal: The remote end hung up unexpectedly
error: Could not fetch origin
Alcarin:crisscross steven$ nano -w .git/config
Alcarin:crisscross steven$ git remote update
Updating origin
The 'ssh://' part is omitted in numerous places on github.com. I
realize github.com isn't the final authority on the syntax of the URI,
but was this an intentional change or a regression?
- Steven
On Sun, Oct 11, 2009 at 1:40 AM, Junio C Hamano <gitster@pobox.com> wrote:
> The latest feature release GIT 1.6.5 is available at the usual
> places:
>
> http://www.kernel.org/pub/software/scm/git/
>
> git-1.6.5.tar.{gz,bz2} (source tarball)
> git-htmldocs-1.6.5.tar.{gz,bz2} (preformatted docs)
> git-manpages-1.6.5.tar.{gz,bz2} (preformatted docs)
>
> The RPM binary packages for a few architectures are found in:
>
> RPMS/$arch/git-*-1.6.5-1.fc9.$arch.rpm (RPM)
>
> This cycle took a bit longer than I hoped, but here it is. We already
> have some new features cooking in 'next', and I expect we may be able to
> have 1.6.6 by the end of the year.
>
> Enjoy.
>
> ----------------------------------------------------------------
>
> GIT v1.6.5 Release Notes
> ========================
>
> In git 1.7.0, which was planned to be the release after 1.6.5, "git
> push" into a branch that is currently checked out will be refused by
> default.
>
> You can choose what should happen upon such a push by setting the
> configuration variable receive.denyCurrentBranch in the receiving
> repository.
>
> Also, "git push $there :$killed" to delete the branch $killed in a remote
> repository $there, when $killed branch is the current branch pointed at by
> its HEAD, will be refused by default.
>
> You can choose what should happen upon such a push by setting the
> configuration variable receive.denyDeleteCurrent in the receiving
> repository.
>
> To ease the transition plan, the receiving repository of such a
> push running this release will issue a big warning when the
> configuration variable is missing. Please refer to:
>
> http://git.or.cz/gitwiki/GitFaq#non-bare
> http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007
>
> for more details on the reason why this change is needed and the
> transition plan.
>
> Updates since v1.6.4
> --------------------
>
> (subsystems)
>
> * various updates to gitk, git-svn and gitweb.
>
> (portability)
>
> * more improvements on mingw port.
>
> * mingw will also give FRSX as the default value for the LESS
> environment variable when the user does not have one.
>
> * initial support to compile git on Windows with MSVC.
>
> (performance)
>
> * On major platforms, the system can be compiled to use with Linus's
> block-sha1 implementation of the SHA-1 hash algorithm, which
> outperforms the default fallback implementation we borrowed from
> Mozilla.
>
> * Unnecessary inefficiency in deepening of a shallow repository has
> been removed.
>
> * "git clone" does not grab objects that it does not need (i.e.
> referenced only from refs outside refs/heads and refs/tags
> hierarchy) anymore.
>
> * The "git" main binary used to link with libcurl, which then dragged
> in a large number of external libraries. When using basic plumbing
> commands in scripts, this unnecessarily slowed things down. We now
> implement http/https/ftp transfer as a separate executable as we
> used to.
>
> * "git clone" run locally hardlinks or copies the files in .git/ to
> newly created repository. It used to give new mtime to copied files,
> but this delayed garbage collection to trigger unnecessarily in the
> cloned repository. We now preserve mtime for these files to avoid
> this issue.
>
> (usability, bells and whistles)
>
> * Human writable date format to various options, e.g. --since=yesterday,
> master@{2000.09.17}, are taught to infer some omitted input properly.
>
> * A few programs gave verbose "advice" messages to help uninitiated
> people when issuing error messages. An infrastructure to allow
> users to squelch them has been introduced, and a few such messages
> can be silenced now.
>
> * refs/replace/ hierarchy is designed to be usable as a replacement
> of the "grafts" mechanism, with the added advantage that it can be
> transferred across repositories.
>
> * "git am" learned to optionally ignore whitespace differences.
>
> * "git am" handles input e-mail files that has CRLF line endings sensibly.
>
> * "git am" learned "--scissors" option to allow you to discard early part
> of an incoming e-mail.
>
> * "git archive -o output.zip" works without being told what format to
> use with an explicit "--format=zip".option.
>
> * "git checkout", "git reset" and "git stash" learned to pick and
> choose to use selected changes you made, similar to "git add -p".
>
> * "git clone" learned a "-b" option to pick a HEAD to check out
> different from the remote's default branch.
>
> * "git clone" learned --recursive option.
>
> * "git clone" from a local repository on a different filesystem used to
> copy individual object files without preserving the old timestamp, giving
> them extra lifetime in the new repository until they gc'ed.
>
> * "git commit --dry-run $args" is a new recommended way to ask "what would
> happen if I try to commit with these arguments."
>
> * "git commit --dry-run" and "git status" shows conflicted paths in a
> separate section to make them easier to spot during a merge.
>
> * "git cvsimport" now supports password-protected pserver access even
> when the password is not taken from ~/.cvspass file.
>
> * "git fast-export" learned --no-data option that can be useful when
> reordering commits and trees without touching the contents of
> blobs.
>
> * "git fast-import" has a pair of new front-end in contrib/ area.
>
> * "git init" learned to mkdir/chdir into a directory when given an
> extra argument (i.e. "git init this").
>
> * "git instaweb" optionally can use mongoose as the web server.
>
> * "git log --decorate" can optionally be told with --decorate=full to
> give the reference name in full.
>
> * "git merge" issued an unnecessarily scary message when it detected
> that the merge may have to touch the path that the user has local
> uncommitted changes to. The message has been reworded to make it
> clear that the command aborted, without doing any harm.
>
> * "git push" can be told to be --quiet.
>
> * "git push" pays attention to url.$base.pushInsteadOf and uses a URL
> that is derived from the URL used for fetching.
>
> * informational output from "git reset" that lists the locally modified
> paths is made consistent with that of "git checkout $another_branch".
>
> * "git submodule" learned to give submodule name to scripts run with
> "foreach" subcommand.
>
> * various subcommands to "git submodule" learned --recursive option.
>
> * "git submodule summary" learned --files option to compare the work
> tree vs the commit bound at submodule path, instead of comparing
> the index.
>
> * "git upload-pack", which is the server side support for "git clone" and
> "git fetch", can call a new post-upload-pack hook for statistics purposes.
>
> (developers)
>
> * With GIT_TEST_OPTS="--root=/p/a/t/h", tests can be run outside the
> source directory; using tmpfs may give faster turnaround.
>
> * With NO_PERL_MAKEMAKER set, DESTDIR= is now honoured, so you can
> build for one location, and install into another location to tar it
> up.
>
> Fixes since v1.6.4
> ------------------
>
> All of the fixes in v1.6.4.X maintenance series are included in this
> release, unless otherwise noted.
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: Installing full fledged git on solaris? - solved
From: Dilip M @ 2009-10-11 16:38 UTC (permalink / raw)
To: Ben Walton; +Cc: git
On Sun, Oct 11, 2009 at 6:42 PM, Ben Walton <bwalton@artsci.utoronto.ca> wrote:
> Excerpts from Dilip M's message of Sun Oct 11 08:26:10 -0400 2009:
>
> Hi Dilip,
>
>> Has anyone has the list of pkg's to be installed on solaris 10 sparc,
>> to get the GIT compiled (with all features)..
>
> This may not be what you want, but if you use the CSW package stack,
> you can get git easily. This is, I believe, a very complete git
> installation. There will soon be an update to 1.6.5.
>
> http://www.opencsw.org/packages/git
>
> If your intent is to build it yourself, let me know and I'll share
> with you the build recipe I use, which will outline (within the CSW
> stack) which packages are used for compilation and which for runtime
> dependencies. You should be able to translate it to use the
> libs/tools available to solaris 10 (that aren't in 8, which we also
> support).
Thank Ben. You saved my day!
BTW, any info on making tig package available! Just asking...
--
Dilip
^ permalink raw reply
* ident pattern match is incorrect
From: Bruce Korb @ 2009-10-11 16:52 UTC (permalink / raw)
To: git; +Cc: Bruce Korb
The git attribute "ident" fails here:
sed '2,/and the template file/d
/\$Id:/d
/Last template edit:/d' getopt-test_${testname}.c
The pattern match for ident should be (shell syntax):
$'\$Id(:[^$\n]+\$|\$)'
In other words, it is not a multi-line pattern.
I was looking for a bugzilla entry here:
http://git-scm.com/
but I did not see a bug reporting method.
^ permalink raw reply
* git log --graph
From: Dilip M @ 2009-10-11 18:27 UTC (permalink / raw)
To: git
I am using: git version 1.6.3.2
Somehow not getting text graph as mentioned in
http://www.gitready.com/intermediate/2009/01/26/text-based-graph.html
Any hints would really help..
I am trying git log --graph. (has commits in two branches...). But
always see one line :(
--
Dilip
^ permalink raw reply
* Re: git log --graph
From: Sverre Rabbelier @ 2009-10-11 18:35 UTC (permalink / raw)
To: Dilip M; +Cc: git
In-Reply-To: <c94f8e120910111127q102aa6a1qc3c0850f8a8a1509@mail.gmail.com>
Heya,
On Sun, Oct 11, 2009 at 20:27, Dilip M <dilipm79@gmail.com> wrote:
> I am trying git log --graph. (has commits in two branches...). But
> always see one line :(
It'll show you the history of one branch at a time online, you won't
get the demo-ed multiple lines unless the branch you're looking at
contains merges.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* [RFC/PATCH] git: add --no-replace option to disable replacing
From: Christian Couder @ 2009-10-11 15:32 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Jakub Narebski, Johannes Sixt, bill lam, Andreas Schwab
Commit dae556b (environment: add global variable to disable replacement)
adds a variable to enable/disable replacement, and it is enabled by
default for most commands.
So there is no way to disable it for some commands, which is annoying
when we want to get information about a commit that has been replaced.
For example:
$ git cat-file -p N
would output information about the replacement commit if commit N is
replaced.
With the "--no-replace" option that this patch adds it is possible to
get information about the original commit using:
$ git --no-replace cat-file -p N
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
git.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
Jakub Narebski wrote:
> Wouldn't it be better for this option to be option for git
> wrapper, i.e.
>
> $ git --no-replace cat-file -p N
>
> and not
>
> $ git cat-file --no-replace -p N
You mean something like this patch?
This is untested yet. I will add some tests and documentation
later if it's ok to add this option.
diff --git a/git.c b/git.c
index 9883009..cfef7ac 100644
--- a/git.c
+++ b/git.c
@@ -6,7 +6,7 @@
const char git_usage_string[] =
"git [--version] [--exec-path[=GIT_EXEC_PATH]] [--html-path]\n"
- " [-p|--paginate|--no-pager]\n"
+ " [-p|--paginate|--no-pager] [--no-replace]\n"
" [--bare] [--git-dir=GIT_DIR] [--work-tree=GIT_WORK_TREE]\n"
" [--help] COMMAND [ARGS]";
@@ -87,6 +87,8 @@ static int handle_options(const char ***argv, int *argc, int *envchanged)
use_pager = 0;
if (envchanged)
*envchanged = 1;
+ } else if (!strcmp(cmd, "--no-replace")) {
+ read_replace_refs = 0;
} else if (!strcmp(cmd, "--git-dir")) {
if (*argc < 2) {
fprintf(stderr, "No directory given for --git-dir.\n" );
--
1.6.5.1.g31b53
^ permalink raw reply related
* Re: [ANNOUNCE] GIT 1.6.5
From: Junio C Hamano @ 2009-10-11 18:47 UTC (permalink / raw)
To: Steven Noonan; +Cc: git
In-Reply-To: <f488382f0910110930u1af92299ld5d72dbb31ed1914@mail.gmail.com>
Steven Noonan <steven@uplinklabs.net> writes:
> Uh-oh.
>
> Alcarin:crisscross steven$ git remote update
> Updating origin
> fatal: 'git@github.com/tycho/crisscross.git' does not appear to be a
> git repository
> fatal: The remote end hung up unexpectedly
> error: Could not fetch origin
Try user@site:path/to/repo.git with a colon. As you mentioned already,
you could also use ssh://user@site/full/path/to/repo.git
> The 'ssh://' part is omitted in numerous places on github.com. I
> realize github.com isn't the final authority on the syntax of the URI,
What do you mean by "final authority"?
Your misconfigured URL is diagnosed by the local client on your end and I
do not think it has anything to do with github. Do you mean github.com
documentation primarily uses scp syntax (i.e. [user@]site:path/to/repo)
instead of the fake URI syntax (i.e. ssh://user@site/full/path/to/repo),
*but* misspells the former without colon (i.e. [user@]site/path/to/repo)?
If that is the case, it is something github folks need to fix, but I doubt
they have such a breakage.
> but was this an intentional change or a regression?
I do not think older clients ever allowed your colon-less scp syntax. Do
you really see any *change*? IOW, not the difference between the ssh://
syntax and a misspelled scp syntax, but a difference between versions of
git working and not working with a misspelled scp syntax?
Which version of git worked with "git@github.com/tycho/crisscross.git" for
you?
^ permalink raw reply
* Re: [PATCH] disallow refs containing successive slashes
From: Junio C Hamano @ 2009-10-11 18:52 UTC (permalink / raw)
To: Jens Lehmann; +Cc: git
In-Reply-To: <4AD1B6A4.8060405@web.de>
Jens Lehmann <Jens.Lehmann@web.de> writes:
>>> I became aware of this issue while looking into problems occuring
>>> when a user created a branch starting with a '/' in git gui (e.g.
>>> "/foo"). Strange things happen, while git gui shows the current
>>> branch as "/foo" under the hood a branch "foo" (without the slash)
>>> had been created. But then you can't delete "/foo" from git gui,
>>> because a branch of that name doesn't exist.
>>
>> Perhaps an interface to give a cleaned-up version, e.g.
>>
>> $ git check-ref-format --print refs/heads//foo/bar
>> refs/heads/foo/bar
>>
>> is what you want in order to fix git-gui? I dunno.
>
> Yes, one solution could be to fix every application handling branch, tag
> or repo names to mimic the namechange done in the bowels of git. But i
> think it is not worth the hassle.
That cuts both ways.
When the users make typoes (e.g. /foo//bar) you can accept the only sane
correction (e.g. foo/bar) instead of rejecting, since the only thing the
user can do after getting such a rejection is to correct it to that
corrected name (e.g. foo/bar) himself and re-issue the command anyway.
You can push the "hassle" down to the user, or you can fix the tool to
remove the hassle from the user.
Besides, by rejecting what we used to accept you are breaking people's
expectations. So I am moderately negative, unless you can say your "every
application" is literally _tons_.
^ permalink raw reply
* Re: [PATCH] git-add--interactive: never skip files included in index
From: Junio C Hamano @ 2009-10-11 18:52 UTC (permalink / raw)
To: Pauli Virtanen; +Cc: git
In-Reply-To: <1255189906-16049-1-git-send-email-pav@iki.fi>
Thanks.
The change looks innocent enough and I do not expect to see any unexpected
regressions from it, but it is a bit too late for 1.6.5 cycle, so let's
queue this fix and aim for 1.6.5.1.
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.6.5
From: Steven Noonan @ 2009-10-11 18:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfx9pydhk.fsf@alter.siamese.dyndns.org>
On Sun, Oct 11, 2009 at 11:47 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Steven Noonan <steven@uplinklabs.net> writes:
>
>> Uh-oh.
>>
>> Alcarin:crisscross steven$ git remote update
>> Updating origin
>> fatal: 'git@github.com/tycho/crisscross.git' does not appear to be a
>> git repository
>> fatal: The remote end hung up unexpectedly
>> error: Could not fetch origin
>
> Try user@site:path/to/repo.git with a colon. As you mentioned already,
> you could also use ssh://user@site/full/path/to/repo.git
Oops. You're right, of course. I'm going on 4 hours of sleep in 2
days, so needless to say I'm not at my best right now. Sorry for the
noise.
>
>> The 'ssh://' part is omitted in numerous places on github.com. I
>> realize github.com isn't the final authority on the syntax of the URI,
>
> What do you mean by "final authority"?
I didn't want to imply that "github says to do it this way, so git
should follow".
^ permalink raw reply
* Re: git svn with non-standard svn layout
From: Fabian Molder @ 2009-10-11 19:00 UTC (permalink / raw)
To: git
In-Reply-To: <20091011070937.GC16264@dcvr.yhbt.net>
Eric Wong <normalperson <at> yhbt.net> writes:
...
>
> Hi Fabian,
>
> Since you don't want to track the entire repo and these seem like
> unrelated (history-wise) trees, you probably want the simplest cases:
>
> git svn clone svn://example.com/path/to/xapplication2
> git svn clone svn://example.com/path/to/aa/bb/cc/xapplication1
>
> These commands are like doing the following with plain old svn:
>
> svn co svn://example.com/path/to/xapplication2
> svn co svn://example.com/path/to/aa/bb/cc/xapplication1
>
> > I tried to use "git config svn-remote.svn.branches" to do this,
> > please see in function "do_git_svn" in bash-script - but no success
>
> svn-remote.svn.branches and tags are really only for repos with
> standard layouts.
>
Hello Eric,
hmm, understand,
but this just does an checkout to the working dir
the reason for using git is:
- work offline, with (at least read) access to all the svn branches
- have some more (privat, not commit back to svn) branches for experiments
- all the nice git stuff ..
regards,
Fabian
^ permalink raw reply
* Re: [PATCH] git-add--interactive: never skip files included in index
From: Jeff King @ 2009-10-11 19:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Pauli Virtanen, git
In-Reply-To: <7viqelwyp1.fsf@alter.siamese.dyndns.org>
On Sun, Oct 11, 2009 at 11:52:10AM -0700, Junio C Hamano wrote:
> Thanks.
>
> The change looks innocent enough and I do not expect to see any unexpected
> regressions from it, but it is a bit too late for 1.6.5 cycle, so let's
> queue this fix and aim for 1.6.5.1.
I think this patch is good to apply, as there is no conceivable reason
to even look at excludes when listing modified files.
But this triggered my spider sense; shouldn't --exclude-standard simply
be a no-op for ls-files when we are not listing untracked files? And
bisecting, it seems that it is a very old regression caused by 63d285c
(per-directory-exclude: lazily read .gitignore files, 2007-11-29).
I don't know if it is worth fixing now or not. It does seem a bit
inconsistent to me (since everything else is very clear that .gitignore
is only about untracked files), but nobody seems to have been
complaining for the last two years (and they may have, in fact, been
coding to the new behavior).
-Peff
^ permalink raw reply
* Re: git log --graph
From: Matthieu Moy @ 2009-10-11 19:40 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Dilip M, git
In-Reply-To: <fabb9a1e0910111135v4f3c75a7v6657f5dcfacf13ac@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
> Heya,
>
> On Sun, Oct 11, 2009 at 20:27, Dilip M <dilipm79@gmail.com> wrote:
>> I am trying git log --graph. (has commits in two branches...). But
>> always see one line :(
>
> It'll show you the history of one branch at a time online, you won't
> get the demo-ed multiple lines unless the branch you're looking at
> contains merges.
That said, git log --graph --all will show multiple branches.
I personnally like the format of
git log --graph --pretty=oneline --abbrev-commit
with ui.color set to true in ~/.gitconfig.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: git log --graph
From: Jakub Narebski @ 2009-10-11 20:30 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Sverre Rabbelier, Dilip M, git
In-Reply-To: <vpqhbu5zplr.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> I personnally like the format of
>
> $ git log --graph --pretty=oneline --abbrev-commit
>
> with ui.color set to true in ~/.gitconfig.
You can use
$ git log --graph --oneline
nowadays for that. A bit shorter.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH 0/2] user-manual: reorganize the configuration steps
From: Felipe Contreras @ 2009-10-11 20:43 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, J. Bruce Fields, Jonathan Nieder,
Felipe Contreras
This basically introduces the "getting started" section so users get familiar
with the configuration from the get-go, and also, most people prefer to teach
'git config --global' to setup the user name and email. Here are a few
examples:
git tutorial:
http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html
GNOME:
http://live.gnome.org/Git/Developers
SourceForge:
http://sourceforge.net/apps/trac/sourceforge/wiki/Git
github:
http://help.github.com/git-email-settings/
Felipe Contreras (2):
user-manual: add global config section
user-manual: simplify the user configuration
Documentation/user-manual.txt | 35 ++++++++++++++++++++++++++++++-----
1 files changed, 30 insertions(+), 5 deletions(-)
^ permalink raw reply
* [PATCH 2/2] user-manual: simplify the user configuration
From: Felipe Contreras @ 2009-10-11 20:43 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, J. Bruce Fields, Jonathan Nieder,
Felipe Contreras
In-Reply-To: <1255293786-17293-2-git-send-email-felipe.contreras@gmail.com>
This is shorter, avoids the burder to think about the format of the
configuration file, and most guides out there prefer this form.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
Documentation/user-manual.txt | 8 +++-----
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index ff2563a..bab64f8 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1008,13 +1008,11 @@ Telling git your name
---------------------
Before creating any commits, you should introduce yourself to git. The
-easiest way to do so is to make sure the following lines appear in a
-file named .gitconfig in your home directory:
+easiest way is to use the linkgit:git-config[1] command:
------------------------------------------------
-[user]
- name = Your Name Comes Here
- email = you@yourdomain.example.com
+$ git config --global user.name "Your Name Comes Here"
+$ git config --global user.email you@yourdomain.example.com
------------------------------------------------
(See the "CONFIGURATION FILE" section of linkgit:git-config[1] for
--
1.6.5.4.g31fc3
^ permalink raw reply related
* [PATCH 0/3] Trivial patches
From: Felipe Contreras @ 2009-10-11 20:46 UTC (permalink / raw)
To: git; +Cc: Felipe Contreras
These are a bunch of no-brainers. The one for bool types has been discussed and
agreed before.
Felipe Contreras (3):
Fix a bunch of pointer declarations (codestyle)
git config: clarify bool types
user-manual: use 'fast-forward'
Documentation/user-manual.txt | 14 +++++++-------
builtin-config.c | 4 ++--
diff.c | 2 +-
3 files changed, 10 insertions(+), 10 deletions(-)
^ permalink raw reply
* [PATCH 1/2] user-manual: add global config section
From: Felipe Contreras @ 2009-10-11 20:43 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, J. Bruce Fields, Jonathan Nieder,
Felipe Contreras
In-Reply-To: <1255293786-17293-1-git-send-email-felipe.contreras@gmail.com>
So that users get to know how to configure git from the get-to with good
practical example (color.ui = auto) that most people would probably like
anyway.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
Documentation/user-manual.txt | 27 +++++++++++++++++++++++++++
1 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 67ebffa..ff2563a 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -40,6 +40,33 @@ without any explanation.
Finally, see <<todo>> for ways that you can help make this manual more
complete.
+[[getting-started]]
+Getting started
+=============
+
+Git's configuration is distributed among different locations--this manual will
+only to deal with 'global' (for the user) and 'repository' variables, where
+'repository' variables take precedence over 'global' ones.
+
+You would probably want to start setting up something useful:
+------------------------------------------------
+$ git config --global color.ui auto
+------------------------------------------------
+
+This will make prettier the output of certain commands such as `git diff`, but
+that's not important; what is important here is that `color.ui` has been
+stored in the 'global' configuration.
+
+View and manually modify the configuration by opening `~/.gitconfig`:
+------------------------------------------------
+[color]
+ ui = auto
+------------------------------------------------
+
+Other locations are `/etc/gitconfig` (system), and `.git/config` (repository).
+
+More git configurations will be covered in the rest of the manual, if you want
+to learn more look at linkgit:git-config[1] for details.
[[repositories-and-branches]]
Repositories and Branches
--
1.6.5.4.g31fc3
^ permalink raw reply related
* [PATCH 3/3] user-manual: use 'fast-forward'
From: Felipe Contreras @ 2009-10-11 20:46 UTC (permalink / raw)
To: git; +Cc: Felipe Contreras
In-Reply-To: <1255293973-17444-3-git-send-email-felipe.contreras@gmail.com>
It's a compound word.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
Documentation/user-manual.txt | 14 +++++++-------
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 67ebffa..42d92fd 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1384,7 +1384,7 @@ were merged.
However, if the current branch is a descendant of the other--so every
commit present in the one is already contained in the other--then git
-just performs a "fast forward"; the head of the current branch is moved
+just performs a "fast-forward"; the head of the current branch is moved
forward to point at the head of the merged-in branch, without any new
commits being created.
@@ -1719,7 +1719,7 @@ producing a default commit message documenting the branch and
repository that you pulled from.
(But note that no such commit will be created in the case of a
-<<fast-forwards,fast forward>>; instead, your branch will just be
+<<fast-forwards,fast-forward>>; instead, your branch will just be
updated to point to the latest commit from the upstream branch.)
The `git pull` command can also be given "." as the "remote" repository,
@@ -1943,7 +1943,7 @@ $ git push ssh://yourserver.com/~you/proj.git master
-------------------------------------------------
As with `git fetch`, `git push` will complain if this does not result in a
-<<fast-forwards,fast forward>>; see the following section for details on
+<<fast-forwards,fast-forward>>; see the following section for details on
handling this case.
Note that the target of a "push" is normally a
@@ -1976,7 +1976,7 @@ details.
What to do when a push fails
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-If a push would not result in a <<fast-forwards,fast forward>> of the
+If a push would not result in a <<fast-forwards,fast-forward>> of the
remote branch, then it will fail with an error like:
-------------------------------------------------
@@ -2115,7 +2115,7 @@ $ git checkout release && git pull
Important note! If you have any local changes in these branches, then
this merge will create a commit object in the history (with no local
-changes git will simply do a "Fast forward" merge). Many people dislike
+changes git will simply do a fast-forward merge). Many people dislike
the "noise" that this creates in the Linux history, so you should avoid
doing this capriciously in the "release" branch, as these noisy commits
will become part of the permanent history when you ask Linus to pull
@@ -2729,9 +2729,9 @@ In the previous example, when updating an existing branch, "git fetch"
checks to make sure that the most recent commit on the remote
branch is a descendant of the most recent commit on your copy of the
branch before updating your copy of the branch to point at the new
-commit. Git calls this process a <<fast-forwards,fast forward>>.
+commit. Git calls this process a <<fast-forwards,fast-forward>>.
-A fast forward looks something like this:
+A fast-forward looks something like this:
................................................
o--o--o--o <-- old head of the branch
--
1.6.5.4.g31fc3
^ permalink raw reply related
* [PATCH 2/3] git config: clarify bool types
From: Felipe Contreras @ 2009-10-11 20:46 UTC (permalink / raw)
To: git; +Cc: Felipe Contreras
In-Reply-To: <1255293973-17444-2-git-send-email-felipe.contreras@gmail.com>
The value is what it is, the --bool and --bool-or-int options don't
specify the value type, just how it is interpreted. For example: a value
of '1' can be interpreted as 'true'.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
builtin-config.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin-config.c b/builtin-config.c
index a2d656e..29d7b75 100644
--- a/builtin-config.c
+++ b/builtin-config.c
@@ -66,9 +66,9 @@ static struct option builtin_config_options[] = {
OPT_STRING(0, "get-color", &get_color_slot, "slot", "find the color configured: [default]"),
OPT_STRING(0, "get-colorbool", &get_colorbool_slot, "slot", "find the color setting: [stdout-is-tty]"),
OPT_GROUP("Type"),
- OPT_BIT(0, "bool", &types, "value is \"true\" or \"false\"", TYPE_BOOL),
+ OPT_BIT(0, "bool", &types, "value is intepreted as bool (\"true\" or \"false\")", TYPE_BOOL),
OPT_BIT(0, "int", &types, "value is decimal number", TYPE_INT),
- OPT_BIT(0, "bool-or-int", &types, "value is --bool or --int", TYPE_BOOL_OR_INT),
+ OPT_BIT(0, "bool-or-int", &types, "value is interpreted either as bool or int", TYPE_BOOL_OR_INT),
OPT_GROUP("Other"),
OPT_BOOLEAN('z', "null", &end_null, "terminate values with NUL byte"),
OPT_END(),
--
1.6.5.4.g31fc3
^ permalink raw reply related
* [PATCH 1/3] Fix a bunch of pointer declarations (codestyle)
From: Felipe Contreras @ 2009-10-11 20:46 UTC (permalink / raw)
To: git; +Cc: Felipe Contreras
In-Reply-To: <1255293973-17444-1-git-send-email-felipe.contreras@gmail.com>
Essentially; s/type* /type */ as per the coding guidelines.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
diff.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/diff.c b/diff.c
index e1be189..b39c1b6 100644
--- a/diff.c
+++ b/diff.c
@@ -999,7 +999,7 @@ static void show_stats(struct diffstat_t *data, struct diff_options *options)
total_files, adds, dels);
}
-static void show_shortstats(struct diffstat_t* data, struct diff_options *options)
+static void show_shortstats(struct diffstat_t *data, struct diff_options *options)
{
int i, adds = 0, dels = 0, total_files = data->nr;
--
1.6.5.4.g31fc3
^ permalink raw reply related
* Re: [PATCH 1/3] Fix a bunch of pointer declarations (codestyle)
From: Thiago Farina @ 2009-10-11 20:53 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <1255293973-17444-2-git-send-email-felipe.contreras@gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> wrote:
"Fix a bunch of pointer declarations".
But in this patch you fixed *only* one pointer declaration:
struct diffstat_t* data -> struct diffstat_t *data
^ 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