Showing posts sorted by relevance for query leftover bits. Sort by date Show all posts
Showing posts sorted by relevance for query leftover bits. Sort by date Show all posts

Friday, May 24, 2013

Git 1.8.3 and even more leftover bits

The 1.8.3 release has finally been tagged and pushed out to the usual places. Also the release tarballs at kernel.org are back.

For a list of highlights, please see the previous post on -rc2; not much has changed since then.

During the last development cycle including its pre-release feature freeze, a few more interesting topics were discussed, and at this moment there aren't actual patches or design work.

[Previous list of "leftover bits" is here]
  • "git config", when removing the last variable in a section, leaves an empty section header behind. Anybody who wants to improve this needs to consider ramifications of leaving or removing comments.
    Cf. $gmane/219524
  • [STARTED AND THEN STALLED] Add "git pull --merge" option to explicitly override configured pull.rebase=true. Make "git pull" that does not say how to integrate fail when the result does not fast-forward, and advise the user to say --merge/--rebase explicitly or configure pull.rebase=[true|false]. An unconfigured pull.rebase and pull.rebase that is explicitly set to false would mean different things (the former will trigger the "fast-forward or die" check, the latter does the "pull = fetch + merge".
    Cf. $gmane/225326
  • Teach more commands that operate on branch names about "-" shorthand for "the branch we were previously on", like we did for "git merge -" sometime after we introduced "git checkout -".
    Cf. $gmane/230828
  • Proofread our documentation set, and update to reduce newbie confusion around "remote", "remote-tracking branch", use of the verb "to track", and "upstream".
    Cf. $gmane/230786.

Wednesday, August 14, 2013

Delaying Git 1.8.4 by a week

It appears that we need to revert two topics that cause regressions before the upcoming 1.8.4 release.

  • There is a corner case bug in git stash.  Suppose you have a path that is a regular file (or a symbolic link) in the committed state. You change it to a directory in your working tree, and have various new files in it. Some of them may be tracked, while others may not be. You issue git stash. The command needs to match the path to the committed state, hence it needs to remove the directory to resurrect the path. The new files in the directory you have git added will be in the stash so they are OK, but what happens to the untracked ones? They are killed. The same issue exists if you turned a tracked directory into a file and run the command without first running git add.
    An attempted fix was to ask
    git ls-files --killed to see if such a path exists that will be lost, but it turns out that this makes the command unusably slow in certain directories with very many untracked files.
  • There was an attempt to save typing four capital letters "H", "E", "A" and "D" by instead allowing you to type "@", e.g. git log @. The idea may have been a good one, but the change was executed poorly and incorrectly triggered when it shouldn't (e.g. having a branch whose name is @/foo made it into HEAD/foo or something insane).

Because we have already passed -rc3, I'd feel safer to add another rc week before the final. Updated Git Calendar is here.

Both of these changes meant well, and because we are not reverting them due to design mistakes (i.e. we are not saying that "we do not ever want to have such a feature or fix in our system"), hopefully these can be redone properly after the upcoming release is done.

Some leftover bits (I'll add more to this list later).

  • [DONE] Find out where ls-files --killed is unnecessarily wasting time, and fix it. This is a prerequisite to resurrect the stash corner case fix.
    Cf. $gmane/
    232113
  • Refactor run_hook() interface to be truly reusable by codepath other than git commit, resurrecting a "how about this" patch sent in the past.
    Cf. $gmane/192806, $gmane/212284
  • [IN PROGRESS] Extend the upload-pack protocol to tell what symbolic ref points at which other ref by resurrecting the idea outlined in 2008.
    Cf. $gmane/102039
  • [IN PROGRESS] Rethink how name-hash keeps track of names of directories and actual files to help case insensitive filesystems. Since 2092678c (name-hash.c: fix endless loop with core.ignorecase=true, 2013-02-28), there appears to be no reason why a directory name has to be registered to the hash with a trailing slash, which is the root cause why directory_exists_in_index_icase() reads past the end of the buffer.
    Cf. $gmane/232822
  • [DONE] Look into cvsserver permission bits regression between 1.8.1 and 1.8.3.
    Cf. $gmane/234476
  • Look into pathspec-limited revision traversal regression between 1.8.3 and 1.8.4.
    Cf. $gmane/234462
  • Checking out a branch X that does not have directory D (or worse, has a file D), while you are in the directory D, may want to fail.
    Cf. $gmane/234905
  • Allow extra options to "ssh" invocation made from connect.c, in a way that (ideally) does not break backward compatibility.
    Cf. $gmane/234624
  • Perhaps add a --post-service-hook to the git-daemon that can be used after a service finishes? The exit status from the service process means totally different thing from what the user of service perceives because the former has to say "successfully told the requester that the request is denied", it may not be such a useful mechanism as one naïvely would expect, though.
    Cf. $gmane/
    234706
  • git checkout $commit -- somedir should remove somedir/file that is not in $commit but is in the original index.
    Cf. $gmane/
    234935

Friday, August 10, 2012

Leftover bits

While developing for Git, sometimes I find a topic getting "stuck" for various reasons, e.g. the basic direction is good, but the remainder of the system is not ready for such a change.

Instead of running "git branch -D topic" in such a case, I use a "git hold" alias that looks like this:

[alias]
  hold = "!sh -c 'git update-ref refs/hold/$1 refs/heads/$1 && \
          git branch -D $1' -"

to stash it away. And "git for-each-ref refs/hold/" gives me many such "held" topics.

Of course, without an active effort to go back, reconsider and prune from time to time, these things tend to accumulate. And today was a good day to review them for me. I found a couple of topics that may still be viable as my reward:
  • [DONE - will be in Git 2.0] Make "git add " notice removals of files in the named directories; after all "add" is not about "add files to git", but is "add the current state to the index", and the lack of files that previously existed is part of that state.
    Cf. $gmane/171811

  • [DONE] Allow "git log .." to mean "Give me a log of recent commits that touch my parent directory and what are under it". The current code instead insists that ".." could be both a revision range and a path and asks the user to disambiguate.
    Cf. $gmane/172619
I did not find major downsides on either of these topics after re-thinking the issues, and I didn't see any valid objections from people whose judgement I trust in the old discussions, either.

Perhaps I should try resurrecting them and see what happens.

Monday, February 18, 2013

The Maintainer's Life (1)

While I was getting interviewed for an article in the "Open Source community leaders" series on a Japanese trade publication (due to come out in many weeks), I was asked an interesting question:
What is your role in the community? What is your job?
My immediate reaction was "Huh?". The interviewer contacted me knowing that I am the Git maintainer. Don't all maintainers do more or less the same thing and operate more or less in the same way?

But here is my version of what I do, anyway. What I do fall into two categories.

One is what I do as a member of the Git development community like everybody else.
  • Triage end-user bug-reports into non-bugs and real bugs. Non-bugs may result in referring the user to an appropriate manual page, or may result in updates to the documentation. Bugs may result in fixes.
  • Read other end-user requests, ranging from "Help, I do not know what I am doing" to a solidly written feature requests. Again, many may result in referring the user to an existing documentation, some may result in real enhancements.
  • Design and propose fixes and/or enhancements (possibly inspired by end-user inputs above, or perhaps scratching own itch) to the community and discuss with the members to reach consensus. Post a series of patches to implement the design and get them reviewed by community members. With their help, polish the patches to perfection.
  • Participate in the discussion and the review process initiated by other community members who do the above.
The other is what I the maintainer alone does as the project leader.
  • Keep an eye on end-user reports and requests that haven't been responded, find somebody in the community (i.e. victims) who are knowledgeable enough to handle them, and redirect.
  • Accept the patches polished in the review process and manage releases.
An interesting thing to notice is that the latter, at least when expressed as a list of bullet items, is a lot smaller than the former. Strictly speaking, the "Keep an eye on leftover bits and redirect" item could be done by anybody in the community, and in fact we saw various people acting as capable project secretaries to do exactly that from time to time. Even though I rarely do a "grand redesign with a road-map toward the future", such a topic would not be done by me as the maintainer descending from above with an edict, but as a proposal by me as one of the members of the community (bullet 3 in the former list). Also, compared to less experienced community members, I find myself saying "Let's step back a bit" a lot more often, asking other participants in design discussions to temporarily free their thinking of whatever narrow problem description originally given by the proposer of the topic, and instead to view the issue with wider context in mind. That is not done as the maintainer, but as one of the more experienced members of the development community. Other experienced community members can and often do the same to inject sanity to ongoing discussions.

I think one of the biggest reasons why the community does not come to a screeching halt when I disappear for a few weeks is because there aren't many tasks only the maintainer is supposed to do in our community in the first place. Capable others can take over fairly smoothly while I am away, because no matter who the interim maintainer is, what other community members do do not change very much.

Perhaps what the maintainer does may be different from communities to communities. How does your community work?

Sunday, February 24, 2013

More leftover bits

I've spent the past few days to see if there were discussions that are worth salvaging but somehow petered out without reaching conclusion, veered into tangent, or did not even start.

I tried to be fairly thorough, but I am sure I have missed some. Note that I deliberately excluded ones that fall into the Nobody who knows what they are talking about has any idea how to approach this feature category. I also left out discussions that are fairly young, hoping that they will stay alive without me keeping track of them.
  • Teach "--first-parent" to "git rebase" to deal better with a history with (possibly evil) merges from side branches.
    Cf. $gmane/198516
  • More fixes to bring sanity to "git diff --no-index", some discussed in the thread are definitely worthwhile, while some others are not.
    Cf. $gmane/200769
  • The name sanitization code may be overly conservative.
    Cf. $gmane/200823
  • The behaviour of "git filter-branch" around annotated tag may be under-documented to cause misunderstanding on the user's part, or it could be simply buggy.
    Cf. $gmane/212353
  • Annotating a pair of commit objects and trigger interesting behaviour when they both appear in the history.
    Cf. $gmane/212570
  • Make it safer to export mandir, htmldir, etc. from the top-level to Documentation/ Makefile.
    Cf. $gmane/216222
  • Allow escaping glob metacharacters in .gitattributes.
    Cf. $gmane/212631
  • Remove contrib/ciabot/.
    Cf. $gmane/212649
  • The return value from getenv(3) may be volatile across calls.
    Cf. $gmane/212660
  • Support VPATH build
    Cf. $gmane/212744
  • Build on "custom comment char" to make it "custom comment prefix string", e.g. "## ".
    Cf. $gmane/213802
  • Serving "git archive" over smart-http.
    Cf. $gmane/213243
  • "git fetch --deepen"?
    Cf. $gmane/213180 $gmane/212950
  • Perhaps reword some questions from "send-email"
    Cf. $gmane/213233
  • Improve "git remote -v" output to show where these URLs come from?
    Cf. $gmane/213806
  • Perhaps add a robust "shell portability check" mode for test scripts?
    Cf. $gmane/214709
  • Perhaps treat failures to write to a hook process that did not consume its input as success?
    Cf. $gmane/213548
  • "git rm -u"?
  • Cf. $gmane/213993
  • "git submodule foreach --untracked"
    Cf. $gmane/214860
  • [DONE] Prepare to change the default behaviour when "git add -u/-A" is run without pathspec with Git 2.0
    Cf. $gmane/214822
  • Perhaps concatenate young and small packs into one as a cheap repack?
    Cf. $gmane/215288
  • Align the logic format-patch decides to omit S-o-b to that is used by cherry-pick and commit.
    Cf. $gmane/216026
  • Allow installation filemode to be tweaked.
    Cf. $gmane/215119
  • "git log --cc" without other diff format specifiers like --raw should imply "--cc -p".
    Cf. $gmane/215470
  • [DONE] Perhaps "git grep" may want to pay attention to --textconv.
    Cf. $gmane/215385
  • Perhaps forbid "log --graph --no-walk", as --graph is about connected history while --no-walk is about discrete points?
    Cf. $gmane/216083
  • Possible merge-recursive corner case bug?
    Cf. $gmane/216117
  • Complete smart HTTP protocol documentation?
    Cf. $gmane/216262
  • Perhaps include an artificial HEAD to a bundle when HEAD is not specified from the command line?
    Cf. $gmane/216401
  • Restructure the revision parsing loop in bundle.c:create_bundle() to remove duplicates correctly, e.g. "git bundle create t.bundle master heads/master"
    Cf. $gmane/225837
  • Come up with a better default selection logic than the tentative "use the remote-tracking branch of the destination" for --force-with-lease option
    Cf. $gmane/230483
  • Force "git format-patch" (or at least allow it to be configured back to normal, when the user wants to use nonstandard settings for other commands) to use standard --commit-abbrev and --no-numstat settings.
  • Discuss and decide if we want to choose between the "mode word" UI (e.g. "git submodule add") and the "mode option" UI (e.g. "git tag --delete") and standardise on one; if it turns out to be a good idea, devise the migration plan to break the backward-compatibility.
    Cf. $gmane/231478