RE: [ANNOUNCE] Git v2.22.0
Hi Randall, On Mon, 10 Jun 2019, Randall S. Becker wrote: > On Friday, June 7, 2019 5:31 PM, Junio C Hamano wrote: > > The latest feature release Git v2.22.0 is now available at the > > usual places. It is comprised of 745 non-merge commits since > > v2.21.0, contributed by 74 people, 18 of which are new faces. > > Report from NonStop tests: > t7519 subtest 25 still fails on first execution but not on second. As mentioned previously: known issue. The patch to fix that is in `next` (1aa850bc59 (Merge branch 'js/fsmonitor-unflake' into next, 2019-05-30). > t9001 subtests 33, 82, 118, 119, 146 fail. We have no normal sendmail on > platform. Maybe you should craft a patch series that adds a new prereq that verifies that sendmail works, and contribute a patch that marks those test cases with that prereq. > t9020, t9600, t9601, t9602 all fail - we have no SVN. I may be able to > handle exclusions for the next release. The question is why they fail even if the correspondig prereq should have triggered. Another opportunity for you to contribute a patch series! (By my analysis, you rank #277 in the `git shortlog -nse --no-merges` statistics, and just 17 patches would improve your rank to #150 or better...) > So essentially, no change from previous releases other than t7519 being > wonky. This is a pass. Thanks for all hard work from the team. Yes, t7519 became "more wonky" as a consequence of a bug fix of mine that made that particular bug a lot more prominent. So prominent, in fact, that I contributed two patches that will improve my rank ;-) Ciao, Johannes
Re: [Breakage] Git v2.21.0-rc0 - t5403 (NonStop)
Hi Randall, On Fri, 8 Feb 2019, Randall S. Becker wrote: > This looks like it is a "bash thing" and $GIT_DIR might have to be in > quotes, and is not be specific to the platform. If I replace > > echo "$@" >$GIT_DIR/post-checkout.args > > with > > echo "$@" >"$GIT_DIR/post-checkout.args" > > The test passes. I wonder I should provide this patch or whether the > author would like to do so. It is the correct fix, you came up with it, why not simply provide a patch yourself? Thanks, Dscho
Re: [ANNOUNCE] Git v2.16.0-rc0
Hi, On Thu, 28 Dec 2017, Junio C Hamano wrote: > An early preview release Git v2.16.0-rc0 is now available for > testing at the usual places. And a corresponding Git for Windows prerelease is also available: https://github.com/git-for-windows/git/releases/tag/v2.16.0-rc0.windows.1 Ciao, Johannes
Re: [ANNOUNCE] Git v2.16.0-rc0
Hi, On Thu, 28 Dec 2017, Junio C Hamano wrote: > An early preview release Git v2.16.0-rc0 is now available for > testing at the usual places. And a corresponding Git for Windows prerelease is also available: https://github.com/git-for-windows/git/releases/tag/v2.16.0-rc0.windows.1 Ciao, Johannes
Re: [ANNOUNCE] Git v2.15.0-rc0
Hi Junio, On Thu, 5 Oct 2017, Junio C Hamano wrote: > New contributors whose contributions weren't in v2.14.0 are as follows. > Welcome to the Git development community! > > Ann T Ropea, Daniel Watkins, Dimitrios Christidis, Eric Rannaud, > Evan Zacks, Hielke Christian Braun, Ian Campbell, Ilya Kantor, > Jameson Miller, Job Snijders, Joel Teichroeb, joernchen, > Łukasz Gryglicki, Manav Rathi, Martin Ågren, Michael Forney, > Patryk Obara, Rene Scharfe, Ross Kabus, and Urs Thuermann. I think we need a .mailmap entry there... I guess the difference is the é vs e. Ciao, Dscho
Re: [ANNOUNCE] Git v2.15.0-rc0
Hi Junio, On Thu, 5 Oct 2017, Junio C Hamano wrote: > New contributors whose contributions weren't in v2.14.0 are as follows. > Welcome to the Git development community! > > Ann T Ropea, Daniel Watkins, Dimitrios Christidis, Eric Rannaud, > Evan Zacks, Hielke Christian Braun, Ian Campbell, Ilya Kantor, > Jameson Miller, Job Snijders, Joel Teichroeb, joernchen, > Łukasz Gryglicki, Manav Rathi, Martin Ågren, Michael Forney, > Patryk Obara, Rene Scharfe, Ross Kabus, and Urs Thuermann. I think we need a .mailmap entry there... I guess the difference is the é vs e. Ciao, Dscho
Re: [ANNOUNCE] Git v2.8.2
Hi all, On Fri, 29 Apr 2016, Junio C Hamano wrote: > The latest maintenance release Git v2.8.2 is now available at > the usual places. I considered releasing Git for Windows v2.8.2 today, too. However, I decided to delay the release for a couple of days, for a couple of reasons: - I expect an update of the Git Credential Manager in the next few days. - OpenSSL is slated to receive critical updates on Tuesday and I plan to incorporate these into Git for Windows' next version, too. I will also use version 2.8.2 as an excuse to ship with support for the extra HTTP headers configured via `http.extraheader`, which I hoped to get into Git v2.8.2, too, because I'd like the feature to be available on Linux and MacOSX, too. In short: the tentative release date of Git for Windows v2.8.2 is Tuesday, May 3rd, 2016. Stay tuned, Johannes
Re: [ANNOUNCE] Git v2.8.2
Hi all, On Fri, 29 Apr 2016, Junio C Hamano wrote: > The latest maintenance release Git v2.8.2 is now available at > the usual places. I considered releasing Git for Windows v2.8.2 today, too. However, I decided to delay the release for a couple of days, for a couple of reasons: - I expect an update of the Git Credential Manager in the next few days. - OpenSSL is slated to receive critical updates on Tuesday and I plan to incorporate these into Git for Windows' next version, too. I will also use version 2.8.2 as an excuse to ship with support for the extra HTTP headers configured via `http.extraheader`, which I hoped to get into Git v2.8.2, too, because I'd like the feature to be available on Linux and MacOSX, too. In short: the tentative release date of Git for Windows v2.8.2 is Tuesday, May 3rd, 2016. Stay tuned, Johannes
Re: [GIT PULL] GPIO bulk changes for kernel v4.6
Hi Linus, On Fri, 18 Mar 2016, Linus Torvalds wrote: > I thought git didn't merge two branches that have no common base by > default, but it seems it will happily do so. What happened to "The coolest merge EVER!"? http://thread.gmane.org/gmane.comp.version-control.git/5126/ Ciao, Dscho
Re: [GIT PULL] GPIO bulk changes for kernel v4.6
Hi Linus, On Fri, 18 Mar 2016, Linus Torvalds wrote: > I thought git didn't merge two branches that have no common base by > default, but it seems it will happily do so. What happened to "The coolest merge EVER!"? http://thread.gmane.org/gmane.comp.version-control.git/5126/ Ciao, Dscho
Re: git guidance
Hi, On Fri, 7 Dec 2007, Al Boldi wrote: > Jakub Narebski wrote: > > > Version control system is all about WORKFLOW B, where programmer > > controls when it is time to commit (and in private repository he/she > > can then rewrite history to arrive at "Perfect patch series"[*1*]); > > something that for example CVS failed at, requiring programmer to do a > > merge if upstream has any changes when trying to commit. > > Because WORKFLOW C is transparent, it won't affect other workflows. So > you could still use your normal WORKFLOW B in addition to WORKFLOW C, > gaining an additional level of version control detail at no extra cost > other than the git-engine scratch repository overhead. > > BTW, is git efficient enough to handle WORKFLOW C? The question is not if git is efficient enough to handle workflow C, but if that worflow is efficient enough to help anybody. Guess what takes me the longest time when committing? The commit message. But it is really helpful, so there is a _point_ in writing one, and there is a _point_ in committing when I do it: it is a point in time where I expect the tree to be in a good shape, to be compilable, and to solve a specific problem which I describe in the commit message. So I absolutely hate this "transparency". Git _is_ transparent; it does not affect any of my other tools; they still work very well thankyouverymuch. What your version of "transparency" would do: destroy bisectability, make an absolute gibberish of the history, and more! Nobody could read the output of "git log" and form an understanding what was done. Nobody could read the commit message for a certain "git blame"d line that she tries to make sense of. IOW you would revert the whole meaning of the term Source Code Management. Hth, Dscho -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: git guidance
Hi, On Fri, 7 Dec 2007, Al Boldi wrote: Jakub Narebski wrote: Version control system is all about WORKFLOW B, where programmer controls when it is time to commit (and in private repository he/she can then rewrite history to arrive at Perfect patch series[*1*]); something that for example CVS failed at, requiring programmer to do a merge if upstream has any changes when trying to commit. Because WORKFLOW C is transparent, it won't affect other workflows. So you could still use your normal WORKFLOW B in addition to WORKFLOW C, gaining an additional level of version control detail at no extra cost other than the git-engine scratch repository overhead. BTW, is git efficient enough to handle WORKFLOW C? The question is not if git is efficient enough to handle workflow C, but if that worflow is efficient enough to help anybody. Guess what takes me the longest time when committing? The commit message. But it is really helpful, so there is a _point_ in writing one, and there is a _point_ in committing when I do it: it is a point in time where I expect the tree to be in a good shape, to be compilable, and to solve a specific problem which I describe in the commit message. So I absolutely hate this transparency. Git _is_ transparent; it does not affect any of my other tools; they still work very well thankyouverymuch. What your version of transparency would do: destroy bisectability, make an absolute gibberish of the history, and more! Nobody could read the output of git log and form an understanding what was done. Nobody could read the commit message for a certain git blamed line that she tries to make sense of. IOW you would revert the whole meaning of the term Source Code Management. Hth, Dscho -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: git guidance
Hi, On Fri, 7 Dec 2007, Al Boldi wrote: > Andreas Ericsson wrote: > > Al Boldi wrote: > > > > > By pulling the sources into a git-client manager mounted on some > > > dir, it should be possible to let the developer work > > > naturally/transparently in a readable/writeable manner, and only > > > require his input when reverting locally or committing to the > > > server/repository. > > > > How is that different from what every SCM, including git, is doing > > today? The user needs to tell the scm when it's time to take a > > snapshot of the current state. Git is distributed though, so > > committing is usually not the same as publishing. Is that lack of a > > single command to commit and publish what's nagging you? If it's not, > > I completely fail to see what you're getting at, unless you've only > > ever looked at repositories without a worktree attached, or you think > > that git should work like an editor's "undo" functionality, which > > would be quite insane. > > You need to re-read the thread. I don't know why you write that, and then say thanks. Clearly, what you wrote originally, and what Andreas pointed out, were quite obvious indicators that git already does what you suggest. You _do_ work "transparently" (whatever you understand by that overused term) in the working directory, unimpeded by git. And whenever it is time to revert or commit, you cry for help, invoking git. So either you succeeded in making yourself misunderstood, or Andreas had quite the obvious and correct comment for you. Not that diffcult, Dscho -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: git guidance
Hi, On Fri, 7 Dec 2007, Al Boldi wrote: Andreas Ericsson wrote: Al Boldi wrote: By pulling the sources into a git-client manager mounted on some dir, it should be possible to let the developer work naturally/transparently in a readable/writeable manner, and only require his input when reverting locally or committing to the server/repository. How is that different from what every SCM, including git, is doing today? The user needs to tell the scm when it's time to take a snapshot of the current state. Git is distributed though, so committing is usually not the same as publishing. Is that lack of a single command to commit and publish what's nagging you? If it's not, I completely fail to see what you're getting at, unless you've only ever looked at repositories without a worktree attached, or you think that git should work like an editor's undo functionality, which would be quite insane. You need to re-read the thread. I don't know why you write that, and then say thanks. Clearly, what you wrote originally, and what Andreas pointed out, were quite obvious indicators that git already does what you suggest. You _do_ work transparently (whatever you understand by that overused term) in the working directory, unimpeded by git. And whenever it is time to revert or commit, you cry for help, invoking git. So either you succeeded in making yourself misunderstood, or Andreas had quite the obvious and correct comment for you. Not that diffcult, Dscho -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: git guidance
Hi, On Wed, 28 Nov 2007, Al Boldi wrote: > [EMAIL PROTECTED] sometimes bounces, so let's leave lkml as backup. Fair enough. > Johannes Schindelin wrote: > > On Wed, 28 Nov 2007, Rogan Dawes wrote: > > > Al Boldi wrote: > > > > Willy Tarreau wrote: > > > > > It should not turn into an endless thread led by people who want > > > > > to redefine GIT's roadmap, but experience sharing helps a lot > > > > > with GIT. > > > > > > > > Well, now that you mentioned it, if there is one thing I dislike, > > > > it's for version control to start mutilating your sources. > > > > Version Control should be completely transparent. GIT isn't. > > > > > > Care to explain? Git is quite happy handling arbitrary binary > > > content, so I find it difficult to believe that it is changing your > > > source code in strange ways. > > > > It is nice of you to ask him to explain: Unless this handwaving claim > > is substantiated, it is quite hard to argue with. > > Sure, the problem with GIT is that it stores the sources inside a > backend container that is only accessible via GIT; iow, you can't > retrieve your sources directly / transparently. That is a very funny way to define a "transparent SCM". Are you complaining about SQL servers being "not transparent"? By that definition, no SCM, not even CVS, is transparent. Nothing short of unpacked directories of all versions (wasting a lot of disk space) would. IOW the issue you raised is a non-issue. Ciao, Dscho - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: git guidance
Hi, On Wed, 28 Nov 2007, Al Boldi wrote: [EMAIL PROTECTED] sometimes bounces, so let's leave lkml as backup. Fair enough. Johannes Schindelin wrote: On Wed, 28 Nov 2007, Rogan Dawes wrote: Al Boldi wrote: Willy Tarreau wrote: It should not turn into an endless thread led by people who want to redefine GIT's roadmap, but experience sharing helps a lot with GIT. Well, now that you mentioned it, if there is one thing I dislike, it's for version control to start mutilating your sources. Version Control should be completely transparent. GIT isn't. Care to explain? Git is quite happy handling arbitrary binary content, so I find it difficult to believe that it is changing your source code in strange ways. It is nice of you to ask him to explain: Unless this handwaving claim is substantiated, it is quite hard to argue with. Sure, the problem with GIT is that it stores the sources inside a backend container that is only accessible via GIT; iow, you can't retrieve your sources directly / transparently. That is a very funny way to define a transparent SCM. Are you complaining about SQL servers being not transparent? By that definition, no SCM, not even CVS, is transparent. Nothing short of unpacked directories of all versions (wasting a lot of disk space) would. IOW the issue you raised is a non-issue. Ciao, Dscho - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] qgit-1.5.5
Hi, On Mon, 26 Feb 2007, Marco Costalba wrote: > On 2/26/07, Johannes Schindelin <[EMAIL PROTECTED]> wrote: > > Hi, > > > > On Mon, 26 Feb 2007, Marco Costalba wrote: > > > > > Actually, I didn't test with MinGW port of Git but I would be surprised > > > if it doesn't work (famous last words ;-) ) > > > > You don't use cygpath to translate between Windows <-> POSIX filenames? > > > > AFAICT this is the single most important user-visible difference > > between Cygwin Git and MinGW Git. > > > > I call git programs as if they were native windows programs. I run git > programs without requiring cygwin shell or something similar. Actually, what I was getting at is the silly "Drive:\bla" filename syntax on Windows boxen. But - you have to cd to the working directory in order to start the git programs, and - AFAIK Windows is not stupid enough to forbid "dir/name" syntax. So, all my objections are invalid. > I hope I have understood correctly your answer. Yes ;-) Ciao, Dscho - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] qgit-1.5.5
Hi, On Mon, 26 Feb 2007, Marco Costalba wrote: > Actually, I didn't test with MinGW port of Git but I would be surprised > if it doesn't work (famous last words ;-) ) You don't use cygpath to translate between Windows <-> POSIX filenames? AFAICT this is the single most important user-visible difference between Cygwin Git and MinGW Git. Ciao, Dscho - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] qgit-1.5.5
Hi, On Mon, 26 Feb 2007, Marco Costalba wrote: > On 2/26/07, Martin Langhoff <[EMAIL PROTECTED]> wrote: > > On 2/26/07, Marco Costalba <[EMAIL PROTECTED]> wrote: > > > P.S: There is also a Qt4 version (works under Windows) downloadable > > > from git://repo.or.cz/qgit4.git it is a little bit experimental > > > tough. > > > > Is the QT4 Windows port working against the MinGW port of GIT? > > > > Yes, Qt4Windows does not need cygwin at all and is compiled itself with > MinGW. I think what Martin was getting at is if you can use the MinGW port of _Git_, not if Qt4Windows or qgit needs cygwin. Ciao, Dscho - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] qgit-1.5.5
Hi, On Mon, 26 Feb 2007, Marco Costalba wrote: On 2/26/07, Martin Langhoff [EMAIL PROTECTED] wrote: On 2/26/07, Marco Costalba [EMAIL PROTECTED] wrote: P.S: There is also a Qt4 version (works under Windows) downloadable from git://repo.or.cz/qgit4.git it is a little bit experimental tough. Is the QT4 Windows port working against the MinGW port of GIT? Yes, Qt4Windows does not need cygwin at all and is compiled itself with MinGW. I think what Martin was getting at is if you can use the MinGW port of _Git_, not if Qt4Windows or qgit needs cygwin. Ciao, Dscho - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] qgit-1.5.5
Hi, On Mon, 26 Feb 2007, Marco Costalba wrote: Actually, I didn't test with MinGW port of Git but I would be surprised if it doesn't work (famous last words ;-) ) You don't use cygpath to translate between Windows - POSIX filenames? AFAICT this is the single most important user-visible difference between Cygwin Git and MinGW Git. Ciao, Dscho - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] qgit-1.5.5
Hi, On Mon, 26 Feb 2007, Marco Costalba wrote: On 2/26/07, Johannes Schindelin [EMAIL PROTECTED] wrote: Hi, On Mon, 26 Feb 2007, Marco Costalba wrote: Actually, I didn't test with MinGW port of Git but I would be surprised if it doesn't work (famous last words ;-) ) You don't use cygpath to translate between Windows - POSIX filenames? AFAICT this is the single most important user-visible difference between Cygwin Git and MinGW Git. I call git programs as if they were native windows programs. I run git programs without requiring cygwin shell or something similar. Actually, what I was getting at is the silly Drive:\bla filename syntax on Windows boxen. But - you have to cd to the working directory in order to start the git programs, and - AFAIK Windows is not stupid enough to forbid dir/name syntax. So, all my objections are invalid. I hope I have understood correctly your answer. Yes ;-) Ciao, Dscho - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Announce] GIT v1.5.0-rc2
Hi, On Sun, 21 Jan 2007, Jakub Narebski wrote: > Johannes Schindelin wrote: > > > On Sun, 21 Jan 2007, Bill Lear wrote: > > > >> Also (apologies for the ignorance), how do I get the 1.5.0-rc2 release? > > > > Direct your browser to > > > > http://repo.or.cz/w/git.git?a=snapshot;h=eaf6459e4d482af51429f9464125621b805eb5f > > Better URL is > > http://repo.or.cz/w/git.git?a=snapshot;h=v1.5.0-rc2 It is a better URL. Somehow I fscked up when I tried it, so I had the impression that does not work. But it does. Sorry, Dscho - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Announce] GIT v1.5.0-rc2
Hi, On Sun, 21 Jan 2007, Junio C Hamano wrote: > - 'git pack-refs' appeared in v1.4.4; You should probably mention that it is not necessary to run git-pack-refs by hand: git-gc is what you want. BTW have I praised y'all for inventing git-gc? It is _awesome_. I think I will turn into a DWIM geek yet; it is s much more convenient to issue "git gc" from time to time, than to think exactly about what I want to clean up right now. > - 'git repo-config', 'git grep', 'git rebase' and 'gitk' were >seriously enhanced during v1.4.0 timeperiod. Should we introduce "git config" in time for the "let's please end-users" release (1.5.0)? > - git-clone always uses what is known as "separate remote" >layout for a newly created repository with a working tree; >i.e. tracking branches in $GIT_DIR/refs/remotes/origin/ are >used to track branches from the origin. ... instead of $GIT_DIR/refs/heads/, making the difference between remotely tracked and local branches more obvious. > - git-branch and git-show-branch know remote tracking branches. ... (use the command line switch "-r" to list only tracked branches.) > - git-push can now be used to delete a remote branch or a tag. >This requires the updated git on the remote side. ... (use "git push :refs/heads/" to delete "branch".) > - git-push more agressively keeps the transferred objects >packed. Earlier we recommended to monitor amount of loose >objects and repack regularly, but you should repack when you >accumulated too many small packs this way as well. Updated >git-count-objects helps you with this. It might make sense to enable something similar for git-fetch in time for 1.5.0. > * Reflog > > - Reflog records the history of where the tip of each branch >was at each moment. It might make sense to reformulate that: Reflog records the history from the view point of the local repository. In other words, regardless of the real history, the reflog shows the history as seen by one particular repository (this enables you to ask "what was the current revision in _this_ repository, yesterday at 1pm?"). > - There is a toplevel garbage collector script, 'git-gc', that >is an easy way to run 'git-repack -a -d', 'git-reflog gc', >and 'git-prune'. Did I mention that I really _love_ git-gc? > - The original implementation of git-merge-recursive which was >in Python has been removed; we have C implementation of it >now. I am no native speaker, but should that not be "we have a C implementation" instead? > - The default suffix for git-format-patch output is now ".patch", >not ".txt". This can be changed with --suffix=.txt option, >or "format.suffix = .txt" in the configuration. I fully expect people to complain that a config like this format.suffix = .txt does not work. better say ... or setting the config variable "format.suffix" to ".txt". > - Better error messages for often used Porcelainish commands. Amen. I think this really helped a lot of people already. >- Cloning and fetching _from_ a shallow clone are not > supported (nor tested -- so they might work by accident but > they are not expected to). Maybe we should go the "restrict first, and loosen later" approach? I.e. forbid git-upload-pack to run if is_repository_shallow()? >- Pushing from nor into a shallow clone are not expected to > work. Maybe forbid git-push and git-receive-pack to run if is_repository_shallow()? (I _think_ git-push should be safe, but not git-receive-pack.) Ciao, Dscho - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Announce] GIT v1.5.0-rc2
Hi, On Sun, 21 Jan 2007, Bill Lear wrote: > Also (apologies for the ignorance), how do I get the 1.5.0-rc2 release? Direct your browser to http://repo.or.cz/w/git.git?a=snapshot;h=eaf6459e4d482af51429f9464125621b805eb5f BTW please don't top post. It uses bandwidth unnecessarily (both in terms of megabytes and attention). Ciao, Dscho - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Announce] GIT v1.5.0-rc2
Hi, On Sun, 21 Jan 2007, Bill Lear wrote: Also (apologies for the ignorance), how do I get the 1.5.0-rc2 release? Direct your browser to http://repo.or.cz/w/git.git?a=snapshot;h=eaf6459e4d482af51429f9464125621b805eb5f BTW please don't top post. It uses bandwidth unnecessarily (both in terms of megabytes and attention). Ciao, Dscho - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Announce] GIT v1.5.0-rc2
Hi, On Sun, 21 Jan 2007, Junio C Hamano wrote: - 'git pack-refs' appeared in v1.4.4; You should probably mention that it is not necessary to run git-pack-refs by hand: git-gc is what you want. BTW have I praised y'all for inventing git-gc? It is _awesome_. I think I will turn into a DWIM geek yet; it is s much more convenient to issue git gc from time to time, than to think exactly about what I want to clean up right now. - 'git repo-config', 'git grep', 'git rebase' and 'gitk' were seriously enhanced during v1.4.0 timeperiod. Should we introduce git config in time for the let's please end-users release (1.5.0)? - git-clone always uses what is known as separate remote layout for a newly created repository with a working tree; i.e. tracking branches in $GIT_DIR/refs/remotes/origin/ are used to track branches from the origin. ... instead of $GIT_DIR/refs/heads/, making the difference between remotely tracked and local branches more obvious. - git-branch and git-show-branch know remote tracking branches. ... (use the command line switch -r to list only tracked branches.) - git-push can now be used to delete a remote branch or a tag. This requires the updated git on the remote side. ... (use git push remote :refs/heads/branch to delete branch.) - git-push more agressively keeps the transferred objects packed. Earlier we recommended to monitor amount of loose objects and repack regularly, but you should repack when you accumulated too many small packs this way as well. Updated git-count-objects helps you with this. It might make sense to enable something similar for git-fetch in time for 1.5.0. * Reflog - Reflog records the history of where the tip of each branch was at each moment. It might make sense to reformulate that: Reflog records the history from the view point of the local repository. In other words, regardless of the real history, the reflog shows the history as seen by one particular repository (this enables you to ask what was the current revision in _this_ repository, yesterday at 1pm?). - There is a toplevel garbage collector script, 'git-gc', that is an easy way to run 'git-repack -a -d', 'git-reflog gc', and 'git-prune'. Did I mention that I really _love_ git-gc? - The original implementation of git-merge-recursive which was in Python has been removed; we have C implementation of it now. I am no native speaker, but should that not be we have a C implementation instead? - The default suffix for git-format-patch output is now .patch, not .txt. This can be changed with --suffix=.txt option, or format.suffix = .txt in the configuration. I fully expect people to complain that a config like this format.suffix = .txt does not work. better say ... or setting the config variable format.suffix to .txt. - Better error messages for often used Porcelainish commands. Amen. I think this really helped a lot of people already. - Cloning and fetching _from_ a shallow clone are not supported (nor tested -- so they might work by accident but they are not expected to). Maybe we should go the restrict first, and loosen later approach? I.e. forbid git-upload-pack to run if is_repository_shallow()? - Pushing from nor into a shallow clone are not expected to work. Maybe forbid git-push and git-receive-pack to run if is_repository_shallow()? (I _think_ git-push should be safe, but not git-receive-pack.) Ciao, Dscho - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Announce] GIT v1.5.0-rc2
Hi, On Sun, 21 Jan 2007, Jakub Narebski wrote: Johannes Schindelin wrote: On Sun, 21 Jan 2007, Bill Lear wrote: Also (apologies for the ignorance), how do I get the 1.5.0-rc2 release? Direct your browser to http://repo.or.cz/w/git.git?a=snapshot;h=eaf6459e4d482af51429f9464125621b805eb5f Better URL is http://repo.or.cz/w/git.git?a=snapshot;h=v1.5.0-rc2 It is a better URL. Somehow I fscked up when I tried it, so I had the impression that does not work. But it does. Sorry, Dscho - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
