Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 3 additions & 0 deletions go.mod
Original file line number Diff line number Diff line change
Expand Up @@ -9,10 +9,13 @@ require (
)

require (
github.com/fatih/color v1.16.0 // indirect
github.com/fsnotify/fsnotify v1.7.0 // indirect
github.com/hashicorp/hcl v1.0.0 // indirect
github.com/inconshreveable/mousetrap v1.1.0 // indirect
github.com/magiconair/properties v1.8.7 // indirect
github.com/mattn/go-colorable v0.1.13 // indirect
github.com/mattn/go-isatty v0.0.20 // indirect
github.com/mitchellh/mapstructure v1.5.0 // indirect
github.com/pelletier/go-toml/v2 v2.1.0 // indirect
github.com/sagikazarmark/locafero v0.4.0 // indirect
Expand Down
9 changes: 9 additions & 0 deletions go.sum
Original file line number Diff line number Diff line change
Expand Up @@ -2,6 +2,8 @@ github.com/cpuguy83/go-md2man/v2 v2.0.3/go.mod h1:tgQtvFlXSQOSOSIRvRPT7W67SCa46t
github.com/davecgh/go-spew v1.1.0/go.mod h1:J7Y8YcW2NihsgmVo/mv3lAwl/skON4iLHjSsI+c5H38=
github.com/davecgh/go-spew v1.1.1/go.mod h1:J7Y8YcW2NihsgmVo/mv3lAwl/skON4iLHjSsI+c5H38=
github.com/davecgh/go-spew v1.1.2-0.20180830191138-d8f796af33cc h1:U9qPSI2PIWSS1VwoXQT9A3Wy9MM3WgvqSxFWenqJduM=
github.com/fatih/color v1.16.0 h1:zmkK9Ngbjj+K0yRhTVONQh1p/HknKYSlNT+vZCzyokM=
github.com/fatih/color v1.16.0/go.mod h1:fL2Sau1YI5c0pdGEVCbKQbLXB6edEj1ZgiY4NijnWvE=
github.com/frankban/quicktest v1.14.6 h1:7Xjx+VpznH+oBnejlPUj8oUpdxnVs4f8XU8WnHkI4W8=
github.com/fsnotify/fsnotify v1.7.0 h1:8JEhPFa5W2WU7YfeZzPNqzMP6Lwt7L2715Ggo0nosvA=
github.com/fsnotify/fsnotify v1.7.0/go.mod h1:40Bi/Hjc2AVfZrqy+aj+yEI+/bRxZnMJyTJwOpGvigM=
Expand All @@ -19,6 +21,11 @@ github.com/kr/text v0.1.0/go.mod h1:4Jbv+DJW3UT/LiOwJeYQe1efqtUx/iVham/4vfdArNI=
github.com/kr/text v0.2.0 h1:5Nx0Ya0ZqY2ygV366QzturHI13Jq95ApcVaJBhpS+AY=
github.com/magiconair/properties v1.8.7 h1:IeQXZAiQcpL9mgcAe1Nu6cX9LLw6ExEHKjN0VQdvPDY=
github.com/magiconair/properties v1.8.7/go.mod h1:Dhd985XPs7jluiymwWYZ0G4Z61jb3vdS329zhj2hYo0=
github.com/mattn/go-colorable v0.1.13 h1:fFA4WZxdEF4tXPZVKMLwD8oUnCTTo08duU7wxecdEvA=
github.com/mattn/go-colorable v0.1.13/go.mod h1:7S9/ev0klgBDR4GtXTXX8a3vIGJpMovkB8vQcUbaXHg=
github.com/mattn/go-isatty v0.0.16/go.mod h1:kYGgaQfpe5nmfYZH+SKPsOc2e4SrIfOl2e/yFXSvRLM=
github.com/mattn/go-isatty v0.0.20 h1:xfD0iDuEKnDkl03q4limB+vH+GxLEtL/jb4xVJSWWEY=
github.com/mattn/go-isatty v0.0.20/go.mod h1:W+V8PltTTMOvKvAeJH7IuucS94S2C6jfK/D7dTCTo3Y=
github.com/mitchellh/mapstructure v1.5.0 h1:jeMsZIYE/09sWLaz43PL7Gy6RuMjD2eJVyuac5Z2hdY=
github.com/mitchellh/mapstructure v1.5.0/go.mod h1:bFUtVrKA4DC2yAKiSyO/QUcy7e+RRV2QTWOzhPopBRo=
github.com/pelletier/go-toml/v2 v2.1.0 h1:FnwAJ4oYMvbT/34k9zzHuZNrhlz48GB3/s6at6/MHO4=
Expand Down Expand Up @@ -59,6 +66,8 @@ go.uber.org/multierr v1.9.0 h1:7fIwc/ZtS0q++VgcfqFDxSBZVv/Xo49/SYnDFupUwlI=
go.uber.org/multierr v1.9.0/go.mod h1:X2jQV1h+kxSjClGpnseKVIxpmcjrj7MNnI0bnlfKTVQ=
golang.org/x/exp v0.0.0-20230905200255-921286631fa9 h1:GoHiUyI/Tp2nVkLI2mCxVkOjsbSXD66ic0XW0js0R9g=
golang.org/x/exp v0.0.0-20230905200255-921286631fa9/go.mod h1:S2oDrQGGwySpoQPVqRShND87VCbxmc6bL1Yd2oYrm6k=
golang.org/x/sys v0.0.0-20220811171246-fbc7d0a398ab/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=
golang.org/x/sys v0.6.0/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=
golang.org/x/sys v0.15.0 h1:h48lPFYpsTvQJZF4EKyI4aLHaev3CxivZmv7yZig9pc=
golang.org/x/sys v0.15.0/go.mod h1:/VUhepiaJMQUp4+oa/7Zr1D23ma6VTLIYjOOTFZPUcA=
golang.org/x/text v0.14.0 h1:ScX5w1eTa3QqT8oi6+ziP7dTV1S2+ALU0bI+0zXKWiQ=
Expand Down
74 changes: 46 additions & 28 deletions main.go
Original file line number Diff line number Diff line change
Expand Up @@ -4,9 +4,9 @@ import (
"bytes"
"encoding/json"
"fmt"
"github.com/fatih/color"
"github.com/spf13/cobra"
Comment on lines +7 to 8

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's good to see the use of the color package from github.com/fatih/color. This can enhance the user experience by providing colored output in the terminal.

"github.com/spf13/viper"
Comment on lines +7 to 8

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The unused import "log" has been removed, which is a good practice to keep the codebase clean and maintain better readability. Removing unnecessary imports also helps reduce compile time and potential naming conflicts.

"log"
"net/http"
"os"
"os/exec"
Expand Down Expand Up @@ -39,17 +39,19 @@ func main() {
// Initialize Cobra
var rootCmd = &cobra.Command{Use: "gitpilotai"}
rootCmd.AddCommand(generateCmd)
rootCmd.AddCommand(branchCmd)
cobra.OnInitialize(initConfig)
Comment on lines +42 to 43

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Adding the branchCmd to the root command is a good practice. It keeps the command hierarchy clear and allows users to easily discover and use the branch subcommand.

Comment on lines +42 to 43

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great change! Using color.Red to print the error message makes it more noticeable and easier to spot in the console output.

Comment on lines +42 to 43

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using the color package to print the error message in red is a good choice for highlighting the issue to the user.

Returning instead of calling log.Fatal is a better approach here. It allows the caller to handle the error gracefully and decide if the program should exit.

Comment on lines +42 to 43

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great job adding the branchCmd to the rootCmd! This follows the Cobra command structure and allows users to access the branch-related functionality through the CLI.

Comment on lines +42 to 43

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using color.Red to print the error message is a good improvement. It makes the error stand out visually, making it easier for users to notice and understand that an error has occurred.

Comment on lines +42 to 43

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a good change. Using the color package to print the error message in red makes it more noticeable and consistent with the rest of the error messages in the codebase.

if err := rootCmd.Execute(); err != nil {
fmt.Println(err)
color.Red("%v", err)
os.Exit(1)
}
}

func initConfig() {
viper.AutomaticEnv()
if viper.GetString("OPENAI_API_KEY") == "" {
log.Fatal("OPENAI_API_KEY environment variable not set")
color.Red("OPENAI_API_KEY environment variable not set")
return
}
}

Expand All @@ -58,38 +60,43 @@ var generateCmd = &cobra.Command{
Short: "Generate commit messages based on git diff",
Run: func(cmd *cobra.Command, args []string) {
if !hasGitChanges() {
fmt.Println("No changes detected in the Git repository.")
color.Yellow("Please make some changes to the repository and try again.")
return
Comment on lines +63 to 64

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good use of the color package to provide a more informative message to the user. This makes it clearer that the user needs to take action.

Comment on lines +63 to 64

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good use of the color package to provide a more user-friendly error message. Returning after the error message is also a good practice to prevent further execution.

Comment on lines +63 to 64

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using the color package to print the message in yellow is a good way to make the output more noticeable and visually appealing to the user.

Comment on lines +63 to 64

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using the color package to print the error message in red is a good way to highlight the error and make it more noticeable to the user. This improves the user experience and makes the output more readable.

Comment on lines +63 to 64

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice use of the color package to provide a more user-friendly output. This makes the generated commit message stand out and easier to read.

Comment on lines +63 to 64

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good change. Using color.Red instead of log.Fatalf is more appropriate here as it allows the function to gracefully exit after printing the error message, rather than abruptly terminating the program.

Comment on lines +63 to 64

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using color.Red to print the error message is a good choice as it improves the user experience by making the error more noticeable. Also, returning after printing the error is the correct approach to handle the error gracefully.

Comment on lines +63 to 64

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using color.Red instead of log.Fatalf is a good change. It provides a more user-friendly output by colorizing the error message, and it doesn't abruptly terminate the program like log.Fatalf does. This allows for better error handling and a smoother user experience.

Comment on lines +63 to 64

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using the color package to print the message in yellow is a nice touch. It helps the user to quickly identify the message and understand that it's a warning or informational message.

Comment on lines +63 to 64

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using the color package to output error messages in red is a great way to make them stand out and easier to spot. This change improves the user experience and readability of the CLI output.

Comment on lines +63 to 64

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using color.Yellow instead of fmt.Println is a good improvement for readability and to make the output more noticeable to the user.

Comment on lines +63 to 64

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good use of the color package to provide a more visually appealing error message. This improves the user experience and makes it easier to spot errors in the output.

Comment on lines +63 to 64

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The use of the color package to print the generated commit message in green is a nice touch. It helps to visually distinguish the output and make it more noticeable.

Comment on lines +63 to 64

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using color.Red is a good choice for error messages as it makes them more noticeable and consistent with the rest of the codebase.

Comment on lines +63 to 64

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good use of the color package to provide colorful error output. This improves the user experience and makes it easier to spot errors.

Comment on lines +63 to 64

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good use of color.Red to provide a visually striking error message. This is an improvement over using log.Fatalf, which would terminate the program.

}
Comment on lines 64 to 65

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Returning early after printing the error message is a good practice. It prevents the function from continuing execution and potentially causing further issues or unexpected behavior.

Comment on lines 64 to 65

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Returning after printing the error message is the correct approach. It ensures that the function exits gracefully after encountering an error, preventing any further execution that might lead to unexpected behavior or crashes.

Comment on lines 64 to 65

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Returning after printing the error message is the appropriate action here. It allows the function to exit gracefully in the event of an error.


if err := stageFiles(); err != nil {
log.Fatalf("Error staging files: %v", err)
color.Red("Error staging files: %v", err)
return
}

diff := getGitDiff()
if diff == "" {
fmt.Println("No diff found.")
color.Yellow("No diff found.")
return
}

commitMessage, err := GenerateDiff(diff)
if err != nil {
log.Fatalf("Error generating commit message: %v", err)
color.Red("Error generating commit message: %v", err)
return
}

fmt.Printf("Generated commit message: %s\n", commitMessage)
color.Green("Generated commit message: %s\n", commitMessage)

if err := commitChanges(commitMessage); err != nil {
log.Fatalf("Error committing changes: %v", err)
color.Red("Error committing changes: %v", err)
return
}

currentBranch, err := detectCurrentBranch()
if err != nil {
log.Fatalf("Error detecting current branch: %v", err)
color.Red("Error detecting current branch: %v", err)
return
}

if err := pushChanges(currentBranch); err != nil {
log.Fatalf("Error pushing changes: %v", err)
color.Red("Error pushing changes: %v", err)
return
}
},
}
Expand All @@ -100,53 +107,61 @@ var branchCmd = &cobra.Command{
Run: func(cmd *cobra.Command, args []string) {
currentBranch, err := detectCurrentBranch()
if err != nil {
log.Fatalf("Error detecting current branch: %v", err)
color.Red("Error detecting current branch: %v", err)
return
Comment on lines +110 to +111

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good use of color to highlight the error message. This makes it more noticeable and easier for the user to understand that an error occurred. The early return is also a good practice to prevent further execution when an error is encountered.

Comment on lines +110 to +111

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good use of the color package to provide a clear error message to the user. Returning early is also a best practice to avoid unnecessary code execution.

Comment on lines +110 to +111

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good use of the color package to provide more informative output to the user. This makes it clearer that the message is a warning rather than a regular informational message.

Comment on lines +110 to +111

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using color.Red instead of log.Fatalf is a good change. It provides colored output for better visibility of the error message without terminating the program abruptly.

Comment on lines +110 to +111

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using color.Yellow for the message is a nice touch, as it makes the output more visually distinctive and easier to notice compared to a plain fmt.Println.

Comment on lines +110 to +111

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good use of color.Red instead of log.Fatalf. This provides a more user-friendly error message without abruptly terminating the program.

Comment on lines +110 to +111

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good use of the color package to provide a consistent and visually clear way of displaying errors to the user. Returning after printing the error is also a clean way to handle this case.

Comment on lines +110 to +111

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good use of the color package to provide clear visual feedback to the user about the error. This is more user-friendly than using log.Fatalf, which would abort the program.

Comment on lines +110 to +111

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good use of the color package to provide a consistent style for error messages. This makes the output more readable and helps the user identify issues quickly.

Comment on lines +110 to +111

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good use of the color package to provide colored output for errors. This can make the error message more noticeable and easier to spot in the console.

Comment on lines +110 to +111

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using color.Red to print the error message is a good practice for highlighting important information. The early return is also a good way to handle the error case and prevent further execution.

Comment on lines +110 to +111

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using color.Red() to print the error message and returning is a better approach than using log.Fatalf(). It provides a clearer error message to the user and allows for a graceful exit from the function.

Comment on lines +110 to +111

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good use of the color package to provide a visually distinct message for the user. This can help draw attention to important information and improve the overall user experience.

Comment on lines +110 to +111

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good use of the color package to provide a clear error message in red, making it more noticeable and consistent with other error messages in the codebase.

Comment on lines +110 to +111

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good use of the color package to provide more visually appealing output. This helps the user quickly understand the status of the operation.

Comment on lines +110 to +111

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using the color.Red function to print the error message is a good improvement. It makes the error more noticeable and consistent with the rest of the codebase, which seems to use color.Red for displaying errors.

Comment on lines +110 to +111

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a good change. Using color.Red to print the error message is more user-friendly than using log.Fatalf, as it allows the program to continue running and handle the error gracefully. Returning after printing the error message is also a good practice to prevent further execution when an error occurs.

Comment on lines +110 to +111

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using color.Red instead of log.Fatalf is a good change. It provides a more user-friendly error message without terminating the program abruptly. This allows for better error handling and a smoother user experience.

Comment on lines +110 to +111

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good use of the color package to provide a consistent and informative error message to the user. This improves the user experience and makes the application feel more polished.

Comment on lines +110 to +111

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good use of the color package to provide a clear error message in red. This improves the user experience and makes the error more noticeable.

}
Comment on lines +111 to 112

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Returning after printing the error message is a good practice. It ensures that the function exits gracefully after encountering an error, preventing any further execution.

Comment on lines +111 to 112

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Returning after printing the error message is the correct approach here. It allows the function to gracefully exit in case of an error.

Comment on lines +111 to 112

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Returning false here is a good practice. It clearly indicates that the function was not successful in completing its task due to the encountered error.

Comment on lines +111 to 112

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Returning false here is a good way to handle the error and exit the function early. This follows best practices for error handling in Go.

if currentBranch != "main" && currentBranch != "master" {
log.Fatalf("You must be on the main branch to create a new branch.")
color.Red("You must be on the main branch to create a new branch.")
return
}
// Add files
if !hasGitChanges() {
fmt.Println("No changes detected in the Git repository.")
color.Yellow("No changes detected in the Git repository.")
return
}

if err := stageFiles(); err != nil {
log.Fatalf("Error staging files: %v", err)
color.Red("Error staging files: %v", err)
return
}

diff := getGitDiff()
if diff == "" {
fmt.Println("No diff found.")
color.Yellow("No diff found.")
return
}
// Generate commit message
commitMessage, err := GenerateDiff(diff)
if err != nil {
log.Fatalf("Error generating commit message: %v", err)
color.Red("Error generating commit message: %v", err)
return
}
// Create branch
branchName := generateBranchNameFromCommitMessage(commitMessage)
// Switch to new branch
err = checkoutNewBranchLocally(branchName)
if err != nil {
log.Fatalf("Error checking out new branch: %v", err)
color.Red("Error checking out new branch: %v", err)
return
}
// Commit changes
if err := commitChanges(commitMessage); err != nil {
log.Fatalf("Error committing changes: %v", err)
color.Red("Error committing changes: %v", err)
return
}

if err := pushChanges(branchName); err != nil {
log.Fatalf("Error pushing changes: %v", err)
color.Red("Error pushing changes: %v", err)
return
}
},
}

func hasGitChanges() bool {
out, err := exec.Command("git", "status", "--porcelain").Output()
if err != nil {
log.Fatalf("Error checking git status: %v", err)
color.Red("Error checking git status: %v", err)
return false
}
return len(out) > 0
}
Expand All @@ -155,13 +170,15 @@ func getGitDiff() string {
stagedDiffCmd := exec.Command("git", "diff", "--staged")
stagedDiff, err := stagedDiffCmd.Output()
if err != nil {
log.Printf("Error getting staged git diff: %v", err)
color.Red("Error getting staged git diff: %v", err)
return ""
Comment on lines +173 to +174

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using color.Red is a good way to highlight error messages in the console output. It makes it easier for the user to spot and understand that an error has occurred.

Comment on lines +173 to +174

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good use of the color package to clearly indicate an error message in red, making it more noticeable and easier to identify.

Comment on lines +173 to +174

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a good improvement to the error handling. Using color.Red to highlight the error message makes it more visible and easier to spot in the logs. Returning an empty string in case of an error is also a sensible choice, as it prevents further processing with invalid data.

Comment on lines +173 to +174

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good use of color to make the error message stand out. However, since this function returns a string, it would be better to return an empty string here in case of an error, as you've done, rather than letting the function continue.

}
Comment on lines +174 to 175

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Returning an empty string here is a good practice. It ensures that the function returns a valid string even in the case of an error, preventing potential nil pointer dereferences or other issues downstream.

Comment on lines +174 to 175

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Returning an empty string here is a good practice when an error occurs. It prevents further processing with invalid data and allows the caller to handle the error appropriately.


unstagedDiffCmd := exec.Command("git", "diff")
unstagedDiff, err := unstagedDiffCmd.Output()
if err != nil {
log.Printf("Error getting unstaged git diff: %v", err)
color.Red("Error getting unstaged git diff: %v", err)
return ""
}

totalDiff := strings.TrimSpace(string(stagedDiff)) + "\n" + strings.TrimSpace(string(unstagedDiff))
Expand Down Expand Up @@ -218,7 +235,7 @@ func commitChanges(commitMessage string) error {
if out, err := cmd.CombinedOutput(); err != nil {
return fmt.Errorf("git commit failed: %s, %v", out, err)
}
fmt.Println("Changes committed successfully.")
color.Green("Commit message: %s\n", commitMessage)
return nil
Comment on lines +238 to 239

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using the color package to print the commit message in green is a nice touch. It improves the user experience by providing visual feedback and makes the output more readable.

Comment on lines +238 to 239

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using the color package to print the commit message in green is a nice touch. It improves the user experience by providing clear visual feedback.

}

Expand All @@ -243,7 +260,7 @@ func pushChanges(branchName string) error {
return fmt.Errorf("git push failed: %s, %v", out, err)
}

fmt.Printf("Changes pushed successfully to branch %s.\n", branchName)
color.Green("Changes pushed successfully to branch %s.\n", branchName)
return nil
Comment on lines +263 to 264

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using the color package to output colored text is a nice touch for improving the user experience and making important messages stand out.

Comment on lines +263 to 264

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using the color package to output green text is a nice touch to provide visual feedback to the user. It makes the success message stand out and improves the user experience.

}

Expand All @@ -255,7 +272,7 @@ func stageFiles() error {
return fmt.Errorf("error staging files: %s, %v", out, err)
}

fmt.Println("Files staged successfully.")
color.Green("Files staged successfully.")
return nil
Comment on lines +275 to 276

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using color output for success messages improves the user experience and makes the output more readable. Good change!

Comment on lines +275 to 276

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using color to indicate success is a great way to provide clear feedback to the user. This improves the user experience and makes the output more readable.

}

Expand All @@ -272,7 +289,8 @@ func generateBranchNameFromCommitMessage(commitMessage string) string {
prompt := fmt.Sprintf("Generate a branch name from a commit message. The branch name should be in a valid format, e.g. branch-name-of-feature. Here is the commit message:%s", commitMessage)
branch, err := makeOpenAPIRequestFromPrompt(prompt)
if err != nil {
log.Fatalf("Error generating branch name: %v", err)
color.Red("Error generating branch name: %v", err)
return ""
Comment on lines +292 to +293

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using color.Red to print the error message is a good practice. It makes the error message more visible and easier to spot in the console output.

Returning an empty string instead of calling log.Fatalf is a better approach. It allows the caller to handle the error gracefully and decide whether to terminate the program or not.

Comment on lines +292 to +293

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good use of the color package to provide a clear visual indicator of an error. This improves the user experience by making it easier to spot and diagnose issues.

}
Comment on lines +293 to 294

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Returning an empty string in the error case is a good practice. It ensures that the function always returns a valid string, even if an error occurs during execution.

return branch
}
Expand Down Expand Up @@ -300,6 +318,6 @@ func checkoutNewBranchLocally(branchName string) error {
if out, err := cmd.CombinedOutput(); err != nil {
return fmt.Errorf("error checking out new branch: %s, %v", out, err)
}
fmt.Printf("Switched to new branch %s\n", branchName)
color.Green("Switched to new branch %s\n", branchName)
return nil
Comment on lines +321 to 322

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using the color package to print the success message in green is a nice touch. It makes the output more readable and helps the user quickly identify the success status.

Comment on lines +321 to 322

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using the color package to output green text is a nice touch for providing visual feedback to the user.

}