Re: How to propagate critical fixs from master to develope branch.
Hi GB, On Fri, 23 Nov 2018 at 04:23, Mgr Georg Black wrote: > > Hello everyone.I red git manual but I can't figure out how to propagate > critical change from master branch to long live develop branch. I red chapter > about rebasing that I think could solve it but at the end of this chapter is > written that it's not recommended for pubic repositories. I don't know how to > do it without merging develop branch to master. > I'll appreciate list of orders very much. :-) > Thanks for any info or link. > GB A lot of what to do comes down to how you and your team work, and your ongoing maintenance needs are. The two methods I've seen used are to either cherry-pick the critical change on top of whichever branches need it, or to build the change from the oldest branch point that has the error, and then merging those changes up to any maintained branches. The cherry-pick method is quick and dirty, and doesn't require much messing about. The 'hotfix branch' method requires a bit more work to set up, but can make it easier to see where the change is coming from and where it has been applied. This fits in with the 'git flow' development methodology (but doesn't require it). A pretty good discussion of these ideas can be found at https://stackoverflow.com/questions/7175869/managing-hotfixes-when-develop-branch-is-very-different-from-master Regards, Andrew Ardill
Re: [GSoC] Info: new blog series of my work on Git GSoC '18
On 2 May 2018 at 17:12, Johannes Schindelin <johannes.schinde...@gmx.de> wrote: > Hi Pratik, > > On Wed, 2 May 2018, Pratik Karki wrote: > >> As promised in my proposal, I've started >> to write a blog series of GSoC '18 with Git. The initial blog is up. >> You can find it here[1]. The initial one is just to get started and >> from next iterations, I'll start detailing of my work towards converting >> rebase to builtin. >> >> [1]: https://prertik.github.io/categories/git/ > > This is awesome! Thanks for doing this, > Dscho Agreed, was fun to read. I'd encourage you to post to the list when you blog, or perhaps include a link to the blog as part of any regular updates you give on your project progress. Would also make for an interesting addition to the newsletter. I know it can be difficult to sit down and write about what you're doing, especially when it feels like you could be focusing on 'real work'. Hopefully you will find the process rewarding; I'm looking forward to reading about what you find easy and hard, how you learn the git developer processes, and the challenges you find in converting shell scripts to a built-in. I'm sure other people are too, and I'll bet the ones who have been there before will have feedback for you as well. I'd find it interesting even if it was a 5-line bullet list of what's going through your mind with respect to the project! Looking forward to following along. Regards, Andrew Ardill
Re: please change stash
Hi Karsten, > Normal git tooling creates different files file.ORIG file.LOCAL > file.REMOTE in case of conflicts. Which tools are you referring to here? Can you give a short sequence of commands that show what you mean? > However `git stash pop` manipulates your files directly resulting in > lines like: > > <<<<<<< Updated upstream > >>>>>>>> Stashed changes > > This can seriously corrupt files and workflows. This looks like a normal merge conflict. I suspect that you are using tools that know how to deal with this format when it used the merge conflict markers, but maybe not the equivalent markers you get when popping a conflicting stash. To demonstrate, here is a short script: git init test cd test echo "base file" >test git commit -m "base file" git add test git commit -m "base file" git checkout -b conflict_branch echo "conflicting file" >test git commit -am "conflict file" git checkout master echo "updated file" >test git commit -am "updated file" git merge conflict_branch This merge fails, and the file 'test' looks like this: <<<<<<< HEAD updated file === conflicting file >>>>>>> conflict_branch As you can see, this sequence of actions doesn't result in 3 different files. The merge conflict format is a relatively old one, and lots of tools know how to use it in different ways (such as the tool you are using, I presume) but say this was to be changed for the stash operation - what would you propose replace it? Some options might be to: - instead of placing the conflicts in the original file, place the different conflicting versions into different files - warn when adding/committing/pushing files with conflict markers in them - teach the tool you are using to handle the stash conflict markers in a nicer way Some of these may be possible to do with little work. This link[0] on stack overflow deals with creating separate files, and it looks like it might work for stash pop conflicts. This one[1] shows how to create hooks that catch any conflicts that are being committed, and would also probably work with stash conflicts. Teaching the tool to handle stash conflicts, or making any of the above changes to the base distribution of git would be significantly harder, but maybe this can help you in the meantime. Regards, Andrew Ardill [0] https://stackoverflow.com/questions/47512337/configure-git-to-create-multiple-files-for-merge-conflicts [1] https://stackoverflow.com/questions/24213948/prevent-file-with-merge-conflicts-from-getting-committed-in-git
Re: Bug/comment
Hi Ilija, On 30 January 2018 at 10:21, Ilija Pecelj <pec...@gmail.com> wrote: > Though it might not be considered a bug 'per se' it is definitely wired. > Namely, when you type 'yes' word and hit enter in git bash for widnows, the > process enters infinite loop and just prints 'y' letter in new line. What you are seeing is a program called `yes`, the job of which is to print the letter 'y' (or something else if requested) on a new line as often as it can. It is used, for example, when you want to answer 'yes' to all the prompts a program may ask. See more at https://en.wikipedia.org/wiki/Yes_(Unix) I agree it's a little weird if you have no idea what it's doing, but it is very useful and very old, used by many many different scripts etc, and so unlikely to change. Regards, Andrew Ardill
Re: Branch name support & character
Hi, On 7 September 2017 at 13:27, 夏大雨 <xia.jaso...@gmail.com> wrote: > I want to merge branch a to branch b so I rename branch b to a, but > when I push a to remote repo, '&' is took as & operator for shell, > and git push fails. So it would be better that branch name support & > character for me. Have you tried quoting the branch name? Using git checkout -b 'my' works for me (single quotes around the branch name). Pushing to a local remote also works: git push --set-upstream ../git-test-2 'my' That being said, I would advise not using & in branch names, specifically because it is a special character in shells. Regards, Andrew Ardill
Re: Please fix the useless email prompts
Hi Anatoli, On 21 August 2017 at 07:57, Anatolii Borodin <anatoly.boro...@gmail.com> wrote: > On Sun, Aug 20, 2017 at 2:40 PM, Andrew Ardill <andrew.ard...@gmail.com> > wrote: >> Maybe I am missing something obvious, but if that's the case then >> can't we just do the identity check when trying to make new commits, >> in which case you should be able to pull without setting your >> identity? > > `git pull` is `git fetch + git merge / git rebase` in disguise, so we > should be ready if git will want to create a merge commit or do a > rebase automatically (and potentially create new commits with > `Committer` set to the current user). `git fetch` and `git clone` > alone, `git branch`, `git checkout` etc don't care about the email (as > of 2.14.1), even if `user.useConfigOnly` is set to `true`. Is there any reason `git pull` can't delay that check until the point where it actually tries to create a new commit? It's fair enough to error if a new commit needs to be made, and there is no user configured, but for the use cases discussed here it seems a little eager to error on the chance that the user will be needed. It seems nicer for the user if the `git fetch` happens first, and if the merge is not a fast forward, and there is no user configured, that the error pops then. I don't know if this idea of "do as much as possible before erroring" is consistent with any other errors we handle. Regards, Andrew Ardill
Re: Please fix the useless email prompts
On 20 August 2017 at 19:18, Jeff King <p...@peff.net> wrote: > On Sat, Aug 19, 2017 at 02:02:09PM -0400, Jeffrey Walton wrote: > >> > Hasn't this been asked and answered already? >> > >> > >> > https://public-inbox.org/git/cacbzzx4veod-4a-ek-ubxmfrb1glsvjkxhw51whcsbczdh7...@mail.gmail.com/ >> >> Its 2017. I'd like the tools to work for me instead of me working for the >> tools. > > Ironically, Git used to behave as you requested in 2005. After being > bombarded with complaints about how Git was too lax in creating commits > with bogus ident information, we changed it in 2012. Maybe I am missing something obvious, but if that's the case then can't we just do the identity check when trying to make new commits, in which case you should be able to pull without setting your identity? Regards, Andrew Ardill
Re: git clean -fdx deletes tracked files
Hi Kim, I have cc'd the git for windows mailing list, but doing a quick search on the bug tracker shows this issue which looks related: https://github.com/git-for-windows/git/issues/607 Hope that helps, seems like it may be an issue with how junctions on windows are handled by git. Regards, Andrew Ardill On 16 August 2017 at 16:47, Kim Birkelund <k...@birkelund.me> wrote: > Apologies. I should obviously have mentioned which OSes the machines I > tested on ran. > > One Windows 10 (fully updated) and one Windows Server 2016 (also > updated). I've also seen it in a real repository on our build server > which is Windows Server 2012 R2. > > After my first mail I updated git to latest and could still reproduce. > > > > On Aug 15, 2017 21:25, "Kevin Daudt" <m...@ikke.info> wrote: > > On Tue, Aug 15, 2017 at 08:45:20PM +0200, Kim Birkelund wrote: >> Hi >> >> I hope this is gonna sound as weird to you as it does to me. >> >> The link below is a zip of a small git repository that I can reproduce >> the bug in on 2 machines. >> >> Repo: https://www.dropbox.com/s/fz4d0i5ko7s7ktr/test.zip?dl=0 >> >> It contains 2 folders: helpers and b, each of which is an empty npm >> module. b\package.json refers to the helpers module. >> >> The following reproduces the bug: >> >> 1) in terminal cd to the b folder >> 2) run npm install >> 3) run git reset HEAD --hard >> 4) run git clean -fdx >> >> At this point both files in the helpers folder has been deleted and >> running git status confirms this. >> >> Tool version: >> >> git --version => git version 2.10.2.windows.1 >> node -v => v6.11.2 >> npm -v => 5.3.0 >> >> >> I have no idea what is going. Very much hope you can explain :-) > > I cannot reproduce it on linux. > > git clean -fdx output: > > Removing node_modules/ > Removing package-lock.json > > These are all untracked, and nothing in the helpers dir is being > removed.
Re: Contact with Latinamerica
On 31 July 2017 at 04:01, Philip Oakley <philipoak...@iee.org> wrote: > From: "Christopher Díaz" <christopher.diaz@gmail.com> > >> As one of the main problems when getting involved with a community here >> is the barrier of english language, and few are able to have fluent >> conversations in that language, as it is a bit intimidating for most to >> approach an open source community. My community hopes to get in touch >> with different open source projects throughout the world and seeks to >> be a midpoint to interact with young developers and communities. >> > > I can see two simple steps toward your goal that may help. > Another idea, and I don't think anyone has done this yet, would be to localise news posts coming out of projects. For git, one option would be to localise 'Git Rev News' [0]. Christian Couder (cc'd) organised the last few editions, and might have an idea about how it could be localised if that was something your community wanted to support. Regards, Andrew Ardill [0] https://git.github.io/rev_news/
Re: Should I store large text files on Git LFS?
On 25 July 2017 at 04:11, Jeff King <p...@peff.net> wrote: > On Mon, Jul 24, 2017 at 02:58:38PM +1000, Andrew Ardill wrote: > >> On 24 July 2017 at 13:45, Farshid Zavareh <fhzava...@gmail.com> wrote: >> > I'll probably test this myself, but would modifying and committing a 4GB >> > text file actually add 4GB to the repository's size? I anticipate that it >> > won't, since Git keeps track of the changes only, instead of storing a copy >> > of the whole file (whereas this is not the case with binary files, hence >> > the >> > need for LFS). >> >> I decided to do a little test myself. I add three versions of the same >> data set (sometimes slightly different cuts of the parent data set, >> which I don't have) each between 2 and 4GB in size. >> Each time I added a new version it added ~500MB to the repository, and >> operations on the repository took 35-45 seconds to complete. >> Running `git gc` compressed the objects fairly well, saving ~400MB of >> space. I would imagine that even more space would be saved >> (proportionally) if there were a lot more similar files in the repo. > > Did you tweak core.bigfilethreshold? Git won't actually try to find > deltas on files larger than that (500MB by default). So you might be > seeing just the effects of zlib compression, and not deltas. I tweaked nothing! The space saving I assumed was pretty much just zlib compression, and I wasn't sure how much delta we actually could get, and how long that might take to run. > You can always check the delta status after a gc by running: > > git rev-list --objects --all | > git cat-file --batch-check='%(objectsize:disk) %(objectsize) %(deltabase) > %(rest)' > > That should give you a sense of how much you're saving due to zlib (by > comparing the first two numbers for a copy that isn't a delta; i.e., > with an all-zeros delta base) and how much due to deltas (how much > smaller the first number is for an entry that _is_ a delta). Let's have a look: $ git rev-list --objects --all | git cat-file --batch-check='%(objectsize:disk) %(objectsize) %(deltabase) %(rest)' 174 262 171 260 139 212 47 36 377503831 2310238304 data.txt 47 36 500182546 3740427683 data.txt 47 36 447340264 3357717475 data.txt Yep, all zlib. What do you think is a reasonable config for storing text files this large, to get good delta compression, or is it more of a trial and error to find out what works best? Regards, Andrew Ardill
Re: Should I store large text files on Git LFS?
Hi Farshid, On 24 July 2017 at 13:45, Farshid Zavareh <fhzava...@gmail.com> wrote: > I'll probably test this myself, but would modifying and committing a 4GB > text file actually add 4GB to the repository's size? I anticipate that it > won't, since Git keeps track of the changes only, instead of storing a copy > of the whole file (whereas this is not the case with binary files, hence the > need for LFS). I decided to do a little test myself. I add three versions of the same data set (sometimes slightly different cuts of the parent data set, which I don't have) each between 2 and 4GB in size. Each time I added a new version it added ~500MB to the repository, and operations on the repository took 35-45 seconds to complete. Running `git gc` compressed the objects fairly well, saving ~400MB of space. I would imagine that even more space would be saved (proportionally) if there were a lot more similar files in the repo. The time to checkout different commits didn't change much, I presume that most of the time is spent copying the large file into the working directory, but I didn't test that. I did test adding some other small files, and sometimes it was slow (when cold I think?) and other times fast. Overall, I think as long as the files change rarely, and the repository remains responsive, having these large files in the repository is ok. They're still big, and if most people will never use them it will be annoying for people to clone and checkout updated versions of the files. If you have a lot of the files, or they update often, or most people don't need all the files, using something like LFS will help a lot. $ git version # running on my windows machine at work git version 2.6.3.windows.1 $ git init git-csv-test && cd git-csv-test $ du -h --max-depth=2 # including here to compare after large data files are added 35K ./.git/hooks 1.0K./.git/info 0 ./.git/objects 0 ./.git/refs 43K ./.git 43K . $ git add data.txt # first version of the data file, 3.2 GB $ git commit $ du -h --max-depth=2 # the data gets compressed down to ~580M of objects in the git store 35K ./.git/hooks 1.0K./.git/info 2.0K./.git/logs 580M./.git/objects 1.0K./.git/refs 581M./.git 3.7G. $ git add data.txt # second version of the data file, 3.6 GB $ git commit $ du -h --max-depth=1 # an extra ~520M of objects added 1.2G./.git 4.7G. $ time git add data.txt # 42.344s - second version of the data file, 2.2 GB $ git commit # takes about 30 seconds to load editor $ du -h --max-depth=1 1.7G./.git 3.9G. $ time git checkout HEAD^ # 36.509s $ time git checkout HEAD^ # 44.658s $ time git checkout master # 38.267s $ git gc $ du -h --max-depth=1 1.3G./.git 3.4G. $ time git checkout HEAD^ # 34.743s $ time git checkout HEAD^ # 41.226s Regards, Andrew Ardill
Re: Should I store large text files on Git LFS?
Hi Farshid, On 24 July 2017 at 12:01, Farshid Zavareh <fhzava...@gmail.com> wrote: > I'v been handed over a project that uses Git LFS for storing large CSV files. > > My understanding is that the main benefit of using Git LFS is to keep the > repository small for binary files, where Git can't keep track of the changes > and ends up storing whole files for each revision. For a text file, that > problem does not exist to begin with and Git can store only the changes. At > the same time, this is going to make checkouts unnecessarily slow, not to > mention the financial cost of storing the whole file for each revision. > > Is there something I'm missing here? Git LFS gives benefits when working on *large* files, not just large *binary* files. I can imagine a few reasons for using LFS for some CSV files (especially the kinds of files I deal with sometimes!). The main one is that many users don't need or want to download the large files, or all versions of the large file. Moreover, you probably don't care about changes between those files, or there would be so many that using the git machinery for comparing them would be cumbersome and ineffective. For me, if I was storing any CSV file over a couple of hundred megabyte I would consider using something like LFS. An example would be a large Dunn & Bradstreet data file, which I do an analysis on every quarter. I want to include the file in the repository, so that the analysis can be replicated later on, but I don't want to add 4GB of data to the repo every single time the dataset gets updated (also every quarter). Storing that in LFS would be a good solution then. Regards, Andrew Ardill
Re: Dropping a merge from history -- rebase or filter-branch or ...?
Hi Martin, >From the sound of it you really just want to revert the merge of the pull requests. A really good description of options for this is at https://git-scm.com/blog/2010/03/02/undoing-merges.html There is also a section there about bringing the changes back in at a future date, depending on how you do the revert. Does that page describe what you're trying to do? Regards, Andrew Ardill On 8 July 2017 at 07:07, Martin Langhoff <martin.langh...@gmail.com> wrote: > Hi git-folk! > > long time no see! I'm trying to do one of those "actually, please > don't" things that turn out to be needed in the field. > > I need to open our next "for release" development branch from our > master, but without a couple of disruptive feature branches, which > have been merged into master already. We develop in github, so I'll > call them Pull Requests (PRs) as gh does. > > So I'd like to run a filter-branch or git-rebase --interactive > --preserve-merges that drops some PRs. Problem is, they don't work! > > filter-branch --commit-filter is fantastic, and gives me all the > control I want... except that it will "skip the commit", but still use > the trees in the later commits, so the code changes brought in by > those commits I wanted to avoid will be there. I think the docs/help > that discuss "skip commit" should have a big warning there! > > rebase --interactive --preserve-merges --keep-empty made a complete > hash of things. Nonsense conflicts all over on the merge commits; I > think it re-ran the merge without picking up the conflict resolutions > we had applied. > > The changes we want to avoid are fairly localized -- a specific module > got refactored in 3 stages. The rest of the history should replay > cleanly. I don't want to delete the module. > > My fallback is a manually constructed revert. While still an option, I > think it's better to have a clean stat without sizable feature-branch > reverts. > > cheers, > > > > m > -- > martin.langh...@gmail.com > - ask interesting questions ~ http://linkedin.com/in/martinlanghoff > - don't be distracted~ http://github.com/martin-langhoff >by shiny stuff
Re: [GSoC] Update: Week 5
On 20 June 2017 at 07:41, Prathamesh Chavan <pc44...@gmail.com> wrote: >But as communicating between child_process is still an issue >and so there was no simple was to current carry out the >porting. And hence, a hack was used instead. But after >discussing it, instead using the repository-object patch >series will help to resolve these issues in this situation. Just wondering, does that mean that your patch series is dependent on the repository-object one? I saw some discussion around it recently but couldn't see it in the latest whats cooking so maybe I missed what has happened to it. Really enjoying your updates, by the way, they are very clear and show what looks like great progress! Regards, Andrew Ardill
Re: feature request: user email config per domain
On 23 February 2017 at 00:12, Tushar Kapila <tgkp...@gmail.com> wrote: > I can set my email via: > git config --global user.email tgkp...@xyz.dom > > this is dangerous when I use this my office or in a multi repository > provider environment where my email is different for a few (like > tgkp...@search.com for github and tus...@mycompany.com for my company > private repo). There has been a large discussion around this idea before, see this thread for example [0]. The proposed idea was to have something set in your global config that would only be turned on if you were within a given directory. This would allow you to have two root directories, one for your work projects and one for open source projects (for example) and any git repositories within those folders would each would have their own config options automatically applied based on their location. There was a patch suggested, and it worked quite well, but nothing further has been done to my knowledge. [0] http://public-inbox.org/git/7vvc3d1o01@alter.siamese.dyndns.org/ Regards, Andrew Ardill
Re: Potential Same Name Bug
Hi Kevin, On 13 September 2016 at 09:29, Kevin Smith <noi...@gmail.com> wrote: > So when I move from master to develop that status would come up. If I > ran "git reset --hard" I would no longer have that message. I also > saw that when I do a git clone and specify to clone the develop branch > that I would not see the git status above. Is this an issue where if > one branch has two files of the same name where one gets removed that > it will remove both instances of that file in another branch when you > switch to it? I fixed this issue in our repo by removing the > "file_NAME.png" file in the master branch, but it seems like this > should be handled better in the case I described. Just to clarify, is the machine you are cloning to on a case-insensitive file system, or have you set core.ignorecase=true? If so, I would imagine the behaviour would have been _interesting_ in that repository before you removed one of the versions - that may be why you removed it in the first place. For future reference, the typical way I have seen this situation dealt with is to git mv one file to a different filename, or using git rm. There may be better ways to do it, and it's possible git should deal with the specific situation you mentioned better, but I'm not able to comment on that. This situation commonly arises when you set core.ignorecase=false on a case insensitive file system and then rename a file. When you commit that change, git doesn't notice that the old filename has been 'deleted' (git sees a rename as a delete+create with the same file contents) and so now thinks that you have two files with very similar names in your working directory. To avoid this, make sure core.ignorecase is set correctly, and use git mv -f to rename files on case insensitive file systems. Details at https://stackoverflow.com/questions/17683458/how-do-i-commit-case-sensitive-only-filename-changes-in-git Regards, Andrew Ardill
Re: [RFC] Proposed questions for "Git User's Survey 2016"
Hi, Jakub Narębski <jna...@gmail.com> wrote: > Andrew Ardill pisze: > > Jakub Narębski <jna...@gmail.com> wrote: > >> 25. What [channel(s)] do you use to request/get help about Git [(if any)] > > > > It may also be useful to ask how people hear news about git, such as > > when a new release comes out. Not sure if worth a separate question, > > as there is a lot of crossover in the resources available for this and > > for requesting help, but knowing this information would help us > > understand what kinds of users are responding and which communication > > channels are effective for git news. > > How would you propose such question would look like, and what proposed > answers would be (if it were not a free-text / essay question)? Something like: XX. How do you hear about git related news (such as new releases and community events)? (multiple choice or single choice?) * I wasn't aware there was any news * I don't read any news, but I'm aware of it * through news aggregation sites (such as reddit or hacker news) * from a newsletter (such as Git Rev News) * from a mailing list (such as the git developer or the git for windows list) * other It would be good to allow a list of specific resources to be written to capture things we don't know about, and specific instances of the categories above, eg: "hacker news, git mailing list, git rev news" > Note that there might be a problem of severe bias: people who heard > about Git User's Survey 2016 are probably ones that watch news about Git. > Still, it would be useful to know if people read RelNotes... Agreed, the intent behind the question is to work out what are the effective communication channels so that they can be used more effectively. > That is, if people have a pattern to their upgrade of Git, and can > tell how often they upgrade. > > XX. How often you upgrade Git? > (multiple choice or single choice?) > > * as soon as new version is released > * when there is new binary package / distribution package > * when updating distribution / system > * around every month, or more often > * around every 6 months or more often > * I use what is installed on system > > Something like that? Exactly, looks great. Regards, Andrew Ardill -- 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: [RFC] Proposed questions for "Git User's Survey 2016"
On 21 August 2016 at 04:56, Jakub Narębski <jna...@gmail.com> wrote: > 25. What [channel(s)] do you use to request/get help about Git [(if any)] It may also be useful to ask how people hear news about git, such as when a new release comes out. Not sure if worth a separate question, as there is a lot of crossover in the resources available for this and for requesting help, but knowing this information would help us understand what kinds of users are responding and which communication channels are effective for git news. Related, it might be worth asking how often people upgrade their git clients and servers, particularly in corporate/managed environments. This question would ask two things, how long after a new release comes out do you install it, and do you install every update that comes out or do you skip versions. I suspect many would just use whatever is released in their distro and update at the same time as they update other packages, but it would be interesting to know if people, for example, only upgrade their managed environments every year/6 months or something to avoid introducing changes to their users. Regards, Andrew Ardill -- 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 Bash Slow in Windows (possible fix)
Hi Michael, First up, Git for Windows has a dedicated issue tracker over at https://github.com/git-for-windows/git/issues you may want to submit a bug report there (reference this email if it's easier). On 24 June 2016 at 02:02, UberBooster <i...@uberbooster.com> wrote: > > Back in February 2016, I installed Git-Bash on my Windows 7 computer > and everything worked great. Git-Bash would execute commands as fast > as the Windows command prompt. > > In June, Microsoft, in its infinite wisdom, decided to self install > Windows 10 without my authorization. Now when I used Git-Bash, it was > painfully slow Is there a chance that git was also upgraded at the time? If the slow-down was caused by some change in git for windows it would be useful to identify when that happened. > After speaking with some people about this, they recommended that I > inform you of my situation as it could be something that Microsoft > installs as part of Office that helped make it faster. I don't know of anything specific, but if the upgrade path you took assumes something is installed (when it isn't), that is something that may be able to be fixed. The reason this seems unlikely that that is all that is going on is due to you seeing the behaviour on a completely fresh OS and git install. If you are able to give more details in the bug report about how to reproduce the behaviour that will help a lot too. Regards, Andrew Ardill -- 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 merge branch --no-commit does commit fast forward merges
On 18 April 2016 at 17:23, Christoph Paulik <cpau...@gmail.com> wrote: > My expectations from what should happen came mainly from the description of > the --no-commit flag in the help: > > With --no-commit perform the merge but pretend the merge failed and do not > autocommit, to give the user a chance to inspect and further tweak the merge > result before committing. > So in the case of a fast-forward the flag does not pretend that the merge > failed. Yes, I think the mis-alignment in expectations comes from a technicality in the description you quote. The fast forward is in some ways not really counted as a true merge, and no new commits are created. Thus, the merge progresses up to the point where a merge resolution would have to take place, realises that there is no merge resolution to do (it's just a fast forward!) and so exits out. Unfortunately, a side effect of this is that the fast-forward has already happened and so you are left with something different from what was expected. I do think that the --no-commit option should imply --no-ff (as this would make the behaviour consistent for end-users). I don't know if this is something that would break scripts etc, but if so you could make it implied only if we detect a terminal or something like is done in other places. Regards, Andrew Ardill -- 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 merge branch --no-commit does commit fast forward merges
On 18 April 2016 at 16:26, Johannes Schindelin <johannes.schinde...@gmx.de> wrote: > > > The command only works as expected when also adding the --no-ff flag. > > Then you need to fix your expectations ;-) I *think* the core of this problem is that the intent of the end-user does not align with the command options available. In this use case (as far as I can tell), the user wants to see what the result of a merge from somewhere else will look like, without changing their HEAD. While you are correct in saying a fast-forward does not create any new commits, for the user it certainly looks like a whole slew of new commits have been added. Moreover, the nature of the option means that the user has to investigate if the merge is a fast-forward in order to know what the outcome of the command will be. If the merge is a fast-forward, --no-commit has no effect on the outcome. If the merge is not a fast-forward, --no-commit has a huge effect on the outcome. If I see a --no-commit option, as an inexperienced user, I would be quite surprised to find my HEAD changed after using it. It would be far more intuitive, for that user, for --no-commit to imply --no-ff however I suspect that such a change may well cause more problems then it fixes. What I wonder is, in what situation is the current behaviour is desirable? While I agree that the option works as designed, I think its behaviour is more surprising to the end user then it should be. Regards, Andrew Ardill -- 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: Gated Merge?
On 12 February 2016 at 09:06, Junio C Hamano <gits...@pobox.com> wrote: > > To realize this, there are low-hanging-fruit building blocks that > are trivial: > > - Such an annotation can be made as a note attached to the commit >in question; > > - Such a check can be done in pre-commit hook; > > - Such a pre-commit hook can iterate over this set of commits > > DIFF=$(git rev-list --left-right HEAD...MERGE_HEAD) > >collect these Merge Gate annotations from the commit appears on >the left hand side (e.g. only exists on the trunk that a side >branch is about to be merged in), and run them. > > But the last one feels very costly, and I suspect that there must be > a better way to do this. I do not think we want the "what to do" > part (i.e. checking new lines for __attribute__ in the first > example, or rewriting new lines that has __attribute_ in the second > example) to be in git-core; that clearly is outside the scope of the > plumbing. But the part that finds these "annotations", especially > if we can come up with a fast implementation that may be hard to > script, may be a good addition to the plumbing command set. > > Thoughts? What is the benefit in doing this in notes vs having the tests in the working tree? Pros: - merge-gates can be added after the commit, but will stick with the commit if it moves around (as opposed to creating a second commit to add the merge-gate to the working tree) - cross repository standards can be established that allow merge-gates to be detected and run automatically (arguably could be done with a standardised folder structure too, but that is more disruptive) - can view the relevant merge-gates in git log against each commit that they are protecting Cons: - difficult to see the current complete set of merge-gates - difficult to make changes to a number of merge-gates at the same time - poorly defined behaviour when multiple merge-gates overlap in functionality. Which gates execute first? What if I reorder the commits? My practical knowledge of notes is severely lacking so excuse me if I missed anything obvious. Regards, Andrew Ardill (sorry for the double post Junio, gmail ate my plain text encoding at some point...) -- 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: Starting on a microproject for GSoC
On 28 January 2016 at 11:40, Moritz Neeb <li...@moritzneeb.de> wrote: > I suppose just fixing/revising this would be kind > of a too low hanging fruit? I am in no way qualified to speak to the majority of your post, but I can't imagine anyone refusing your work because it was 'too low hanging fruit'. Indeed, the general gist of getting people to start with a microproject has always appeared to help potential applicants understand what it takes to get a patch accepted in git. As long as the low hanging fruit is useful (your example of polishing a patchset to get it into master is definitely useful, assuming the patchset is useful) then I'd say go for it. In the worst case, if you feel your contribution was not 'meaty' enough, there is nothing to stop you working on some other problem, or extending the first further. That said, I do remember previous applicants trying to do as many microprojects as possible, leaving few for other people. Regards, Andrew Ardill -- 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: email sender plugin in stash
Hi Ankit, On 22 September 2015 at 15:35, Ankit Jain <ankit...@gmail.com> wrote: > HI > > I need to modify the notifyemail.vm plugin to show only those changes in the > email which i committed as a part of pull request. I do not want to see all > the > commits which happen again and again during the review process. As this is the git developer mailing list, you'll probably get better assistance over at the Atlassian Answers website https://answers.atlassian.com/ Essentially what you need to do is adjust the list of changesets to display. In the given template, the changesets are grabbed using the function smtpNotificationRenderer.getChangesetPage(repository, refChange) You need to either filter that list, or alternatively write your own helper to get only the changesets you care about. Filtering would be relatively straight forward, using either changeset.author.name or changeset.author.emailAddress if you want to filter on whose commits are included, or changeset.parents if you only want to include merge commits. There are plenty of options for more complex filtering, but that might be able to help Regards, Andrew Ardill -- 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: Draft of Git Rev News edition 6
Hi Thomas.
On 3 August 2015 at 08:52, Thomas Ferris Nicolaisen tfn...@gmail.com wrote:
Hi,
A draft of Git Rev News edition 6 is available here:
https://github.com/git/git.github.io/blob/master/rev_news/drafts/edition-6.md
Everyone is welcome to contribute in any section, either by editing the
above page on GitHub and sending a pull request, or by commenting on
this GitHub issue:
https://github.com/git/git.github.io/issues/89
You can also reply to this email.
I did a quick read through and it looks like another interesting
edition, thank you! I couldn't see any obvious issues with it.
There is quite a lot of discussion in the support section, which I
really like. The following sections pack a lot in, but I think could
warrant a little more discussion themselves.
For example, I think it would be good to add a brief discussion about
the 2.5 release. This seems important/interesting enough to provide a
bit more context in the edition itself. Perhaps something like the
following?
--8--
## Releases
* Git 2.5 is out! The project maintainer, Junio C. Hamano, has [shared
his thoughts on the release at his
blog](http://git-blame.blogspot.de/2015/07/git-25.html). Git 2.5 is
packed full of new features, and includes contributions from 21 new
contributors. In his post, Junio describes how `git help` has changed:
One interesting change is to git help. We now list commands, grouped by the
situation in which you would want to use them. This came from discussion on
usability, inspired by one of the talks at GitMerge conference we had in
spring.
He goes on to talk about some of his favourite new features included
in the release, such as a new short hand `branch@{push}` that denotes
the remote-tracking branch that tracks the branch at the remote the
branch would be pushed to, and a new option `--ws-error-highlight`
that can be used with `git diff` and friends to show whitespace
breakages in deleted and context lines.
Be sure to see the post for more on the new features, or checkout the
[release notes in the
source](https://github.com/git/git/blob/master/Documentation/RelNotes/2.5.0.txt)
for all the nitty gritty details.
--8--
I'll copy this over to a pull request so you have it there if you
think it's useful.
Again, thanks for the edition, love reading these each month!
Regards,
Andrew Ardill
--
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: Promoting Git developers
On 12 March 2015 at 08:28, Junio C Hamano gits...@pobox.com wrote: OK, I've updated the Announce script on the 'todo' branch. The announcement for 2.3.2 I sent out earlier as $gmane/264975 would have looked like this. I think the changes are excellent, and think they add a lot of value regardless of any other measures that might be introduced, such as Git Traffic. At the least it gives long time lurkers, and people who skim the list, an easy way to put 'names to code', and it promotes the very people who should be promoted. Thanks to everyone involved in making this happen. Regards, Andrew Ardill -- 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: gitignore vs. exclude vs assume-unchanged?
On 18 April 2014 10:36, a...@bellandwhistle.net wrote: Like the $GIT_DIR/info/exclude file, gitignore files specify intentionally untracked files that Git should ignore. The difference is that files matched by a pattern in a gitignore file will be untracked for all users of the repository. As a data point, I have seen people add .gitignore to their .gitignore file, as they don't want to share the file. This seems like a misuse of the functionality, as $GIT_DIR/info/exclude is a better choice for the same use case, but I'm not sure why the misuse is there. My guess is that users aren't aware of excludes, whilst gitignore is placed front of mind living at the root of many repositories. Education will help here, but is there any way to make the 'correct' way more intuitive? It would be possible to check for this antipattern during normal use and provide a hint to the user, but that is probably too heavy handed and might annoy people with a legitimate use case. For that matter, if the gitignore file is easier to use for the 'private ignore' use case we have a bigger problem and shouldn't dictate to users what to use. As to the documentation, it is already quite comprehensive. All exclusion methods are listed, and the reasons for why to use them are well laid out. The introduction does specifically mention 'gitignore' files, but that seems to be due to all the ignore files ($HOME/.config/git/ignore, $GIT_DIR/info/exclude, .gitignore) being classified as 'gitignore' files. So some possible improvements. We could replace 'gitignore' with 'git ignore' in instances where we are referencing all forms of the ignore file, not just the .gitignore file. Git ignore files specify intentionally untracked files that Git should ignore. We could reference the multiple ignore locations earlier, for people who don't read past the first paragraph of to documentation. Git ignore files specify intentionally untracked files that Git should ignore. A git ignore file can be specified for all local repositories, a specific local repository, or shared with other users of a repository. Files already tracked by Git are not affected; see the NOTES below for details. Finally, it's a little confusing that one of the files is called 'exclude'. It would be great to rename it to 'ignore'; $GIT_DIR/info/exclude - $GIT_DIR/info/ignore. Is there any reason this shouldn't be done? I haven't checked how extensive a change this would need be, but it would make the usage much more consistent. The only reference I have found to this file is at http://markmail.org/message/l7shxticxo3kzdpn from Junio in a discussion around an RFD for ignore rules. I think these three changes together would make the intended usage more obvious to both new and old users, though each change could stand on its own as well. Regards, Andrew Ardill -- 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 in GSoC 2014
Congrats everyone who was successful in being picked for this year's GSoC. Fabian with Line options for git rebase --interactive [0] Brian Gesiak with Unify and Refactor Temporary File Handling [1] Tanay Abhra with Git configuration API improvements [2] I look forward to seeing how you go! [0] https://www.google-melange.com/gsoc/project/details/google/gsoc2014/bafain/5750085036015616 [1] https://www.google-melange.com/gsoc/project/details/google/gsoc2014/modocache/5639274879778816 [2] https://www.google-melange.com/gsoc/project/details/google/gsoc2014/tanayabh/5766466041282560 Regards, Andrew Ardill -- 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: Our official home page and logo for the Git project
On 10 April 2014 02:43, Felipe Contreras felipe.contre...@gmail.com wrote: Junio C Hamano wrote: - To officially adopt the logo that appears on the project home page as our project logo. I have made my objections to that logo before, but here it goes again: bright red is a horrible color for a logo, as it only looks good in limited situations. I propose you use the logo I chose for git-fc[1] which has a better color, and instead of showing commits going down, they go up. It's normal for an organisation to have a collection of logos to choose from, with one 'official' version. For example, a black and white version is useful for print. Similarly, it's useful to have a couple of different contrast level/colours that can be used in the appropriate situations. I think it is fair to say that the red version is the one people recognise as 'git' and so should be kept as the official version. There is nothing wrong with having alternates that have been approved for various situations. I recommend creating a git repository called git-resources, git-marketing, or git-assets, to contain the various approved logos. If there is not another location, or a more appropriate one, https://github.com/git would be a good place to put this. Regards, Andrew Ardill (I'm always concerned about making useless contributions to conversations like this, but I think having a specific location for resources like the logo will be very valuable). -- 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: An idea for git bisect and a GSoC enquiry
On 27 February 2014 06:47, Christian Couder christian.cou...@gmail.com wrote:
But I think the most important thing right now is first to gather as
much information as you can from the previous discussions on this
topic on this mainling list.
Perhaps you should also gather information on how git bisect works.
I have also, at one time, started working on this problem, though I
never submitted any of my patches :(. I went the way of renaming the
internal logic to make it less tied to the good/bad distinction that
is currently hard coded in. That may not be the best starting point,
but let me summarise the thoughts I had at the time, particularly
around the different adjective pairs that we might use.
A general description of git bisect is that you start with a commit
that exhibits a given property, find a commit that does not have that
property, and then look for when the property was introduced. I think
of this property as the 'bisect property' of the bisect search. The
property is described with our adjective pair, currently 'bad' (with
the property) and 'good' (without the property). We assume that
commits with the property have an ancestor without the property, and
as this assumption is so essential to how git bisect works I think of
it as the 'bisect relationship' of the bisect search, and we care
about the direction of this relationship between commits.
The proposed adjectives tend to be along the lines of the following:
- good-bad (current); good-bad
The bisect property is currently always described as 'bad', the
introduction of a bug being the motivating use case. The problem with
this is that we often want to find when a 'good' behaviour was
introduced, or when a neutral change occurred.
A solution is to allow reversing our bisect relationship, by either
detecting the intended direction or allowing the user to choose. If we
reverse the direction our adjectives also flip, and so the bisect
property we are now looking for is 'good' instead of 'bad'. The terms
good and bad don't work well with neutral searches.
- unfixed-fixed
For this pair, the bisect property would always be described by the
'fixed' adjective. It seems odd to ever reverse the bisect
relationship, as we don't usually say something was 'fixed' and then
became 'unfixed'. The behaviour of this pair would thus be near
identical to current usage of 'good-bad', but with the bisect
property conceptually reversed (when was a bug fixed vs when was a bug
introduced).
- old-new
This pair avoids making any judgement on what type of bisect property
we have. The adjectives are thus simply describing the bisect
relationship, and the user is free to use any bisect property they
wish. The main problem with this is that it is possible to have
commits without the property (thus described as 'old') that were made
chronologically after a commit with the property ('new'). This has the
potential to cause confusion for users.
- without-with
This pair also avoids making a judgement on the bisect property, but
avoids potential chronological confusion that 'old-new' has. You
could potentially allow users to reverse the bisect relationship's
direction, but these adjectives allow you to easily invert the bisect
property without causing confusion. For example, 'without bug XYZ' can
instead be written as 'with bug XYZ fixed'.
My preference is for the without-with adjective pair, as I believe it
maps most closely to the concept of finding a commit that changed a
given property, and it allows that property to be negated without
introducing too much confusion. Reversing the relationship's direction
would also make sense, however that is a significantly greater change
to the commands logic.
Thus, my initial work was to refactor the internal naming to use the
terms with and without, as that would make a better place from which
to add other features (such as reversing the relationship direction,
or adding new adjective pairs).
Sorry if that is all confusing to read, or if I'm repeating things
that have been said before :)
Regards,
Andrew Ardill
--
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: Feature Request Google Authenticator Support
On 30 January 2014 15:07, Max Rahm ac90b...@gmail.com wrote: Github supports google authenticator 2-step authentication. I enabled it and how can't figure out how to connect to my github account through git. I've looked pretty hard in the man pages and on google and can't seem to find anything on how to set up git to work with a repository with 2-step verification. Here's a link to my stackoverflow question with my exact problem if there's something I'm missing. http://stackoverflow.com/questions/21447137/git-github-not-working-with-google-authenticator-osx As far as I can tell the feature is not supported. I'd like to be able to use the 2-step authentication but obviously I'd like to be able to push my code :D I was under the impression that private key authentication worked regardless of two-factor authentication. Is using git over ssh an option for you? Regards, Andrew Ardill -- 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: Add a bugzilla website
On 15 November 2013 01:51, Konstantin Khomoutov flatw...@users.sourceforge.net wrote: But there was an announcement that an experimental JIRA instance has been set up for Git [1]. I'm not sure what its current status is, but you could look at it. So! The biggest concern has always been that any bug tracking system needs to complement the existing workflow of many developers. For bugs and feature requests, they are raised, discussed, and fixed on the list. Replacing this process is not in scope for a bug tracker. In that framework the main value a bug tracker has is keeping track of what bugs exist, what versions they affect, and when they are fixed. Unfortunately, at the moment, collecting and curating this information is entirely manual. The JIRA attempt [1] looks to pull in every conversation and thread it for us (adding replies as comments to existing tickets), but hasn't tried to anything beyond that. Automation may be possible, to do things like parse What's Cooking and the release notes, but that is a harder problem :) The tools are there, and you should be able to log in and add/update issues. Feel free! (Definite value would be derived from a dedicated curator who updated the bug tracker manually) I had a look over the set up (I hadn't in a while) and realised we were dropping some emails, so I'll try and fix that, but the bigger problem is that simply creating tickets to track conversations is not enough. We need to then identify those conversations that we care about and capture some metadata about them - did they resolve the reported issue, and when did that happen? Junio is the source of truth for this, and so ideally we would use his communications to understand it, but that just shifts the problem to linking the issues he writes about to the conversations that started them. In any case, adding value to the existing process is hard (because it works quite well!) and probably requires significantly more work to even understand what that value might look like. This, I think, is the key reason it is hard to truly get started with any bug tracking solution; the solution is not obvious, and the current (very customised) workflow is not supported directly by any tool. Regards, Andrew Ardill [1] https://git-scm.atlassian.net -- 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: Help creating git alias
Have you tried backslash escaping the backslash? double escaping? I don't know how many are required, but I would try first \S, then \\S, then S, etc Regards, Andrew Ardill On 30 October 2013 12:34, Eugene Sajine eugu...@gmail.com wrote: Hi, I need some advice about creating the git command alias: I have this as the command: git log --pretty=format:%h %ad %ae %s --date=short | sed 's/@\S*//g' The purpose is to cut off the email domain and keep only username. I'm trying to create this as the alias: lg = !sh -c 'git log --pretty=format:%h %ad %ae %s --date=short | sed 's/@\S*//g'' - but it complains about the \S and i'm failing to come up with the escape sequence to make it work right. I know i can work around that by creating shell alias, but it is not what i would like to have. Any ideas? Thanks! -- 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 -- 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: collapsing old git history to reduce repo size, while preserving commit #s and tags
On 29 October 2013 15:42, Stas Cherkassky scher...@gmail.com wrote: I'd like to clone the repo to the new project and slim it down I'd like to collapse 900 first commits into one, but keep last 100, with their commit numbers and tags. I also want to be able to push and merge changes from the old repo to the new one. If you want to change the actual history of your repository, it will be largely incompatible with the original, and this is by design. You don't want somebody being able to change your history without you knowing about it. I've read about git rebase, but it seems to tamper with commit numbers and looses tags.. Is there any other way to have it done ? It sounds like a shallow checkout might be appropriate for you, try looking that up. Regards, Andrew Ardill -- 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
Has Git 2.0 started to be integrated?
There has been plenty of comments lately about how certain features will be released in 2.0 Have these features been tied together anywhere yet? If not, when might such an integration branch be created? Would be very interested in seeing how Git 2.0 plays, even in these early days. Regards, Andrew Ardill -- 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: Has Git 2.0 started to be integrated?
On 16 October 2013 15:11, Jonathan Nieder jrnie...@gmail.com wrote: There has been plenty of comments lately about how certain features will be released in 2.0 Have these features been tied together anywhere yet? They're in Junio's jch branch: https://github.com/gitster/git/commits/jch Thanks! I'll build it and have a play tonight. If not, when might such an integration branch be created? Would be very interested in seeing how Git 2.0 plays, even in these early days. I wonder if it would make sense to keep these topics in next even though they will probably not be part of the next release, to encourage people who test that branch to try them out. (Just thinking out loud.) I guess that's my real question; we haven't had a major version release for a long time and I don't know what the cycle will look like. Will be interesting to see how it progresses. Regards, Andrew Ardill -- 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: [ANNOUNCE] git-related-0.1
On 11 October 2013 08:43, Felipe Contreras felipe.contre...@gmail.com wrote: After gathering all the relevant people, it groups them to show what exactly was their role when the participated in the development of the relevant commit, and on how many relevant commits they participated. It looks like you group by emails, any idea if anyone purposefully uses the same email but a different name? I don't know if the email is assumed to be the unique identifier, or if the name/email pair is, however I think the typical use case is definitely to group by email so it's a useful default behaviour. They are only displayed if they pass a minimum threshold of participation. Out of interest, how is the threshold determined and is it configurable? Regards, Andrew Ardill -- 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 should not use a default user.email config value
On Mon, Aug 12, 2013 at 11:01:03PM +1000, Andrew Ardill wrote: On 12 August 2013 22:39, Jeff King p...@peff.net wrote: We could do something like the patch below, which allows: $ git config --global include./magic/.path .gitconfig-magic to read ~/.gitconfig-magic only when we are in a repository with a directory component /magic/. Thanks, this looks great! I'll have a play with it tomorrow. I applied this on top of latest next (1da3ebde8999d07), and it worked perfectly for my use case. For what it's worth, it also passed the test suite! Would be great to see this, or something on the same theme, get into master. I'd be happy to review patches/write tests/write documentation if needed. Regards, Andrew Ardill -- 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 should not use a default user.email config value
On 13 August 2013 21:46, Jeff King p...@peff.net wrote: Like I said, I do not have a particular use for it, but I don't think it would hurt anybody who does not use it. If you want to polish it up into a real patch with docs and tests, I don't mind. I'll have a go at this. The only downside I can think of is that we might want to use the subsection in include.SUBSECTION.* for some other limiting conditions (e.g., only include this config when running version = X.Y, or even include only when environment variable FOO is true). It seems as though gitconfig doesn't have a standard way of dealing with 'sub-subsections', which is essentially what this is trying to implement. It makes sense that there could be different 'modes' of includes. These could be the ones you mentioned already, such as repo and env, but could also be things like branch where the config changes depending on which branch you are on. Ideally, multiple entries per mode would be allowed. Implementing all that initially would be overkill however if this sort of functionality is desirable the ability to easily add new modes would be a great boon down the track. The four pieces of information we need to include are that this is an include, the path to the include, the mode, and the mode specific parameter. Your proposal is to allow the sub-subsection by concatenating with a : like this [include mode:mode-param] path = path Alternatively, we could allow chaining of subsections (couldn't find any previous discussion on this) by adding whitespace between each subsection. Seems like lots of potentially unnecessary work, but maybe this has already been discussed or is the most appropriate way of doing it. $ git config --global include.repo./magic/.path ~/.gitconfig-magic [include repo /magic/] path = .gitconfig-magic We could also require a unique key that grouped the options together. This seems like the easiest and most flexible method, and doesn't require any 'special' considerations for the subsection. It would be harder for a user to configure, and the concept of a mode seems less intuitive. $ git config --global include.magicrepos.mode repo $ git config --global include.magicrepos.param /magic/ $ git config --global include.magicrepos.path ~/.gitconfig-magic [include magicrepos] mode = repo param = /magic/ path = ~/.gitconfig-magic Of the three I probably think the subsection chaining is the nicest overall, though your original repo: proposal seems to be the easiest to implement. Regards, Andrew Ardill -- 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 should not use a default user.email config value
On 11 August 2013 02:58, Junio C Hamano gits...@pobox.com wrote: Perhaps we need a lighter-weight mechanism git init --profile=open git clone --profile=open git://git.kernel.org/git.git This is something I would definitely use. All of my work git directories are in a separate folder to my other git directories, and as such it would be extremely convenient if every repository under that folder defaulted to the same profile. That may be asking for too much though! Regards, Andrew Ardill -- 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 should not use a default user.email config value
On 12 August 2013 22:39, Jeff King p...@peff.net wrote: We could do something like the patch below, which allows: $ git config --global include./magic/.path .gitconfig-magic to read ~/.gitconfig-magic only when we are in a repository with a directory component /magic/. Thanks, this looks great! I'll have a play with it tomorrow. Would locally configured config options override this one? From a quick read of the patch there doesn't look like there is a way of turning this off for a specific repository, but perhaps that is unnecessary. I think after a bit of use the edge cases will be a bit clearer. Again thanks, this will scratch an itch I didn't even realise I had. Regards, Andrew Ardill -- 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: merging commit history
On 12 July 2013 09:43, Stephen Linda Smith isch...@cox.net wrote: I'm working on a project that used to use a proprietary CM system (aka oldCM). At a point in time, the state of the code was frozen and used as the basis for commits in SVN. What I would like to to do is take the individal commits from the oldCM and place them into git knowing that the time/date stamps won't match. Then I want to do whatever is necessary to setup git so that I can run svn rebase to pull in the commits from the SVN repository. What is the easy way to do this? There may be other tools that make this easier, but if I had this problem I would simply create two repositories, one for oldCM and one for SVN. I would then merge the two together (as branches with different roots) and do my rebase from there. I haven't tried this, and maybe there is something I am missing, but there shouldn't be too much pain going that way. Regards, Andrew Ardill -- 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: Feature request: author branch in commit object
On 4 July 2013 09:46, Jakub Narebski jna...@gmail.com wrote: Junio C Hamano gitster at pobox.com writes: It is not just misleading but is actively wrong to recording the name of the original branch in commits and carrying them forward via rebase. If you want a record of what a group of commits were about, the right time to do so is when you merge. There is even git-resurrect.sh script in 'contrib/' that makes use of that practice to find merged-in and deleted branches, and resurrect them (among other tools). How do users who wish to keep a record of branch names find out that --no-ff will enable this behaviour? Is this a common enough requirement to make --no-ff the default behaviour (probably not, and that transition would be painful)? What are the shortcomings of using --no-ff in the analogue to how mercurials named branches work? I think the git-flow and git-list style workflows have done a lot to promote a set of usage patterns that keep this metadata around, I just wonder if we can do more to assist users in what seems to be a relatively common request. Regards, Andrew Ardill -- 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: Why does git config output nothing instead of the default value for unset variables?
On 14 April 2013 22:34, Sebastian Schuberth sschube...@gmail.com wrote: Usually when I query a variable I'm not so much interested in whether it is at all (explicitly) set to some value or not, but what value is currently in use. With your change in place, how do you know if the config item has been explicitly set in your system? The closest thing I can see for doing this is git config --list, but perhaps there should be a flag to check if a config item is set? More to the point, I can easily imagine many scripts relying on git config returning a value to indicate that a config item has been set. Your proposed change would break all those. For that reason, it might be nicer to introduce a flag that returns the config if it is set or the default otherwise. Something like git config --value perhaps. Regards, Andrew Ardill -- 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: Why does git config output nothing instead of the default value for unset variables?
On 14 April 2013 22:56, Sebastian Schuberth sschube...@gmail.com wrote: The closest thing I can see for doing this is git config --list, but perhaps there should be a flag to check if a config item is set? Yet more command line options? Well, there's probably no way around that in order to maintain backward compatibility. '--list' already exists; it shows all defined options. With your change in place (and no others) then the only (documented) way to know if something was configured would be by looking at git config --list. Changing the default behaviour is probably too big a breaking change, but a flag to change the behaviour might be nice. Then again, there may be away to do what you want already :-) Regards, Andrew Ardill -- 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 (Feb 2013, #05; Tue, 12)
On 14 February 2013 02:27, Junio C Hamano gits...@pobox.com wrote: If we need to support this behaviour than I would suppose a config option is required. A default config transition path similar to git push defaults would probably work well, in the case where breaking these expectations is unacceptable. We've discussed that before. http://thread.gmane.org/gmane.comp.version-control.git/171811/focus=171818 Something that I couldn't find discussed was the option of, rather than providing a config to 'turn it off', inverting the current default/flags combo. That is, currently git add defaults to not staging file deletions, and we provide command line flags to include them. The consensus in the thread is that it is better to stage them by default; it seems reasonable to me that if we stage deletions by default we should provide flags to _not_ stage them. If that was the entirety of the change, would your position from that thread, if we need this optional, then it is not worth doing this, still hold? Some people would be adversely affected by this change, but any objections I can come up with are not game stoppers. - It is possible newcomers might stumble at deleted files being staged for commit by a command called 'add', but if they can already grok the concept of staging then including deletions in that is trivial. If they don't understand staging then we have a different issue. - For people who rely heavily on file deletions remaining out of the index, providing a flag allows them to keep their workflow. No data would be lost, and most accidents would be easily recoverable. - For scripts that rely on this behaviour, a flag allows it to be updated, though it may break in the meantime. (I would presume that not many of these scripts exist in the first place, but I don't really know) Finally, making this change makes sense from a consistency point of view. For example, we don't track file renames because (and I paraphrase) we can work that out from the content that is moved. However if I rename a file and then 'git add .' I see that a new file is added, not that it has been renamed! Manually adding the deletion to the index causes git to correctly detect the rename, however this is unintuitive and not consistent with how git works and is communicated in general. Git add is also inconsistent with git add -p (although that might be due to unclear documentation for -p). When in patch mode, git add will propose deletions get added to the index as well, not just additions and modifications. Regards, Andrew Ardill -- 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 (Feb 2013, #05; Tue, 12)
On 14 February 2013 15:36, Junio C Hamano gits...@pobox.com wrote: That is, currently git add defaults to not staging file deletions, and we provide command line flags to include them. The consensus in the thread is that it is better to stage them by default; it seems reasonable to me that if we stage deletions by default we should provide flags to _not_ stage them. If that was the entirety of the change, would your position from that thread, if we need this optional, then it is not worth doing this, still hold? If that is the change we are going to make, and if you can guarantee that nobody who is used to the historical behaviour will complain, then I am fine with it, but I think the latter part of the condition will not hold. Does the impossibility of asserting that no-one will complain put this in the 'too hard' bucket? Some people would be adversely affected by this change, but any objections I can come up with are not game stoppers. - It is possible newcomers might stumble at deleted files being staged for commit by a command called 'add',... New people are fair game; we haven't trained them with the inconsistent behaviour, and the default being different from historical behaviour will not affect them adversely. - For people who rely heavily on file deletions remaining out of the index, providing a flag allows them to keep their workflow. Allowing to do the things they used to be able to do is a bare minimum. You are still forcing them to do things differently. The implication here is that a relatively small number of people will be inconvenienced by needing to specify extra flags/set up an alias. Compare this to the many for whom the expected behaviour is now default, and we have a net win. Finally, making this change makes sense from a consistency point of view. That is a given. Otherwise we wouldn't be even discussing this. Obviously I agree. I was actually bringing up a point about patch mode and it got incorporated into the bigger picture; patch mode includes deletions by default and I don't even know if you can turn that behaviour off. So, when we talk about git add -u and git add -A, we should also mention git add -p. Regards, Andrew Ardill -- 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 (Feb 2013, #05; Tue, 12)
On 13 February 2013 11:06, Junio C Hamano gits...@pobox.com wrote: * jc/add-delete-default (2012-08-13) 1 commit - git add: notice removal of tracked paths by default git add dir/ updated modified files and added new files, but does not notice removed files, which may be Huh? to some users. They can of course use git add -A dir/, but why should they? Resurrected from graveyard, as I thought it was a worthwhile thing to do in the longer term. Stalled mostly due to lack of responses. What do you need to progress this? I have been bitten by this before (the 'huh?' reaction) and think the previous discussions and patch look reasonable. Does it need testing? Further input?? Regards, Andrew Ardill -- 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 (Feb 2013, #05; Tue, 12)
On 13 February 2013 11:34, Junio C Hamano gits...@pobox.com wrote: The change could negatively affect people who expect that removing files that are not used for their purpose (e.g. a large file that is unnecessary for their build) will _not_ affect what they get from git add .; How big a problem is this? If we need to support this behaviour than I would suppose a config option is required. A default config transition path similar to git push defaults would probably work well, in the case where breaking these expectations is unacceptable. obviously they must have trained themselves not to do git add -u or git commit -a. Many people use git add -p by default, so I would not be surprised about people not using -u or -a. Regards, Andrew Ardill -- 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: Feature request: Allow extracting revisions into directories
On 4 February 2013 23:14, Robert Clausecker fuz...@gmail.com wrote: The specific workflow I am planning is this: I have a server that hosts a bare git repository. This git repository contains a branch production. Whenever somebody pushes to production a hook automatically puts a copy of the current production branch into /var/www/foo. I could of course use pull for that but it just does not feels right. Why should I have a repository twice on the server? Maybe I'm missing something. How does the behaviour you need differ from GIT_WORKING_DIR=/var/www/foo git checkout -f tree-ish ?? Regards, Andrew Ardill -- 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: How to identify the users?
(resending previous response. Forgot to turn off HTML, and apprently gmail doesn't wrap lines automatically anymore?) On 31 January 2013 16:52, Scott Yan scottya...@gmail.com wrote: The user info of git client (user name and email) is set by the users themselves, so , how to avoid userA pretend to be userB? Git server could authentication the user, but it do nothing about the user info of commit message. The simplest thing is to have the server reject commits that have the 'committer' set to someone other then the authenticated user. Of course, there are potential workflows that this would cause problems for, such as if you sync directly to another user's repository and then try and push those to a central server. The most robust system would probably involve using signed tags to verify what is being pushed, however I am not aware of any set-ups that have done this yet. Regards, Andrew Ardill -- 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: RFC: git config -l should not expose sensitive information
On 21 December 2012 02:49, Aaron Schrab aa...@schrab.com wrote: Tools outside of the core git tree may add support for new config keys which are meant to contain sensitive information, and there would be no way for `git config` to know about those. I understand that we've come down mostly on the 'users must check before sending' side of things, but this point isn't necessarily true. It wouldn't be too hard to create a config setting with a list of 'sensitive' keys filled with sensible defaults. It would be the job of the 3rd party to add the relevant keys to this config file. This wouldn't help with old 3rd party tools but would provide a way to 'hide' things automatically. A user could of course configure this themselves (though one would think most who knew how wouldn't need to). On 21 December 2012 02:52, Jeff King p...@peff.net wrote: I think that attempting to do this would only result in a false sense of security. Yeah. Thanks for a dose of sanity. I was really trying not to say the given advice is bad, and we cannot help those people. But I think you are right; the only sensible path is for the user to inspect the output before posting it. One thing that a new option could provide (or maybe even the existing option if it detects an interactive session) is to prompt the user to review the content before outputting it. This is a nice way of helping users who don't know that there might be sensitive information in the output. Are there any use cases where prompting the user would be annoying when using this command? Regards, Andrew Ardill -- 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: Noob Question
Hi! On 21 December 2012 12:07, awingnut wtriker@gmail.com wrote: My main questions center around the git repository and accessing it. The main thing you need to know is that you can work on your code base in the *exact* same way while using git. You don't *have* to change anything about how you work, as git's primary purpose is to store snapshots of your work so that you have a history of what has changed. That being said, you can (and maybe should) change how you work to take into account the power of git. Most of what you do will stay the same, however. 1) Should I install git on Linux or Windows or does it matter? Install git wherever you need to access the code. From the sounds of it you will want git on both machines, as you are working on windows and but keeping the code on the linux shared drive. When working on the windows machine you will use a windows copy of git to manipulate the workspace, though I'm not sure if there are any gotchas with the interaction with a linux shared drive. If you want to manipulate the repository from the linux machine you will need git on it as well. Unless you're using a git server, manipulating the repository is a local action and so is performed by the client. That is, when working on windows use the windows client, if you also work on the linux machine then you will need a client there as well. 2) How will my build scripts access the source? Will it be the same as now (my scripts 'cd' to the Eclipse project directory and run there) or do I need to add a wrapper to my script to check out the entire source for the builds? It's the same as now. Git uses the concept of a 'work tree' to talk about the actual files you are working on now. The work tree corresponds exactly to your current project files. When you create a git repository you gain the ability to store snapshots of this working tree into the 'object store', as well as metadata about the snapshots, so that you can restore that snapshot later. Your actual files keep their current layout and format, until you change them. 3) How do I move my current Eclipse project into git after I create the empty repository? I can only find info on how to import git into Eclipse not the other way around. You have two options. Create the git repository in the same location as your Eclipse project. Navigate to the project folder using git bash and do a 'git init' inside it; voila! you now have a git repository. You can choose to create a 'remote' repository somewhere to store a backup of your code as well, but this _still_ requires you to init a local repository to backup. The other option is to create a blank repository somewhere (anywhere) and then tell that repository to use your Eclipse project as its working tree. The benefit to doing this is being able to keep your snapshots and metadata in a different location to your working directory (say keep the snapshots on a local windows drive while your working directory is on the linux share). Unless you shouldn't or aren't able to create the repository within the Eclipse project, I would recommend against this. 4) Do I need to checkout the entire project from Eclipse to modify and test it or only the classes I want to change? Does the plugin get the others as needed when I run the app within Eclipse for testing? Not sure exactly what you are asking here, but in general people will 'clone' an entire repository including all its history. If you want to update only certain files that is fine, but the commit object stores the state of the entire tree of files. Note that a commit object does _not_ store the difference between two snapshots, but stores the entire state of the files. You can grab a file from a given snapshot and test that along side files from a second snapshot, but if you wanted to commit the resulting tree to the repository it would store a third snapshot containing the exact state of all files. Hopefully that clears it up for you? Regards, Andrew Ardill -- 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: [PATCH 1/2] Documentation/git-checkout.txt: clarify usage
Regards, Andrew Ardill On 17 December 2012 19:20, Johannes Sixt j.s...@viscovery.net wrote: Am 12/17/2012 8:21, schrieb Junio C Hamano: Chris Rorvick ch...@rorvick.com writes: 'git checkout' [branch]:: Is branch really optional in this form? BTW, what does plain 'git checkout' do? Just report ahead/behind information? I think it defaults to either HEAD or the current branch, which shows uncommitted changes and relationship to upstream. + +Update the index, working tree, and HEAD to reflect the +specified branch. ... +'git checkout' [--detach] [commit]:: The title here is better spelled as two lines: 'git checkout' commit:: 'git checkout' --detach branch:: I don't think that commit or branch should be indicated as optional here. doing 'git checkout --detach' will detach from the current branch if you have one, but maybe listing branch as optional would work in that case? Here is my suggestion, differing from what Junio put forward primarily by first indicating that a checkout is a 'switch' to a different branch or commit. This makes sense to me, and is used elsewhere in the documentation, so I thought it might make sense here too. --8-- From: Andrew Ardill andrew.ard...@gmail.com Date: Mon, 17 Dec 2012 18:53:41 +1100 Subject: [PATCH] Documentation/git-checkout.txt: Use consistent terminology git checkout is described as 'switching' branches in places. Use this terminology more consistently. Expand on the purpose of switching to a branch or commit, which is typically to prepare to build history on top of that branch or commit. Signed-off-by: Andrew Ardill andrew.ard...@gmail.com --- Documentation/git-checkout.txt | 18 -- 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt index db89cf7..e6db14f 100644 --- a/Documentation/git-checkout.txt +++ b/Documentation/git-checkout.txt @@ -23,8 +23,11 @@ branch. 'git checkout' [branch]:: - Update the index, working tree, and HEAD to reflect the - specified branch. + Switch to the specified branch. Prepares for building new + history on branch, by updating the index and the files in the + working tree, and by pointing HEAD at the branch. Local + modifications to the files in the working tree are kept, so that + they can be committed on the branch. + If branch is not found but there does exist a tracking branch in exactly one remote (call it remote) with a matching name, treat as @@ -56,10 +59,13 @@ successful. 'git checkout' [--detach] [commit]:: - Update the index and working tree to reflect the specified - commit and set HEAD to point directly to commit (see - DETACHED HEAD section.) Passing `--detach` forces this - behavior even if commit is a branch. + Switch to the specified commit. Prepares for building new + history on top of commit, by updating the index and the files + in the working tree, and by pointing HEAD at commit. Local + modifications to the files in the working tree are kept, so that + they can be committed on top of commit. Passing `--detach` + forces HEAD to point directly at commit even if commit is a + branch (see DETACHED HEAD section.) 'git checkout' [-p|--patch] [tree-ish] [--] pathspec...:: -- -- 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: [PATCH 1/2] Documentation/git-checkout.txt: clarify usage
On 18 December 2012 08:59, Junio C Hamano gits...@pobox.com wrote: Andrew Ardill andrew.ard...@gmail.com writes: Even if the primary purpose of git checkout branch is to check out the branch so that further work is done on that branch, I don't believe that means it has to be stated first. In fact, I would say that there are enough other use cases that the language should be slightly more use-case agnostic in the first situation. For example, someone might switch to another branch or commit simply to see what state the tree was in at that point. I've been deliberately avoiding the term switch, actually. I agree that it may be familiar to people with prior exposure to subversion, but that is not the primary audience of the manual. I don't have much experience with svn, so I didn't make that connection. Independent of svn usage, what is wrong with the term 'switch'? I would be interested to hear how translators communicate the checkout concept, as I assume the word checkout doesn't exist in many languages. For me, switching between revisions is a natural way of phrasing the action, but perhaps there is a better way of saying the same thing? Some people use checkout to deploy a tag of the working tree onto a production server. The first example in particular is, I think, a common enough operation that restricting the opening lines of documentation to talking about building further work is misleading. I agree with you that sightseeing use case where you do not intend to make any commit is also important. That is exactly why I said further work is done on that branch not to that branch in the message you are responding to. Ah ok, I didn't pick up on that nuance. Your suggestion from earlier has, for example, Prepare to work on building new history on branch which *is* excluding that use case. Perhaps modifying similar lines to something like Prepare to work with the repository/history/something from branch or maybe just Prepare to work with branch would better encapsulate those use cases. Following lines would expand on what it means to work with a branch or commit, and the technical details of updates to the repositories current state. Regards, Andrew Ardill -- 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: problem with BOINC repository and CR/LF
On 18 December 2012 03:01, Toralf Förster toralf.foers...@gmx.de wrote: On 12/17/2012 12:38 PM, Andrew Ardill wrote: On 17 December 2012 21:23, Toralf Förster toralf.foers...@gmx.de wrote: Hello, I'm faced with this situation : http://lists.ssl.berkeley.edu/mailman/private/boinc_alpha/2012-December/017371.html and even a git stash doesn't help. Hi Toralf, That list is private and not visible without an account. Can you transcribe the relevant parts? Regards, Andrew Ardill Oh of course : On 12/17/2012 12:03 AM, Gianfranco Costamagna wrote: So if you have further issues with boinc feel free to look in our debian git and feel free to download appropriate patches :-) Gianfranco thx Currently I'm struggling with a git problem of the boinc repository itself and b/c I'm using git for the linux kernel tree w/o any problems since eons /me wonders whether this is a BOINC-repository specific problem : After doing the following sequence with git 1.8.0.2 : $ git clone git://boinc.berkeley.edu/boinc.git $ cd boinc $ git checkout client_release_7.0.39 $ git checkout master (sometimes I've to repeat this : $ git checkout client_release_7.0.39 $ git checkout master ) I'm faced with this situation : $ git status # On branch master # Changes not staged for commit: # (use git add file... to update what will be committed) # (use git checkout -- file... to discard changes in working directory) # # modified: clientgui/AsyncRPC.cpp # modified: clientgui/sg_BoincSimpleFrame.cpp # no changes added to commit (use git add and/or git commit -a) (sometimes only clientgui/sg_BoincSimpleFrame.cpp is mentioned) Now these commands $ git checkout -- clientgui/AsyncRPC.cpp $ git checkout -- clientgui/sg_BoincSimpleFrame.cpp doesn't help - the status is still the same (and ofc now I'm no longer allowed to make a git checkout - due to un-commited changes). Now I'm wondering where to start to investigate this issue ... Hi Toralf, That does look like a weird issue. What operating system are you on? What happens if you do a hard reset to the branch? What is the ouptut of git diff --cached ? Regards, Andrew Ardill -- 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: [PATCH 1/2] Documentation/git-checkout.txt: clarify usage
I like these, and I think they are conveying the right amount of
information. There is a slight discrepancy between the branch and
commit versions, where it seems we are assuming that by checking out
a commit you are intending to work 'on top of' it. This could be
avoided by using the term 'with' in both cases. Also, they are in
different tenses, but I'm not sure which is preferred ('Prepare to' vs
'To prepare for').
In the second tense, these opening lines might look like this:
+ To prepare for working with branch, switch to it by updating
+ To prepare for working with commit, detach HEAD at it
+ (see DETACHED HEAD section), and update the index and the
+ files in the working tree.
Regards,
Andrew Ardill
--
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: How to specify remote branch correctly
On 17 December 2012 13:30, Woody Wu narkewo...@gmail.com wrote: 1. git checkout foo 2. git checkout origin/foo The first method run silently with success, but the second method complains that I got a 'detached HEAD'. So, I think I don't understand the difference between 'foo' and 'origin/foo'. Can someone give me a hint? Hi Woody, I think you are just missing a couple of important distinctions that git makes about the different references that exist in your repository. A remote reference (origin/foo) describes exactly the state of somebody else's branch at the time you last synchronised with them. It does not make sense for you to be able to 'edit' this state, as it doesn't belong to you. Instead, we create a copy of that reference and give it a name (git checkout foo origin/foo) and call this a local reference (foo). Git then provides machinery around keeping these in sync with each other (git branch --set-upstream foo origin/foo) but we don't _have_ to keep these in sync at all! In fact, the names can be completely arbitrary and we don't have to track the upstream at all. If I have some other remote (remote-x) that has the same branch as origin but with some other changes I want to look at, we can just check that out to another branch (git checkout remote-x-foo remote-x/foo), or simply download it as a remote ref and merge the changes on top of my existing local branch (git fetch remote-x; git checkout foo; git merge remote-x/foo). There are lots of patterns that can emerge from this functionality, but the main thing to remember is that to create changes on top of a remote branch, we first need to create a local copy of it. A 'detached HEAD' here means that we are looking at the remote repository's branch but don't have a local copy of it, so any changes we make might be 'lost' (that is, not have an easy to find branch name). Regards, Andrew Ardill -- 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: How to specify remote branch correctly
On 17 December 2012 16:06, Woody Wu narkewo...@gmail.com wrote: 1. git checkout foo. By this command, I think I am checking out files in my local branch named foo, and after that I also switch to the branch. Right? Correct. Your working directory (files) switch over to whatever your local branch 'foo' points to, and your HEAD is updated to point to your local branch 'foo'. Unless something goes wrong/you have conflicting files/uncommitted changes etc. 2. git checkout origin/foo By this command, I am checking out files in remote branch origin/foo, but don't create a local branch, so I am not in any branch now. This is the reason why git tell me that I am in a 'detached HEAD'. Is this understanding right? Correct! Your working directory is updated, however it doesn't make sense for you to make changes to a remote branch, so HEAD is updated to be detached. There are lots of patterns that can emerge from this functionality, but the main thing to remember is that to create changes on top of a remote branch, we first need to create a local copy of it. A 'detached HEAD' here means that we are looking at the remote repository's branch but don't have a local copy of it, so any changes we make might be 'lost' (that is, not have an easy to find branch name). I think here is a little confuse to me. You mean that a 'detached HEAD' means I don't have a local copy, but I remember that if I run something like: $ git checkout a-tag-name then I ususally went into 'detached HEAD' but my local files really get switched to those files in the tag 'a-tag-name'. So what does you mean by 'don't have a local copy'? I should have been more clear. Here I mean that you don't have a local copy of the branch reference. Your working directory is updated to be in sync with the remote branch, but you haven't yet copied that remote reference to a local branch that you can update with your changes. Hope that clears it up. Regards, Andrew Ardill -- 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: How to specify remote branch correctly
On 17 December 2012 16:30, Tomas Carnecky tomas.carne...@gmail.com wrote: 'git checkout foo' has special meaning if a local branch with that name doesn't exist but there is a remote branch with that name. In that case it's equivalent to: git checkout -t -b foo origin/foo. Because that's what people usually want. This is true, but I don't think it is documented. Does anyone know if this is documented anywhere in particular? The git checkout man pages seem to not mention it, and the git branch page doesn't seem to mention it either, but perhaps I am just missing it? In any case, might be useful to make this behaviour more clear. Regards, Andrew Ardill -- 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: [PATCH 2/2] Documentation/git-checkout.txt: document 70c9ac2 behavior
On 17 December 2012 18:21, Junio C Hamano gits...@pobox.com wrote: does it format well (I didn't check)? It applied cleanly for me on latest master, and the output looked consistent with existing documentation. Regards, Andrew Ardill -- 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: Feature Request - Hide ignored files before checkout
Hi Matt, On 8 December 2012 11:50, Matthew Ciancio matthew.cianci...@gmail.com wrote: Problem: ignore.txt does not disappear like foo.txt does and is now just sitting in branchA (and now any other branch I checkout into). When I first started using Git, I genuinely thought this was a bug, because it seems so logical to me that ignore files should hide/reappear just like tracked files do, when switching branches. Let me address this by asking a few questions; *why* do files hide/reappear, what is the mechanism behind that and does it really make sense to apply it to ignored files. For each commit, git stores a snapshot of your files. When we switch branches we are telling git to restore the previously saved snapshot so we can work with those files. This means resetting the working directory so that it looks like what we had committed; git will delete files that were part of the current checked out snapshot but not the new one, and create files that need to be created. As a convenience to users, files that are not tracked are left 'as-is' when switching branches. So we see that in order to hide/reappear a file it has to be tracked in a snapshot, and so has to be committed *somewhere*. An ignored file is by definition not included in commits, and furthermore you hope to keep these files out of your commit history. I have been told ways of circumventing this (using commits and un-commits OR using stash), but my reason for avoiding commits is: say you have binary/OS specific files which really do not belong in the commit logs (even locally) and hence should be ignored. What if you want those files in only one branch and not all? Stashing doesn't seem appropriate either, because it would get messy. I am not sure how viable a suggestion this is, but perhaps you can have two separate repositories, one tracking your standard branches, and another tracking the ignored files. These repositories could be kept in sync through submodules or some similar mechanism. This could also allow you to, for example, publish the histories of these independently, for example releasing the non-ignored repository publicly. I haven't heard of anyone doing this, but if you need to keep the history clean it might be a way of achieving it. I also don't know what the implications of checking out two repositories into the same tree might be, or even if git would allow it in general (maybe if you ignored everything belonging to the other repository?) In any case, this solution could quickly become messy, but if carefully controlled might solve your problem. Then again, maybe you can achieve what you want using more 'traditional' git workflows. Regards, Andrew Ardill -- 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: Remote hung up during `git fetch`
On 23 November 2012 05:39, Yichao Yu yyc1...@gmail.com wrote: Hi everyone, I sent this email yesterday to the git mailing list but I cannot find it in any archive so I decide to send it again. Does anyone know what has happened to the mailing list? I haven't receive any email from several kernel related busy mailing lists for several hours Yichao Yu Your original message just came through to me (I'm on GMail) so obviously there was a delay somewhere in routing your message/s. Looks like it was delayed by around 18 hours somewhere... Looking at your delayed message more closely I can see that there was a big delay just before vger.kernel.org got it. From: Yichao Yu yyc1...@gmail.com Date: Wed, 21 Nov 2012 23:18:34 -0500 Received: by 10.64.15.165 with HTTP; Wed, 21 Nov 2012 20:18:34 -0800 (PST) Received: by 10.50.12.165 with SMTP id z5mr1895031igb.17.1353557934382; Wed, 21 Nov 2012 20:18:54 -0800 (PST) Received: by mail-ie0-f174.google.com with SMTP id k11so2625936iea.19 for git@vger.kernel.org; Thu, 22 Nov 2012 15:00:04 -0800 (PST) Not sure if anyone else saw issues, but it is likely an issue with your service provider (either gmail or gmail's SMTP routers). My other gmail traffic has been fine over the period. Maybe somebody else knows what happened :) Regards, Andrew Ardill -- 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: [wishlist] support git flow-like view
On 21 November 2012 10:42, Lisandro Damián Nicanor Pérez Meyer perezme...@gmail.com wrote: Hi! I am not suscribed to the list, so please CC-me. That is the default etiquette on this list :) I think this may have been proposed before, but I could not find anything in the web, so I better try myself :) The idea would be to gitk to show a git flow-like[0] view when it detects git flow (or the user ask for it or...) What does it mean to 'show a git flow-like view'? Show multiple branches? Place commits on each branch in 'swim-lanes', rather than moving them around on the horizontal to fit the space available? Some more detail, or even a mock-up would help a lot here. Basiccaly, you can show the main two branches: master and develop. Of course, having the possibility to show feature/release/hotfixes branches would be ideal. It is already possible to show multiple branches in gitk at the same time. You probably have some more specific needs beyond simply showing the different branches. Maybe you can be more specific? Regards, Andrew Ardill -- 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: [wishlist] support git flow-like view
On 21 November 2012 11:13, Lisandro Damián Nicanor Pérez Meyer perezme...@gmail.com wrote: ... Well, two ideas come to my mind: - detect when using git flow (.git/config contains [gitflow some_branch] entries). I guess this part is just so the next part can be done automatically? - Show swim-lane-like graphs, including branches that may not be present, but where there (release branches often are created and merged back, for example) I think this could be useful in general, however it might struggle with already merged branches. I may be mistaken here, however I think in general there is no way to specify which commits belonged to a certain branch after they have been merged, as branch information is not kept in the commit object. There may be some exceptions that make it feasible at times, but a general solution would be to show any merged branches as part of the same swim-lane, as per current behaviour, but to have separate branch heads in different swim-lanes. This would be a nice feature, and is similar to the behaviour in, for example, Atlassian's Fisheye repository viewer and the GitHub network view. Regards, Andrew Ardill -- 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: Local clones aka forks disk size optimization
On 15 November 2012 10:42, Javier Domingo javier...@gmail.com wrote: Hi, I have come up with this while doing some local forks for work. Currently, when you clone a repo using a path (not file:/// protocol) you get all the common objects linked. But as you work, each one will continue growing on its way, although they may have common objects. Is there any way to avoid this? I mean, can something be done in git, that it checks for (when pulling) the same objects in the other forks? Have you seen alternates? From [1]: How to share objects between existing repositories? --- Do echo /source/git/project/.git/objects/ .git/objects/info/alternates and then follow it up with git repack -a -d -l where the '-l' means that it will only put local objects in the pack-file (strictly speaking, it will put any loose objects from the alternate tree too, so you'll have a fully packed archive, but it won't duplicate objects that are already packed in the alternate tree). [1] https://git.wiki.kernel.org/index.php/GitFaq#How_to_share_objects_between_existing_repositories.3F Regards, Andrew Ardill -- 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: Local clones aka forks disk size optimization
On 15 November 2012 11:40, Javier Domingo javier...@gmail.com wrote: Hi Andrew, The problem about that, is that if I want to delete the first repo, I will loose objects... Or does that repack also hard-link the objects in other repos? I don't want to accidentally loose data, so it would be nice that althought avoided to repack things, it would also hardlink them. Hi Javier, check out the section below the one I linked earlier: How to stop sharing objects between repositories? To copy the shared objects into the local repository, repack without the -l flag git repack -a Then remove the pointer to the alternate object store rm .git/objects/info/alternates (If the repository is edited between the two steps, it could become corrupted when the alternates file is removed. If you're unsure, you can use git fsck to check for corruption. If things go wrong, you can always recover by replacing the alternates file and starting over). Regards, Andrew Ardill -- 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: Local clones aka forks disk size optimization
On 15 November 2012 12:15, Javier Domingo javier...@gmail.com wrote: Hi Andrew, Doing this would require I got tracked which one comes from which. So it would imply some logic (and db) over it. With the hardlinking way, it wouldn't require anything. The idea is that you don't have to do anything else in the server. I understand that it would be imposible to do it for windows users (but using cygwin), but for *nix ones yes... Javier Domingo Paraphrasing from git-clone(1): When cloning a repository, if the source repository is specified with /path/to/repo syntax, the default is to clone the repository by making a copy of HEAD and everything under objects and refs directories. The files under .git/objects/ directory are hardlinked to save space when possible. To force copying instead of hardlinking (which may be desirable if you are trying to make a back-up of your repository) --no-hardlinks can be used. So hardlinks should be used where possible, and if they are not try upgrading Git. I think that covers all the use cases you have? Regards, Andrew Ardill -- 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: Links broken in ref docs.
On 21 October 2012 18:31, Mike Norman mknor...@gmail.com wrote: Many links on scm-git.org/docs simply reload the page. For example, all of Sharing and Updating section simply reload the docs page. And tons others. Must be a broken link or routing problem. Repros on FF 14.0.1 and Chrome. Good luck! Including Scott Chacon as he manages this site (to my knowledge). Looking at the request, I am getting a 302: Request URL:http://git-scm.com/docs/git-fetch Request Method:GET Status Code:302 Moved Temporarily Maybe those pages are not done yet? That doesn't seem right as this is simply the reference manual, but perhaps there is something else going on here. On another (related) note, the wayback machine has some very interesting entries for the scm-git.org domain [1] and it seems the /doc directory is not indexed at all. Is this on purpose? Regards, Andrew Ardill [1] http://wayback.archive.org/web/*/http://git-scm.com/* -- 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: Merge option suggestion (dictator, humble)
On 17 October 2012 04:23, Junio C Hamano gits...@pobox.com wrote: 乙酸鋰 ch3co...@gmail.com writes: I would like to suggest 2 merge options --dictator use all my changes --humble use all their changes These allows to produce a fast-forward commit, without resolving any conflicts. Sometimes, someone did something completely wrong, so the commit needs to be ignored. I cannot tell everyone in the world to run git fetch followed by git reset --hard. Then you cannot tell them to use pull --humble either, can you? Not seeing any merit in the proposal (yet). Would this allow setting up a project-default merge configuration for contributors that defaulted to --humble? Not sure if that is useful or not, but it at least seems safer than trying to default to doing reset --hard after every merge. Regards, Andrew Ardill -- 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: feature request
On 17 October 2012 04:27, Angelo Borsotti angelo.borso...@gmail.com wrote: Hi Andrew, one nice thing is to warn a developer that wants to modify a source file, that there is somebody else changing it beforehand. It is nicer than discovering that at push time. Take into account that there are changes in files that may be incompatible to each other, or that can be amenable to be automatically merged producing wrong results. So, knowing it could help. -Angelo If you simply want to know when a file has been changed by someone else, git already has this capability, but as you note it only occurs when you try to push. Unless you force push, you have to merge changes before committing to upstream. In a distributed situation you can only inform the user when they 'touch-base' with the server, and if that is what you want than one of the locking systems others have proposed might be a good choice. There are two concerns to deal with here. The first is when any conflicts at all will cause problems, as there is no way to merge them. This often happens with binary files, and is a good reason to use a locking system. The second concern is situations where a merge happens 'silently' (i.e. no conflicts) thus allowing potential logic bugs to be introduced even though semantically the merge was fine. For this situation the best option is to require whoever is merging to check the merge output for logical errors. This has to happen anyway, as it is possible for logical errors to be introduced across different files, although it's probably more common to see logic conflicts within the one file. To make it easier to discover such changes early in the process you could write a tool that did some (or all) of the following: 1. Automatically fetch changes from remote repositories at a regular interval. 2. Compare files changed in the working tree and index to changes fetched from remote repositories. This would need to find the merge base of the two and compare files touched since then. 3. Notify the user of the files that have been changed through some fashion. 4. Automatically push changes to a 'wip' branch so that others can see what you are modifying. Alternatively, automatically publish a list of changed files for the same purpose, though this seems a lot more hacky (though both options are surely hacky). 2 and 3 could be combined into a single tool run whenever the user wants to check for potential logic changes down the track. Automating it would allow for this information to be communicated a bit faster. Running it after each fetch would be a nice to have. Pushing the work in progress branch is something I am not sure is a good idea, but it would be the only way to know when someone else is working on something before they commit and push it manually. Pushing a single file with files being worked on is less invasive, but would require the other aspects of the tool to use it as well (hence forming a stronger coupling and reducing the usefulness of the other components as standalone tools). There is no way that I know of to force merge to stop every time the file is changed on both theirs and ours (regardless of whether or not it is an actual conflict or not). It could potentially be done with a pre-merge hook, but no such hook exists to my knowledge. If this were implemented, using it would make merging a potentially tiresome affair, however I could see its usefulness for people who were very concerned about introducing logic errors with merges on the same file. The best solution is in my opinion to check what is going to be merged before you merge it, but a tool to warn that someone else is modifying the same file would have its uses. Regards, Andrew Ardill -- 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: Ignore on commit
On 5 October 2012 12:20, Sitaram Chamarty sitar...@gmail.com wrote: On Fri, Oct 5, 2012 at 7:05 AM, demerphq demer...@gmail.com wrote: On 5 October 2012 03:00, Andrew Ardill andrew.ard...@gmail.com wrote: On 5 October 2012 07:20, Marco Craveiro marco.crave...@gmail.com wrote: ... Similar but not quite; the idea is that you know that there is some code (I'm just talking about files here, so lets ignore hunks for the moment) which is normally checked in but for a period of time you want it ignored. So you don't want it git ignored but at the same time you don't want to see these files in the list of modified files. What is the reason git ignore is no good in this case? Is it simply that you can't see the ignored files in git status, or is it that adding and removing entries to .gitignore is too cumbersome? If it's the latter you could probably put together a simple shell wrapper to automate the task, as otherwise it seems like git ignore does what you need. Git ignore doesn't ignore tracked files. would 'git update-index --assume-unchanged' work in this case? Didn't see it mentioned in any of the replies so far (but I have never used it myself) From the help page: --assume-unchanged, --no-assume-unchanged ... This option can be also used as a coarse file-level mechanism to ignore uncommitted changes in tracked files (akin to what .gitignore does for untracked files). Seems like it does everything required. I tested and it correctly hides changes that I want hidden. The only thing I can't see how to do is get git status to show files with the assume unchanged bit set. I think there is no way currently, but that might be a nice addition to make the initial request feature complete. It could show either all files with the bit set, or files with the bit set that have been changed (or this could be configurable). Regards, Andrew Ardill -- 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: Suggestions for What's cooking
On 14 September 2012 12:29, Junio C Hamano gits...@pobox.com wrote: Andrew Ardill andrew.ard...@gmail.com writes: On 14 September 2012 04:06, Junio C Hamano gits...@pobox.com wrote: Andrew Ardill andrew.ard...@gmail.com writes: short-branch-description long-branch-description notes next-steps * branch-name (creation-date) number-of-commits (merge-status) [list-of-commits] (branch-usage) I do not see how it makes any sense to have the This is where the section begins with, and its name is this line in the middle of a block indented in such a way. Care to explain? I'm not quite sure what aspect you are referring to,... Just this part, as I do not have much time. Here is your reordered one I will reject: A jc/maint-blame-no-such-path git blame MAKEFILE run in a history that has Makefile but not MAKEFILE should say No such file MAKEFILE in HEAD, but got confused on a case insensitive filesystem. B* jc/maint-blame-no-such-path (2012-09-10) 1 commit - blame $path: avoid getting fooled by case insensitive filesystems I was noting that B which *is* formatted as a header line (it EVEN has a leading asterisk to make it clear that it begins something new) is in the middle, and you added a redundant A that is not even marked clearly as a header line. The leading asterisk is actually not as useful to me, as indicating a header line, as the 'out-denting' I am proposing. I think this is due to the similarities between the asterisk and the other symbols used to indicate commits. This is maybe just a typographic issue, but I think in general the contrast between letters and spaces appearing in the first columns of text is stronger than either of characters and letters, or spaces and characters. A quick comparison of all three: --Letters and Spaces-- jc/maint-ident-missing-human-name git show --format='%ci' did not give timestamp correctly for... + split_ident_line(): make best effort when parsing author/committer line --Characters and Letters-- * jc/maint-ident-missing-human-name git show --format='%ci' did not give timestamp correctly for... + split_ident_line(): make best effort when parsing author/committer line --Characters and Spaces-- * jc/maint-ident-missing-human-name git show --format='%ci' did not give timestamp correctly for + split_ident_line(): make best effort when parsing author/committer line My preference would be first for letters and spaces, or if that is not good enough then characters and spaces. With regards to the comment that the old header line appears in the middle of the output, as I said earlier that was a consequence of reordering and indenting everything but otherwise leaving it as is. This should be changed, so how about: branch-name (creation-date) branch-description? notes-and-memoranda? next-steps? #-commits (merge-status?) [list-of-commits] (branch-usage?) eg: jc/maint-ident-missing-human-name (2012-08-31) git show --format='%ci' did not give timestamp correctly for commits created without human readable name on committer line. 1 commit (merged to 'next' on 2012-09-07 at 0e99b20) + split_ident_line(): make best effort when parsing author/committer line with no description: sl/autoconf (2012-09-11) 2 commits - build: don't duplicate substitution of make variables - build: improve GIT_CONF_SUBST signature Hopefully that makes more sense and addresses the concerns you raised. Adding an asterisk at the start is ok by me, if that is something you think is needed. One thing I did think about, when leaving the asterisk in the middle of the listing in the first version, was how machine readable the format was. I'm not sure if that is important, but the asterisk was a clear signal that what followed was a listing of commits. In any case, the new and revised format is perhaps slightly less machine readable as a result. I feel a little bit like I might be bikeshedding this, however I do think an improvement to the formatting of What's cooking is a meaningful one for the project! Regards, Andrew Ardill -- 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: Suggestions for What's cooking
(sorry about double replying - html sub-part creeped in!) On 13 September 2012 08:49, Philip Oakley philipoak...@iee.org wrote: From: Jens Lehmann jens.lehm...@web.de Sent: Wednesday, September 12, 2012 8:21 PM Am 11.09.2012 21:41, schrieb Junio C Hamano: Thanks. I wish all others paid attention to What's cooking like you did here. And if it is hard to do so for whatever reason, suggest a better way for me to publish What's cooking or an equivalent (I am interested in finding the least bureaucratic way to help people and keep the balls rolling). I think What's cooking makes lots of sense in its current form as one gets a very good overview over current development tracks. Maybe in addition it would be nice to email the author(s) of a series when the state changes or new comments are added (and to only include the relevant part from What's cooking there). For me it's not a big problem as I just have to grep for submodule to get the bits I care about, but I suspect others might have to invest much more time to check the current state of their series and may appreciate being mailed directly when something happens. Opinions? My comment, as a simple reader, is that I misread the order of the items, in that I miss-associate the description paragraph with the * title _below_. That is, I see the description first and then read on... Thinking about it, if the description paragraph was indented by one space then the * title would create that obvious content indent that (I am) would be expected. Obviously only a useful suggestion if it's easy to implement... I can attest to the fact that the format can be at times difficult to parse, and I often find myself rereading sections to make sure I understood what each was referring to. As a casual reader, interested in the development that is going on, the things I am interested in for each branch/topic are like: - Branch/Topic description - Current integration status - Next steps required - Notes and memoranda I understand that references to where the branch is found (it's name) and what it includes (commit list) are important too, but these are less important for me. Currently, the output for each branch looks something like: * branch-name (creation-date) number-of-commits (merge-status) [list-of-commits] (branch-usage) long-description notes-and-memoranda next-steps and these are grouped by current integration status (new, graduated, stalled etc) A format that would make this information easier for me to parse would be something like: short-branch-description long-branch-description notes next-steps * branch-name (creation-date) number-of-commits (merge-status) [list-of-commits] (branch-usage) Essentially, shifting the details of the branch to the bottom, and adding a short description for the entire branch. Indent everything after the short description to make it clear that they belong together. The only real 'new' information required is the short description, but that could be replaced with the topic name if short description is not available (or the topic name is self explanatory). Most of the parsing benefit would come from the indentation, but having the 'summary' information near the top would let me skip things I am not interested in without having to scan the list of commits and other details. Regards, Andrew Ardill -- 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
