Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

using crecord on a repo with already staged changes still shows those within crecord #52

Open
calestyo opened this issue Dec 16, 2023 · 7 comments

Comments

@calestyo
Copy link

Hey.

When using crecord on a repo with already staged changes it still shows those within crecord, which I guess is unnecessary.

Especially, it does not seem to have any effect when the already staged changes are unselected in crecord.

Cheers,
Chris.

@andrewshadura
Copy link
Owner

Actually, I’d argue that not having any effect when unselecting is the bug. My mental model has always been that crecord shows the difference between what’s committed and what’s in the working tree. I can’t remember why, though 🙂

@calestyo
Copy link
Author

Actually, I’d argue that not having any effect when unselecting is the bug.

Hmm, most git commands (in that area) typically operate either on the working directory or on the staging area.

So if crecord were to follow this concept, then I think it would be better to also show either only the unstaged differences or the staged differences.

@andrewshadura
Copy link
Owner

andrewshadura commented Dec 16, 2023

I’m not sure how that would work. For example, let’s say the user deselects everything. What should happen in that situation? I don’t think there’s an obvious thing git-crecord could do.

@calestyo
Copy link
Author

calestyo commented Dec 16, 2023

At least personally, I find it often useful to really consider the staged stuff as "checked that already... it's ready to be commited" ... and from that PoV its nice that it doesn't show up in e.g. git diff or difftool...

I’m not sure how that would work. For example, let’s say the user deselects everything. What should happen in that situation? I don’t think there’s an obvious thing git-crecord could do.

Not exactly sure what you mean now. My idea would be about like this:

When just calling git crecord:

  • It shows only the unstaged differences (as e.g. git diff does).
  • If I now select lines in crecord and do stage, those selected lines would be added to the staging area.
  • Lines that are not selected, are simply ignored.
  • If I select commit, than at least those lines would be committed, and I'd say additionally all that has already been staged before.

So c in crecord would rather act like a git add (i.e. stage) the selected lines and immediately git commit (plus everything that was already staged).

When calling git crecord --staged (or --cached):

  • It shows only the staged differences (as e.g. git diff --staged does).
  • If I now select lines in crecord and do stage, those selected lines would be added to the staging area. Lines that are unselected in crecord would be unstaged (but not deleted from the working directory), like e.g. git reset.
  • If crecord --staged and commit is used, I'd say it should do the "same" as add + commit, that is: lines that are (still) selected will be committed, lines that are (no longer) won't be commited.

    The only question here is: Will those lines, that have already been staged (we’re in --staged mode), but have been unselected and not commited, be still staged (just not commited)? Or will the be also unstaged?

    I tend to wish that this was configurable but default to the latter err I mean the former (i.e. still staged).

@andrewshadura
Copy link
Owner

So c in crecord would rather act like a git add (i.e. stage) the selected lines and immediately git commit (plus everything that was already staged).

Well, I think this would go against the idea that git-crecord directly shows the changes it is going to commit. I can try and make that a non-default mode, but I’m not sure it is a good idea by default.

@calestyo
Copy link
Author

calestyo commented Dec 16, 2023

Well, I think this would go against the idea that git-crecord directly shows the changes it is going to commit. I can try and make that a non-default mode, but I’m not sure it is a good idea by default.

Hmm I see... so I guess in the end that would mean three modes that could make sense:

  • the two I've described above
  • your's, which AFAIU would show staged and unstaged changes, and in which c would commit exactly what's selected, and in which s - I guess - would cause exactly what's selected to be staged afterwards and everything else to be unstaged?

@calestyo
Copy link
Author

I think I might have found another (current) bug which would apply to "your" concept (i.e. showing what get's actually committed/staged):

  • I have a working directory in clean state
  • add e.g. a single line to a file, and stage that
  • crecord would now show the line as one to be added
  • now remove the line again, but do not stage that
  • crecord shows nothing (it exits right away), so one cannot even commit or stage either with or without the new line

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants