Re: [Opinions] Integrated tickets
Am 06.11.2014 um 19:45 schrieb Junio C Hamano: This is a tangent, but I personally do not think ticket meshes very well with commit. If you already know which commit was problematic, why are you annotating it with a ticket before reverting it first? I would expect a ticket to be annotating the commit or version tag where the bug was found, which usually isn't the commit where the bug was introduced. -- 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: [Opinions] Integrated tickets
Am 11.11.2014 um 18:17 schrieb Junio C Hamano: Holger Hellmuth hellm...@ira.uka.de writes: Am 06.11.2014 um 19:45 schrieb Junio C Hamano: This is a tangent, but I personally do not think ticket meshes very well with commit. If you already know which commit was problematic, why are you annotating it with a ticket before reverting it first? I would expect a ticket to be annotating the commit or version tag where the bug was found, which usually isn't the commit where the bug was introduced. [...] Either way, I do not see how such an arrangement is the most convenient way to organize the tickets and ask questions such as what are the known, untriaged, or unresolved issues in v1.8.5?, what are the issues that didn't exist in v1.7.0 but appear in v1.8.5?, what are the outstanding issues around refs handling that are the highest priority?, etc. With your arrangement of data, any of the common questions I think of asking would require a linear scan of a commit range, followed by an enumeration and parsing of all the notes attached to the commits to answer. So I would have to say that your expectation makes even less sense than annotating an exact buggy commit with a note saying what is broken by it. Not less sense, because with tickets attached to the exact buggy commit one would have the same problems answering the questions above. I don't dispute that tickets and commits don't mesh, it was the reason that you gave the first time that didn't sound right. Sorry if I have wasted your time, but looking at it from the management side removed any lingering doubts for me that there might be a benefit to an integration, even if some sort of indexing or database was used. -- 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: rebase flattens history when it shouldn't?
On 23.07.2014 21:33, Sergei Organov wrote: What actually bothers me is the unfortunate consequence that git pull is not always a no-op when nothing was changed at the origin since the last git pull. THIS is really surprising and probably should better be fixed. Requiring -f is just one (obvious) way to fix this. That would invalidate the simple rule that git pull is equivalent to git fetch + git rebase. git rebase depends on both branches it operates on, not just one. The same goes for git merge, I assume it is just a coincidence that git merge does have this characteristic you now expect both to have. -- 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: Silly time stamps
Am 11.04.2014 13:08, schrieb Michael Haggerty: On 04/09/2014 10:50 PM, Mahmoud Asshole wrote: [...] Please conduct your discussions here in a civil tone. It is both more pleasant for all involved and also more likely to elicit a response. I hardly think that the waste of 12 bytes in every commit is an act of stupidity so inexcusable that it would deserve your bile, even *if* one were to agree that this information is useless (which I personally don't think). I would guess he is more concerned about the unnecessary disclosure of information that could be used to track or (together with other data) identify you. Since the reasons to include it seem to be specifically to know more about the comitter this seems to me the typical conflict between privacy and security. -- 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: Silly time stamps
Am 11.04.2014 17:14, schrieb Max Horn: More between privacy (or perhaps personal safety? think: dissident coder?) vs. feature that is useful to some people. Well, at least the reason mentioned in the gmane citation about knowing if it was 2 am for them, is strange. Did anyone ever check this timestamp to see if a patch was made at an unusal hour? What does it tell you? Some people sleep from 4am to 11am and do their best work at 2am. Only if you know someone you could infer he made a patch at an unusual time, but then you probably also know where he lives and have this information anyway. Your best and only indication of a sub-par patch is the patch itself. The only reason I can see is as a warning signal or indication that a patch wasn't sent by the person whos name is on the cover. -- 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
Am 11.04.2014 17:39, schrieb Philippe Vaucher: FWIW, I think if you made a poll and asked which color is the most positive between green and red, the vast majority of people would say green. Examples could be traffic green lights vs red lights, or Coca-Cola uses red. So red is refreshing and hip (if you believe the commercials). Apples are red. Red is healthy. Firefox is red on blue. I like Firefox. Green is the color of nature but also of poison. Which is to say, git's wellfare will surely not depend on the color of its logo. Otherwise the Coca-Cola company would have used a different color. -- 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 stash pop` UX Problem
Am 24.02.2014 17:21, schrieb Matthieu Moy: $ git add foo.txt $ git status On branch master Changes to be committed: (use git reset HEAD file... to unstage) modified: foo.txt Maybe status should display a stash count if that count is 0, as this is part of the state of the repo. $ git status On branch master Stashes: 1 -- Changes to be committed: (use git reset HEAD file... to unstage) modified: foo.txt It would be in Omars example case a clear message that git kept the stash. And generally a reminder that there is still a stash around that might or might not be obsolete. -- 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: is there a fast web-interface to git for huge repos?
Am 07.06.2013 22:21, schrieb Constantine A. Murenin: I'm totally fine with daily updates; but I think there still has to be some better way of doing this than wasting 0.5s of CPU time and 5s of HDD time (if completely cold) for each blame / log, at the price of more storage and some pre-caching, and (daily (in my use-case)) fine-grained incremental updates. To get a feel for the numbers: I would guess 'git blame' is mostly run against the newest version and the release version of a file, right? I couldn't find the number of files in bsd, so lets take linux instead: That is 25k files for version 2.6.27. Lets say 35k files altogether for both release and newer versions of the files. A typical page of git blame output on github seems to be in the vicinity of 500 kbytes, but that seems to include lots of overhead for comfort functions. At least that means it is a good upper bound value. 35k files times 500k gives 17.5 Gbytes, a trivial value for a static *disk* based cache. It is also a manageable value for affordable SSDs -- 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: first parent, commit graph layout, and pull merge direction
Am 23.05.2013 21:25, schrieb Andreas Krey: On Thu, 23 May 2013 11:06:57 +, Andreas Krey wrote: ... ... Don't do that, then. Ouch, you're right. The problem is not actually in the pull; only the *last* pull into a feature branch that then get pushed back ff to master needs to be reversed. And at that time you don't know it's the last one - swap parents before the push if necessary. if you have to be so careful to ensure the correct ordering of parents it almost defeats the initial objective to make commit graphs in gitk look nice without re-educating/restricting other users. A solution that works for everyone should work without users having to think about it. Here is an idea (probably already discussed in the long history of git): 1) the branch name is recorded in a commit (for merges the branch that is updated) 2) unique identifier of repository is recorded in commit (optional) 3) simple configurable ordering and/or coloring scheme in gitk based on committer,branch name and repo (with wildcards). With this users could pull and push as often as they like, the main branches would always be ordered and straight lines. If instead you already do the work to keep your history clean you could just use the coloring scheme and see committers color coded in gitk. Further benefit: the history of really old commits could be more easily remembered if you knew in what branch they originated Is this a bad idea or just no one did it yet? -- 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: first parent, commit graph layout, and pull merge direction
Am 24.05.2013 15:42, schrieb Andreas Krey: On Fri, 24 May 2013 11:29:00 +, Holger Hellmuth (IKS) wrote: ... Here is an idea (probably already discussed in the long history of git): 1) the branch name is recorded in a commit (for merges the branch that is updated) The branch name is almost completely meaningless. I could just do my feature in my local master and never have a different name. In which case parent switching in the commit wouldn't help you either. But even you could keep your master always on the left side of gitk if you deem it special. And you could keep longer running cooperative branches (the main develop and the release branch of your project for example) in a seperate lane. Depending on your use of branches many branches won't get any ordering, but at a minimum important branches can easily be highlighted. Or commit something onto tmp that I then fast-forward into my (properly named) feature branch. Yes, but then you would see a feature branch in its expected column in gitk and you would also see (even years later) that it didn't start as a feature but later was made into one. Cues like this help to remember what happened even if you forgot to mention them in the commit message 2) unique identifier of repository is recorded in commit (optional) That is pure noise (in my workflow). It is important to differentiate between branches of the same name in different repositories. For example if your project has a central repository with master getting all the release stuff you want to sort that master differently than your own master. The unique identifier might be just a random number or string created at init time of the repo. 3) simple configurable ordering and/or coloring scheme in gitk based on committer,branch name and repo (with wildcards). Ok, gitk could use some features. :-) Without additional information about the commit history gitk can do exactly what it does now. ... Is this a bad idea or just no one did it yet? Possibly not bad (hg does parts of it), but un-git-ish? Don't know. No CVS does branches as good as git. But then it drops that information which depending on development style could be useful or not. Not that useful for people who keep their history clean, a lot for people who don't. -- 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: English/German terminology, git.git's de.po, and pro-git
Am 22.05.2013 17:16, schrieb Ralf Thielow: hunk = Bereich IMHO Kontext is better if you use a German word. Technically the context is something else, but in a German text IMHO it fits nicer when explaining to the user where he/she can select the n-th hunk. Not sure if German users would know what hunk means, in case we leave it untranslated. And I'm not sure if I would understand Kontext. I tend to leave it untranslated. I don't think Bereich is a bad choice. As hunk is not a word with special meaning in cvs and not used in any commands I don't see a lot of reasons to keep it in english. Alternative translations might be Teilbereich, Dateibereich. Kontext would be very confusing IMHO -- 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: English/German terminology, git.git's de.po, and pro-git
+bare repository= bloßes Repository Since bloßes Rep. does not convey any sensible meaning to a german reader (at least it doesn't to me) it might as well be bare. Also bare is used as parameter to commands +remote tracking branch = externer Übernahmezweig Anyone used to the english client will switch as soon as he has to read this. No idea how to improve that though except to just use the english terms like the pro git translation does. +upstream branch= -||- Use upstream as it is used as parameter to commands +fetch = anfordern fetch = fetch +pull = zusammenführen pull = pull +push = versenden push = push established vocabulary used in stack programming as well as in vcs. Should not be translated. +clean(verb)= clean(verb) = säubern/aufräumen +clean(noun)= clean(noun) = Säuberung aufräumen is the better verb but there is no noun for it. +whitespace = Leerzeichen (FIXME?) (maybe Leerraum) whitespace = whitespace There is no german word for whitespace +Still being worked out: + +prune = veraltete(n) Zweig(e) entfernen +checkout(verb) = auschecken + +git add = hinzufügen mittels git add hinzufügen if you want to emphasize that you add something with the command + +merge conflict = Merge-Konflikt +3-way merge= 3-Wege-Merge +paths = Pfade + +symbolic link = symbolische Verknüfung +path = Pfad +link = Verknüpfung + +reflog = Referenzprotokoll +partial commit = teilweise committen, partiell committen As a noun, Teil-Commit + +reset = neu setzen (maybe umsetzen?) zurücksetzen -- 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: English/German terminology, git.git's de.po, and pro-git
Am 14.05.2013 19:51, schrieb Ralf Thielow: - repository = Projektarchiv - bare repository = bloßes Projektarchiv + repository = Projektarchiv, (or just Repository?) + bare repository = bloßes Projektarchiv (-||-), (reines, pures Repository) I would vote for Repository or if it needs to be translated, simply Archiv. Neither Projektarchiv nor Archiv is commonly used by me but Archiv is shorter and not everything in a repository is a project. I'm not sure about using Repository. I think Projektarchiv is actually good enough. - committer = Eintragender - tagger = Markierer + committer = Eintragender (or Committer, Commit-Ersteller) + tagger = Markierer (or Tagger, Tag-Ersteller) ...[each usage of commit and tag]... Both commit and tag are used in commands so with the exception of the place where they are defined the english words should be used. I think Commit-/Tag-Ersteller actually sounds fine and german enough so no one notices there is an english word in there ;-) + branch = Zweig (or Branch) I think Zweig is already fine. Same reason, branch is used as a command and should not be translated. But Zweig is a really natural and together with Baum fitting translation, so I'm conflicted here. -- 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: English/German terminology, git.git's de.po, and pro-git
Am 15.05.2013 15:14, schrieb Jan Engelhardt: On Wednesday 2013-05-15 14:27, Jens Lehmann wrote: While it's spoken Packdatei, the way to actually write it is .pack-Datei or .pack-Datei. I actually had the '-' in there too until I tried to look up Zip-Datei in the Duden. While I don't get the leading '.' (I cannot remember having seen that anywhere, AFAIK the file extensions are always used without the dot), I'm not a grammar expert and will be fine either way. In UNIX-land, extension seemed to always include the dot. In DOS-land, it's without (inherited from VMS too, perhaps?) As such, either way to write it is acceptable. Even in unix-land no one adds a dot because usually the extension is named after the data format, only that the file extension is used as the common abbreviation (at least that is my interpretation). Compare with jpeg. You often write jpeg-Datei instead of jpg-Datei because the data format is called jpeg. This is why I don't think the dot has any reason to be there. I can't remember ever seeing anyone writing .jpg-Datei (or .doc-Datei, .rar-Datei) except to ask what a .xyz Datei contains (i.e. when he doesn't know what the data format is) -- 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: [ITCH] Specify refspec without remote
Am 19.03.2013 12:33, schrieb Duy Nguyen: git push . foo:bar '.' has more like a here semantic, '..' might be a more fitting mnemonic here. -- 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: [ITCH] Specify refspec without remote
Would it make sense to allow abbreviation similar to how git objects can be abbreviated? This would mean origin usually could be spelled just o -- 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 14/19] Document pull-all and push-all
Am 09.03.2013 20:28, schrieb Paul Campbell: From 7dcd40ab8687a588b7b0c6ff914a7cfb601b6774 Mon Sep 17 00:00:00 2001 From: Herman van Rink r...@initfour.nl Date: Tue, 27 Mar 2012 13:59:16 +0200 Subject: [PATCH 14/19] Document pull-all and push-all --- contrib/subtree/git-subtree.txt | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/contrib/subtree/git-subtree.txt b/contrib/subtree/git-subtree.txt index e0957ee..c8fc103 100644 --- a/contrib/subtree/git-subtree.txt +++ b/contrib/subtree/git-subtree.txt @@ -92,13 +92,19 @@ pull:: Exactly like 'merge', but parallels 'git pull' in that it fetches the given commit from the specified remote repository. - + +pull-all:: + Perform a pull operation on all in .gittrees registered subtrees. + push:: Does a 'split' (see below) using the prefix supplied and then does a 'git push' to push the result to the repository and refspec. This can be used to push your subtree to different branches of the remote repository. +push-all:: + Perform a pull operation on all in .gittrees registered subtrees. - pull-push + split:: Extract a new, synthetic project history from the history of the prefix subtree. The new history -- 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
Am 21.11.2012 01:13, schrieb Lisandro Damián Nicanor Pérez Meyer: Well, two ideas come to my mind: - detect when using git flow (.git/config contains [gitflow some_branch] entries). Shouldn't it be part of the gitflow package then? - 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) As a general feature there could be a config option gitk reads with an ordered list of branch names (with wildcards). Those branches would always be printed in gitk as the leftmost branches (i.e. have their own lane on the left side). All other branches would be shown normally. This would give you part of what you want, a special lane at least for master and develop and for branches you can group under wildcard branch names (for example if you prefix all release branches with rel-). And it would give others the ability to make special branches in gitk more visible. (Yes I know, I'm talking again of stuff I won't have time or ability to implement ;-). Sigh) -- 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.
Am 30.10.2012 09:07, schrieb Mike Norman: Not seen any recently. I'm guessing the dev is in the path of hurricane Sandy? (Not sarcasm, btw.) Do you still see failures? I checked out the website just now and it seemed to work flawlessly (at least the links I tried, could not find any Sharing or Updating section). New design since I last visited, more end-user polish. -- 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: Support of '^' as alias for 'HEAD^'
Am 15.07.2012 00:24, schrieb Zeeshan Ali (Khattak): On Sun, Jul 15, 2012 at 12:26 AM, Junio C Hamanogits...@pobox.com wrote: Zeeshan Ali (Khattak)zeesha...@gnome.org writes: What about '^' and '^^' that I suggested? If you want a shortcut, you might try this: echo ref: HEAD .git/h Then you can use 'h' instead of 'HEAD'. Tested it and it seemed to work. If not someone on this list surely will correct me. -- 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: Problems pushing???
Am 08.07.2012 11:12, schrieb pbGit: http://www.petermac.com/setup-git-local-and-remote-repositories/ this . All The recipe at this address seems to have a --bare parameter missing at the git init in step 7 -- 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: Problems pushing???
Am 08.07.2012 17:43, schrieb pbGit: Just tried starting again on my local machine because when I tried pushing, git said that it local was also set to bare init. When I looked this was the case. Silly me. So I deleted on my local and added a single file and when I try pushing this I get the following: ! [rejected]master - master (non-fast-forward) error: failed to push some refs to 'paul@localhost:/Users/paul/prject' hint: Updates were rejected because the tip of your current branch is behind hint: its remote counterpart. Merge the remote changes (e.g. 'git pull') hint: before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details. When I try and pull I then get the following: fatal: No remote repository specified. Please, specify either a URL or a remote name from which new revisions should be fetched. I then addded my repo with the following command, but this is the wrong syntax!!! git pull --repo=project What the hell am I doing wrong??? This is the moment where you have to begin reading man pages, i.e. git fetch, git help pull, git help remote git help push (read the examples as they show typical use cases) or preferably read about it in books like Pro Git (git-scm.com/book/) or tutorials. For example the --repo parameter in git push --repo=project doesn't exactly do what you think it does. It only sets the default remote repo from origin to project. Normally you would just use git push project. And the equivalent pull command would be git pull project. Naturally you can configure that git pull or git push will just do what you want, but for that you need to know what a refspec is and how to use git remote. Generally git pull and git push are not complementary. Neither in effect nor in parameters they take. For example assume you have just cloned a remote repository. This will add configuration that connects both repositories and adds a default remote repo named origin and adds default refspecs git pull without parameters will then fetch all remote branches into correpondingly named local remote tracking branches (under .git/refs/remotes/, do a git branch -a to list them too), but then only merge one of them with the branch you are in at the moment. But git push will push *all* your local branches into branches of the same name on the remote repository. Another difference: If you pull, the merge might fail because of merge conflicts and you have to manually merge conflicting files. If you push, this manual merge is not possible so usually only trivial merges called fast-forward-merges are allowed. That is what happened on your push Something like git remote add -m master origin urlofyourrepo does the same configuration as a git clone would do and would allow you to just use git pull without parameters. -- 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
