git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Git GSoC 2014

From
Ramkumar Ramachandra <artagnon@gmail.com>
Date
Feb 13, 2014, 23:17 UTC
Message-ID
<CALkWK0mR=9ZD256bHx9d=W9ayqn5bOETWBQLW_kvRSy-GeQK4Q@mail.gmail.com>
In-Reply-To
<20140213091037.GA28927@sigill.intra.peff.net>
Jeff King wrote:
>   - ideas ideas ideas
I'll throw in a few ideas from half-finished work.
1. Speed up git-rebase--am.sh

Currently, git-rebase--am.sh is really slow because it dumps each patch to a file using git-format-patch, and picks it up to apply subsequently using git-am. Find a way to speed this up, without sacrificing safety. You can use the continuation features of cherry-pick, and dump to file only to persist state in the case of a failure.

Language: Shell script, C
Difficulty: Most of the difficulty lies in "what to do", not so much
"how to do it". Might require modifying cherry-pick to do additional
work on failure.
2. Invent new conflict style

As an alternative to the diff3 conflict style, invent a conflict style that shows the original unpatched segment along with the raw patch text. The user can then apply the patch by hand.

Language: C
Difficulty: Since it was first written, very few people have touched
the xdiff portion of the code. Since the area is very core to git, the
series will have to go through a ton of iterations.
3. Rewrite git-branch to use git-for-each-ref

For higher flexibility in command-line options and output format, use git for-each-ref to re-implement git-branch. The first task is to grow features that are in branch but not fer into fer (like --column, --merged, --contains). The second task is to refactor fer so that an external program can call into it.

Language: C
Difficulty: fer was never written with the idea of being reusable; it
therefore persists a lot of global state, and even leaks memory in
some places. Refactoring it to be more modern is definitely a
challenge.
4. Implement @{publish}
(I just can't find the time to finish this)

@{publish} is a feature like @{upstream}, showing the state of the publish-point in the case of triangular workflows. Implement this while sharing code with git-push, and polish it until the prompt shows publish-state.

Language: C, Shell script
Difficulty: Once you figure out how to share code with git-push, this
task should be relatively straightforward.
Previous: Vicent MartíNext: Jeff King
Message 11 of 15 in “Git GSoC 2014”
  1. Jeff KingFeb 13, 2014
  2. Thomas RastFeb 13, 2014
  3. Junio C HamanoFeb 13, 2014
  4. Thomas RastFeb 14, 2014
  5. David KastrupFeb 14, 2014
  6. Thomas RastFeb 15, 2014
  7. Duy NguyenFeb 15, 2014
  8. David KastrupFeb 15, 2014
  9. Shawn PearceFeb 15, 2014
  10. Vicent MartíFeb 14, 2014
  11. Ramkumar RamachandraFeb 13, 2014
  12. Jeff KingFeb 14, 2014
  13. Ramkumar RamachandraFeb 14, 2014
  14. Jeff KingFeb 14, 2014
  15. Jeff KingFeb 14, 2014

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.