On Sun, 5 Feb 2012, Ben Walton wrote: > Excerpts from Jakub Narebski's message of Sat Feb 04 14:45:53 -0500 2012: > > Hi Jakub, > > These items are as much about UI as anything else, I think. UI that > better helps users to know the state of their commits and branches can > only be a good thing. People that have used git for a while and are > comfortable with it may not see the need/point of these, but I think > they could both really help new users. As I said, 1500+ git users would like to have such feature, according to latest Git User's Survey. > > In Mercurial 2.1 there are three available phases: 'public' for > > published commits, 'draft' for local un-published commits and > > 'secret' for local un-published commits which are not meant to be > > published. > > How do you envision such a feature in git? > > A 'draft' commit (or chain of commits) could be determined from the > push matching definitions and then marked with simple decorations in > log output...This would extend the ability of status to note that your > are X commits ahead of foo. This would see any commit on a branch > that would be pushed automatically decorated with a 'draft' status. I think that in its basic form (treating all remotes equally) commits in 'public' phase would be those reachable from remote-tracking branches. Otherwise commits would be in 'draft' phase, unless explicitly marked as 'secret' (it we implement 'secret' phase, that is). The safety new I think of would (similarly to Mercurial phases) prevent or warn about amending published commit, and rebasing commits which were already published (in 'public' phase). That would require modifications to git-commit and git-amend, I think... Maybe even Git could refuse or warn on the local side about non fast-forward update of public branch, to help users of third-party tools. > > While default "push matching" behavior makes it possible to have > > "secret" commits, being able to explicitly mark commits as not for > > publishing might be a good idea also for Git. > > Do you see using configuration or convention to achieve this? > > For example, any branch named private/foo could, by convention, be > un-pushable without a force option? Alternately, a config item > similar to the push matching stuff to allow the users to designate > un-pushable branches could work too. I'm not sure, but the config item might be a good solution. Git would skip publishing 'secret' commits (commits from 'secret' branch) if it would otherwise publish it due to glob refspec, and refuse (or warn) publishing 'secret' branches explicitly. Currently if you use default "push matching", then those branches that you didn't push explicitly wouldn't be pushed. But that does not prevent pushing them by accident, and does not give UI to check if branch is private or not (e.g. to use in git-aware shell prompt). -- Jakub Narebski Poland -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html