Re: user-manual: patch proposals and questions
thank you for your answer and hints.
kalle
Am 19.03.2018 um 01:27 schrieb Eric Sunshine:
> On Sun, Mar 18, 2018 at 7:49 PM, kalle <ka...@projektwerkstatt.de> wrote:
>> 1.I wonder, why the "user-manual" is so hidden on the (official?) site
>> git-scm.com [it is accessible at git-scm.com/docs/user-manual ,but is
>> not viewable in /docs ]
>
> The git-scm.com website is maintained as a distinct project[1] at
> Github; it is not directly related to the Git project itself. A good
> way to voice your concern about the website is either to open an issue
> ticket[2] or submit a pull request[3] if you have a specific change in
> mind.
>
> [1]: https://github.com/git/git-scm.com
> [2]: https://github.com/git/git-scm.com/issues
> [3]: https://github.com/git/git-scm.com/pulls
>
>> 2.I did not receive an answer to my mail. Maybe it could have to do with
>> a possible stopped maintainment of the 'user-manual'
>
> More likely it was because your email was not composed in a way for
> people to digest and respond to it easily. There are some things you
> can do to help make it easier for people to respond:
>
> * Send patches inline rather than attachments since it is much easier
> for people to respond to them directly when inline. When they are
> attachments, people are forced to open the attachment, then copy/paste
> parts of the patch back into the email for response, and most people
> won't bother with such effort. Also, make each patch a separate email
> with a meaningful commit message ("git format-patch" and "git
> send-email" can help with this).
>
> * For your questions about documentation, quote the section of
> documentation you want to talk about directly in your email, then ask
> a question about it. This saves people the effort of manually having
> to open the file and locate the line or paragraph in question. Also,
> line numbers change as changes are made to files, so the line number
> you cite might not match the line number in a version of the file
> someone else is looking at.
>
>> 3.it would be for non-graphics-users to have the Git-Pro-book in
>> text-format.
>
> Like the website, the Pro Git book is a distinct project[4], not
> directly related to the Git project. To suggest making the book
> available as plain text, you can open an issue ticket[5] or submit a
> pull request[6] if you implement it yourself.
>
> [4]: https://github.com/progit/progit2
> [5]: https://github.com/progit/progit2/issues
> [6]: https://github.com/progit/progit2/pulls
>
>
>> Weitergeleitete Nachricht
>> Betreff: user-manual: patch proposals and questions
>> Datum: Tue, 6 Mar 2018 00:08:55 +0100
>> Von: kalle <ka...@projektwerkstatt.de>
>> An: git@vger.kernel.org
>>
>> The patches are attached.
>> Further some questions:
>>
>> -see the explanations of the branch command, ca. line 280: wouldn't it
>> be better to use other words than 'references'?
>> -sentence "it shows all commits reachable from the parent commit": it
>> seems wrong to me. The last commit is also shown.
>> - chapter "Browsing revisions": it seems counterintuitive to me to have
>> two different logics for the meaning of "branch1..branch2" and
>> "branch1...branch2", according to whether it's the argument of `git log'
>> or `git diff'
>> -section "Check whether two branches point at the same history": 'git
>> diff origin..master' -> shouldn't it be rather 'git diff
>> branch1..branch2'? … or rewrite the example with branch1=origin and
>> branch2=master.
>>
>> greetings,
>> kalle
Fwd: user-manual: patch proposals and questions
hello, 1.I wonder, why the "user-manual" is so hidden on the (official?) site git-scm.com [it is accessible at git-scm.com/docs/user-manual ,but is not viewable in /docs ] 2.I did not receive an answer to my mail. Maybe it could have to do with a possible stopped maintainment of the 'user-manual' 3.it would be for non-graphics-users to have the Git-Pro-book in text-format. thanks, kalle Weitergeleitete Nachricht Betreff: user-manual: patch proposals and questions Datum: Tue, 6 Mar 2018 00:08:55 +0100 Von: kalle <ka...@projektwerkstatt.de> An: git@vger.kernel.org The patches are attached. Further some questions: -see the explanations of the branch command, ca. line 280: wouldn't it be better to use other words than 'references'? -sentence "it shows all commits reachable from the parent commit": it seems wrong to me. The last commit is also shown. - chapter "Browsing revisions": it seems counterintuitive to me to have two different logics for the meaning of "branch1..branch2" and "branch1...branch2", according to whether it's the argument of `git log' or `git diff' -section "Check whether two branches point at the same history": 'git diff origin..master' -> shouldn't it be rather 'git diff branch1..branch2'? … or rewrite the example with branch1=origin and branch2=master. greetings, kalle >From 19061a0dd4363edbf8757a5e9eee8ace210f4029 Mon Sep 17 00:00:00 2001 From: kalledaballe <ka...@projektwerkstatt.de> Date: Fri, 9 Feb 2018 20:46:52 +0100 Subject: [PATCH 2/5] 3 small formulation changes in Documentation/user-manual.txt --- Documentation/user-manual.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt index eff7890..e3efc26 100644 --- a/Documentation/user-manual.txt +++ b/Documentation/user-manual.txt @@ -322,7 +322,7 @@ do so (now or later) by using -b with the checkout command again. Example: HEAD is now at 427abfa Linux v2.6.17 -The HEAD then refers to the SHA-1 of the commit instead of to a branch, +If you haven't created a new branch yet, the HEAD then refers to the SHA-1 of the commit instead of to a branch, and git branch shows that you are no longer on a branch: @@ -370,7 +370,7 @@ be updated by `git fetch` (hence `git pull`) and `git push`. See <> for details. You might want to build on one of these remote-tracking branches -on a branch of your own, just as you would for a tag: +a branch of your own, just as you would for a tag: $ git checkout -b my-todo-copy origin/todo @@ -404,7 +404,7 @@ they may also be packed together in a single file; see linkgit:git-pack-refs[1]). As another useful shortcut, the "HEAD" of a repository can be referred -to just using the name of that repository. So, for example, "origin" +to by just using the name of that repository. So, for example, "origin" is usually a shortcut for the HEAD branch in the repository "origin". For the complete list of paths which Git checks for references, and -- 2.1.4 >From 3917eeaf8d21b8b90a773c46ee5b9d12eac901e3 Mon Sep 17 00:00:00 2001 From: kalledaballe <ka...@projektwerkstatt.de> Date: Sat, 10 Feb 2018 16:08:45 +0100 Subject: [PATCH 3/5] I changed the sequence of 2 sentences. --- Documentation/user-manual.txt | 10 +++--- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt index e3efc26..b9dc17a 100644 --- a/Documentation/user-manual.txt +++ b/Documentation/user-manual.txt @@ -609,13 +609,9 @@ $ git show HEAD^2 # show the second parent of HEAD In addition to HEAD, there are several other special names for commits: -Merges (to be discussed later), as well as operations such as -`git reset`, which change the currently checked-out commit, generally -set ORIG_HEAD to the value HEAD had before the current operation. +ORIG_HEAD is set to the value HEAD before merging (to be discussed later) operations as well as operations such as `git reset'. which change the currently checked-out commit. -The `git fetch` operation always stores the head of the last fetched -branch in FETCH_HEAD. For example, if you run `git fetch` without -specifying a local branch as the target of the operation +FETCH_HEAD after a `git fetch' operation stores the head of the last fetched branch. For example, if you run `git fetch' without specifying a local branch as the target of the operation. - $ git fetch git://example.com/proj.git theirbranch @@ -664,7 +660,7 @@ can also make more specific requests: - $ git log v2.5.. # commits since (not reachabl
Re: git help clone: questions
Am 07.03.2018 um 23:45 schrieb Junio C Hamano: > kalle <ka...@projektwerkstatt.de> writes: > >> Am 06.03.2018 um 02:36 schrieb Junio C Hamano: >>> kalle <ka...@projektwerkstatt.de> writes: >>> >>>> -In the explanation of the option --reference: shouldn't there be >>>> written '' instead of 'reference repository'? >>> >>> "Shouldn't X be Y?" is not an effective way to communicate; it >>> solicits a "no, the current one is fine." without any explanation. >>> >>> If you think X should be Y for some reason, please say "I think X >>> should be Y BECAUSE Z" instead. Without stating why you think >>> differently from what those who wrote the current text, it is hard >>> for people to respond either with "Yeah, you're right---I agree >>> with Z" or with "No, Z does not hold because..." >>> >> I wrote this, because when it is written about 'reference repository', I >> consider it not totally clear, which repository is meant, as the option >> '--reference ' only names one as . >> For reasons of clearness, I now propose writing "reference repository >> ". > > I do not have particularly a strong opinion, but I think it is very > sensible to call the value given to the option "--reference" with a > phrase that is not just "repository". i agree and didn't state this. i proposed to add . could also be named . > > As the command line of "clone" must name one repository (i.e. the > one which we clone from), and its "--reference" option must name > another repository as its value (i.e. the one that we borrow from in > order to reduce the object transfer), calling both > makes it easier to confuse readers you made my point unless the writer carefully makes > sure that in the desription is unambiguous and it is > clear which one of these two repositories is being discussed by the > context.> > I just re-read the existing Documentation/git-clone.txt and looked > for "reference". All uses of "reference repository" in the prose > made sense and I found it would not be an improvement if any of them > is replaced with just "repository". This was never my proposal, though. It may be helpful to add > something like: > >--reference[-if-able] :: > + Define a repository (reference repository) to borrow > + objects from. > If the reference repository is on the local machine, > ... > > to define which repository we mean by that term, though. > in all, it was just meant as a quite small proposal for me. i also don't have any strong opinion about it. greetings, kalle
Re: git help clone: questions
I wrote this, because when it is written about 'reference repository', I consider it not totally clear, which repository is meant, as the option '--reference ' only names one as . For reasons of clearness, I now propose writing "reference repository ". kalle Am 06.03.2018 um 02:36 schrieb Junio C Hamano: > kalle <ka...@projektwerkstatt.de> writes: > >> -In the explanation of the option --reference: shouldn't there be >> written '' instead of 'reference repository'? > > "Shouldn't X be Y?" is not an effective way to communicate; it > solicits a "no, the current one is fine." without any explanation. > > If you think X should be Y for some reason, please say "I think X > should be Y BECAUSE Z" instead. Without stating why you think > differently from what those who wrote the current text, it is hard > for people to respond either with "Yeah, you're right---I agree > with Z" or with "No, Z does not hold because..." >
Re: man gittutorial: patch proposal
hello. 1.I understood, that verbose commands are quoted in ` ' or ' '. While the points I changed are not verbose commands. Therefore I didn't see any sense in them. Because of the different quoting ways (e.g. `merge`), I thought that someone didn't understand the quoting concept. But it could also be me... 2.yes please. I will read this section. kalle Am 06.03.2018 um 00:25 schrieb Jonathan Nieder: > Hi, > > kalle wrote: > >> see attachment. > > Thanks for writing. A few questions: > > 1. Can you say a little more about the rationale for this change? > E.g. is the current formatting sending a confusing message? Is the > current formatting intending to use '' as quotes and using italics > instead? If so, should this use "" to fix it? > > 2. May we forge your sign-off? See the section "Certify your work" > in Documentation/SubmittingPatches for more about what this means. > > Thanks, > Jonathan >
user-manual: patch proposals and questions
The patches are attached. Further some questions: -see the explanations of the branch command, ca. line 280: wouldn't it be better to use other words than 'references'? -sentence "it shows all commits reachable from the parent commit": it seems wrong to me. The last commit is also shown. - chapter "Browsing revisions": it seems counterintuitive to me to have two different logics for the meaning of "branch1..branch2" and "branch1...branch2", according to whether it's the argument of `git log' or `git diff' -section "Check whether two branches point at the same history": 'git diff origin..master' -> shouldn't it be rather 'git diff branch1..branch2'? … or rewrite the example with branch1=origin and branch2=master. greetings, kalle >From 19061a0dd4363edbf8757a5e9eee8ace210f4029 Mon Sep 17 00:00:00 2001 From: kalledaballe <ka...@projektwerkstatt.de> Date: Fri, 9 Feb 2018 20:46:52 +0100 Subject: [PATCH 2/5] 3 small formulation changes in Documentation/user-manual.txt --- Documentation/user-manual.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt index eff7890..e3efc26 100644 --- a/Documentation/user-manual.txt +++ b/Documentation/user-manual.txt @@ -322,7 +322,7 @@ do so (now or later) by using -b with the checkout command again. Example: HEAD is now at 427abfa Linux v2.6.17 -The HEAD then refers to the SHA-1 of the commit instead of to a branch, +If you haven't created a new branch yet, the HEAD then refers to the SHA-1 of the commit instead of to a branch, and git branch shows that you are no longer on a branch: @@ -370,7 +370,7 @@ be updated by `git fetch` (hence `git pull`) and `git push`. See <> for details. You might want to build on one of these remote-tracking branches -on a branch of your own, just as you would for a tag: +a branch of your own, just as you would for a tag: $ git checkout -b my-todo-copy origin/todo @@ -404,7 +404,7 @@ they may also be packed together in a single file; see linkgit:git-pack-refs[1]). As another useful shortcut, the "HEAD" of a repository can be referred -to just using the name of that repository. So, for example, "origin" +to by just using the name of that repository. So, for example, "origin" is usually a shortcut for the HEAD branch in the repository "origin". For the complete list of paths which Git checks for references, and -- 2.1.4 >From 3917eeaf8d21b8b90a773c46ee5b9d12eac901e3 Mon Sep 17 00:00:00 2001 From: kalledaballe <ka...@projektwerkstatt.de> Date: Sat, 10 Feb 2018 16:08:45 +0100 Subject: [PATCH 3/5] I changed the sequence of 2 sentences. --- Documentation/user-manual.txt | 10 +++--- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt index e3efc26..b9dc17a 100644 --- a/Documentation/user-manual.txt +++ b/Documentation/user-manual.txt @@ -609,13 +609,9 @@ $ git show HEAD^2 # show the second parent of HEAD In addition to HEAD, there are several other special names for commits: -Merges (to be discussed later), as well as operations such as -`git reset`, which change the currently checked-out commit, generally -set ORIG_HEAD to the value HEAD had before the current operation. +ORIG_HEAD is set to the value HEAD before merging (to be discussed later) operations as well as operations such as `git reset'. which change the currently checked-out commit. -The `git fetch` operation always stores the head of the last fetched -branch in FETCH_HEAD. For example, if you run `git fetch` without -specifying a local branch as the target of the operation +FETCH_HEAD after a `git fetch' operation stores the head of the last fetched branch. For example, if you run `git fetch' without specifying a local branch as the target of the operation. - $ git fetch git://example.com/proj.git theirbranch @@ -664,7 +660,7 @@ can also make more specific requests: - $ git log v2.5.. # commits since (not reachable from) v2.5 -$ git log test..master # commits reachable from master but not test +$ git log ..master # commits reachable from master but not from test $ git log master..test # ...reachable from test but not master $ git log master...test # ...reachable from either test or master, #but not both -- 2.1.4 >From a084b699ed7a0768530f9112ae8469fd5e297356 Mon Sep 17 00:00:00 2001 From: kalledaballe <ka...@projektwerkstatt.de> Date: Sat, 10 Feb 2018 16:14:25 +0100 Subject: [PATCH 4/5] I errouneously have deleted one word too much in the last commit --- Documentation/user-manual.txt | 2 +- 1 file ch
user-manual: patch proposals and questions
The patches are attached. Further some questions: -see the explanations of the branch command, ca. line 280: wouldn't it be better to use other words than 'references'? -sentence "it shows all commits reachable from the parent commit": it seems wrong to me. The last commit is also shown. - chapter "Browsing revisions": it seems counterintuitive to me to have two different logics for the meaning of "branch1..branch2" and "branch1...branch2", according to whether it's the argument of `git log' or `git diff' -section "Check whether two branches point at the same history": 'git diff origin..master' -> shouldn't it be rather 'git diff branch1..branch2'? … or rewrite the example with branch1=origin and branch2=master. greetings, kalle
git help clone: questions
-In the explanation of the option --reference: shouldn't there be written '' instead of 'reference repository'? greetings, kalle
man gittutorial: patch proposal
see attachment. greetings, kalle >From ed466d29733a14acf3b2071d3d35aa829e09b1d7 Mon Sep 17 00:00:00 2001 From: kalledaballe <ka...@projektwerkstatt.de> Date: Thu, 8 Feb 2018 18:53:54 +0100 Subject: [PATCH 1/5] I corrected some few quotation mistakes --- Documentation/gittutorial.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/gittutorial.txt b/Documentation/gittutorial.txt index 242de31..d04f8ac 100644 --- a/Documentation/gittutorial.txt +++ b/Documentation/gittutorial.txt @@ -372,7 +372,7 @@ her work-in-progress on top of the resulting history. When you are working in a small closely knit group, it is not unusual to interact with the same repository over and over -again. By defining 'remote' repository shorthand, you can make +again. By defining remote repository shorthand, you can make it easier: @@ -406,8 +406,8 @@ could merge the changes into her master branch: alice$ git merge bob/master - -This `merge` can also be done by 'pulling from her own remote-tracking -branch', like this: +This merge can also be done by pulling from her own remote-tracking +branch, like this: - alice$ git pull . remotes/bob/master -- 2.1.4
Re: What's cooking in git.git (Nov 2012, #02; Fri, 9)
Paul Fox p...@foxharp.boston.ma.us writes: you're sending SIGINT to the cvs commit command, and that causes the editor to die right away? That's right. It is not a quirk of shell-mode in Emacs, because I get the same result with ^C in xterm too. % EDITOR=$HOME/prefix/x86_64-unknown-linux-gnu/bin/emacsclient --current-frame % export EDITOR % cvs commit BUGIT Waiting for Emacs...^Ccvs commit: warning: editor session failed Log message unchanged or not specified a)bort, c)ontinue, e)dit, !)reuse this message unchanged for remaining dirs Action: (continue) a cvs [commit aborted]: aborted by user % While cvs was waiting from emacsclient: % cat /proc/2030/stat 2030 (cvs) S 1849 2030 1849 34816 2030 4202496 598 0 0 0 0 0 0 0 20 0 1 0 94752537 34254848 410 18446744073709551615 140168182550528 140168183348316 140737407935424 140737407931680 140168163193950 0 0 6 20513 0 0 0 17 2 0 0 0 0 0 % grep 'Name\|Pid\|Sig' /proc/2030/status Name: cvs Pid:2030 PPid: 1849 TracerPid: 0 SigQ: 0/28998 SigPnd: SigBlk: SigIgn: 0006 SigCgt: 000180005021 % cat /proc/2031/stat 2031 (emacsclient) S 2030 2030 1849 34816 2030 4202496 155 0 0 0 0 0 0 0 20 0 1 0 94752538 4169728 81 18446744073709551615 4194304 4210620 140735996104016 140735996095456 140664960886018 0 0 0 0 0 0 0 17 1 0 0 0 0 0 % grep 'Name\|Pid\|Sig' /proc/2031/status Name: emacsclient Pid:2031 PPid: 2030 TracerPid: 0 SigQ: 0/28998 SigPnd: SigBlk: SigIgn: SigCgt: % which I interpret to mean both processes were in process group 2030, the cvs process ignored SIGINT and SIGQUIT, the emacsclient process neither ignored nor handled any signals, and neither process blocked any signals (not even SIGCHLD as system(3) would). When ^C in the terminal sent SIGINT to the process group, it terminated the emacsclient process only. If git did the same thing as cvs here, i.e. ignore the signals in the parent process only and check the exit status of the editor, I think that would be OK. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Nov 2012, #02; Fri, 9)
Jeff King p...@peff.net writes: Comments welcome from people using unusual editors (e.g., a script that starts an editor in another window then blocks, waiting for the user to finish). I often run a shell in Emacs in X, then start git commit in that shell. $EDITOR is emacsclient --current-frame, which asks the existing Emacs instance to load the file and waits until I press C-x # in Emacs to mark the file done. If I want to abort the commit, it is most intuitive to return to the *Shell* buffer in Emacs and press C-c C-c (comint-interrupt-subjob) to send SIGINT to git from there. (I see that an empty message aborts the commit, and indeed it does, but well, I prefer not to trust such a feature if I can instead just interrupt the thing.) With pf/editor-ignore-sigint, C-c C-c in the *Shell* buffer kills neither git nor the emacsclient started by git. This is not good. SIGQUIT from C-c C-\ (comint-quit-subjob) still works though. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git with large files...
2012/7/23 Sitaram Chamarty sitar...@gmail.com: On Mon, Jul 23, 2012 at 2:24 AM, Junio C Hamano gits...@pobox.com wrote: mer...@stonehenge.com (Randal L. Schwartz) writes: Darek == Darek Bridges darek.brid...@me.com writes: Darek I use git for many things, but I am trying to work out the Darek workflow to use git for deployment. Don't. Yeah, don't think 'git checkout' is a way to 'deploy'. Using Git as a transport measure is probably fine. You can also try http://sitaramc.github.com/the-list-and-irc/deploy.html. Whether it's saying you *can* use git for deploying something, or you *can* but *should not*, or you *cannot*, will depend on your own thoughts on the matter ;-) Nice summary list of options! If you combine that with several key concepts: 1. You plan and design to deploy - hence you have separate deploy repositories dedicated for that 2. You design for modularity and complete audit trail, hence you have this: http://abstractiondev.files.wordpress.com/2011/12/git-distribution-overview.png You can combine the staging with any approach, that *tries* to maintain the local version copy. But if any problem arises in pull/fetch, simply trash that part and get it from fresh (or just use the git archive approach). Now this model would introduce complete and as detailed security enforcement - as the deployment can validate with certificates (from the additional catalogue-metadata binding, whether there is authorized party confirmed signature available for the wished deployable version). I don't see much overhead in any of the steps here - and the deployment is as detailed and as securely controlled as desired. With just Git (and well, possibly GnuPG or alike common tool for digital certificate work). Everything is also transparent - which is very important in having that complete control and audit trail. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Complete audit trail for embedded (Linux) system lifecycle with Git
Hello, We are to solve a complete audit trail solution for full subcontractor value-chain fullfilling European Union machinery directive: http://ec.europa.eu/enterprise/sectors/mechanical/machinery/ To summarize, the directive is created to ensure safe operating environment for all kind of machinery devices (from industrial machinery to consumer shopping-centre lifts/elevators). This also includes the embedded software that controls the machinery (which is as we know, the make-or-break the true safety of the device). The solution is based on the very core Git functionality, in very brief overview explained here: http://abstractiondev.wordpress.com/git-based-distribution/ As Git is completely file-system based, in our solution it is used as the core technology to audit ANY digital document or information. It is serving as a distributed set of master data repositories, including the digital signature repositories and 3rd party validation stacks. In the validation chains it is critical to be able to support responsible decision makers to approve design choises beyond the software, thus the digital signature infrastructure for any legal-binding document is as important as the actual embedded software stack, that is by its nature version controlled within Git as well. While I would hope this post to serve a purpose for demonstrating that Git works as a perfect solution in the core, I'd also like to hear if there is already established community/ongoing process of achieving anything described above? We have no intention of reinventing the wheel here, although being very core solution for ANY audit trail and being so close based on Git - bare functionality, I'm expecting any existing solution to share much of similar design. Any existing tooling to support the solution (especially dynamic cross-connected metadata repository searches - the bottom image of the overview, that indexes the repositories together) would be very welcome. The current technical solution is using GnuPG for the digital signatures and open-source cross platform XML-database for metadata indexing - grid databases being considered for the larger implementations. Any comments and/or feedback would be greatly appreciated. Cheers, Kalle Launiala -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Could not interpret heads/dbrt-test as something to pull
Junio C Hamano [EMAIL PROTECTED] writes: Rsync works for me also. But HTTP is still broken. Sorry, a broken repo. Fix made on master should percolate through soonish. HTTP clone works now, thanks. -- Kalle Valo - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cvsimport error: need a valid pathname
Martin Langhoff [EMAIL PROTECTED] writes: On 8/28/05, Kalle Valo [EMAIL PROTECTED] wrote: The documentation says that it should be possible to update incrementally from the CVS repository. Am I doing something wrong or is this a bug? It _should_ work the way you are running it, so consider it a bug. Do you think you can do some tinkering/debugging to tell us some more? I investigated it and realized that this was my mistake. I had copied the imported git repository from my laptop to my desktop using 'scp -r' and it changed .git/HEAD to a file, not a link as it should have been. I copied it again, this time with tar to preserve symbolic links, and cvsimport started to work again. So this was just a PEBCAK. Thanks for your help. Otherwise. how large is the cvs repo? 'git log | grep commit | wc -l' says 2704 commits. I have to say that git has made my life a lot easier. It was really easy to import the CVS history to git and now I can read the history properly with gitk. With CVS I would have been banging my head to the wall all the time. Now all I want is svnimport and darcsimport :) -- Kalle Valo - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] undo and redo
Carl Baldwin [EMAIL PROTECTED] writes: For this, I may also use branching, as suggested. I meant for undo/redo to be a lighter weight alternative to allow for a faster context switch. I have been missing the undo command since I started to use git, so I'll share a user's perspective. I was also considering undo as a really lightweight command, nothing too fancy. Usually, I want to try implement something wild or stupid, but almost immediately decide to abandon it. With 'git undo', this kind of prototyping would be really easy. For me, redo would be just a backup if (read: when) I undo something important, nothing more. For anything else I would use branches, as was suggested. -- Kalle Valo - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Change git-branch to list branches
Junio C Hamano [EMAIL PROTECTED] writes: I do not think we have agreed to limit ourselves to a flat namespace under refs/heads without subdirectories. Something like what git-show-branches-script does when $# == 0, perhaps? I didn't realise this. I'll send a revised patch soon. -- Kalle Valo - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add git-branches-script
Amos Waterland [EMAIL PROTECTED] writes: For people whose workflow involves switching back and forth between a lot of branches, it can be really helpful to be able to quickly tell which branch you are on and which ones are available. This patch introduces a small script that when invoked as `git branches' prints a list of available branches with a star in front of the one you are on: $ cd linux-2.6/ $ git checkout -b ppc64-cleanups $ git checkout -b ppc64-new-devel $ git checkout -b ppc64-all-merge $ git branches master * ppc64-all-merge ppc64-cleanups ppc64-new-devel I would prefer to using some git command compared to 'ls -l .git/refs/heads/'. In my opinion there is a need for this command and it should be included. But my immediate concern was that there is already 'git branch' command and 'git branches' is too similar. I think they should be merged. I have a patch coming up. -- Kalle Valo - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Change git-branch to list branches
If no argument provided to `git branch`, show available branches and mark current branch with star. This is based on patch written by Amos Waterland [EMAIL PROTECTED]. Signed-off-by: Kalle Valo [EMAIL PROTECTED] --- git-branch-script |8 +++- 1 files changed, 7 insertions(+), 1 deletions(-) 38aca3bb4ad4e6b0e10e295a87a9f5ce37ff5be4 diff --git a/git-branch-script b/git-branch-script --- a/git-branch-script +++ b/git-branch-script @@ -11,7 +11,13 @@ case $2 in esac rev=$(git-rev-parse --revs-only --verify $head) || exit -[ -z $branchname ] die git branch: I want a branch name +if [ -z $branchname ]; then +current=$(basename $(readlink $GIT_DIR/HEAD)) +cd $GIT_DIR/refs/heads +ls | sed -e s/^/ / -e s/ $current/* $current/ +exit +fi + [ -e $GIT_DIR/refs/heads/$branchname ] die $branchname already exists echo $rev $GIT_DIR/refs/heads/$branchname - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
